|
此版本仍在开发中,尚未被视为稳定版本。对于最新的稳定版本,请使用 Spring Security 6.4.3! |
会话管理迁移
以下步骤与如何完成迁移会话管理支持相关。
需要显式保存 SecurityContextRepository
在 Spring Security 5 中,默认行为是针对SecurityContext以自动保存到SecurityContextRepository使用SecurityContextPersistenceFilter.
保存必须在HttpServletResponse正在提交和之前SecurityContextPersistenceFilter.
遗憾的是,自动持久化SecurityContext在请求完成之前(即在提交HttpServletResponse).
跟踪状态以确定是否需要保存也很复杂,这会导致对SecurityContextRepository(即HttpSession)。
在 Spring Security 6 中,默认行为是SecurityContextHolderFilter只会读取SecurityContext从SecurityContextRepository并将其填充到SecurityContextHolder.
用户现在必须显式保存SecurityContext使用SecurityContextRepository如果他们想要SecurityContext以在请求之间持续存在。
这消除了歧义并提高了性能,因为只需要写入SecurityContextRepository(即HttpSession) 时。
|
清除上下文时(例如在注销期间),也需要保存上下文。请参阅此部分以了解更多信息。 |
如果您明确选择使用 Spring Security 6 的新默认值,则可以删除以下配置以接受 Spring Security 6 默认值。
-
Java
-
Kotlin
-
XML
public SecurityFilterChain filterChain(HttpSecurity http) {
http
// ...
.securityContext((securityContext) -> securityContext
.requireExplicitSave(true)
);
return http.build();
}
@Bean
open fun springSecurity(http: HttpSecurity): SecurityFilterChain {
http {
securityContext {
requireExplicitSave = true
}
}
return http.build()
}
<http security-context-explicit-save="true">
<!-- ... -->
</http>
使用配置时,将SecurityContextHolder替换为SecurityContext还会保存SecurityContext到SecurityContextRepository是否应在请求之间持久保存。
例如,以下代码:
SecurityContextHolder跟SecurityContextPersistenceFilter-
Java
-
Kotlin
SecurityContextHolder.setContext(securityContext);
SecurityContextHolder.setContext(securityContext)
应替换为
SecurityContextHolder跟SecurityContextHolderFilter-
Java
-
Kotlin
SecurityContextHolder.setContext(securityContext);
securityContextRepository.saveContext(securityContext, httpServletRequest, httpServletResponse);
SecurityContextHolder.setContext(securityContext)
securityContextRepository.saveContext(securityContext, httpServletRequest, httpServletResponse)
多个 SecurityContextRepository
在 Spring Security 5 中,默认的SecurityContextRepository是HttpSessionSecurityContextRepository.
在 Spring Security 6 中,默认的SecurityContextRepository是DelegatingSecurityContextRepository.
如果您配置了SecurityContextRepository仅为了更新到 6.0,您可以将其完全删除。
优化查询RequestCache
在 Spring Security 5 中,默认行为是在每个请求上查询保存的请求。
这意味着,在典型设置中,为了使用RequestCache这HttpSession在每个请求中查询。
在 Spring Security 6 中,默认值是RequestCache如果 HTTP 参数continue已定义。
这允许 Spring Security 避免不必要地读取HttpSession使用RequestCache.
在 Spring Security 5 中,默认使用HttpSessionRequestCache将在每个请求中查询缓存的请求。
如果您没有覆盖默认值(即使用NullRequestCache),则以下配置可用于在 Spring Security 5.8 中显式选择加入 Spring Security 6 行为:
RequestCache仅在以下情况下检查保存的请求continue参数存在-
Java
-
Kotlin
-
XML
@Bean
DefaultSecurityFilterChain springSecurity(HttpSecurity http) throws Exception {
HttpSessionRequestCache requestCache = new HttpSessionRequestCache();
requestCache.setMatchingRequestParameterName("continue");
http
// ...
.requestCache((cache) -> cache
.requestCache(requestCache)
);
return http.build();
}
@Bean
open fun springSecurity(http: HttpSecurity): SecurityFilterChain {
val httpRequestCache = HttpSessionRequestCache()
httpRequestCache.setMatchingRequestParameterName("continue")
http {
requestCache {
requestCache = httpRequestCache
}
}
return http.build()
}
<http auto-config="true">
<!-- ... -->
<request-cache ref="requestCache"/>
</http>
<b:bean id="requestCache" class="org.springframework.security.web.savedrequest.HttpSessionRequestCache"
p:matchingRequestParameterName="continue"/>