2 Commits

Include renames

Author	SHA1	Message	Date
lzf_0626	5018f11843	增加投顾（advisor）角色；修正登录测试的错误假设；修投顾带入的 2 处文档重号 ... ## 投顾角色 投顾线合并后，bootstrap.py 有 10 处 allowed_roles 引用 advisor， financial_nl2sql_service.py:272 还硬编码检查 {"advisor","operator","admin","super_admin"}， promotion_material_service.py:164 按 "advisor" in context.roles 走业务分支 —— 但 sys_role 里没有这个角色、sys_permission 里也没有投顾那 16 个权限码（种子只建到 9019）。 表现是所有投顾接口 403，而报错看起来像"权限配错了"，实际是角色根本不存在。 - tools/grant_advisor_role.py：建 advisor 角色（id=9004，避开种子的 9001-9003 重建范围） + 16 个投顾权限（id 9020-9035）+ 授权（advisor 拿 10 项工作流、admin 补齐 16 项）。 只增不删、可重复执行、带 --dry-run。 - tools/create_test_user.py：ROLE_IDS 加 advisor。 - 先跑 alembic upgrade head：补 21 张 advisor_* 表，业务表 68 → 89，审计通过。 权限划分：投顾工作流 10 项（read:self / generate:self / review / publish）给 advisor； 治理类 6 项（product-governance:*、profile-governance:*、asset-allocation:backtest）只给 admin。 review/publish 也给 advisor，与既有决策一致（此前已裁定不做双人复核）。 验证：advisor_t 登录 200，roles=['advisor'] data_scope=all 权限 10 项； 用它查 RBAC 清单得 403（没有 audit:read），边界正确。 ⚠️ 与种子的冲突：seed_test_rbac.py 是 DELETE 重建语义，其 DELETE FROM sys_permission WHERE id BETWEEN 9001 AND 9099 会清掉本脚本建的权限。 要把投顾权限固化，应并进 seed_test_rbac.py 的 PERMISSIONS 常量。 ## 修正登录测试的一个错误假设 test_issued_token_actually_works_on_a_real_endpoint 原本用客户的 /users/me/memory-profile 验证令牌可用，投顾合并后它返回 403。追下去发现**与令牌无关**： 那个接口对客户有业务前置"请先完成开户风险测评问卷"，而演示客户 9001 没有测评记录。 是我的测试选错了验证端点，把"业务前置未满足"误判成"令牌坏了"。 - 改用管理员令牌调 /api/v1/admin/roles（需要 audit:read，走完整鉴权链路）， 并补一条反向对照：不带令牌必须 401，否则那个 200 说明不了令牌有效。 - 把那个业务前置单独写成一个用例，让后来者一眼看到条件，而不是反复怀疑令牌。 过程里我先按控制台乱码猜了两次失败原因，都不对；最后把响应抓成 UTF-8 文件才看到真实 消息。教训记下：不要读乱码猜消息。 ## 修投顾带入的 2 处文档重号 21-投顾Agent迁移TODO.md → 30-…、22-投顾Agent灰度与回滚操作手册.md → 31-… （沿用 NL 那次让号的先例：既有文档更早、引用更多；且这两份新文档没有被任何地方引用。） 文档守卫：40 份无编号冲突。 验证：ruff 干净 / mypy 228 文件 0 错 / 文档守卫 40 份无冲突 / unit+contract 1207 passed（0 failed）/ integration 99 passed / 业务表 89 张。	2026-09-11 21:49:46 +08:00
lzf_0626	01ee68034d	新增登录接口：账号密码换访问令牌（POST /api/v1/auth/tokens） ... 背景：客户 / 员工 / 管理员三种身份此前无法区分。但区分逻辑其实早就完备 —— bootstrap.py 里各 Agent 的 allowed_roles 一直是分开的（CustomerServiceAgent 只要 customer、RiskAgent 要 risk_operator/admin、PlatformProbeAgent 只要 admin）， 唯独缺"怎么证明你是谁"；sys_user.password_hash 字段也一直存在，只是全是占位符 （种子写 'x'、worker 身份写 !worker-only-no-password-login!），从没写过真实密码。 实现： - app/service/auth_service.py：bcrypt 校验 + 签发只含 sub 的 JWT + 审计。令牌里只放 sub 是刻意的：角色/权限/数据范围由 IdentityService 每次请求查库解析 （identity_repository.load_context），权限变更因此立即生效，现有鉴权链路一行未改。 - app/api/controllers/auth.py + app/api/schemas/auth.py：POST /api/v1/auth/tokens， 响应含 roles/data_scope 供前端决定进哪个界面（鉴权仍以库里实时数据为准）。 - tools/set_user_password.py：设密码（客户 123456 / 员工 666666 / 管理员 88888888）。 ⚠️ 脚本与文档均标注"仅限演示环境"，这三种弱口令上线前必须更换。 - pyproject / requirements 加 bcrypt（cryptography 只用于 JWT，不提供密码哈希）。 安全约定（逐条有实现与测试）：失败不区分原因 —— 用户不存在/密码错/账号停用返回同一条 401，否则接口就成了账号枚举器；用户不存在时也跑一次 bcrypt 以抹掉时序差异； 成功与失败都写 interaction_audit（actor_id 可空正是为失败场景准备的）；绝不记录密码。 过程中踩到一个自己挖的坑：给登录路由挂了通用的 enforce_rate_limit，而它声明依赖 build_request_context ⇒ 变成"要登录先登录"，所有登录都 401。改为新增 enforce_login_rate_limit：按客户端 IP 独立限流（60 秒 10 次）、不依赖认证上下文。 集成测试据此调整：注入恒放行替身隔离跨用例的计数累积，同时保留一个恒超限用例验证闸门 确实会拦 —— 不能因为加了替身就把这道防线测丢。 接口登记：docs/05 §19 加 A034；并更新 §11 —— 那里原写"JWT 签发、刷新、注销由统一身份 认证模块负责，Agent 平台不重复实现"，现注明平台只做登录这一步，刷新/注销仍归该模块。 验证：ruff 干净 / mypy 183 文件 0 错 / 文档守卫 37 份无重号（此前因 docs/21 重号失败）/ unit+contract 1140 passed / integration 90 passed。	2026-09-11 20:43:21 +08:00