Errr... How do we determine what is a previous post? Spambots tend to
make each request from a different address and ignore cookies. Or is
it so that if the post is determined to contain spam, you get a
redirect to the editor page, but this time with a captcha? 'cos that
would be really nice, since it allows you to re-edit the content.
/Janne
On Jan 5, 2010, at 18:10 , Andrew Jaquith wrote:
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
