What was wrong with the first suggestion? 1.) When your user logs in, throw an object in their session. 2.) In each servlet/jsp (or, better, in a filter), test for the existence of that object and forward back to the login if it is null.
Seems pretty straight forward to me. On Thursday 20 May 2004 12:51 pm, Jonathan Eric Miller wrote: > Yeah, that seems like it would work. I'm wondering if I could maybe use a > filter by itself though and not use the listener and do something like the > following. > > 1. Intercept all requests with a filter. > 2. Get the HttpSession out of the request. Get the session ID by calling > HttpSession.getId(); > 3. Get the cookie array and see if there is a cookie named "jsessionid." If > there is, compare the two session IDs. If they are different forward to > sessionexpired.jsp to display error page. Otherwise, continue as normal. > > This assumes that the session ID changes everytime it expires. As far as I > know, that is the case. > > I would also have to figure out how to get the jsessionid if it is in the > URL rather than in a cookie. > > I would prefer to do it that way if I can for the sake of simplicity. I > want to avoid having a Hashtable that grows indefinitely if possible. > > Does it seem like this work, or, am I missing something? > > I'm wondering if this wouldn't work if I didn't have single sign-on > enabled. i.e. the login page would get displayed at session expiration. I'm > not sure if the login page does only forwards, or if it does a redirect. > I'm thinking the redirect might make the above logic not work since the > session ID in the cookie would get updated first by the login page. Note, > the filter runs after the login page. > > It seems like there should be a generic way to handle this kind of thing > that is well understood and known to work. > > Jon > > ----- Original Message ----- > From: "Veniamin Fichin" <[EMAIL PROTECTED]> > To: "Tomcat Users List" <[EMAIL PROTECTED]> > Sent: Thursday, May 20, 2004 2:59 AM > Subject: Re: Session Timeout and "Direct Reference to login page" > > > Jonathan Eric Miller wrote: > > > Thanks. I think option #1 is what I'm looking for. What I don't > > understand > > > > is what I need to do with the session listener though? > > > > > > I don't understand how to determine whether the new session is truly > > new, or > > > > if it's a new session because a previous session timed out. Could I use > > a > > > > filter and check the incoming session ID and if the session ID isn't in > > the > > > > list of session IDs that the server knows about, assume that it's an > > expired > > > > session? > > > > Yes, this may be the right solution. Store a hash in a singleton > > class and fill it with session ids that has expired (add a new hash pair > > in every invocation of sessionDestroyed()). And at every request check > > that: > > 0) HttpSession.isNew()==true . > > 1) HttpServletRequest.getCookies() array contains an entry that matches > > one of your hash pairs. > > That way you may determine if that session is truly new or an > > expired one. It's just a guess. > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Ben Souther F.W. Davison & Company, Inc. This e-mail message, and any accompanying documents, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, distribution or copying is prohibited. If you are not the intended recipient, please contact our office by email or by telephone at (508) 747-7261 and immediately destroy all copies of the original message. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
