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

On Dec 21, 2009, at 13:11, Janne Jalkanen <ja...@ecyrd.com>
wrote:
> 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.

Sorry -- I have been working hard to eradicate the top-level JSP
scriptlet code. I wanted to get something decent and working (albeit
not perfect) checked in so that it could be refined.

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

I am particularly proud of the AsirraCaptcha implementation. It
replaces a bunch of crapply JavaScript with something that we can
completely control (and skin). In particular I hated the recommended
practice of causing the Asirra submit button to JavaScript-submit the
containing form. I had to reverse-engineer it to make it do cat-
checking server-side, but that was easy enough.
>
> Not all things that are commonly done are the best possible. I think
> our way was actually better, because it

In the case of page-edits, I can see your point of view. A challenge-
after-post model might make sense. But for self-registration of user
profiles, I think the CAPTCHA needs to be on the same form.

So we should probably support both models.

> The whole thing was *thought out*.

Although in your commit notes, you said you had to do some things you
"weren't proud of." ;) *twinkle*

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

That is a good idea... but we'd need to think about how/when a bit  
more...

> /Janne

So here is what we should do. The Captcha code itself is now nicely  
modularized. It would be easy to invoke it (1) either on the original  
form or (2) afterwards, on a form that the user is forwarded to after  
the post. I suspect the easiest thing to do is to extract the Captcha- 
generating code from SpamProtectTag and put it in a new CaptchaTag  
class, which the JSP author could include (or not). SpamInterceptor  
would know whether to forward to a dedicated CAPTCHA page depending on  
whether the relevant (hidden) CAPTCHA parameters were included with  
the POST. (Presence of CAPTCHA params means the params was on the form  
and we can process them now; absence means forward to Captcha.JSP as a  
separate step -- if a CAPTCHA is really needed.)

So, from a JSP perspective things would stay pretty simple. Just add  
wiki:Captcha to the JSP if you want it always on that form; otherwise,  
we'll know we need to forward the user to a dedicated page afterwards  
if the content inspection evaluation calls for it.

Either way, the coding won't be too complicated...