incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <>
Subject Re: CAPTCHA handling -- quick update
Date Tue, 05 Jan 2010 16:10:55 GMT
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).


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