南昌建设公司网站建网站前途

南昌建设公司网站,建网站前途,源码网站模板,软件技术毕业做什么工作前言#xff1a;登出不仅仅是“跳回登录页” 在传统的 Session 时代#xff0c;登出只需要 session.invalidate()。但在现代前后端分离、基于 Token#xff08;Redis MySQL#xff09; 的架构中#xff0c;登出变成了一个**“销毁凭证”**的系统工程。 如果登出逻辑写得不…前言登出不仅仅是“跳回登录页”在传统的 Session 时代登出只需要session.invalidate()。但在现代前后端分离、基于TokenRedis MySQL的架构中登出变成了一个**“销毁凭证”**的系统工程。如果登出逻辑写得不好可能会出现“用户点了登出复制之前的 Token 还能继续调用接口”或者“明明登出了过一会又自动登录了”的灵异现象。本文将基于Access Token Refresh Token的双令牌模式手把手教你实现一个安全的登出逻辑。一、 核心概念双令牌机制 (Dual Token) 工作原理在实现登出功能前必须明确Access Token与Refresh Token的技术分工与交互流程。1. 令牌定义与区别Access Token (访问令牌)用途作为访问业务接口的身份凭证。时效短时效通常 30 分钟。存储通常存储于Redis与数据库 (MySQL)中验证使用redis以满足高频验证的性能需求。Refresh Token (刷新令牌)用途仅用于在 Access Token 过期后获取新的 Access Token。时效长时效通常 7 ~ 30 天。存储通常存储于数据库 (MySQL)中用于持久化状态管理。2. 交互流程初始化用户通过账号密码登录服务端生成并返回 Access Token 和 Refresh Token。业务请求客户端在 HTTP Header 中携带 Access Token 请求业务接口服务端通过 Redis 校验通过后响应数据。过期拦截Access Token 过期Redis Key 失效客户端请求业务接口时服务端返回401 Unauthorized。令牌刷新客户端拦截 401 响应携带 Refresh Token 请求/refresh-token接口。服务端校验数据库中 Refresh Token 的有效性签发新的 Access Token。重试客户端使用新的 Access Token 重新发起之前的业务请求。二、 登出的核心原理斩草要除根在双 Token 机制下用户手里有两把钥匙Access Token短效存 Redis与MySQL用于日常访问接口。Refresh Token长效存 MySQL用于在 Access Token 过期时换取新的。完美的登出必须同时销毁这两把钥匙。只删 Access Token用户会立刻掉线但前端的 Axios 拦截器发现 401 后会拿着 Refresh Token 偷偷去换把新钥匙用户莫名其妙“复活”了。只删 Refresh Token用户现在的 Access Token 还没过期比如还有 20 分钟这 20 分钟内他依然能非法访问接口。结论登出 删除 Redis与DB 中的 Access Token删除 DB 中的 Refresh Token。二、 代码实现 (Controller 层)Controller 层非常简单主要是提取请求头中的 Token并调用 Service。Tag(name管理后台 - 认证)RestControllerRequestMapping(/system/auth)publicclassAuthController{ResourceprivateAuthServiceauthService;PostMapping(/logout)Operation(summary登出系统)publicCommonResultBooleanlogout(HttpServletRequestrequest){// 1. 从 Header 中剥离出 Bearer xxxx 后面的 Token 字符串StringtokenSecurityFrameworkUtils.obtainAuthorization(request,Authorization,token);// 2. 只要 Token 不为空就执行登出逻辑if(StrUtil.isNotBlank(token)){authService.logout(token,LoginLogTypeEnum.LOGOUT_SELF.getType());}returnsuccess(true);}}三、 核心逻辑 (Service 层)这是登出业务的灵魂。我们需要在一个事务中完成三个动作。ServicepublicclassAuthServiceImplimplementsAuthService{ResourceprivateOAuth2TokenServiceoauth2TokenService;Overridepublicvoidlogout(Stringtoken,IntegerlogType){// 1. 核心动作移除访问令牌和刷新令牌OAuth2AccessTokenDOaccessTokenDOoauth2TokenService.removeAccessToken(token);// 2. (可选) 记录登出日志if(accessTokenDO!null){createLoginLog(accessTokenDO.getUserId(),logType,LoginResultEnum.SUCCESS);}}}四、 底层实现 (TokenService) —— 关键步骤详解这里我们展示oauth2TokenService.removeAccessToken的具体实现。ServicepublicclassOAuth2TokenServiceImplimplementsOAuth2TokenService{ResourceprivateOAuth2AccessTokenMapperoauth2AccessTokenMapper;// 操作 MySQL (Access)ResourceprivateOAuth2RefreshTokenMapperoauth2RefreshTokenMapper;// 操作 MySQL (Refresh)ResourceprivateOAuth2AccessTokenRedisDAOoauth2AccessTokenRedisDAO;// 操作 RedisOverrideTransactional(rollbackForException.class)// ⚠️ 开启事务保证原子性publicOAuth2AccessTokenDOremoveAccessToken(StringaccessToken){// 1. 先查库确认 Token 存在OAuth2AccessTokenDOaccessTokenDOoauth2AccessTokenMapper.selectByAccessToken(accessToken);if(accessTokenDOnull){returnnull;// 查无此人直接返回}// 2. 删除 MySQL 中的 Access Token (清理垃圾数据)oauth2AccessTokenMapper.deleteById(accessTokenDO.getId());// 3. 【关键】删除 Redis 中的 Access Token// 这一步最重要删了它用户的请求会被立刻拦截 (401)oauth2AccessTokenRedisDAO.delete(accessToken);// 4. 【斩草】删除 MySQL 中的 Refresh Token// 这一步防止“诈尸”防止前端利用 Refresh Token 自动续期oauth2RefreshTokenMapper.deleteByRefreshToken(accessTokenDO.getRefreshToken());returnaccessTokenDO;}}五、 思考为什么是这个删除顺序你会发现代码里的顺序是删 DB (Access) - 删 Redis (Access) - 删 DB (Refresh)。Q: 为什么不先删 Redis在 Spring 的Transactional事务机制下不会对Redis回滚如果先删了 Redis但在后续删除 DB 时报错了抛出异常事务回滚DB 里的删除操作被撤销数据恢复。Redis 无法回滚Redis 数据已经没了。结果用户被踢下线了因为 Redis 没了但 DB 里留了两条垃圾数据。Q: 现在的顺序有什么好处我们把 Redis 操作夹在 DB 操作中间或者放在最后。如果删 Redis 报错抛出异常事务回滚前面删 DB 的操作撤销。结果Redis 还在DB 也在。用户登出失败但数据是强一致的。最佳实践总结对于“登出”这种操作“删多了”导致用户下线永远比“删少了”用户本该下线却没下线要安全。所以无论哪种顺序只要保证Redis 一定被删掉即可。六、如果后端查询accesstoken时查询的redis那么为什么mysql数据库中也要存储accesstoken表只存 Redis 在技术上是行的但在业务管理和系统健壮性上是不够的。1. 复杂的运维管理需求最主要原因Redis 是Key-Value数据库它的查询能力非常弱。它只能通过 KeyToken查 Value用户信息。但后台管理员通常有以下需求Redis 很难高效实现“查看当前在线用户列表”需要分页显示所有有效的 Token。Redis 的KEYS *命令是性能杀手生产环境禁止使用使用SCAN又比较麻烦且难以排序。“查看某个用户登录了几个设备”需要SELECT * FROM token WHERE user_id 1。Redis 要做这个查询需要维护额外的 Set 索引开发复杂度高。“强制踢某个用户下线”管理员只知道用户的 ID例如 1024不知道他的 Token 是多少。如果只存 Redis你很难通过 ID 反查出 Token Key 并将其删除。而在 MySQL 里只需SELECT access_token FROM table WHERE user_id 1024拿到 Token 后再去 Redis 删除即可。结论MySQL 是为了方便管理员“查账”和“管理”的。2. 数据持久化与审计AuditRedis 是易失的虽然 Redis 有持久化RDB/AOF但它本质上是缓存。如果 Redis 集群崩溃或者被误清空所有用户的登录状态瞬间丢失全部被迫下线。MySQL 是持久的审计追踪安全审计可能需要查询“上周三中午 12 点IP 为 1.2.3.4 的请求是哪个 Token 发起的”。Redis 的 Token 过期就没了只有 MySQL 这种关系型数据库适合做长期的日志保留虽然 Access Token 短期会删但 Refresh Token 或登录日志通常保留较久。3. 系统架构的“兜底”原则在标准的架构设计中缓存Redis应该永远只是数据库MySQL的一份子集或加速层。Source of Truth单一真理来源系统应该有一个地方存储了全量、最准确的数据这个通常是 MySQL。灾难恢复极端情况下如果 Redis 彻底挂了且无法恢复虽然系统性能会降级但如果我们有 MySQL 备份理论上我们可以通过代码逻辑临时降级查 DB或者利用 DB 数据快速预热恢复缓存虽然 Access Token 这种短效数据通常不恢复但架构一致性上通常保持双写。