incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <andrew.r.jaqu...@gmail.com>
Subject CAPTCHA handling -- quick update
Date Tue, 05 Jan 2010 15:46:29 GMT
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
View raw message