|
Mantis - Resin
|
|||||
| Viewing Issue Advanced Details | |||||
|
|
|||||
| ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
| 55 | minor | always | 03-24-05 00:00 | 05-11-05 00:00 | |
|
|
|||||
| Reporter: | ferg | Platform: | |||
| Assigned To: | OS: | ||||
| Priority: | urgent | OS Version: | |||
| Status: | closed | Product Version: | 3.0.12 | ||
| Product Build: | 3.0.12 | Resolution: | fixed | ||
| Projection: | none | ||||
| ETA: | none | Fixed in Version: | 3.0.13 | ||
|
|
|||||
| 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. |
||||
| Steps To Reproduce: | |||||
| Additional Information: | |||||
| Relationships | |||||
| Attached Files: | |||||
| Notes | |||||
|
|
|||||
|
|
||||
|
|
|||||
|
|
||||