This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Since the answer to the secret question is as good as having the password associated with the user, why can't I use AbstractProcessingFilter as follows:

The AbstractProcessingFilter is launched when a URL is requested (that is different from the URL watched by the regular username/password processing filter i.e. AuthenticationProcessingFilter).

Filter extracts username and secret answer from request.

If unsuccessful, we go to failureUrl.

If successful, the overridden successfulAuthentication method does NOT put the authentication into the context. It skips that step. I read that a best practice is to not allow the user to change his password immediately after a successful secret question challenge. We just go to the defaultUrl (which says an email has been sent containing a link to reset the password, blah, blah, blah).

Most forgotten password type use cases are implemented without modifying any Acegi Security code. The general approach is to write your own MVC controller that responds to the token emailed to the user, and after the token is validated from some database or hash-based system, guide the user through changing their password and then putting a new Authentication object inside SecurityContextHolder. You might like to consider 0.9.0 / CVS' Captcha support, which increases the robustness of the emailed tokens as it requires a human operator to be detected.