Cookie不适合做动态权限校验的数据载体，因其存在安全性、时效性和可控性三方面硬伤；应仅存短期有效的session_id，权限数据完整存储于服务端（如Redis），每次请求时由后端查证并校验。
Cookie本身不适合做动态权限校验的数据载体，因为它存在安全性、时效性和可控性三方面硬伤。真正安全的做法是：用 Cookie 仅存一个无意义的、短期有效的会话标识（如 session_id），而把权限数据（角色、菜单、接口白名单等）完整存在服务端（如 Redis），每次请求时由后端根据该标识查出对应权限并完成校验。
为什么不能把权限数据直接写进 Cookie
把权限信息（比如 {"role":"admin","permissions":["/user/edit","/order/delete"]}）加密后塞进 Cookie 看似方便，但实际风险很高：
- 客户端可篡改：即使加了签名或简单加密，前端仍可能通过调试工具伪造 Cookie 内容，绕过权限控制；
- 无法实时失效：用户权限变更（如被降权）后，已下发的 Cookie 在过期前始终有效，后端无法主动作废；
- 大小和传输开销：权限数据随每次 HTTP 请求自动携带，增大请求头体积，也增加解析负担；
- 敏感信息暴露风险：若加密方式薄弱或密钥泄露，权限逻辑可能被逆向分析。
推荐做法：Cookie 只传 session_id，权限查服务端
标准且安全的流程如下：
Ai Coach Batch Session Summary
下载
批量分析录音转写，输出多维度拓客报告。触发词：录音分析、总结、音频总结、拜访记录总结。当用户提及「分析录音」「看看录音数据」「最近的录音」「通话记录」且意图为批量统计/分析时触发。仅出现「录音」或「拜访」时需结合上下文，若仅查看单条详情则不触发。
- 登录成功后，后端生成唯一
session_id（如 UUID），存入 Redis，键为session:{id}，值为该用户的完整权限数据（JSON 格式）和过期时间； - 通过
Set-Cookie下发该session_id，设置HttpOnly、Secure、SameSite=Strict等安全属性； - 后续每个受保护接口，后端从 Cookie 中读取
session_id，查 Redis 获取权限，再比对当前请求路径/方法是否被允许； - 用户登出或权限变更时，直接删除 Redis 中对应的 session 记录，实现即时生效。
前端能做的辅助配合
前端不参与权限决策，但可以提升体验和安全性：
立即学习“Java免费学习笔记（深入）”；
- 路由守卫中，根据后端返回的权限数据（如登录后一次性拉取的
menuList或permissionList）做前端菜单过滤和按钮显隐，但这只是“掩码”，不是校验； - 所有 API 请求统一在拦截器中带上 Cookie，不手动拼接权限字段；
- 监听 403 响应，触发自动登出或提示“权限不足”，避免用户误操作；
- 避免 localStorage/sessionStorage 存储角色或权限字段用于判断——它们一样可被篡改。
特殊情况下的轻量级方案（仅限低敏感场景）
如果项目极小、无后台权限系统、且对安全性要求不高（如内部工具），可考虑用 Signed Cookie：
- 后端用密钥对权限对象做 HMAC 签名，拼成
payload.sig存入 Cookie； - 每次请求时验证签名有效性，并检查 payload 中的
exp时间戳； - 仍需限制权限字段粒度（只放角色名，不放具体接口列表），并设置较短过期时间（如 30 分钟）；
- 明确告知团队：这不是生产级方案，上线前必须升级为服务端校验。
