I am a member of the JCaptcha team, and we have planned to release a new JCaptcha-module in order to integrate it with Acegi.
We are so honored that you think about it too!
Our plan is to provide a standard way to ckeck user humanity, which can be needed in many situations (posting comment, registering, login, ect...)
This implies many uses cases that are sum up here :
http://forum.springframework.org/viewtopic.php?t=4106
This thread explain also the proposed solution and the implementation details.
What do you think about it?
We have still some issues about re-post.
Ben Alex told me recently that the API is now stabilized and thus we planned to share our code before two weeks and release it this summer.
What is your opinion about the plan?
Best regards
Marc-Antoine
On 6/24/05, George Franciscus <[EMAIL PROTECTED]> wrote:
I had been reading about Captcha recently, so this JIRA caught my eye.
http://opensource.atlassian.com/projects/spring/browse/SEC-2
I thought I would float my thoughts here on implementing this in Acegi. Here
it goes ...
I'm assuming there are two use cases. (1) user need to defeat the captcha
challenge without logging in. This would be the case where for example
someone was registering for an email address (2) user needs to defeat the
captcha challenge as part of the login process. For example, this might be
used to protect against a dictonary attack. In either case, I think a single
solution accomodates both. jCaptcha seems to be the popular way to doing
Captcha. Here's how it works
1. user requsts a page. The page has an <img> tag that points to a JCapatcha
servlet that create an image with a distorted word on it. The page has a
input box for the user to input the word on the image. The http session id
is used as the key to generate the image from a jCaptcha singleton
2. the page is submitted
3. server side the request is intercepted and the response to the challenge
is passed to the jCaptcha singleton, along with the session id, to verify if
the response is correct. It appars to work like a hash of sorts.
4. if the response is not correct, then direct the response to the challenge
page again. If its good, then process the request.
Here's my proposal for a solution
A. Build a page as describe in #1.
B. Use a filter to intercept the request. If the request contains a
parameter holding the challenge response, then got to C. Othewise let it
process the rest of the chain.
C. If the challenge needs to be processed, then verify its true by calling
the singleton
D. If the challenge is not defeated, then send the response back to an entry
point.
Implementation Details
* create a CaptchaFilter interface to support any captcha implementation
* create a AbstractCaptchaFilter class to provide base logic ... like
checking for the input parameter and calling an abstract isValid method. It
also calls the entry point on a failure.
* Create a JCaptchaFilter to extend AbstractCaptchaFilter. This class
provides a implementation specific logic for jCaptcha ... specifically the
isValid call to the jCaptcha singleton and the implementation to get the key
(usually session.getId()), but this could be overriden here.
* In addition, a JCaptchaAuthenticationExcception that extends
AuthenticationException is required to round things out.
I've got a prototype working. Does anybody see flaws here? What's the next
step to moave things forward?
~~George
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Home: http://acegisecurity.sourceforge.net
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
--
Best regards.
Marc-Antoine Garrigue
