共计 2070 个字符,预计需要花费 6 分钟才能阅读完成。
1. Sa-Token 认证流程与 Token 机制简介
Sa-Token 是一个轻量级 Java 权限认证框架,其核心思想是通过 Token 实现会话管理。Token 本质上是服务器颁发给客户端的一个凭证,用于标识用户身份。框架默认采用 JWT 形式存储 Token,但支持灵活扩展。

认证流程分为三步:
- 用户登录成功后,服务器生成 Token 并返回给客户端
- 客户端后续请求携带该 Token
- 服务端验证 Token 有效性,通过后允许访问
NotLoginException 是框架在检测到无效 Token 时抛出的运行时异常,通常意味着认证流程中断。
2. NotLoginException 触发场景深度分析
2.1 Token 过期
这是最常见场景。Sa-Token 默认 Token 有效期为 30 天(v1.30.0),可通过配置修改:
// 设置 Token 有效期,单位:秒
SaManager.getConfig().setTimeout(60 * 60 * 24 * 7); // 7 天
过期后框架会抛出异常,源码中对应 StpLogic.checkLogin() 方法的时间校验逻辑。
2.2 跨域问题
当前后端分离架构下,若未正确配置 CORS,可能导致:
- 浏览器无法存储 Token
- 请求未携带 Token
- 预检请求失败
2.3 多端登录冲突
当同一账号在不同设备登录时,默认配置会踢掉前一个登录态。可通过以下配置改为共存:
// 允许同一账号并发登录
SaManager.getConfig().setIsConcurrent(true);
3. 解决方案与实现
3.1 Token 自动续期方案
适用场景 :需要延长用户活跃会话的场景
// 配置自动续期(框架内置功能,只需开启)SaManager.getConfig().setAutoRenew(true);
// 自定义续期策略
@Component
public class CustomTokenRenew implements SaTokenAction {
@Override
public void renewTimeout(Object loginId, String tokenValue, long timeout) {
// 仅当剩余时间不足 50% 时续期
if(timeout < SaManager.getConfig().getTimeout()/2) {StpUtil.renewTimeout(loginId, timeout);
}
}
}
注意事项 :
– 频繁续期会增加 Redis 压力
– 敏感操作应强制重新认证
3.2 多端登录适配方案
适用场景 :支持用户多设备同时在线
// 配置不同端互不干扰(示例:PC 端和移动端)StpUtil.getStpLogic("pc").setIsConcurrent(true);
StpUtil.getStpLogic("mobile").setIsConcurrent(true);
// 获取当前设备类型
String device = request.getHeader("Device-Type");
StpUtil.login(userId, device); // 按设备类型登录
3.3 自定义 Token 解析
适用场景 :需要兼容旧系统或特殊 Token 格式
// 实现自定义 Token 生成与解析
public class CustomTokenTemplate implements SaTokenTemplate {
@Override
public String createToken(Object loginId, String device) {return "CustomPrefix-" + UUID.randomUUID();
}
@Override
public Object parseToken(String token) {if(!token.startsWith("CustomPrefix-")) {throw NotLoginException.INVALID_TOKEN;}
return token.substring(12);
}
}
// 注册自定义实现
SaManager.setSaTokenTemplate(new CustomTokenTemplate());
4. 生产环境避坑指南
- Token 存储策略 :
- 生产环境务必使用 Redis 等集中存储
-
避免本地缓存导致集群环境下会话不一致
-
续期机制 :
- 敏感操作(如支付)前强制检查 Token 新鲜度
-
设置最大续期次数防止无限延长会话
-
安全防护 :
- 启用 Token 签名校验(默认开启)
-
定期轮换签名密钥
-
监控报警 :
- 监控 NotLoginException 发生频率
-
异常突增时及时排查
-
降级方案 :
- 准备 OAuth2 等备用认证方案
- 核心链路允许临时令牌补发
5. 延伸思考
- 如何实现基于地理位置的安全认证?当检测到登录地变更时,是否应该强制重新认证?
- 在微服务架构下,如何优化 Token 的校验性能?是否可以采用局部校验 + 异步全量校验的组合方案?
- 对于超高并发系统,如何设计 Token 的黑名单 / 灰名单机制?
通过本文的分析和解决方案,开发者应该能够有效处理 Sa-Token 中的认证异常。框架的灵活设计允许我们根据实际业务需求定制认证策略,这是其相比传统安全框架的优势所在。
正文完
