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]
