Thanks for the suggestion. The reason that I can't do it that way (as far as I know) is because I'm using container-based security. I'm not handling the submission of the login form directly.
Before I switched to using container-based security, I was doing it exactly as you described. Jon ----- Original Message ----- From: "Ben Souther" <[EMAIL PROTECTED]> To: "Tomcat Users List" <[EMAIL PROTECTED]> Sent: Thursday, May 20, 2004 12:26 PM Subject: Re: Session Timeout and "Direct Reference to login page" > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
