# 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 的迁移路径

1. 新增 `/api/auth/login` 接口，接收用户名密码，返回 JWT
2. 新增 JWT 中间件，验证令牌并注入 `req.user`
3. 保留 header `x-user-role` 作为兼容层（降级方案）
4. 前端将 token 存储于 `localStorage` 或 `httpOnly` Cookie
5. 移除前端 role-switcher，替换为登录页

## 风险

- **选项 A 当前风险**：任何人可以通过修改 header 访问任意角色数据
- **缓解**：当前环境为本地开发/内网，不暴露于公网；上线前必须完成 JWT 改造
- **硬编码人员**：`server/index.js` 中的 `identities` 对象需改为从数据库读取真实用户表