[Acegisecurity-developer] Support for HTTP request memento in Form Authenticator
Hello, I've been looking through the AuthenticationProcessingFilter source in Acegi Security, and I haven't seen support for storing a memento of the original HTTP request in the session, providing the ability to let a user re-authenticate without losing the original HTTP post parameters in the event of session expiration. Is this available in Acegi Security and I'm just not seeing its implementation? As a side note, Apache Tomcat 5.5.9 does provide this support in its container managed authentication. See the "authenticate" method. http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/FormAuthenticator.java?rev=1.23&view=markup If this feature is not currently available in Acegi Security, is there interest in adding (configurable) support for it to the AuthenticationProcessingFilter? I could see reasons for NOT wanting to use this (e.g. session creation denial-of-service attacks), but in other situations it can be useful. Thanks, Curtis --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
[Acegisecurity-developer] Support for HTTP request memento in Form Authenticator
Curtis Light wrote: Please let me clarify: the authentication information itself would never be stored--just the last attempted POST in the event of session expiration. I'm looking for a mechanism instead that will save a memento of the content of a regular HTML form if the user takes too long to complete and submit the form. If the user takes 16 minutes to fill out a form, but the session only lasts 15 minutes, then the posted form data would be lost. I've seen this implemented in a hand-rolled fashion before. The servlet would check to see if a session exists for each HTTP POST. If the session does exist and the user has been authenticated, then the servlet processes the transaction normally. However, if the session does not exist, the servlet would create a new session and store those parameters in the new session. The servlet would then display a login page and prompt for reauthentication. After reauthenticating, the servlet would pull the original POST parameters out of the session, and it would process them just as it would if the reauthentication was not required. I realize that this may cause a creation of a session that could open the door for a denial of service attack, so an alternative to this method would be encoding the HTTP POST content into a Base64-encoded string and passing it to the login screen in a hidden field. That gets around the need to create a new session upon the receipt of any post. Most people get around the session timeout issue via these common approaches: - Use the remember-me hooks provided by Acegi Security to send back a "memento" that is subsequently recognised by Acegi Security (see the existing remember-me implementation and code in 0.8.2 or CVS) - Use Digest authentication, so that HTTP sessions are not required - Use BASIC authentication, so that HTTP sessions are not required If you were concerned about the user seeing a login page and spending too long completing it, as you point out you could store the AbstractProcessingFilter.ACEGI_SECURITY_TARGET_URL_KEY in a request parameter that the original login.jsp (or equivalent view) rendered. A custom AuthenticationProcessingFilter would then reassociate the ACEGI_SECURITY_TARGET_URL_KEY with the HttpSession if it detected the HttpSession was new. In effect this moves the only Acegi Security related use of the HttpSession during authentication processing to a request parameter. Also recall that the AbstractProcessingFilter.defaultTargetUrl provides a reasonable solution to timeout during completion of login page. Or, am I misunderstanding your timeout concern? HTH Ben --- 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
Re: [Acegisecurity-developer] Support for HTTP request memento in Form Authenticator
Hi, I don't see how you can store a copy of the login parameters in the session and then retrieve them "in the event of session expiration". Won't an expired session be destroyed by the container, along with any attributes it contains? The tomcat code (saveRequest, restoreRequest methods) looks like it is being used for restoring an original secured request after successful form authentication. Luke. Curtis Light wrote: Hello, I've been looking through the AuthenticationProcessingFilter source in Acegi Security, and I haven't seen support for storing a memento of the original HTTP request in the session, providing the ability to let a user re-authenticate without losing the original HTTP post parameters in the event of session expiration. Is this available in Acegi Security and I'm just not seeing its implementation? As a side note, Apache Tomcat 5.5.9 does provide this support in its container managed authentication. See the "authenticate" method. http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/FormAuthenticator.java?rev=1.23&view=markup If this feature is not currently available in Acegi Security, is there interest in adding (configurable) support for it to the AuthenticationProcessingFilter? I could see reasons for NOT wanting to use this (e.g. session creation denial-of-service attacks), but in other situations it can be useful. Thanks, Curtis -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.monkeymachine.ltd.uk --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
