Re: svn commit: r892689 - in /incubator/jspwiki/trunk: ./ etc/ src/WebContent/ src/WebContent/templates/default/ src/java/org/apache/wiki/ src/java/org/apache/wiki/action/ src/java/org/apache/wiki/content/ src/java/org/apache/wiki/content/inspect/ sr

[Andrew Jaquith <an...@gmail.com>]

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
<ja...@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, ajaquith@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).
>
>

Re: svn commit: r892689 - in /incubator/jspwiki/trunk: ./ etc/ src/WebContent/ src/WebContent/templates/default/ src/java/org/apache/wiki/ src/java/org/apache/wiki/action/ src/java/org/apache/wiki/content/ src/java/org/apache/wiki/content/inspect/ sr

[Janne Jalkanen <ja...@ecyrd.com>]

> The code looks otherwise good, but I just thing it breaks down a good model and replaces it with an inferior one.

...and you can tell that I'm tired by the fact that this came out all wrong too.

I meant that the captcha-after-post is a better model than captcha-in-post, and that should not be replaced, and that the code is otherwise well refactored.

/Janne

Re: svn commit: r892689 - in /incubator/jspwiki/trunk: ./ etc/ src/WebContent/ src/WebContent/templates/default/ src/java/org/apache/wiki/ src/java/org/apache/wiki/action/ src/java/org/apache/wiki/content/ src/java/org/apache/wiki/content/inspect/ sr

[Janne Jalkanen <ja...@ecyrd.com>]

> 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.

Sorry, didn't mean to comment on your code in particular - I just wanted to vent my frustration at the generic intellectual laziness of many people who just slam a captcha on their blog or web site and thinks that solves everything.  I've fought so many bad captcha implementations or totally indecipherable pieces of text that I am often repulsed and leave the site in disgust.

I really, really dislike that, and I was *proud* of the way our Captcha worked in a completely nondisruptive way, and I was very surprised to see it removed without a warning, question, or even a review request.

The code looks otherwise good, but I just thing it breaks down a good model and replaces it with an inferior one.

> 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.

Not all things that are commonly done are the best possible. I think our way was actually better, because it
* is less disruptive to the edit flow
* makes the editor display smaller and less complex
* allows for use of really complicated captchas (like Asirra), or even multi-step or off-site captchas
* works well with a spam filtering system which can score (we can do multiple levels, e.g. "no spam", "check with captcha", "check with really complex captcha", "spam, no need to even ask")
* slows down a spammer (as he can't simply just keep retrying a simple POST, he needs to go build a fairly complicated engine to follow through this one).
* it is a clear competitive advantage against other wiki systems with technically inferior spam/captcha solutions

The whole thing was *thought out*.

> 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.

Why is that better? Adding Asirra on the editor screen makes it simply HUGE, and makes editing really hard (in order to save, your click count goes through the roof - you need 400% more clicks just to save a page.)

Our spam filtering is already extremely efficient (stops several hundred spam edits on jspwiki.org every day).  I don't see why we should add extra burden on the user when we already have very good automatic methods?

> 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.

The reason why I thought the workflow classes would be useful is that we could also flag potential spam edits into the workflow acceptance queue. So either the edit acceptance could be done by a moderator or a captcha.  Or even both.

But as I said, I don't really understand the workflow classes at all, so your proposed solution sounds much better. :-)

/Janne