ShaoHua
58 lines
2.3 KiB
Markdown
58 lines
2.3 KiB
Markdown
# 06 - 云同步（基础可用）：安全（RBAC/二次认证）与“可控落盘”
|
|
|
|
## 目标（PRD 约束）
|
|
|
|
- 高风险操作支持二次认证（例如启用/关闭同步、切换账号、调整“是否允许落盘”等）
|
|
- 客户端读取服务端安全配置，决定任务信息是否允许落盘
|
|
- 当服务端标记“终端不可信/不允许落盘”时，客户端只能在内存中持有任务信息；退出应用后不保留任务数据
|
|
|
|
## 范围
|
|
|
|
- 客户端：落盘策略切换（持久化 ↔ 内存）、高风险操作二次确认/二次认证 UI
|
|
- 服务端：策略下发 + 二次认证挑战/校验接口（与 `04-*` 协作）
|
|
|
|
## 依赖
|
|
|
|
- 依赖 `04-*` 提供策略下发与二次认证能力（接口契约）
|
|
- 依赖 `06.1-*` 提供服务端底层安全实现（账户/密码/Token/策略存储）
|
|
- 依赖 `05-*` 的基础登录/同步 UI 入口
|
|
|
|
## 关键设计点（v1.2.0 必须明确）
|
|
|
|
### 1) “落盘”定义与边界
|
|
|
|
需要明确“哪些数据算落盘”，并在禁止落盘时全部避免：
|
|
- 任务数据（列表/详情）
|
|
- 同步状态（上次同步时间、待同步队列等）
|
|
- 登录凭据（token/refresh token/会话标识）
|
|
|
|
### 2) 本地存储抽象
|
|
|
|
建议把前端（或宿主）本地存储封装为可替换实现：
|
|
- 允许落盘：使用现有 localStorage/SQLite 等
|
|
- 禁止落盘：使用内存实现（刷新/退出即清空）
|
|
|
|
要求：
|
|
- 切换策略时行为可预期（例如从允许 → 禁止：立即清空已落盘数据并提示用户）
|
|
- 不在日志或 UI 中暴露敏感信息
|
|
|
|
### 3) 二次认证（挑战-响应）
|
|
|
|
建议采用“服务端驱动”的挑战流程：
|
|
- 客户端发起高风险操作
|
|
- 服务端返回“需要二次认证”的响应（包含 challenge 信息）
|
|
- 客户端弹出二次认证输入（例如二次口令/一次性验证码）
|
|
- 客户端携带证明再次提交
|
|
|
|
若服务端暂不支持二次认证，也需有“能力探测/降级提示”，避免客户端卡死。
|
|
|
|
## 验收标准
|
|
|
|
- 服务端返回 `allowPersist=false` 时：
|
|
- 客户端不会把任务数据与凭据写入任何持久化介质
|
|
- 退出应用后重新进入，任务数据为空（需重新登录/拉取）
|
|
- 对指定高风险操作：
|
|
- 无二次认证证明时被拒绝，并提示需要二次认证
|
|
- 提供正确二次认证后操作成功
|
|
|