Mantis Bugtracker
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000055 [Resin] minor always 03-24-05 00:00 05-11-05 00:00
Reporter ferg View Status public  
Assigned To
Priority urgent Resolution fixed  
Status closed   Product Version 3.0.12
Summary 0000055: Session invalidation issue
Description RSN-46

I've found a problem with session invalidation in resin-pro-3.0.s050228, which probably exists in at least resin-pro-3.0.11 if not other versions as well. We did not According to the servlet specifications, HttpSessionListener.sessionDestroyed should be called when the session is invalidated. After a session is invalidated the user principal and other information should be removed from the session. Currently however, it appears that the session is still valid after sessionDestroyed is called. Subsequent requests still retain the user principal. Sometimes I will see just sessionActivated being called after sessionDestroyed with the user principal still in place and session attributes still in place. If I wait a few seconds after sessionDestroyed is called, then sessionCreated is also called with no user principal attached and not session attributes. In this case, the user principal is still retained on the request, presumably being reattached to the session at a later time.


The timeline looks like this:
1. request for page
2. no user principal found, sent to login page
3. login successful, sent to page
4. page response returned, session attributes set
5.wait for session to expire
6. sessionDestroyed fires
7. wait
8. request page again

then, depending on how long the wait is you'll either get
9. session attributes still in place, user principal still in place

or
9. session attributes missing, user principal still in place


This appears to happen using file based sessions as well as database. File sessions preserve the session information after session destroyed and never seem to call sessionCreated again even after waiting 5 minutes.

Setting reuse-session-id="false" also seems to have no effect. I tested waiting up to 3 minutes after session destroyed was called (3 times longer than the specified session timeout of 1 minute) and the user principal was still in place.

This is posing problems for us as we are currently relying on the assumption that the user principal and the session attributes will have the same lifetime. Also, we would expect the user principal to have the same timeout behavior as the session attributes, or at a minimum, be configurable so that we can control how long a session can be idle before the user principal is reset.
Additional Information
Attached Files

- Relationships

- Notes
(0000059)
ferg
03-24-05 00:00

server/12dz

Checked that session timeout, principal timeout, and persistent session timeout is identical.
 
(0000060)
sam
03-24-05 00:00

There were a number of session related fixes done for 3.0.12 and 3.0.13, especially in relation to the cluster store.
 

- Issue History
Date Modified Username Field Change
03-24-05 00:00 ferg New Issue
11-30-05 00:00 administrator Fixed in Version  => 3.0.13


Mantis 1.0.0rc3[^]
Copyright © 2000 - 2005 Mantis Group
30 total queries executed.
28 unique queries executed.
Powered by Mantis Bugtracker