Janne,
Please don't use inflammatory language like "intellectually bloody
lazy" and "slap a captcha on" to characterize what I've done. Do not
denigrate my hard work that way, please. That is rude, especially
since you do not seem to have actually looked at the code.
The idea with the revised CAPTCHA system is -- indeed -- to put it on
the same form as the editor. That's quite common (and expected!) with
many blogs these days -- as you noted. I don't perceive that as
disruptive in the way that you seem to.
However, I agree that not everyone will need to see a CAPTCHA, because
(for example) they don't seem to have been a bot based on previous
edits. Right now, a CAPTCHA is inserted by the wiki:spamProtect tag
when the policy for the target ActionBean demands it
(Captcha.Policy.ALWAYS). A "dynamic" or "karma" policy is highly
desirable but I haven't been able to write the code for that yet.
Now, the question is, should we put a CAPTCHA on the same screen as
the editor (dynamic or not), or forward the user to a challenge
CAPTCHA later? I think it's better to put it on the same screen
("CAPTCHA-with-post"), rather than the "CAPTCHA-after-POST" process
like the one you suggested.
But if we did a CAPTCHA-after-POST, it would logically be done via the
SpamInterceptor (which would return a ForwardResolution to a Captcha
display JSP if the threshold was exceeded). The workflow classes
aren't useful for something like this.
Andrew
On Mon, Dec 21, 2009 at 2:52 AM, Janne Jalkanen
<janne.jalka...@ecyrd.com> wrote:
>
> Hey, does this mean that the captcha is now a part of the edit page? If so,
> let's reconsider. Captchas as a part of the edit process are a BAD IDEA (even
> though they're used quite a lot), since they disrupt the edit experience, and
> increase the participation threshold. It's intellectually bloody lazy to
> just slap a captcha onto every editor, which is exactly what I've tried to
> avoid building the Captcha system for JSPWiki.
>
> The idea of Captcha.jsp is that IF we suspect that you're a bot (through the
> context examination system), THEN you are redirected to a custom workflow
> which ensures that you're a human. Unfortunately, the captcha system was
> never rewritten as a workflow, since the spam protection predates that code.
> I think it would be much better if it we did that. Unfortunately, I don't
> understand the workflow system at all (despite reading the documentation
> several times), so I can't help you much there :-(
>
> /Janne
>
> On 21 Dec 2009, at 07:21, ajaqu...@apache.org wrote:
>
>> Author: ajaquith
>> Date: Mon Dec 21 05:21:24 2009
>> New Revision: 892689
>>
>> URL: http://svn.apache.org/viewvc?rev=892689&view=rev
>> Log:
>> CAPTCHA has been re-written. It has been integrated into the new
>> content-inspection system and is pluggable. ActionBean event handler methods
>> that need CAPTCHA can simply add (1) a @SpamProtect annotation to the method
>> declaration and (2) a <wiki:SpamProtect/> tag inside the corresponding JSP
>> <s:form> or <form> elements. Unlike the old Captcha.jsp (which is
>> eliminated), the new system adds CAPTCHA elements right onto the form that
>> is being protected (via the SpamProtect tag). The new Captcha interface
>> specifies the contract that implementations must fulfill. One CAPTCHA
>> implementation is provided, AsirraCaptcha. ReCaptcha is likely, and will
>> come later. More polish (i18n, CSS, JSP formatting, Install configuration)
>> is is needed, but the current checkin works now, and will get us started. I
>> intend to add dynamic CAPTCHA at a later point (e.g., less trustworthy
>> users always get a CAPTCHA to start, etc).
>
>
