2.0 KiB
2.0 KiB
ADR-RSMS-002:认证方案
ADR 编号:ADR-002 状态:已决策(角色模拟) 日期:2026-08-01 项目:RSMS
背景
系统需要识别用户身份并实施数据权限隔离。在 MVP 阶段无需接入真实身份认证体系,但需设计一个可升级的认证架构。
选项
| 选项 | 描述 | 适用阶段 |
|---|---|---|
| A. 角色模拟(header 传参) | 前端切换角色,HTTP header x-user-role 传递值,后端按值查询数据 |
MVP / 演示 |
| B. Session + Cookie | 后端维护 session,基于用户名密码登录 | 首版上线 |
| C. JWT Token | 无状态令牌,携带用户 ID 和角色,可扩展 | 生产环境 |
| D. 微信 OAuth2 | 微信账号登录,与人员档案绑定 | 移动端小程序 |
决策
MVP(当前):选项 A — 角色模拟(header 传参)
二期目标:选项 C — JWT Token + 真实登录
三期目标:选项 D — 微信 OAuth2(若实现小程序端)
选项 A 的实施
前端 role-switcher(<select>)
↓
x-user-role: headquarters | station | reporter
↓
后端中间件读取 header → 注入 req.user 对象
↓
数据访问层按 req.user.role + req.user.station + req.user.name 过滤
- 优点:零门槛,无需注册账号;方便演示和开发测试
- 缺点:安全性极低,header 可被任意伪造;仅适合内部演示环境
升级至 JWT 的迁移路径
- 新增
/api/auth/login接口,接收用户名密码,返回 JWT - 新增 JWT 中间件,验证令牌并注入
req.user - 保留 header
x-user-role作为兼容层(降级方案) - 前端将 token 存储于
localStorage或httpOnlyCookie - 移除前端 role-switcher,替换为登录页
风险
- 选项 A 当前风险:任何人可以通过修改 header 访问任意角色数据
- 缓解:当前环境为本地开发/内网,不暴露于公网;上线前必须完成 JWT 改造
- 硬编码人员:
server/index.js中的identities对象需改为从数据库读取真实用户表