Re: [GMG-Devel] CAPTCHA framework for your consideration

[Christopher Allan Webber]

Hey Ayleph!

ayleph writes:

> Hi Goblins!
>
> As some of you may know, I cobbled together a Google reCAPTCHA plugin a 
> while back. My reCAPTCHA solution was far from optimal. I basically 
> reimplemented the entire basic_auth plugin with customized views just so 
> I could add a bit of CAPTCHA code to a page and receive POST data back. 
> And the reCAPTCHA plugin couldn't be run alongside the basic_auth 
> plugin; to ensure that the CAPTCHA view showed properly, you had to 
> disable the basic_auth plugin.
>
> In the months since my first CAPTCHA attempt, I've been thinking a lot 
> about how to recreate my plugin in a more efficient way. Rather than 
> replacing the basic_auth plugin, it should supplement the basic_auth 
> plugin with only the CAPTCHA code. I think I've finally found a way to 
> make that happen that makes sense in a MediaGoblin sort of way, and I'd 
> like to present that for your consideration.

Woo!

> I. Basic Needs
> In my mind, a CAPTCHA plugin needs to perform two main functions. First, 
> it should display a CAPTCHA challenge on the appropriate view(s). 
> Second, it should provide a mechanism of validating the CAPTCHA 
> response, which probably requires analyzing some POST data of a form.

Yes.

> II. Hook it up
> In the world of Gnu MediaGoblin, we seem to handle this kind of stuff 
> with hooks. A simple template_hook should suffice for the function of 
> displaying a CAPTCHA challenge. To that end, I propose we add a 
> "captcha_challenge" template hook which can be placed wherever 
> appropriate. For a specific example, I would suggest adding it to the 
> register view [1], which would appear something like [2].
>
> The second function is a little trickier. A CAPTCHA plugin must process 
> POST data from a form with varying field names. A CAPTCHA plugin could 
> provide its own forms and views to accommodate these extra fields, but 
> this causes the CAPTCHA plugin to duplicate functionality (displaying 
> forms and views) that the basic_auth plugin already does. One option I 
> discovered was to allow appending fields to a form by adding a 
> @classmethod on the base form. However, it doesn't seem to be in the 
> spirit of the MediaGoblin codebase. The solution I've come up with is to 
> add an additional authentication hook. I propose we add an 
> "auth_captcha_challenge" authentication hook which passes the entire 
> request object to a plugin for CAPTCHA validation. There currently 
> exists an "auth_extra_validation" hook which I tried to use for this 
> purpose, but the "auth_extra_validation" only passes the registration 
> form object, and I need access to POST data for fields which don't exist 
> in the registration form. Because of this, I opted to create a dedicated 
> hook for CAPTCHA processing which passes the entire request object. I 
> propose to implement this hook into the base auth code [3].

So, one way to do things is to use hook_transform to actually subclass
the wtforms form into a *new* wtforms form, with the added fields.  I
think that's probably the cleanest method.  What do you think?

I'm all for adding captcha-relevant hooks though!  Probably adding both
is worthwhile.

> III. Summary of proposed changes
> To ease the creation of various CAPTCHA plugins, I would like to 
> implement two changes into the MediaGoblin infrastructure. First, I 
> would like to add a "captcha_challenge" template hook which can be used 
> to add CAPTCHA code to a page. Second, I would like to add a 
> "auth_captcha_challenge" authentication hook which will actually perform 
> the CAPTCHA validation. I have compiled these changes (along with basic 
> API documentation for the auth_captcha_challenge hook) in a branch for 
> your consideration [4].

Again, all for adding the hooks.  It would be good to have the same
hooks that recaptcha works with and have a builtin free software only
captcha solution.  I have an idea for this... I will spit it out in a
separate reply from this one though.

> IV. Proof of concept
> The branch linked below [4] and an updated Google no CAPTCHA reCAPTCHA 
> plugin (thanks to yanosz on GitHub for his contributions) are running on 
> a test instance of mine [5]. However, there is currently a bug in the 
> CAPTCHA plugin which causes it to fail if you're blocking scripts on the 
> domain, so please be aware that the server error is due to a bug in the 
> CAPTCHA plugin itself, not in the template or authentication hook 
> implementation.
>

Great!