SEC-1561: HttpSecurityContextRepository fails to store security context to a newly authenticated session #1802

spring-issuemaster opened this Issue Sep 7, 2010 · 3 comments


None yet

1 participant


Derek Scherger (Migrated from SEC-1561) said:

When a second (or later subsequent) authentication attempt arrives on an already authenticated session and session attribute migration is disabled the security context is not always persisted to the new session.

With an existing authenticated session, subsequent POST requests to the form-login login-processing url will destroy the old session and create a new session. Occasionally the hash code of the persisted security context does not change and so the HttpSecurityContextRepository does not "update" the context stored in the session. The problem is that the old session held the unchanged security context but the new session does not hold any security context. After successfully authenticating another authentication is required because the new session does not contain a SecurityContext.

One factor causing the HttpSecurityContextRepository to not update/store the SecurityContext is that the session id stored in the security context is the old session id, even after that session has been destroyed and a new one created to replace it. This allows the SecurityContext hashCode to remain the same even though some aspect of the SecurityContext has indeed changed.

The check to set the security context attribute in HttpSecurityContextRepository.SaveToSessionResponseWrapper.saveContext should probably include something to ensure that the current session actually does contain the context, whether it has changed or not. In the case that the context has not changed, but the session has, the context should be stored to the new session.


Derek Scherger said:

This issue appears to be related to SEC-37, SEC-1307 and SEC-1528.


Luke Taylor said:

I think this should already be fixed in master as internal Spring Security attributes are now migrated by default. However, it would probably still make sense to add a check for the presence of the context attribute in the session, in case a new session has been created for some other reason.


Luke Taylor said:

When saving the context, I've added a check on whether the context attribute is set in the session, so it will always be saved if a new session has been created during the request.

@spring-issuemaster spring-issuemaster added this to the 3.1.0.M2 milestone Feb 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment