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 <[email protected]> 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 >
