feat: 多用户登录 —— 账号存 DB + session cookie + per-user 隔离

[mirror29]

背景

线上 dashboard.inalpha.dev 已对公网可达,但仍是单用户 dev 模式:BFF 用固定 sub=console:dev 自签 token,任何访客打开即等于作者本人(能看模拟盘/策略/会话)。本 PR 加一层简单登录关上入口,并把用户身份正规化。账号存数据库,暂不做注册(初始用户用 CLI 种入)。

改动(5 commit,逻辑拆分)

1. db — users 表迁移(subject=JWT sub / email / argon2 password_hash / roles)
2. paper — POST /auth/login(argon2 校验,放线程池不阻塞 live runner,抗时序枚举,失败统一 401)+ create_user.py CLI + 端到端测试
3. orchestration — 修复工具身份转发的遗留缺陷:resolveRequestToken 让 agent 的写操作(start_strategy / execute_plan / 下单)落到登录用户账户,而非此前恒落的 console:dev
4. dashboard — httpOnly session cookie(jose,7d)+ 登录页 + 中间件登录闸门 + copilotkit/会话/占卜/因子审批的 subject 统一改从 session 派生(读路径 per-user 隔离)
5. infra — AUTH_ENABLED 开关:本地默认 false(行为与加登录前完全一致),线上 true 强制登录

隔离链路(既有,零改动复用)

paper 已按 JWT sub 派生 account_id 隔离数据;登录只是把 subject 来源从固定 console:dev 换成登录用户,下游隔离自动生效。作者用 --subject console:dev 种账号即可继承现有模拟盘/会话历史。

验证

• 本地全流程 curl 通过:未登录 / → 307 跳登录 / 错密码 401 / 对密码 200 + Set-Cookie / 带 cookie 访问 200 / 登出清 cookie / 无 cookie 打受保护 API 401
• paper 4 个测试通过;orchestration + dashboard typecheck 通过;ruff / mypy 通过;check-consistency.sh 通过

上线顺序(避免把自己锁在门外)

① 部署使 migrate 跑 0024 建表 → ② create_user.py(作者 --subject console:dev)→ ③ 置 AUTH_ENABLED=true 重启 dashboard

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying inalpha-web with    Cloudflare Pages

Latest commit:	3d3cb68
Status:	✅  Deploy successful!
Preview URL:	https://21b71dd1.inalpha-web.pages.dev
Branch Preview URL:	https://feat-multi-user-login.inalpha-web.pages.dev

View logs

[claude]

3d3cb68 轮 review

一句话:多用户登录闭环(DB 账号 + argon2 + session cookie + per-user 隔离),前几轮 CR 已把节流并发竞态、LRU 绕过、IDOR(chat thread/pending-plan 越权)、429 透传、生产 fail-safe、密码留痕等问题逐个堵上,基础扎实。本轮补一个前几轮 CR 遗留的口子。

必修(major)

• packages/orchestration/src/auth.ts verifyToken/resolveRequestToken + mastra/index.ts identityMiddleware 未校验 token_use,可把泄露的 session cookie 在 mastra 层"洗"成合法 service token —— services/_shared/src/inalpha_shared/auth.py:get_current_user 这轮已加了 token_use==="session" 拒收(commit b794f2),理由是"session cookie 与 service token 同 secret、同形状,泄露可当长效后端凭据重放"。但这个校验只加在直接打 Python 的路径。packages/orchestration/src/mastra/index.ts:96 的 identityMiddleware 只用 verifyToken()(auth.ts:85,纯验签,不看 claim)解出 sub 塞进 AUTH_SUB_KEY;随后 resolveRequestToken(auth.ts:70)拿这个 sub 走 mintServiceToken({ sub }) 现铸一个全新、不带 token_use 的 service token 转发给 paper/data 等 Python 服务。
  • 失败场景:攻击者以任意方式拿到一份 inalpha_session cookie(XSS / 日志泄漏 / 中间代理),只要能连到 mastra:4111(内网互通;infra/docker-compose.prod.yml 注释里也写了"CF 控制台配 ingress 把 api.域名 → http://mastra:4111"这个备选拓扑,不是不可能被启用),带 Authorization: Bearer <session-cookie> 直接打 /api/agents/.../stream 或 scheduler/permissions API,identityMiddleware 会照单全收、按该用户 sub 打通所有 agent 工具(读全部会话历史、start_strategy/execute_plan/下单……),完全绕开这轮专门为"session cookie 当后端凭据重放"加的防线——Python 侧的 token_use 拒收对这条路径不起作用,因为 mastra 转发前已经重新铸造了一个"干净"的 token。
  • 依据:CLAUDE.md 通用原则·安全(§Step3.8 越权/不可信输入进危险路径)+ 本 PR 自己在 services/_shared/src/inalpha_shared/auth.py 建立的威胁模型(session token 不应被当 service token 用)——packages/orchestration 是同一威胁模型下遗漏的一层。
  • 建议:verifyToken/identityMiddleware 里同样拒收 payload.token_use === "session"(视为未认证,走现有"沿用 fallback"路径,不阻断请求,只是不注入 AUTH_SUB_KEY),使 session cookie 在 mastra 这一跳也失效。

可选优化(medium)

• apps/dashboard/src/proxy.ts 的 hasValidSession() 只验签名、不检查 token_use(与 session.ts:readSession() 的校验口径不一致)。实际不构成越权(下游 readSession() 仍会拒收非 session token 触发 401),但用一个不带 token_use 的 service token 当 cookie 能让 middleware "误判已登录"放行到页面 / API,再在更深层失败,排障体验比直接被 middleware 拦在登录页更差。建议 middleware 里也顺带判一下 token_use === "session",两处校验口径统一。

其余(节流原子性、LRU 淘汰、IDOR owns-check、生产 fail-safe、密码不留痕、429 透传)已在前几轮 CR 逐条修复,复核无遗留问题。

[mirror29]

第 5 轮 auto-review 指出聊天发送路径还有一个潜在 IDOR(mastra 侧未校验 threadId 归属)。评估为潜在、当前不可利用(threadId 是不可枚举 UUID、无分享/导出功能、不进 URL),已按讨论决定:本 PR 先合(已修读/改标题两处同根 IDOR + 一堆隔离加固),发送路径这条开 follow-up 单独跟踪 → #130(分享/导出会话功能前必修)。