| Anonymous | Login | Signup for a new account | 11-22-2024 03:02 PST |
| Main | My View | View Issues | Change Log | Docs |
| Viewing Issue Advanced Details [ Jump to Notes ] | [ View Simple ] [ 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 | Platform | |||||
| Status | closed | OS | |||||||
| Projection | none | OS Version | |||||||
| ETA | none | Fixed in Version | 3.0.13 | Product Version | 3.0.12 | ||||
| Product Build | 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. |
||||||||
| Steps To Reproduce | |||||||||
| 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. |  |
