XuJiacheng
02d5686c7b
- 新增 userService.js，包含用户认证、资料更新、token 刷新等功能 - 新增 wechatService.js，处理微信API交互，获取openid和手机号 - 新增 appError.js，封装应用错误处理 - 新增 logger.js，提供日志记录功能 - 新增 response.js，统一成功响应格式 - 新增 sanitize.js，提供输入数据清洗功能 - 更新 OpenAPI 文档，描述新增接口及请求响应格式 - 更新 PocketBase 数据库结构，调整用户表字段及索引策略 - 增强错误处理机制，确保错误信息可观测性 - 更新变更记录文档，详细记录本次变更内容
4.9 KiB
4.9 KiB
针对你的复杂权限需求，建议采用 “RBAC（基于角色的访问控制）+ ABAC（基于属性的访问控制）+ 个性化覆盖（Overrides）” 的混合模式。这种结构能支持从“大颗粒度角色”到“极细颗粒度字段/行”的动态权限矩阵。
以下是为你设计的实施方案及关键表结构规划：
一、 核心表方案设计
为了实现“字段级”和“行级”的动态控制，我们需要将 资源（Resource）、权限定义（Permission）、角色（Role） 与 用户（User） 彻底解耦。
1. 用户基础表：tbl_auth_users
作为全局身份锚点，记录用户的静态信息和动态属性（部门、等级）。
| 字段名 | 类型 | 说明 |
|---|---|---|
| user_id | BigInt (PK) | 内部全局唯一 ID |
| openid | String (Unique) | 全局身份锚点，微信唯一标识 |
| user_name | String | 姓名/昵称 |
| org_id | Int | 所属组织/部门 ID（影响行级权限的关键属性） |
| rank_level | Int | 职级/等级（影响动态权限矩阵的关键属性） |
| status | Int | 账户状态 (1: 正常, 0: 禁用) |
| user_type | Int | 账户类型 (0: 微信小程序，1: 管理平台，2: 其他) |
2. 资源定义表：tbl_auth_resources
定义系统中哪些表、哪些字段属于受控资源。
| 字段名 | 类型 | 说明 |
|---|---|---|
| res_id | Int (PK) | 资源 ID |
| table_name | String | 数据库表名 |
| column_name | String | 字段名（如果是表级权限，此项可为空或设为 '*'） |
| res_type | Enum | 资源类型：TABLE（行/全表）, COLUMN（字段级） |
3. 角色与基础权限：tbl_auth_roles & tbl_auth_role_perms
实现通用的权限模板，方便批量管理。
tbl_auth_roles: 角色表（如：财务经理、普通销售）。tbl_auth_role_perms: 角色权限关联表，定义该角色对某个资源的操作（读/写/无）。
4. 核心：个性化权限覆盖表 tbl_auth_user_overrides
这是满足你“某个用户对某个字段单独设置”需求的关键。
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | BigInt (PK) | 自增 ID |
| user_id | BigInt | 用户 ID（关联 tbl_auth_users） |
| res_id | Int | 资源 ID（关联 tbl_auth_resources） |
| access_level | Int | 权限值 (0: 无权, 1: 只读, 2: 读写) |
| priority | Int | 优先级（当角色权限与个人设置冲突时，以此为准） |
5. 核心：行级过滤策略表 tbl_auth_row_scopes
实现“某个用户只能看自己部门/某几个项目”的动态逻辑。
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | Int (PK) | 策略 ID |
| target_type | Enum | 目标：USER 或 ROLE |
| target_id | BigInt | 对应的 UserID 或 RoleID |
| table_name | String | 作用的表名 |
| filter_sql | String | 过滤逻辑。例如：dept_id = {user.org_id} 或 creator_id = {user.user_id} |
二、 权限实施方案逻辑
你的权限矩阵页面将由以下逻辑驱动：
1. 权限计算路径 (Effective Permissions)
当用户访问某个数据时，系统按照以下顺序合并权限：
- 取基础属性：获取用户的
org_id和rank_level。 - 取角色权限：获取该用户所属角色对应的资源权限列表。
- 应用个性化覆盖：查询
tbl_auth_user_overrides。如果该表中有记录，则覆盖（或叠加）角色权限。 - 注入行级过滤：如果是查询操作，解析
tbl_auth_row_scopes中的filter_sql，将{user.xxx}变量替换为当前用户的真实值。
2. 动态更新机制
- 组织/等级变更：当
tbl_auth_users中的org_id或rank_level变化时，由于行级过滤表（tbl_auth_row_scopes）引用的是动态变量，权限会自动生效，无需重新授权。 - 缓存策略：建议将计算后的“最终权限清单”缓存到 Redis。当用户在后台矩阵页面修改权限，或者发生组织架构调整时，通过
wx_openid主动失效（Purge） 该用户的 Redis 缓存。
3. 字段级权限实现 (Field-Level)
在接口层（中间件），根据计算出的字段级权限清单（即用户对该 Table 下哪些 Column 有读权），动态过滤返回的 JSON 结构。
三、 总结：你需要几张表？
为了实现你描述的系统，最精简需要 5 张表：
tbl_auth_users：用户主体（含 OpenID、部门、等级）。tbl_auth_resources：资源清单（表名、字段名）。tbl_auth_roles：角色定义。tbl_auth_role_perms/tbl_auth_user_overrides：权限映射（解决字段级和个人特权）。tbl_auth_row_scopes：行级过滤表达式（解决多维数据隔离）。