# 结果提取与用户权限审计（2026-06-30）

## 1. 审计范围

本次审计聚焦“结果提取”相关入口和用户权限边界，覆盖：

- 前端结果提取工作台：`frontend/src/ResultExtractionPanel.jsx`
- D-InSAR 结果管理页：`frontend/src/DinsarProductsPanel.jsx`
- D-InSAR 结果导出接口：`POST /api/dinsar-results/export`
- D-InSAR 生产结果提取与登记接口：`POST /api/idl/extract-disp`
- 用户与权限模型：`auth_users.role`、全局认证守卫、用户管理页

本次文档只记录审计结论和后续设计约束，不包含代码修复。

## 2. 当前实现事实

### 2.1 两条“提取”链路

当前系统里“结果提取”实际包含两种不同语义：

1. **生产结果入库**
   - 前端入口：`DinsarProductsPanel.jsx`
   - 后端入口：`POST /api/idl/extract-disp`
   - 后台任务：`EXTRACT_DINSAR_PRODUCTS`
   - 作用：从生产目录提取 D-InSAR 位移结果，发布成标准结果包，并重建结果 catalog。

2. **成果交付导出**
   - 前端入口：`ResultExtractionPanel.jsx`
   - 后端入口：`POST /api/dinsar-results/export`
   - 作用：从已经登记的 D-InSAR catalog 中选择成果，复制到服务器指定交付目录。

这两条链路目前在产品文案上都叫“提取”，容易让用户混淆“入库”和“交付”。

### 2.2 当前接入状态

`ResultExtractionPanel.jsx` 中的通道状态：

| 通道 | 当前状态 | 说明 |
| --- | --- | --- |
| D-InSAR 结果 | 已接入 | 支持查询已登记结果并导出到服务器目录 |
| SBAS-InSAR 结果 | 半接入 | 可读取目录样例，但统一提取接口未实现 |
| LT-1 正射结果 | 占位 | 单景/正射结果 catalog 与导出链路未完成 |
| Sentinel-1 正射结果 | 占位 | 生产和导出链路未完成 |
| GF3 SARscape `_geo` | 占位 | 登记/标准化思路存在，统一导出接口未完成 |

## 3. 当前权限模型

系统当前只有两类角色：

- `admin`
- `viewer`

定义位置：`backend/app/auth_service.py`

全局认证守卫位于 `backend/app/routers/dependencies.py`：

- `GET / HEAD / OPTIONS` 默认视为只读操作，登录用户可访问。
- 除少数显式安全 POST 外，非只读请求要求 `admin`。
- 非管理员执行写操作会被拒绝，返回 `403 Read-only account cannot perform this operation.`

前端在 `App.jsx` 中把非管理员账号映射为 `readOnly`：

- viewer 可以浏览结果、查看任务、查看 catalog。
- viewer 不能提交生产、扫描、提取、导出、删除、修改。
- admin 拥有所有写权限，包括生产、扫描、结果入库、结果导出、用户管理和运维配置。

后端没有依赖前端按钮禁用来保护写操作。`/api/idl/extract-disp` 和 `/api/dinsar-results/export` 都显式要求 `admin`，这一点是正确的。

## 4. 审计发现

### P1：成果交付权限与系统管理员权限耦合过重

当前只有 `admin` 能执行成果导出，但 `admin` 同时拥有用户管理、系统配置、生产扫描、删除记录等高权限。

从业务职责看，成果交付导出不应天然等同于系统管理员权限。后续应拆出更细的权限，例如：

- `operator`：可提交生产任务、结果入库、目录重建。
- `exporter`：可导出已登记成果到受控交付目录。
- `viewer`：只读浏览、预览、查询。
- `admin`：用户管理、系统配置、根目录维护、许可证和高风险运维。

### P1：结果导出是同步请求，存在 504 风险

`POST /api/dinsar-results/export` 在请求线程内执行文件复制，最多允许 500 个结果 ID。成果文件较大或目标目录较慢时，容易再次触发前端或 Nginx 超时。

后续应改成后台任务：

- 接口只创建任务并返回 `task_id`。
- 文件复制由 worker 执行。
- 前端通过任务中心/结果提取工作台展示进度、成功数、失败数和目标目录。

### P1：生产结果入库缺少显式操作审计

`/api/dinsar-results/export` 已写入 `dinsar_results_exported` 审计日志。

`/api/idl/extract-disp` 当前会创建系统任务，但缺少独立的操作审计记录。它会改变结果 catalog，应记录：

- 操作用户
- 源生产目录
- 目标发布目录
- 创建的 `task_id` / `job_id`
- 完成后的 processed/copied/failed/published/registered 数量

### P2：页面命名和工作流边界不清

当前“D-InSAR 结果提取与登记”和“结果提取工作台”容易混淆。

建议命名：

- “生产结果入库”：从生产目录提取并登记为系统 catalog。
- “成果交付导出”：从已登记 catalog 选择成果并复制到交付目录。

这两个动作应该放在同一结果管理域下，但用不同分区和不同权限提示。

### P2：占位通道需要降低可执行暗示

SBAS、LT-1 正射、Sentinel-1 正射、GF3 `_geo` 目前不应被呈现成可执行导出能力。

建议 UI 明确显示：

- `已接入`
- `目录可查，导出未接入`
- `规划中`
- `不可执行`

并隐藏或禁用导出按钮，避免用户误以为功能已经上线。

### P2：导出目录策略需要产品化

当前后端已有 `_validate_export_path()` 和 `ALLOWED_EXPORT_DIRS` 约束能力，但前端仍允许用户输入服务器绝对路径。

后续建议：

- 普通业务用户不输入任意服务器路径。
- 管理员在系统配置中维护“交付目录白名单”。
- 结果导出页只让用户选择白名单目录和子任务名。
- 审计记录保存最终解析后的服务器路径。

### P3：部分前端文案存在历史编码损坏

`DinsarProductsPanel.jsx`、`ResultExtractionPanel.jsx`、`UserAdminPanel.jsx` 等文件存在局部中文乱码。功能不一定受影响，但会降低维护性和产品可信度。

建议后续单独做一次 UTF-8 文案修复，不与权限重构混在同一次提交中。

## 5. 建议目标模型

### 5.1 功能分区

结果管理应拆成三个清晰分区：

1. **产品目录**
   - 查看已登记成果。
   - 预览、筛选、查看详情。
   - viewer 可访问。

2. **生产结果入库**
   - 从生产结果根目录扫描、提取、发布、登记。
   - operator/admin 可执行。

3. **成果交付导出**
   - 从 catalog 选择成果，导出到受控交付目录。
   - exporter/operator/admin 可执行。

### 5.2 权限矩阵建议

| 操作 | viewer | exporter | operator | admin |
| --- | --- | --- | --- | --- |
| 查看结果 catalog | yes | yes | yes | yes |
| 查看预览与详情 | yes | yes | yes | yes |
| 生产结果入库 | no | no | yes | yes |
| 目录重建/发布 | no | no | yes | yes |
| 成果交付导出 | no | yes | yes | yes |
| 生产任务提交 | no | no | yes | yes |
| 用户管理 | no | no | no | yes |
| 根目录/许可证/运维配置 | no | no | no | yes |

实现上可以先保留 `role` 字段，扩展角色枚举；长期可引入权限位表，避免角色继续膨胀。

## 6. 推荐实施顺序

### 阶段 1：修正产品语义和审计

- 页面文案区分“生产结果入库”和“成果交付导出”。
- `/api/idl/extract-disp` 增加操作审计。
- 结果提取工作台明确标注未接入通道。
- 修复相关页面乱码文案。

### 阶段 2：导出任务化

- 新增 `EXPORT_DINSAR_RESULTS` 后台任务类型。
- `/api/dinsar-results/export` 改为返回 `task_id`。
- 前端展示导出任务进度和失败明细。
- 导出结果保留 task log 和 audit log。

### 阶段 3：权限细分

- 扩展角色：`viewer/exporter/operator/admin`。
- 用户管理页支持新角色说明。
- 后端增加能力级依赖，例如 `require_capability("result.export")`。
- 所有高风险写操作按 capability 而不是只按 admin 判断。

### 阶段 4：交付目录白名单产品化

- 将 `ALLOWED_EXPORT_DIRS` 从环境变量能力升级为系统配置/受控根目录。
- 前端从白名单选择交付根目录。
- 用户只输入子目录名或交付批次名。

## 7. 验收标准

完成上述改造后，应满足：

1. viewer 能看结果，不能导出、不能入库。
2. exporter 能导出已登记成果，但不能提交生产、不能用户管理。
3. operator 能生产、入库、导出，但不能用户管理和系统配置。
4. admin 保留全部权限。
5. 所有入库和导出动作都有 task log 和 audit log。
6. 大批量导出不再产生 HTTP 504。
7. 未实现通道在 UI 上不会被误认为可执行功能。