SpringSecurity6 | 问题答疑

news2024/9/8 22:56:39

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

学习参考：

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

✨✨ 粉丝福利订阅✨✨

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

1.前言

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

2.问题引出

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

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

3.问题1

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

在Spring Security中，确实存在一个机制来确保已经登录的用户在随后的请求中仍然被识别和认证。这个机制通常涉及到几个关键组件，包括SecurityContextHolder, SecurityContext, 和一个用于持久化安全上下文的过滤器，通常是SecurityContextPersistenceFilter。

当用户第一次登录成功后，SpringSecurity会将用户的认证信息存储在SecurityContext中，然后将这个SecurityContext保存在会话中（通常是HTTP会话）。在后续的请求中，SecurityContextPersistenceFilter会检查会话，恢复之前存储的SecurityContext，并将其放入SecurityContextHolder，使得当前请求拥有之前认证的用户信息。

因此，如果用户已经登录，SecurityContextPersistenceFilter将恢复用户的认证信息，使得系统知道该用户已经认证。这意味着后续的请求不需要用户再次登录，而且某些过滤器（比如处理登录的过滤器）在检测到用户已经认证的情况下可能会被跳过。

但是需要注意的是，SecurityContextHolderFilter并不是标准的Spring Security过滤器。你可能是在提及SecurityContextPersistenceFilter，这是一个更常见的用于在请求之间持久化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重新构建的，确保了前后端分离架构中的无状态认证机制。