incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harry Metske <harry.met...@gmail.com>
Subject Re: CAPTCHA handling -- quick update
Date Tue, 05 Jan 2010 17:55:30 GMT
sounds good to me

thanks,
Harry


2010/1/5 Andrew Jaquith <andrew.r.jaquith@gmail.com>

> 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
> <andrew.r.jaquith@gmail.com> 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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message