incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janne Jalkanen <>
Subject Re: CAPTCHA handling -- quick update
Date Thu, 07 Jan 2010 08:26:09 GMT

Errr... How do we determine what is a previous post? Spambots tend to  
make each request from a  different address and ignore cookies. Or is  
it so that if the post is determined to contain spam, you get a  
redirect to the editor page, but this time with a captcha? 'cos that  
would be really nice, since it allows you to re-edit the content.


On Jan 5, 2010, at 18:10 , Andrew Jaquith wrote:

> Small correction (this is what happens when you type too quickly) --
> CAPTCHAs are rendered, by default, ONLY if the previous post contains
> spam. The missing "only" makes all the difference. :)
> The important point is that we are treating spam, essentially, as a
> form validation error.
> If you don't submit spam, it won't produce a validation error, so you
> won't see a CAPTCHA. (Unless the JSP requires it, for example, when
> creating a user account).
> Andrew
> On Tue, Jan 5, 2010 at 10:46 AM, Andrew Jaquith
> <> wrote:
>> Hi all --
>> Just thought I'd send a quick update on CATPCHA. Janne and I have had
>> some back-channel conversations about enhancements that I needed to
>> make.
>> Functionally, here's how the revised system will work:
>> - CAPTCHAs will be rendered on the same page as the submitting form,
>> but by default if the previous post contains spam (this is in line
>> with Janne's comments)
>> - CAPTCHA-rendering will be the responsibility of the  
>> wiki:SpamProtect
>> tag (as before)
>> - wiki:SpamProtect must be added as a child of a form or stripes:form
>> element (as before)
>> - If the JSP author wishes, they may require a CAPTCHA by adding an
>> attribute challenge="captcha" to the SpamProtect tag (new)
>> - In addition, a form can require password confirmation by adding
>> attribute challenge="password" to the SpamProtect tag (new)
>> - All of the back-end processing will be done by SpamInterceptor, in
>> collaboration with the content-inspection system (as before)
>> - Stripes ActionBeans that require spam protection need only add a
>> @SpamProtect annotation to the target event methods (as before)
>> We will add the SpamProtect tag to the page-edit form, comment form,
>> new user registration form, and user profile form. For new user
>> registration, a CAPTCHA will likely be required (challenge=captcha).
>> For user profile changes and post-install wiki configuration (coming
>> soon!), the user's password will be required to confirm
>> (challenge=password).
>> So, that's the functional design -- nice and simple. And we knock out
>> some JIRA bugs while we're at it (e.g., confirm password for account
>> changes)...
>> Andrew

View raw message