Colin Sampaleanu wrote:
I was taking a look at the LoginInteceptor in AppFuse,
http://static.raibledesigns.com/downloads/struts-resume/api/org/appfuse/webapp/filter/LoginFilter.java.html
which uses a cookie to remember the user for auto-login purposes, and was thinking that it's probably worth adding some cookie based support to the Acegi Framework for both remember-me functionality in terms of just remembering the login name, and also complete auto-login. Now the former can of course be done mostly by just using code in the login page, but there's something to be said for integrating this into the framework. Ditto for the idea of the framework knowing whether somebody logged in explicitly or via a cookie. This is similar to Amazon knowing who you are immediately, but forcing you to log in again for certain actions.
Colin
Hi Colin
Yes, it would be a good addition.
How about a filter which reads an Acegi client-side cookie which contains the user's username, last "interactive" login time and a hash code? The hash code being the hash of the user's password + last interactive login time + a "remember me" system-wide password. The filter would go directly to an AuthenticationDao to lookup the true password and detect if the presented hash code is valid. If so, it would product an Authentication request token and put it into the HttpSession. A new "interactiveAuthentication" property would be available on Authentication objects. This would be set to the correct date by a relevant net.sf.acegisecurity.ui class. In the case of the "remember me" filter, it would be the date presented in the cookie and confirmed by the hash code comparison. AuthenticationProviders would simply return the same date in its response Authentication object, thus enabling voters etc to consider the date of the last true interactive authentication. A time-based voter could be written that throws an AuthenticationException if the Authentication.getInteractiveAuthentication() is older than a defined period.
In terms of originally setting the cookie, the AuthenticationProcessingFilter could be modified to detect a defined value in the submitted form and set a cookie accordingly.
On SourceForge (http://sourceforge.net/docman/display_doc.php?docid=759&group_id=1#semilogin) they distinguish between unauthenticated, recently authenticated, and "remember me" authenticated. Only recently authenticated is allowed for sensitive operations. We'd be achieving the same functionality AFAICS with the changes above.
The benefits of a hash-code based cookie such as the above include reliable representation of the last interactive authentication date, being able to invalidate all "remember me" cookies on issue (by changing the system-wide "remember me" password), ensuring the user's real password is never stored in a browser cookie, and still providing the user a reasonable compromise between the convenience of "remember me" cookies not breaking if a password is changed versus being able to change a password to remedy a "remember me" cookie being inadvertently left on an untrusted machine.
Would this meet everyone's anticipated needs?
On a related issue, how do people feel about Acegi Security offering the other related functions of lost password recovery and password changes? Lost password recovery would of course email an unlock code to force the user to change their password after entering an obfuscated graphic's value (preventing brute force attempts and ensuring users are aware of someone unlocking their account). I'm currently doing some work on Spring RCP (yes, Acegi Security is almost fully integrated now) and it would be good to be able to offer some unified (web and rich client) lost password recovery and password changing solution.
Ben
------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
