On Dec 21, 2009, at 13:11, Janne Jalkanen <[email protected]> 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...
