ServletRequestAttributes may use wrong session in background thread [SPR-4885]

[spring-projects-issues]

George Baxter opened SPR-4885 and commented

The ServletRequestAttributes.getSession call first tries to get the session from the request. After that, it uses its own session reference.

The problem with this is when a background thread runs past the end of a request, the request.getSession may return null, UNLESS the request object is being reused, as it is in tomcat. In that case, the object is now associated with a new session and getSession() will return another user's session to the background thread.

Basically, the getSession method should check first if the ServletRequestAttributes.session attribute is not null... if it is not null, use it! Only hit the request if we need to build the session (allowCreate is true or the request may have allocated the session later). Do not overwrite a valid session value.

---

Affects: 2.5.2

[spring-projects-issues]

Juergen Hoeller commented

We need to reobtain the session in order to pick up a fresh session after the previous one has been invalidated. This is at least necessary for the regular case of accessing the session within the original request thread (or also from a child thread while the original request is still active). However, we might have to suppress this for access after completion of the original request.

Juergen

[spring-projects-issues]

George Baxter commented

I'm a little puzzled by this 'fresh session' concept. If a session is invalidated, is there a way to get a new 'fresh' session associated with the request? How is this even done? I figured once the session is invalidated, the user better be returned some result quickly, or at least a redirect to a page to create a new session (with a new request).

Just curious!

However, this 'other user's session' was.. an evil little bug for us. Thanks for the attention!

-g.

[spring-projects-issues]

Juergen Hoeller commented

I've generally revised RequestAttributes access from child threads in order to not touch the request object after request completion. The session reference is now stored at request completion time, available for access from child threads after completion of the original request.

During the lifetime of the original request, even child threads will still use "request.getSession" for each session access attempt. However, the algorithm is much clearer now, with the stored session reference only set and actually accessed after request completion.

As for the general need for fresh getSession calls: A session may be invalidated during the lifetime of a request, with an existing session reference rendered invalid through that. A fresh "request.getSession" call will then subsequently return a new session object (usually also with a new id), even when called within the original request (after invalidating the original session).

Juergen