#222: Include Captcha Support

Contents

1. Definitions
2. Motivation
3. Assumptions
4. Proposal
5. Implementation
6. Deliverables
7. Risks
8. Progress log
9. Participants

Proposed by

Jon Stahl

Seconded by

Alexander Limi

Proposal type

Architecture

State

being-discussed

Definitions

CAPTCHA - Completely Automated Public Turing test to tell Computers and Humans Apart.  From Wikipedia:

 A CAPTCHA (IPA: /ˈkæptʃə/) is a type of challenge-response test used in computing to determine whether the user is human. The process involves one computer (a server) asking a user to complete a simple test which the computer is able to generate and grade. Because other computers are unable to solve the CAPTCHA, any user entering a correct solution is presumed to be human. A common type of CAPTCHA requires that the user type the letters of a distorted image, sometimes with the addition of an obscured sequence of letters or digits that appears on the screen.

Motivation

Plone sites that allow open registration are starting to occasionally see automated mass registration of users.  While this doesn't seem to be readily abusable (if email-the-password is turned on), it's a disturbing annoyance, especially to new Plone site administrators.

Other common problems include comment spam (if anonymous commenting is enabled) and abuse of the "E-mail this page" and contact forms.

Fortunately, these problems can be easily addressed with a simple CAPTCHA.

Assumptions

Any captcha implementation must have strong accessibility for visually impaired users.

Captchas should be enabled by default, but there should be a control panel configlet with an option to disable the captchas.  Captchas should be disabled by default on migrated sites, so as to avoid breaking validations of customized forms.

Captcha implementation should not depend on external webservices such as Captchas.net by default (though ideally a plugin system would make it possible to optionally switch to such services).

Proposal

We propose taking the following steps:

1. Add captcha to the following forms:
   
   • join_form
   • contact-info
     
   • comments
     
   • sendto_form
2. Standardize upon the interface of collective.captcha's @@captcha browser view as an interface which can be employed by other captcha products intending to replace collective.captcha.  This browser view provides the following methods:
   
   • image_tag - Returns the HTML img tag for the captcha.
   • audio_url - Returns the URL for an audio version of the captcha.
   • image - Renders the captcha image.
   • audio - Renders the captcha audio.
   • verify - Returns a boolean indicating whether user's input matched the captcha.
     

Implementation

Preferred implementation:

•  Integrate Jarn's Collective.Captcha into the Plone core.  It's a modern, Zope 3-style Product that provides:

A view to generate a captcha image and/or wav file, and to verify user input against it.

A cookie is used to transfer state from one request to the next. The state is used, together with a server-side secret, to create a random string of characters, which in turn is displayed as a captcha image, or transformed to an audio file. Verification happens case-insensitively.

Note that the captcha 'word' is only usable for 5-10 minutes, after which the view will not accept it any more. Moreover, a different word will be generated for a given session key every 5 minutes.

This makes these captchas replayable for up to 10 minutes if a determined user keeps sending the same session id. Because of the server-secret though, captchas are not transferrable between sites.

Pros:

• It exists, and it works.
• No dependency on an external service.
• Provides an audio version of the captcha.
  

Cons:

• SkimpyGimpy produces slightly ugly captcha images (but this can be somewhat mitigated by careful choice of font & configuration options).

Other possible implementations:

• We could use an alternative "mathemtical captcha" implementation, e.g. http://www.mysoftparade.com/blog/improved-mathematical-captcha/
  
  • Pros: strong accessibility, lightweight (no images)
  • Cons: ?

•  We could write a PIL-powered image captcha. perhaps http://blog.objectgraph.com/2007/01/pil-on-captcha-transparency-and-masking.html would be a good example.

If we go with the preferred implementation, such alternative implementations could be swapped in by creating a product which overrides the @@captcha view in a browser layer.

Deliverables

1. Move collective.captcha to the plone svn repository, rename it to plone.captcha.skimpygimpy, and ship it with Plone.
2. Add a plone.captcha egg which has a view to generate the (i18nized) captcha field, and a captcha validator, both of which defer to the @@captcha view from plone.captcha.skimpygimpy for the actual logic.
   
3. Modify the following forms in CMFPlone to use the field and validator from #2.
   
   • join_form
   • contact-info
     
   • comments
     
   • sendto_form
4. Add an "Enable CAPTCHA for anonymous users" option to the Security configlet, which determines whether captcha is actually used on the forms in #3.
5. Migration to ensure captcha is disabled by default for migrated sites.
   
6. Unit and functional tests of all functionality.
7. Documentation of how to swap in a different captcha service by overriding the @@captcha view.
   

Risks

• Captchas are inherently non-cachable, so we need to make sure that common Plone caching solutions don't try to cache any forms which include captcha.
• Collective.captcha does not currently generate captchas in non-Roman alphabets.
  

Progress log

Participants

 David Glick (ONE/Northwest) [davisagli] -- I can do the implementation work if we have consensus on this.