struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Max Cooper" <...@maxcooper.com>
Subject Re: Association between Session object and Cookies/URL rewriting
Date Thu, 06 Mar 2003 12:47:58 GMT
It sounds like there is something else going on. The session timeout set in
the web.xml file is the time required for the server to totally forget about
you, whether you had authenticated yourself or not. It is the time since
your last request that matters. If the timeout is set for 30 minutes, you
can go to the site, click around for a few hours, and then if you wait more
than 30 minutes before making another request, the server will drop your
session. If you happened to have authenticated yourself, it will forget
about that at the same time that it forgets about your HttpSession stuff.

Some login pages and servers may drop your old session when you
authenticate, but I know that Tomcat doesn't do that unless you explicitly
have a session.invalidate() call in your login page. I tested this by having
a simple app with container-managed authentication where you could edit the
contents of your session with both an unprotected page and a protected page.
If you put stuff in your session and then clicked a link to go to the
protected page, you would be asked to login, and then you would arrive at
the protected page to find that all the stuff you put in the session was
still there.

In the SecurityFilter project (a Filter-based mimic of container-managed
authentication), we did have to handle one exception, and that is that your
session will be dropped if you were previously authenticated in that same
session. So, it won't drop the session on an unauthenticated ->
authenticated transition, but the session will be dropped on an
authenticated -> authenticated transition. We did this to be sure that any
information that might have been stored in the session for the last user is
not available to the new user as a security measure. I don't think that
Tomcat has to account for this issue, since it won't ever send you to login
if you have already authenticated yourself, and will give an error if you
submit a login form without being sent there by Tomcat. I am not sure what
they do with your old session in the case that you send a login request
anyway, but you can't really design your app to work that way since it isn't
supported in the first place. You might just get an error and remain logged
in as the original user, or you might get an error and have your old session
dropped (I am not sure if you would be logged in as the new user or not). In
SecurityFilter, you are allowed to send a login request any time you want by
design, so we had to handle that case.

SecurityFilter project home page (shameless plug :P):
http://securityfilter.sourceforge.net/

-Max

----- Original Message -----
From: "Mohan Radhakrishnan" <MohanR@hclcomnet.co.in>
To: "'Struts Users Mailing List'" <struts-user@jakarta.apache.org>
Sent: Thursday, March 06, 2003 3:55 AM
Subject: RE: Association between Session object and Cookies/URL rewriting


Hi,
   It seems that there is no way to associate the session timeout
information in the web.xml for the session created after the user logs in.
Or is there ? Let me know if I am very wrong here but my login page also
expires before the user is authenticated. The user perception is that the
application is expiring even before he is authenticated.
Mohan

-----Original Message-----
From: Gemes Tibor [mailto:tib@i-trade.hu]
Sent: Thursday, March 06, 2003 5:18 PM
To: Struts Users Mailing List
Subject: Re: Association between Session object and Cookies/URL
rewriting


2003. március 6. 12:10 dátummal Max Cooper ezt írtad:
> Here's a little dialog to illustrate:

Wow! That was marvellous!

Tib

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org





---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


Mime
View raw message