sounds good to me thanks, Harry
2010/1/5 Andrew Jaquith <[email protected]> > 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 > > >
