Tomcat behind IIS -> Session timeout is ignored
Hello list, I have a problem with a tomcat 5.0.28 installation connected to IIS 6.0 (Windows 2003 server) with isapi_redirect.dll Everything is working well, except for the session timeout. The timeout is set to 60 minutes in the context's web.xml file (60) which works great in many other installations (without IIS, though) As far as I could tell, the sessions are purely managed by tomcat, so IIS should not pose a problem, but still... Can anyone shed some light on this? Thanks, Tobias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: custom session manager
> -Ursprüngliche Nachricht- > Von: Leon Rosenberg [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 6. Oktober 2005 07:43 > An: Tomcat Users List; Mark > Betreff: Re: custom session manager > > > On 10/6/05, Mark <[EMAIL PROTECTED]> wrote: > > basically, I want to prevent users from logging in and creating a > > second session if a valid session for that user already exists. > > > > For instance. > > > > 1. Log in to my web app, session is created > > 2. browse around in my web app > > 3. close browser, do not logout > > 4. Start browser up again > > 5. try and log in > > 6. Do not allow login, have user 'reconnect' to the old session > > created in step 1. > > > > I have written quite a few web based apps, and I know of no way to > > kill the session at step 3. > > pretty easy, set session timeout to 1 minute and integrate a hidden > frame or javascript-loaded-image in your application that reloads all > 30 seconds. 60-99 seconds after the user closed his browser the > session would be killed. > Or, cou could add a static hashmap to your Servlet (or a bean if using JSPs) where you simply add the sessions with every request. You would have to put an attribute implementing javax.servlet.http.HttpSessionActivationListener in each session though, that removes the session from your hashmap when the session is expired or you will end up with having many invalid entries in your hashmap. (And I don't even know what happens if you keep the references to those Session objects when they are recycled by tomcat) We do this to keep track of our sessions within the application. A quick google revealed http://www.jguru.com/faq/view.jsp?EID=12141 with example code. Once you have the list of sessions, it should be easy to expire the old ones for the same user... Though this will allow you to have only one session per user, it will not kill the session immediately after step 3. Using the reload as described above will do that, but prevents you from having a security-logout if the user just has his browser open all day (without actually doing anything). Hth, Tobias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: custom session manager
> -Ursprüngliche Nachricht- > Von: Leon Rosenberg [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 6. Oktober 2005 11:20 > An: Tomcat Users List > Betreff: Re: custom session manager > > > On 10/6/05, Tobias Meyer <[EMAIL PROTECTED]> wrote: > > > > Or, cou could add a static hashmap to your Servlet (or a > bean if using JSPs) > > where you simply add the sessions with every request. You > would have to put > > an attribute implementing > javax.servlet.http.HttpSessionActivationListener > > in each session though, that removes the session from your > hashmap when the > > session is expired or you will end up with having many > invalid entries in > > your hashmap. (And I don't even know what happens if you > keep the references > > to those Session objects when they are recycled by tomcat) > > We do this to keep track of our sessions within the application. > > If you keep your sessions in a hashmap forever they will never be > freed by the garbage collector and you will end with an outofmemory > error one day. That's why I said you need one Attribute that implements the HttpSessionActivationListener, which, on second thought , was wrong - you need to implement HttpSessionBindingListener. The Method public void valueUnbound(HttpSessionBindingEvent event) will get called automatically when the session expires, and you can add code that removes the session from the hashmap. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: custom session manager
The problem is AFAIK, that you cannot access the list of all sessions through the servlet-api. That feature was in the servlet-api at some time, but was removed, IIRC due to security issues. If you have a list of all sessions, you can easily iterate over them at login and manually expire all old sessions for the same user. => Max. one active session per user. > -Ursprüngliche Nachricht- > Von: Leon Rosenberg [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 6. Oktober 2005 16:11 > An: Tomcat Users List > Betreff: Re: custom session manager > > > Sorry, aber how exactly does it solves the problem of having one > session per user? :-) > > > > On 10/6/05, Tobias Meyer <[EMAIL PROTECTED]> wrote: > > > -Ursprüngliche Nachricht- > > > Von: Leon Rosenberg [mailto:[EMAIL PROTECTED] > > > Gesendet: Donnerstag, 6. Oktober 2005 11:20 > > > An: Tomcat Users List > > > Betreff: Re: custom session manager > > > > > > > > > On 10/6/05, Tobias Meyer <[EMAIL PROTECTED]> wrote: > > > > > > > > Or, cou could add a static hashmap to your Servlet (or a > > > bean if using JSPs) > > > > where you simply add the sessions with every request. You > > > would have to put > > > > an attribute implementing > > > javax.servlet.http.HttpSessionActivationListener > > > > in each session though, that removes the session from your > > > hashmap when the > > > > session is expired or you will end up with having many > > > invalid entries in > > > > your hashmap. (And I don't even know what happens if you > > > keep the references > > > > to those Session objects when they are recycled by tomcat) > > > > We do this to keep track of our sessions within the application. > > > > > > If you keep your sessions in a hashmap forever they will never be > > > freed by the garbage collector and you will end with an > outofmemory > > > error one day. > > > > That's why I said you need one Attribute that implements the > > HttpSessionActivationListener, which, on second thought , > was wrong - you > > need to implement HttpSessionBindingListener. > > > > The Method > > > > public void valueUnbound(HttpSessionBindingEvent event) > > > > will get called automatically when the session expires, and > you can add code > > that removes the session from the hashmap. > > > > > > > - > > 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] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
