workerman需手动实现jwt校验、刷新及存储:解析authorization头、用firebase/php-jwt校验签名与exp、redis存refresh_token哈希、websocket主动推送过期提醒、多进程下确保redis操作原子性与一致性。

Workerman 本身不内置 JWT 支持,也无自动刷新逻辑 —— 所有 Token 校验、续期、存储都得你自己写中间件和路由,否则就是裸奔。
JWT 验证必须手动解析,不能依赖框架自动拦截
Workerman 是纯异步 PHP 长连接框架,没有 Laravel 或 ThinkPHP 那样的中间件生命周期。你不能指望 $request->header('Authorization') 被自动解析成用户对象;每次收到 WebSocket 或 HTTP 请求,都得显式调用 JWT 库(如 firebase/php-jwt)做三件事:
- 从
Authorization头或请求体中提取 token 字符串(注意前缀可能是Bearer) - 用
JWT::decode()解析并校验签名、iss、aud、exp,捕获ExpiredException或SignatureInvalidException - 若校验失败,直接
$response->withStatus(401)并返回错误,别往下走业务逻辑
常见坑:exp 是 Unix 时间戳,但 PHP 的 time() 返回的是秒级整数,而某些 JWT 库(如老版本 firebase)默认用毫秒比对,会导致“明明没过期却报错”。务必确认你用的库是否要求传入 time() * 1000。
Refresh Token 必须存服务端,不能只靠客户端传
前端传来的 refresh_token 字符串,不能直接信任 —— 它必须对应一条可查、未失效、未被撤销的记录。Workerman 没有内置 session 或 Redis 封装,所以你要自己接入:
- 用
Redis存储 refresh token(key 为refresh:{user_id},value 为 token 哈希值,带 TTL) - 登录成功时生成一对 token:
access_token(短时效,如 15 分钟) +refresh_token(长时效,如 7 天),把refresh_token的哈希存 Redis,原值只返回给前端 - 刷新接口(如
/api/refresh)收到请求后,先查 Redis 是否存在且匹配该哈希;存在才签发新access_token,并可选更新refresh_token(滑动过期)
关键点:不要把 refresh_token 明文存数据库;存的是 hash_hmac('sha256', $token, $secret),防止 Redis 被拖库后直接盗用。
WebSocket 场景下 Token 续期要主动推送,不能等下次请求
HTTP 请求可以靠 401 触发前端刷新,但 WebSocket 是长连接,access_token 过期后连接不会断,后续发消息仍会校验失败。你得在服务端主动干预:
- 每次收到 WebSocket 消息时,解析
access_token的exp字段,算出剩余秒数($exp - time()) - 若剩余 $connection->send() 推送一个自定义事件(如
{"type":"token_expiring_soon","expires_in":298}) - 前端监听该事件,在倒计时归零前调用刷新接口,并用新 token 替换后续所有
send()携带的认证头(WebSocket 不支持动态改 header,所以需在消息体里附带新 token 或走独立鉴权通道)
注意:Workerman 的 $connection 对象不保存用户上下文,你得在握手阶段完成鉴权,并把 user_id 和当前 access_token 的 exp 时间存到 $connection->session 或全局数组里,否则每次收包都得重新解析 token。
并发刷新时容易出现 Token 覆盖或重复发放
用户开多个标签页,或网络抖动导致多个刷新请求几乎同时到达,可能让旧 refresh_token 被多次使用,或新 access_token 被覆盖。解决方法只有两个:
- Redis 操作必须原子化:用
GETSET或 Lua 脚本先取旧值再设新值,确保同一refresh_token只能成功刷新一次 - 刷新成功后立即将原
refresh_token从 Redis 删除(DEL),强制前端下次必须用新返回的refresh_token,避免“一钥多刷”
最容易被忽略的是:Workerman 多进程模型下,Redis 连接不是共享的,每个 Worker 进程需独立维护 Redis 实例(或用 Swoole Table 共享状态),否则 refresh_token 撤销操作可能只在某个进程生效,其他进程仍能校验通过。











