Describe the bug
If a security context has been created via a "remember me" mechanism rather than fresh credentials, this should be expressed via a RememberMeAuthenticationToken. This is required so that assertions such as fullyAuthenticated() work correctly.
To Reproduce
Spring Boot application with the following config:
@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) {
return http.securityMatcher("/**")
.formLogin(config -> config.permitAll())
.rememberMe(config -> config.rememberMeServices(new SpringSessionRememberMeServices())
.authorizeHttpRequests(authorize -> authorize
.requestMatchers("/sensitive").fullyAuthenticated()
.anyRequest().authenticated()
).build();
}
- Start server and browser
- Login to application with "remember me" selected
- Visit
/sensitive
- Restart browser
- Visit
/sensitive
Expected behavior
Accessing /sensitive should trigger a login flow, as with the default .rememberMe() behaviour.
Additional context
Due to the implementation of just extending the current session, there is no way to tell whether the user has entered their credentials in the current browser session or not.
If "wontfix", then there should at least be a big warning somewhere that this breaks fullyAuthenticated().
Describe the bug
If a security context has been created via a "remember me" mechanism rather than fresh credentials, this should be expressed via a
RememberMeAuthenticationToken. This is required so that assertions such asfullyAuthenticated()work correctly.To Reproduce
Spring Boot application with the following config:
/sensitive/sensitiveExpected behavior
Accessing
/sensitiveshould trigger a login flow, as with the default.rememberMe()behaviour.Additional context
Due to the implementation of just extending the current session, there is no way to tell whether the user has entered their credentials in the current browser session or not.
If "wontfix", then there should at least be a big warning somewhere that this breaks
fullyAuthenticated().