96 lines
4.9 KiB
Markdown
96 lines
4.9 KiB
Markdown
|
针对你的复杂权限需求，建议采用 **“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)
|
|||
|
|
当用户访问某个数据时，系统按照以下顺序合并权限：
|
|||
|
|
1. **取基础属性**：获取用户的 `org_id` 和 `rank_level`。
|
|||
|
|
2. **取角色权限**：获取该用户所属角色对应的资源权限列表。
|
|||
|
|
3. **应用个性化覆盖**：查询 `tbl_auth_user_overrides`。如果该表中有记录，则**覆盖**（或叠加）角色权限。
|
|||
|
|
4. **注入行级过滤**：如果是查询操作，解析 `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 张表**：
|
|||
|
|
1. **`tbl_auth_users`**：用户主体（含 OpenID、部门、等级）。
|
|||
|
|
2. **`tbl_auth_resources`**：资源清单（表名、字段名）。
|
|||
|
|
3. **`tbl_auth_roles`**：角色定义。
|
|||
|
|
4. **`tbl_auth_role_perms`** / **`tbl_auth_user_overrides`**：权限映射（解决字段级和个人特权）。
|
|||
|
|
5. **`tbl_auth_row_scopes`**：行级过滤表达式（解决多维数据隔离）。
|