SEC-1735: Logged out immediately after logging in on some browsers #1972

Closed
spring-issuemaster opened this Issue May 9, 2011 · 6 comments

2 participants

@spring-issuemaster

James G (Migrated from SEC-1735) said:

This bug is closely related to SEC-1587.
I start at my log in screen, log into the system, see the logged in view and then the next navigation I make I end up being redirect back to the login screen.
It happens periodly, not every time. It happens the most when using Internet Explorer 6.
After I debugged the problem I figured out that the httpSession.removeAttribute(SPRING_SECURITY_CONTEXT_KEY); call in HttpSessionSecurityContextRepository was destroying my newly created authentication object.
Here's how it happens:
1. Browser requests jsf.js.faces during the loading of the login screen. This request passes through the httpSessionContextIntegrationFilter along with all .faces requests.
2. Browser holds on to connection after getting the javascript file. (Browsers do this as an optimization to prevent lots of new tcp connects)
3. I log into my app from the login page. This adds the security context to the session.
4. Browser makes another javascript request from the open connection which causes the thread working on jsf.js.faces to finish up (come back out through the filters)
5. On the request thread of jsf.js.faces the original security context had a null authenication so httpSession.removeAttribute(SPRING_SECURITY_CONTEXT_KEY); is called which wipes up the new authenication.

I've worked around the problem by created my own version of HttpSessionSecurityContextRepository and just changing the lines:
if (httpSession != null) {
// SEC-1587 A non-anonymous context may still be in the session
httpSession.removeAttribute(SPRING_SECURITY_CONTEXT_KEY);
}
return;

to

            if (httpSession != null && contextHashBeforeChainExecution != -1) {
                // SEC-1587 A non-anonymous context may still be in the session
                httpSession.removeAttribute(SPRING_SECURITY_CONTEXT_KEY);
            }
            return;

This means that the security context is only reset if there was one at the beginning of the request. (Hash of -1 means no authenication)

@spring-issuemaster

Rob Winch said:

In general I can see how this would happen.

1) The login page loads and makes an asynchronous request (i.e. javascript, css, image, etc)
2) In the meantime, a user submits their credentials before the asynchronous request completes
3) After the user has logged in, the asynchronous request (with anonymous authentication) completes and removes the authentication established in #2.

Can you confirm that this is a generalization of what is happening?

@spring-issuemaster

James G said:

Yes, that is exactly it. I just want to point out that ie6 seems to prevent the completion of some asynchronous requests until it reuses the connection to do another request. (for example load another javascript file).
Thank you.

@spring-issuemaster

Markus Siegel said:

i got the same problems with Tomcat 6 and Icefaces 1.8 in every browser. In the moment im using also the workaround.

@spring-issuemaster

Rob Winch said:

Thanks for the bug submission. I have pushed a fix to master and the 3.0.x branch. The fix I checked in is a bit different than the orional proposal to ensure it works with other implementations of SecurityContexts.

@spring-issuemaster spring-issuemaster added this to the 3.1.1 milestone Feb 5, 2016
@spring-issuemaster

This issue relates to #2968

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment