Description
The Javadoc for ServerHttpSecurity#securityContextRepository
states:
The strategy used with {@code ReactorContextWebFilter}. It does not impact how the {@code SecurityContext} is saved which is configured on a per {@link AuthenticationWebFilter} basis.
This is, however, outdated since form login does use this value if it's specified by the application:
if (this.securityContextRepository != null) {
this.formLogin.securityContextRepository(this.securityContextRepository);
}
I had a chat with @rwinch, and the desired functionality is the following:
If an application wires a security context repository for a given authentication mechanisms, that takes precedence for that mechanism. For example:
http
.securityContextRepository(a)
.formLogin()
.securityContextRepository(b);
http
.formLogin()
.securityContextRepository(b);
In both cases, b
would be used for form login.
If not, then, the authentication mechanism should use the global one:
http
.securityContextRepository(a)
.formLogin();
In this case, a
would be used for form login.
If none is specified by the application, each authentication mechanisms should use what it already defaults to.
So, to complete this task, there are three steps:
- Update the logic in form login, which currently accepts the global value regardless
- Update the logic in http basic and oauth2 login, which currently don't consider the global value at all
- Update the JavaDoc to indicate that setting the
securityContextRepository
does affect the underlying authentication mechanisms.