怎样在ThinkPHP中实现用户会话Token自动续期【安全】

Token续期必须在每次合法请求时触发，不能依赖前端定时刷新或PHP原生session自动延长；核心是在认证中间件中校验通过后动态生成新JWT、更新Redis中token状态并删除旧键，同时通过响应头X-Auth-Token推送新token供前端更新。

Token续期必须在每次合法请求时触发，不是靠前端定时刷新

ThinkPHP 的 session_start() 默认不会自动延长会话有效期，单纯依赖 PHP 原生 session 机制会导致 Token 过期后用户突然登出。安全续期的核心逻辑是：只要用户本次请求通过身份校验（如 JWT 解析成功、或数据库 token 匹配有效），就生成新 Token 并更新过期时间，同时旧 Token 失效（防重放）。

• 不要在中间件里无条件调用 Session::set() 或写死 ini_set('session.gc_maxlifetime', ...) —— 这会延长所有会话，破坏时效性控制
• 推荐把续期逻辑放在登录态校验中间件中，且仅对非登录接口（如 /api/user/profile）生效；登录接口本身不续期，避免循环刷新
• 若使用 JWT，exp 字段必须每次动态计算（如 time() + 3600），不能复用原始 payload

用 Redis 存储 Token 并设置滑动过期时间

PHP 原生 file session 不适合 Token 续期场景：无法原子性地“读旧值 → 判有效性 → 写新值 → 删旧值”。Redis 是更稳妥的选择，配合 SETEX 和 DEL 操作可精确控制生命周期。

• Token 键名建议为 token:{user_id}:{device_fingerprint}，避免同一账号多端互踢时误删
• 续期时先用 GET 检查原 Token 是否存在且未被标记为失效（可用哈希字段 status 标记 invalid）
• 新 Token 写入用 SETEX token:{new_id} 7200 {jwt_string}，7200 秒是滑动窗口上限，实际每次续期都重置 TTL
• 务必在写入新 Token 后立即 DEL 旧键，否则存在短暂双 Token 窗口，增加重放风险

ThinkPHP 中间件里如何安全执行续期

在 app/middleware/CheckAuth.php 中，完成校验后插入续期动作，而不是在控制器里做——否则容易遗漏或重复执行。

• 从请求头取 Authorization，提取 Bearer 后的 token 字符串，用 JWT::parse($token) 验签并检查 exp 和 nbf
• 验证通过后调用自定义方法 $this->renewToken($userId, $deviceFp)，该方法生成新 JWT、存入 Redis、返回新 token 字符串
• 用 Response::header('X-Auth-Token', $newToken) 推送新 Token 到响应头，前端需监听该 header 并覆盖本地存储
• 禁止直接修改 $_SESSION 或调用 Session::id() —— ThinkPHP 的 Session 封装与 Token 续期无关，混用会导致状态混乱

前端必须配合处理响应头中的新 Token

很多团队只改后端，结果续期形同虚设：前端仍发送旧 Token，服务端虽生成了新 Token 却无人接收。

立即学习“PHP免费学习笔记（深入）”；

• Axios 全局响应拦截器里检查 response.headers['x-auth-token']，存在则更新本地 localStorage.setItem('token', ...)
• 注意：如果前端用 credentials: 'include' 发送 Cookie，而服务端又同时写入 Session，会造成认证凭据冗余甚至冲突，建议统一走 Header Token
• 首次请求无 X-Auth-Token 头是正常的；但连续两次请求都没收到新头，就要排查中间件是否跳过了续期逻辑（比如游客路由未进 CheckAuth）

滑动过期真正起效的前提，是前后端对 Token 生命周期的理解一致——后端不主动踢人，前端不缓存过期值，Redis 键的 TTL 才有意义。任何一环断开，所谓的“自动续期”就只是个后台日志里的空转操作。