Sa-Token 框架中登录状态获取异常问题解析

问题背景

在使用 Sa-Token 框架进行用户认证时，开发者遇到了一个典型问题：用户登录成功后，通过 StpUtil.getTokenInfo() 获取的 token 信息中 isLogin 字段始终为 false。同时，在后续请求中检查登录状态的接口也返回未登录状态。

问题分析

1. 自定义上下文实现

Sa-Token 框架允许开发者自定义上下文实现以适应不同的 Web 框架。在本案例中，开发者使用了 Javalin 框架，并实现了以下核心组件：

• SaTokenContextImpl：连接 Sa-Token 与 Javalin 的桥梁
• SaRequestImpl：处理 HTTP 请求相关操作
• SaResponseImpl：处理 HTTP 响应相关操作
• SaStorageImpl：负责 token 的存储管理

2. 关键问题点

经过深入分析，发现问题的根源在于两个方面：

1. SaStorage 实现问题：最初实现的 SaStorage 没有正确持久化 token 信息，导致登录状态无法保持
2. 请求头配置问题：即使解决了存储问题，后续请求中未正确配置 token 请求头，导致框架无法识别用户身份

解决方案

1. 修复 SaStorage 实现

原始的 SaStorageImpl 仅使用了内存存储，这会导致：

• 不同请求间的 token 信息无法共享
• 服务器重启后 token 信息丢失

修正后的实现应当：

• 使用分布式缓存或持久化存储（如 Redis）
• 确保存储操作是线程安全的
• 实现合理的过期策略

2. 正确配置请求头

Sa-Token 默认使用 "satoken" 作为 token 名称，开发者需要：

1. 登录接口：确保登录成功后返回的 token 信息中包含有效的 token 值
2. 后续请求：
   • 如果使用 Cookie 方式，浏览器会自动携带
   • 如果使用 Bearer Token 方式，需要在请求头中添加：

     Authorization: Bearer <token值>
     

   • 或者使用自定义头：

     satoken: <token值>
     

最佳实践建议

1. 存储层实现：

   • 生产环境建议使用 Redis 等分布式缓存
   • 实现适当的序列化机制
   • 考虑添加本地缓存作为二级缓存

2. token 传输：

   • 明确文档说明 token 的传输方式
   • 考虑安全性，推荐使用 HTTPS + HttpOnly Cookie
   • 为移动端提供 Bearer Token 支持

3. 调试技巧：

   • 启用 Sa-Token 的详细日志
   • 使用拦截器打印请求头信息
   • 编写单元测试验证存储层实现

总结

Sa-Token 作为一个灵活的认证授权框架，其强大之处在于可以适配各种 Web 框架。但在自定义实现时，开发者需要特别注意：

1. 存储层的正确实现是保持登录状态的基础
2. 前后端需要就 token 的传输方式达成一致
3. 完善的日志系统能快速定位认证问题

通过解决这两个关键点，开发者可以构建出稳定可靠的认证系统，充分发挥 Sa-Token 框架的优势。