websocket连接必须在握手阶段验证身份，因协议不自动携带cookie或session，需通过url参数传短期jwt、upgrade前校验token或复用http session，验证后绑定用户信息至socket实例。
WebSocket 本身不自动携带 Cookie 或 Session 信息，所以不能直接复用 HTTP 请求中的 session（比如 Express 的 req.session）。但你可以通过几种安全、可靠的方式在 WebSocket 连接建立时完成身份验证，把用户身份和 WebSocket 连接绑定起来。
连接前用 HTTP 获取并传递 Session 标识
这是最常用也最稳妥的做法：客户端先完成登录（HTTP 请求），服务端设置 Session（如写入 Cookie），然后在建立 WebSocket 连接时，把 Session ID 或 Token 作为参数传过去。
- 前端建立 WebSocket 时，从
document.cookie提取connect.sid（Express 默认 Session Cookie 名）或使用已有的 JWT Token - 拼接 URL 参数，例如：
new WebSocket("wss://example.com/ws?token=xxx")或?sid=abc123 - 后端 WebSocket 服务器（如
ws或socket.io）在connection事件中解析 query 参数，再校验 Session 或 Token 的有效性
用中间件在 upgrade 阶段校验 Session
如果你用的是 Node.js + Express + ws 库，可以在 HTTP upgrade 请求阶段拦截并复用 Express 的 Session 中间件。
- Express 的 Session 是基于
req和res的，而 WebSocket 的upgrade是一个原始 HTTP 请求对象 - 手动调用
sessionMiddleware(req, res, callback)，让 Session 解析 Cookie 并挂载req.session - 校验
req.session.userId是否存在且有效；若失败，调用socket.destroy()拒绝连接 - 验证通过后，把
req.session或用户信息缓存到 WebSocket 实例上（如socket.userId = req.session.userId）
用 Token 替代传统 Session 更适合长连接
WebSocket 是长连接，Session 有超时机制，而 Token（尤其是 JWT）可自定义过期时间，更适合无状态验证。
- 登录成功后，服务端签发一个带用户 ID、角色、过期时间的 JWT，返回给前端
- 前端在 WebSocket 连接 URL 中带上该 Token（
wss://.../ws?token=eyJhb...）或首次send()一条认证消息 - 服务端用密钥验证签名、检查有效期，并解析出用户身份，保存在 socket 上供后续通信使用
- 相比 Cookie Session，Token 不依赖 Cookie，跨域更灵活，也避免了 CSRF 风险
避免常见陷阱
几个容易出错但影响安全的关键点：
- 不要在 WebSocket 消息里反复传密码或明文凭证 —— 认证只做一次，在连接建立时完成
- 不要把 Session ID 当作长期凭证暴露在 URL 中 —— 如果必须放 query，建议搭配短期有效 Token 或一次性 use-once ticket
- WebSocket 连接建立后，仍需对敏感操作二次校验权限 —— 比如收到“删除消息”指令时，检查当前 socket 绑定的用户是否有该房间的操作权
-
注意跨域场景下 Cookie 不会自动发送 —— 若前端域名与后端不同，需设置
credentials: include和响应头Access-Control-Allow-Credentials: true
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
