SpringSecurity6 | 问题答疑

✅作者简介：大家好，我是Leo，热爱Java后端开发者，一个想要与大家共同进步的男人😉😉
🍎个人主页：Leo的博客
💞当前专栏： Java从入门到精通
✨特色专栏： MySQL学习
🥭本文内容：SpringSecurity6 | 问题答疑
🖥️个人小站 ：个人博客，欢迎大家访问
📚个人知识库： Leo知识库，欢迎大家访问

学习参考 ：

• 讲师：孙帅老师
• 课程：孙哥说SpringSecurity6

✨✨ 粉丝福利订阅✨✨

Leo哥收集了一些关于面试以及其他学习资源，这里分享给大家，各位卷王快收下吧!!!

目录

1.前言

大家好，我是Leo哥🫣🫣🫣，今天又是元气满满的周一，大家摸鱼快乐。就在我刚打开电脑的时候，后台私信就看到一条信息，看到了有一位粉丝朋友问了两个有关于SpringSecurity相关的两个问题。具体是啥呢，咱们接下来一步一步看哈。好了，话不多说让我们开始吧😎😎😎。

2.问题引出

相关问题我这里已经进行了截图，大家可以参考一下，这两个问题你是否可以答出来呢，对于这两个问题你是否还有其他思考呢。

好了，我们简单思考一下，就跟着Leo哥视角一起去研究一下这两个问题吧。

3.问题1

假如已经登录过， 下一次请求到达时，是不是 过滤器 SecurityContextHolderFilter用于恢复 SecurityContext 对象，以保证当前请求已经认证，具有身份，不会再执行(跳过)后续的用户登录的相关过滤器 ？

在SpringSecurity6中，如果用户已经登录过，那么在下一次请求到达时，通常不会再执行用于处理用户登录的相关过滤器。这是因为，如果用户的身份信息（

SecurityContext

）已经存在并且可以被正确恢复，Spring Security 会识别出用户已经认证，并跳过那些用于处理初始认证（如登录）的过滤器。

如果已经存在一个有效的安全上下文（即用户已经登录过），并且这个上下文在请求时被正确恢复（例如，通过一个有效的JWT令牌或会话id），后续的请求通常不需要用户再次通过登录过程进行认证。这意味着一旦

SecurityContextPersistenceFilter

（或其在SpringSecurity6中对应的组件）恢复了

SecurityContext

，Spring Security会跳过那些用于处理登录认证的过滤器，如

UsernamePasswordAuthenticationFilter

，直接进入授权阶段，判断用户是否有权访问被请求的资源。

具体来说，这个过程通常涉及以下几个步骤：

1. **恢复SecurityContext**：当请求到达时，一个专门的过滤器（如SecurityContextPersistenceFilter）会尝试从存储（如HTTP会话或其他存储方式）中恢复SecurityContext。如果成功恢复，这表明用户之前已经完成了登录过程。
2. 跳过登录认证过滤器：如果SecurityContext存在并包含一个认证对象（Authentication），这意味着用户已经认证。因此，Spring Security会跳过那些负责处理登录的过滤器（如UsernamePasswordAuthenticationFilter），因为它们主要用于处理未认证用户的登录请求。
3. 授权和资源访问：一旦确认用户已认证，请求将继续流经过滤器链，进行各种授权检查，以确定用户是否有权访问请求的资源。
4. 清理工作：在请求处理结束后，通常会有一些清理工作，例如从SecurityContextHolder中清除SecurityContext，确保线程本地变量不会被未来的请求错误地重用。

因此，如何我们已经在当前系统登录过的话，过滤器SecurityContextHolderFilter就会对SecurityContext 对象进行恢复，保证当前请求是具有身份的。

4.问题2

在前后端分离的应用程序中， 前端通过在请求头中 包含 Authorization: Bearer ，以表明当前请求具有身份信息，
是不是 后台可以处理请求头中的token， 通过将得到的 token 字符串 转换成 SecurityContext 对象， 恢复请求的身份 ？
这里不能再使用 默认的 HttpSessionSecurityContextRepository 或者 RequestAttributeSecurityContextRepository
恢复请求的身份信息，而是要自定义一个 SecurityContextRepository （例如 JwtSecurityContextRepository） 对象来达到此目的 ?

（ 在 JwtSecurityContextRepository 中，从 请求头中获取到 tokenString， 转成 一个 authenticatedToken，然后执行 securityContext.setAuthentication(authenticatedToken)）

在前后端分离的应用程序中，确实常会遇到需要在前端发送带有访问令牌（例如JWT）的请求，而后端需要验证这个令牌并恢复用户身份的情形。这种情况下，令牌通常通过

Authorization

请求头以

Bearer <token>

的形式发送。

后端处理这个流程涉及的关键组件是

AuthenticationFilter

（例如

OncePerRequestFilter

的实现类），这个过滤器会负责分析和验证请求头中的令牌。在SpringSecurity中，你可以使用

JwtAuthenticationTokenFilter

这样的自定义过滤器来实现这个功能。此过滤器会读取请求头中的令牌，验证其有效性，然后创建对应的

Authentication

对象（比如

UsernamePasswordAuthenticationToken

或者自定义的

Authentication

实现，若是JWT可以是

JwtAuthenticationToken

）。

至于提到的

SecurityContextRepository

，这是一个用于从请求中加载或保存

SecurityContext

的策略接口。确实，当使用诸如JWT这样的无状态令牌时，使用

HttpSessionSecurityContextRepository

或

RequestAttributeSecurityContextRepository

这样的基于会话的实现就不再适合了，因为它们依赖于HTTP会话来存储安全上下文。

在这种情况下，你可以自定义一个

SecurityContextRepository

，让我们称之为

JwtSecurityContextRepository

。这个自定义的仓库可以在每次请求中从请求头中解析JWT令牌，然后创建一个带有认证信息的

SecurityContext

。

这个过程可能看起来是这样的：

1. 自定义的JwtAuthenticationTokenFilter从请求头中提取JWT令牌。
2. 对JWT令牌进行验证，确保它有效并来自可信的颁发者。
3. 验证通过后，将JWT令牌转换为Authentication对象，并设置到SecurityContextHolder中。
4. 自定义的JwtSecurityContextRepository不会像基于会话的实现那样保存SecurityContext，因为每个请求都应该是无状态的，并且SecurityContext应该从令牌中重新构建。

通过这样的方式，安全上下文在每次请求中都是根据携带的JWT重新构建的，确保了前后端分离架构中的无状态认证机制。

5.参考文献

• https://springdoc.cn/spring-security/servlet/architecture.html
• http://springboot.fun/

6.总结

以上便是本文的全部内容，本人才疏学浅，文章有什么错误的地方，欢迎大佬们批评指正！我是Leo，一个在互联网行业的小白，立志成为更好的自己。

如果你想了解更多关于Leo，可以关注公众号-程序员Leo，后面文章会首先同步至公众号。