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
