fs-lawrisk/test_report_permission_visibility.md

不同权限用户可视内容测试报告

测试概览

执行时间: 2025-11-18 11:35:38 测试目标: 验证不同权限用户是否只能看到授权范围内的许可数据 测试预期: 上级能看到下级数据，同级用户不能看到彼此数据 测试结果: ❌ 数据可见性未实现分级控制

---

权限体系分析

1. 当前权限结构

系统采用 基于grade的层级权限 模型：

用户类型	grade	role	部门层级	预期可见性
超级管理员	100	admin	无部门	所有数据
市级管理员	90	department_admin	市级服务部门	所有区域数据
区级管理员	80	department_admin	区级服务部门	所属区域数据

2. 现有测试账号

测试过程中验证的账号：

1. admin - 超级管理员 (grade: 100)
2. fssjsj - 市级管理员 (grade: 90)
3. fssjnh - 南海区管理员 (grade: 80)
4. fssjss - 三水区管理员 (grade: 80)
5. fssjsd - 顺德区管理员 (grade: 80)
6. fssjcc - 禅城区管理员 (grade: 80)
7. fssjgm - 高明区管理员 (grade: 80)

---

测试结果详情

测试场景1: 超级管理员 (admin) 权限验证

登录状态: ✅ 成功

• 用户角色: admin
• 用户级别: 100
• 可见许可数量: 91个
  • 市级: 89个许可
  • 顺德区: 1个许可
  • 高明区: 1个许可

测试场景2: 市级管理员 (fssjsj) 权限验证

登录状态: ✅ 成功

• 用户角色: department_admin
• 用户级别: 90
• 可见许可数量: 91个
  • 市级: 89个许可
  • 顺德区: 1个许可
  • 高明区: 1个许可

与分析预期差异:

• ✅ 市级管理员确实可以访问所有区域数据
• ✅ 符合预期设计

测试场景3: 区级管理员 (南海区 fssjnh) 权限验证

登录状态: ✅ 成功

• 用户角色: department_admin
• 用户级别: 80
• 可见许可数量: 91个
  • 市级: 89个许可
  • 顺德区: 1个许可
  • 高明区: 1个许可

与分析预期差异:

• ❌ 区级管理员可以看到所有区域数据（预期只能看到南海区数据）
• ❌ 不符合预期设计

---

关键发现

🔴 核心问题

当前系统未实现数据可见性分级控制

所有权限级别的用户（包括区级管理员）都可以查看所有区域的许可数据，包括：

• 其他区域的数据
• 上级部门的数据
• 同级部门的数据

📊 数据可见性对比

用户类型	预期可见性	实际可见性	是否符合预期
超级管理员	所有数据	所有数据 (91个)	✅
市级管理员	所有数据	所有数据 (91个)	✅
区级管理员	所属区域	所有数据 (91个)	❌

🔍 技术分析

权限控制层次

1. 数据层面: 无部门/用户数据归属字段

   • permits表只有 id 和 name 字段
   • 无 owner_id、department_id、created_by 等字段

2. API层面: 无基于部门的数据过滤

   • 无论用户grade多少，都返回相同数据
   • 获取许可的API不检查用户部门归属

3. 界面层面: 无基于角色的视图控制

   • 所有用户看到相同的许可列表
   • 无按部门/区域过滤选项

当前权限控制的实际作用

当前的权限系统主要控制的是：

• ✅ 管理操作权限: 创建、编辑、删除数据的权限
• ✅ API访问权限: 某些敏感API需要特定角色才能调用
• ❌ 数据可见性: 未实现数据按部门/层级的可见性控制

---

测试数据统计

许可数据分布

区域	许可数量	占比
市级	89	97.8%
顺德区	1	1.1%
高明区	1	1.1%
总计	91	100%

用户权限分布

权限级别	用户数	角色
grade 100	1	admin
grade 90	1	department_admin
grade 80	5	department_admin
总计	7	-

---

安全评估

⚠️ 潜在风险

1. 数据泄露风险: 区级管理员可以看到其他所有区域的数据
2. 职责不清: 用户权限与实际可见数据不匹配
3. 审计困难: 无法追踪谁查看了哪些数据
4. 不符合最小权限原则: 用户拥有超出职责范围的数据访问权限

✅ 安全优势

1. 认证系统健全: 登录、会话管理正常工作
2. 密码安全: 使用哈希存储密码
3. 会话保护: 基于Cookie的会话管理
4. 角色验证: 敏感操作需要相应角色

---

改进建议

方案1: 实现数据归属字段（推荐）

实现方式:

ALTER TABLE permits ADD COLUMN owner_department_id uuid REFERENCES service_departments(id);
ALTER TABLE permits ADD COLUMN created_by uuid REFERENCES auth_users(id);
ALTER TABLE permits ADD COLUMN visibility_level int DEFAULT 1; -- 1=部门, 2=区域, 3=全部

API层面修改:

# 获取许可时根据用户部门过滤
def get_permits_for_user(user, region):
    base_query = "SELECT * FROM permits WHERE region = %s"
    if user['grade'] < 90:  # 区级管理员
        base_query += " AND owner_department_id = %s"
        params = (region, user['service_department_id'])
    else:  # 市级及以上
        params = (region,)
    return execute_query(base_query, params)

方案2: 基于视图的权限控制

创建数据库视图:

CREATE VIEW permits_by_department AS
SELECT p.*, sd.name as owner_department_name
FROM permits p
JOIN service_departments sd ON p.owner_department_id = sd.id;

API使用视图而非原表，根据当前用户自动过滤。

方案3: 增强现有权限系统

在现有API基础上添加权限检查：

@require_permission('view_permits_in_region')
def get_permits(region):
    user = get_current_user()
    if user['grade'] < 90 and user['department']['region'] != region:
        raise PermissionDenied("无法查看其他区域数据")
    return fetch_permits(region)

实施优先级

优先级	改进项目	工作量	效果
P0	添加数据归属字段	高	完全解决可见性问题
P1	API权限检查	中	快速缓解安全问题
P2	前端视图控制	低	提升用户体验
P3	审计日志	中	提升安全可追溯性

---

测试结论

总体评估: ⚠️ 需要改进

当前状态: 系统具备完整的用户管理和权限管理体系，但未实现数据可见性分级控制。

核心问题: 不同权限用户看到的都是相同数据，不符合"上级看数据，下级看数据"的权限隔离需求。

建议行动:

1. 短期 (1周内): 实施API层面的数据可见性检查
2. 中期 (1月内): 添加数据归属字段，完全重构权限模型
3. 长期 (3月内): 建立完整的审计和监控体系

测试评分

维度	评分	说明
功能完整性	⭐⭐⭐⭐⭐	所有测试账号均可正常访问系统
权限验证	⭐⭐	认证正常，但数据可见性未分级
安全性	⭐⭐	数据可见性存在严重问题
稳定性	⭐⭐⭐⭐⭐	系统稳定，无崩溃或错误
综合评分	⭐⭐⭐ (3/5)	需要优先解决数据可见性问题

---

附录

测试环境信息

• 应用地址: http://127.0.0.1:8000
• 测试工具: Python + urllib
• 数据库: PostgreSQL (licensing_risks)
• 测试日期: 2025-11-18

测试文件

1. test_permission_comprehensive.py - 综合权限测试脚本
2. /tmp/permission_test_results.json - 详细测试结果

API端点测试

• ✅ /auth/login - 登录功能正常
• ✅ /auth/logout - 登出功能正常
• ✅ /v2/regions - 获取区域列表正常
• ✅ /getPermits - 获取许可数据正常（但无权限过滤）

---

报告生成时间: 2025-11-18 11:40:00 测试执行人: Claude Code (Anthropic AI Assistant) 报告版本: v1.0