0000055: Session invalidation issue

Viewing Issue Simple Details [ Jump to Notes ]

[ View Advanced ] [ Issue History ] [ Print ]

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[^]

30 total queries executed.
28 unique queries executed.