You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A custom SecurityContextRepository that is configured for a SecurityFilterChain will be ignored by SessionManagementConfigurer/SessionManagementFilter. Instead the SessionManagementFilter uses the default HttpSessionSecurityContextRepository.
This happens in Spring Security 6.0.x. The issue did not appear in Spring Security 5.7.x.
The SessionManagementFilter is created when the method SessionManagementConfigurer#configure(H http) is called (see here).
In Spring Security 5.7.x the SecurityContextRepository is determined by calling http.getSharedObject(SecurityContextRepository.class).
In Spring Security 6.0.x this behavior changed. this.sessionManagementSecurityContextRepository is passed for the SessionManagementFilter constructor.
See SessionManagementConfigurer
SecurityContextRepository securityContextRepository = this.sessionManagementSecurityContextRepository;
SessionManagementFilter sessionManagementFilter = new SessionManagementFilter(securityContextRepository, getSessionAuthenticationStrategy(http));
The default value for this.sessionManagementSecurityContextRepository is new HttpSessionSecurityContextRepository(). This value is only overwritten in SessionManagementConfigurer#init(H http) (see here). But NOT, if SecurityContextRepository from http.getSharedObject(SecurityContextRepository.class) is null
SecurityContextRepository securityContextRepository = http.getSharedObject(SecurityContextRepository.class);
boolean stateless = isStateless();
if (securityContextRepository == null) {
// this.sessionManagementSecurityContextRepository is set
}
// No else case, where
// this.sessionManagementSecurityContextRepository = securityContextRepository;
To Reproduce
Set a custom SecurityContextRepository in a SecurityFilterChain:
If the else case in SessionManagementConfigurer is missing, the test will fail, because the SessionManagementFilter will call the containsContext method of another SecurityContextRepository but not the configured one. With the implemented else case, this issue should be solved
…on (#15804)
The shared objects need to be available when other configurers are run and because of spring-projects/spring-security#12579 a workaround is needed to actually apply the correct SecurityContextRepository
Fixesvaadin/hilla#681
m-ibot
added a commit
to m-ibot/spring-security
that referenced
this issue
Feb 2, 2023
Describe the bug
A custom
SecurityContextRepository
that is configured for aSecurityFilterChain
will be ignored bySessionManagementConfigurer
/SessionManagementFilter
. Instead theSessionManagementFilter
uses the defaultHttpSessionSecurityContextRepository
.This happens in Spring Security
6.0.x
. The issue did not appear in Spring Security5.7.x
.The
SessionManagementFilter
is created when the methodSessionManagementConfigurer#configure(H http)
is called (see here).In Spring Security
5.7.x
theSecurityContextRepository
is determined by callinghttp.getSharedObject(SecurityContextRepository.class)
.In Spring Security
6.0.x
this behavior changed.this.sessionManagementSecurityContextRepository
is passed for theSessionManagementFilter
constructor.See SessionManagementConfigurer
The default value for
this.sessionManagementSecurityContextRepository
isnew HttpSessionSecurityContextRepository()
. This value is only overwritten inSessionManagementConfigurer#init(H http)
(see here). But NOT, ifSecurityContextRepository
fromhttp.getSharedObject(SecurityContextRepository.class)
isnull
To Reproduce
Set a custom
SecurityContextRepository
in aSecurityFilterChain
:Unfortunately, this setting does not have any affect on
SessionManagementFilter
.Expected behavior
The custom
SecurityContextRepository
is passed toSessionManagementFilter
's constructor.The text was updated successfully, but these errors were encountered: