3+1 张表建立一个强大的RBAC鉴权管理系统

讲在前面的

我们一般在开发后台管理应用程序的时候，或多或少都会涉及到鉴权管理。鉴权管理中一般有角色、权限两部分组成，用户直接和角色关联，这种鉴权管理实现简单，在一些较小的项目中也比较容易实现，但是在一些比较大的项目中就有些局限性了，或者说对权限的要求更高、更细粒度。下面我主要讲下如果通过3+1来实现鉴权管理。

3 指的是3张鉴权表设计

yauth_items，这张表记录的是鉴权节点表，表结构如下：

CREATE TABLE `yauth_items` (
    `id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
    `item_code` VARCHAR(191) NOT NULL COLLATE 'utf8mb4_unicode_ci',
    `client_id` INT(10) UNSIGNED NULL DEFAULT NULL,
    `user_id` INT(10) UNSIGNED NULL DEFAULT NULL,
    `item_name` VARCHAR(191) NOT NULL COLLATE 'utf8mb4_unicode_ci',
    `item_desc` VARCHAR(191) NOT NULL COLLATE 'utf8mb4_unicode_ci',
    `item_type` TINYINT(3) UNSIGNED NOT NULL,
    `scope` VARCHAR(191) NOT NULL COLLATE 'utf8mb4_unicode_ci',
    `other_data` TEXT NOT NULL COLLATE 'utf8mb4_unicode_ci',
    `deleted_at` TIMESTAMP NULL DEFAULT NULL,
    `created_at` TIMESTAMP NULL DEFAULT NULL,
    `updated_at` TIMESTAMP NULL DEFAULT NULL,
    PRIMARY KEY (`id`),
    UNIQUE INDEX `yauth_items_item_code_unique` (`item_code`)
)
COLLATE='utf8mb4_unicode_ci'
ENGINE=InnoDB;

yauth_item_relation，这张表记录的是鉴权节点之间的层级关系

CREATE TABLE `yauth_item_relation` (
    `id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
    `item_id` INT(10) UNSIGNED NOT NULL,
    `client_id` INT(10) UNSIGNED NOT NULL,
    `scope` VARCHAR(191) NOT NULL COLLATE 'utf8mb4_unicode_ci',
    `parent_id` INT(11) NULL DEFAULT NULL,
    `lft` INT(11) NULL DEFAULT NULL,
    `rgt` INT(11) NULL DEFAULT NULL,
    `depth` INT(11) NULL DEFAULT NULL,
    `deleted_at` TIMESTAMP NULL DEFAULT NULL,
    `created_at` TIMESTAMP NULL DEFAULT NULL,
    `updated_at` TIMESTAMP NULL DEFAULT NULL,
    PRIMARY KEY (`id`),
    INDEX `yauth_menus_item_id_index` (`item_id`),
    INDEX `yauth_menus_parent_id_index` (`parent_id`),
    INDEX `yauth_menus_lft_index` (`lft`),
    INDEX `yauth_menus_rgt_index` (`rgt`)
)
COLLATE='utf8mb4_unicode_ci'
ENGINE=InnoDB;

yauth_item_group，这张表是记录鉴权节点之间的依赖关系

CREATE TABLE `yauth_item_group` (
    `id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
    `parent_id` INT(10) UNSIGNED NOT NULL,
    `child_id` INT(10) UNSIGNED NOT NULL,
    `client_id` INT(10) UNSIGNED NOT NULL,
    `scope` VARCHAR(191) NOT NULL COLLATE 'utf8mb4_unicode_ci',
    `deleted_at` TIMESTAMP NULL DEFAULT NULL,
    `created_at` TIMESTAMP NULL DEFAULT NULL,
    `updated_at` TIMESTAMP NULL DEFAULT NULL,
    PRIMARY KEY (`id`),
    INDEX `yauth_item_relation_parent_id_index` (`parent_id`),
    INDEX `yauth_item_relation_child_id_index` (`child_id`)
)
COLLATE='utf8mb4_unicode_ci'
ENGINE=InnoDB;

1 指的是用户分配（关联）表设计

yauth_assignments，这张表指的是用户和鉴权节点如何进行分配（关联）

CREATE TABLE `yauth_assignments` (
    `id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
    `item_id` INT(10) UNSIGNED NOT NULL,
    `user_id` INT(10) UNSIGNED NOT NULL,
    `provider` VARCHAR(191) NOT NULL COLLATE 'utf8mb4_unicode_ci',
    `deleted_at` TIMESTAMP NULL DEFAULT NULL,
    `created_at` TIMESTAMP NULL DEFAULT NULL,
    `updated_at` TIMESTAMP NULL DEFAULT NULL,
    PRIMARY KEY (`id`),
    INDEX `yauth_assignments_user_id_index` (`user_id`),
    INDEX `yauth_assignments_item_id_index` (`item_id`)
)
COLLATE='utf8mb4_unicode_ci'
ENGINE=InnoDB;

简单说下鉴权管理的思路

一切皆节点，节点包括权限、菜单、角色等等
节点之间没有显示的层级关系，比如菜单包含权限，角色包含权限，但是权限不能包含菜单，这个需要根据需求在代码里面实现
权限、菜单、角色三者之间的关系如下，并且同级之间也可以相互包含，比如角色A包含角色B，当然，你可以根据自己的需求代码里面去控制

权限、菜单、角色关系
我把4张表的一个ER图大概画了一下，标注了里面节点的一些含义

表之间的关联关系

下面解读下表结构

yauth_items表 = 权限条目表

item_code = 节点代码 // 用来做唯一标识
client_id = 客户端ID // 用来标识是哪个客户端访问过来的用户，你总不想每做一个客户端都写一套rbac系统吧，比如有clientA和clientB，业务功能不同，权限也不同，通过client_id我们就能根据client找到该机构下拥有的权限，来判断权限该用户是否有权限
user_id = 用户ID
item_name = 节点名称 // 比如该节点是一个菜单、它的名字叫首页
item_desc = 节点描述 // 给节点添加更详细的描述信息
item_type = 节点类型 // 节点的类型权限、菜单、角色，可以根据需要扩充
scope = 作用域 // 将这些节点进行作用域划分，比如同样是菜单，分为顶部菜单和左侧菜单，多个作用域用逗号隔开，比如超管的菜单和机构的菜单
other_data = 其他数据// 扩展字段，我们可以为某些节点添加一些别的标识以便做特殊处理

`yauth_item_relation表` = `节点关系表`

item_id = 节点id // 对应yauth_items表id
client_id = 客户端ID // 同上，标识归属于哪个客户端
scope = 作用域 // 该节点属于哪个作用域，单一作用域
parent_id = 父id // 关联本表的id字段
lft = 左值 // 详情可见左右值算法
right = 右值 // 详情可见左右值算法
depth = 层级 // 代表该节点的层级深度

`yauth_item_group表` = `节点分组表`

parent_id = 父ID // 关联yauth_items表的id字段
child_id = 子ID // 关联yauth_items表的id字段
client_id = 客户端ID // 区分客户端
scope = 作用域 // 建立依赖时，在哪个作用域范围添加的

`yauth_assignments` = `权限分配表`

item_id = 节点ID // yauth_items表id
user_id = 用户ID //
provider = 用户提供这 // 用来标识是哪个表提供的用户，适用于多表用户

总结：

yauth_items 用来存储节点，我们添加的所有节点都在这样表中

yauth_item_relation 用来表示节点的层级关系，不然我们看到视图不够直观。注意，添加到yauth_items表是第一步，我们将节点挂载到yauth_item_relation表，才应该生效

yauth_item_group 用来标识节点之间的依赖关系，角色A依赖角色B，角色B依赖菜单A、菜单B，菜单A依赖权限A，给用户分配了角色A相当于拥有了角色B、带单A、菜单B、权限A

这套设计操作起来可能会比较麻烦，比如添加权限这个操作，需要先添加、在挂载、在添加依赖，不过权限这个东西本来不就随着业务要求越高越复杂么

在依赖判断时，yauth_item_group表parent_id 和 child_id 递归查找依赖关系，可能会导致大量递归，使用左右值又丧失了依赖的优点，暂时没有想到好的解决办法

3+1 张表建立一个强大的RBAC鉴权管理系统

讲在前面的

3 指的是3张鉴权表设计

1 指的是用户分配（关联）表设计

简单说下鉴权管理的思路

下面解读下表结构

yauth_item_relation表 = 节点关系表

yauth_item_group表 = 节点分组表

yauth_assignments = 权限分配表

猜你喜欢

`yauth_item_relation表` = `节点关系表`

`yauth_item_group表` = `节点分组表`

`yauth_assignments` = `权限分配表`