JavaScript 不直接管理 Session,而是通过服务端注入的 Session 标识(如 Cookie 或 Token)及角色权限信息(如 role、permissions)实现会话维持与视图控制,但所有鉴权必须在后端执行。

JavaScript 本身不直接管理 Session,Session 是服务端概念;前端 JavaScript 主要通过携带服务端颁发的 Session 标识(如 Cookie 中的 sessionId 或 Token)来维持会话,并在请求中附带权限与角色信息——但关键在于:这些信息必须由后端安全地注入或返回,前端绝不应自行构造或篡改。
服务端注入角色信息到前端上下文
常见做法是后端在用户登录成功后,将角色、权限列表等非敏感字段(如 role: "admin"、permissions: ["user:read", "post:write"])写入 Session,并在首屏 HTML 或登录响应中一并返回:
- 服务端渲染页面时,把角色信息嵌入全局 JS 变量(如
window.__USER__ = {role: "editor", permissions: [...]}),前端可直接读取 - 登录接口(如
POST /api/login)返回 JSON,包含user字段,其中含role和permissions,前端存入内存或localStorage(注意:仅存展示/路由用,不用于鉴权)
每次请求自动携带 Session 标识
浏览器会自动在请求中带上同域下的 Cookie(含 sessionId),后端据此查 Session 并校验权限。JavaScript 无需手动传递 Session ID,但需确保:
抓取并分析 OpenClaw JSONL 会话日志,重建并回填代理记忆文件。适用于:(1) 模型切换后记忆不完整,(2) 验证记忆覆盖度,(3) 重建丢失记忆,(4) 通过 cron/heartbeat 自动同步每日记忆。支持简单提取及基于 LLM 的叙事摘要,并自动清理敏感信息。
- AJAX 请求启用
credentials: 'include'(fetch)或withCredentials = true(XMLHttpRequest),否则 Cookie 不发送 - 后端响应头设置
Access-Control-Allow-Credentials: true,且Access-Control-Allow-Origin不能为*(需指定具体域名)
前端做视图级权限控制(非安全边界)
JavaScript 可基于已知的角色/权限数据控制 UI 显示(如隐藏按钮、跳过路由),但这只是用户体验优化:
立即学习“Java免费学习笔记(深入)”;
- 用
role === 'admin'决定是否渲染「删除用户」按钮 - 路由守卫(如 Vue Router 的
beforeEach或 React Router 的useNavigation)检查user.permissions是否包含目标路由所需权限 - 切记:所有敏感操作(如删除、支付)的权限校验必须在后端重复执行,前端控制可被绕过
避免常见错误
- 不要在前端 localStorage 中存原始 Session ID 或 Token 后手动拼接到每个请求 header(易泄露且违背 Cookie 管理机制)
- 不要把权限逻辑全写在前端(如
if (user.role === 'guest') disableSubmit()),而无后端验证 - 不要用 JavaScript 解析或修改 Cookie 内容(Cookie 通常 httpOnly,JS 无法读取;即使能读,也不该解析加密 Session 数据)

















