SpringSecurity6 | 问题答疑

本文主要是介绍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，直接进入授权阶段，判断用户是否有权访问被请求的资源。

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

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

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

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

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