yii自带rbac数据表分析

来源：互联网发布：安徽快三遗漏数据查询编辑：程序博客网时间：2024/05/22 00:46

我们了解到了什么是基于角色的访问控制。如果让我们自己实现一套基于角色的访问控制，我们又该如何设计，如何开发呢？

开发之前有必要先来分析一下数据表：

RBAC(基于角色的访问控制权限)表结构
Rbac 支持两种类，PhpManager（基于文件的）和 DbManager（基于数据库的）
权限：
就是指用户是否可以执行哪些操作
角色：
就是上面说的一组操作的集合，角色还可以继承
在Yii2.0中
- yii\rbac: Item 为角色或者权限的基类，其中用字段type来标识
- yii\rbac: Role 为代表角色的类
- yii\rbac: Permission 为代表权限的类
- yii\rbac: Assignment 为代表用户角色或者权限的类
- yii\rbac: Rule 为代表角色或权限能否执行的判定规则表
在数据库中存储的RBAC层次是低效率的浪费性能的，但要灵活得多
存储角色或权限的表：auth_item
用来存储角色和权限的数据，Role类和Permission类有一个共同的基类yii\rbac：Item，用$type字段来标识是角色还是权限。
角色权限关联表：auth_item_child
用来保存角色和权限的关系
用户角色（权限）表：auth_assignment
用户的权限包含两部分，一部分是所指定的角色代表的权限，一部分就是直接所指定的权限
规则表：auth_rule
如果要在规则表：[auth_rule]中增加一条规则就得要有对应的规则类，并实现方法abstract public function execute($item, $params)具体的逻辑来判定$item（角色或者权限）是否可执行。
首先主体，也就是用户，需要有一张用户表，很简单，我们已经有了，就是数据表user_backend
我们需要有一张角色表和权限表，分别存放角色和权限的数据表
另外我们还需要一张主体跟角色的关联表，也就是需要给用户分配角色的存储表
最后我们再需要一张角色跟权限的关联表

也就是说，如果现在让我们自己从零开始实现一套基于角色的访问控制，我们总结了上面4小条。开始之前很多人会觉得很难，无从下手，现在感觉呢，是不是思路清晰了好多？开始本篇主题之前有必要再叨唠两句。有些同学学蒙了，为啥这个时候说这些有的没的呢，不是要学实战吗？其实我们现在步步都在实战，网上你也找不到这么好的教程！我们现在就是在为后面的课程做一些铺垫，因为很多人后面构建好了rbac，但是却不明白其前因后果！所以，这里基础的理解很重要！

言归正传。官方自带的rbac在哪呢？在 vendor\yiisoft\yii2\rbac 目录下。

还记得我们之前讲的migrate的用法吗？接下来我们又要用到migrate生成官方自带的数据表了。（部分同学直接拷贝sql执行，但是sql本身未设定utf8模式，导致后面乱码，此处我们统一使用migrate进行操作）

在vendor同级目录，也就是我们项目的顶级目录下执行

./yii migrate --migrationPath=@yii/rbac/migrations/

然后输入yes..然后报错了，报错不可怕，可怕的是看到错误的人躲着错误问这问那！我们看看具体什么错

Exception 'yii\base\InvalidConfigException' with message 'You should configure "authManager" component to use database before executing this migration.'

提示我们说在执行这条migration之前让我们先配置下authManager组件！也就是说我们尚未配置某些操作，那我们就配置下authManager组件呗

打开common\config\main.php文件，在components数组中加入authManager组件

//authManager有PhpManager和DbManager两种方式,    //PhpManager将权限关系保存在文件里,这里使用的是DbManager方式,将权限关系保存在数据库.    "authManager" => [            "class" => 'yii\rbac\DbManager',],

然后我们再次执行上面的migrate命令，控制台提示我们成功创建了4张数据表，我们打开数据库看了下，果真如此。

数据表我们是一股脑的创建完了，但是每个数据表具体什么含义呢？是否真的就如我们一开始所分析的呢？

auth_item：用于存储角色、权限和路由

auth_item_child：角色-权限的关联表

auth_assignment：用户-角色的关联表

大致上跟我们所分析的差不多，只不过关于角色、权限这里共用了一张数据表，统称为授权项目。

说明一下：上面说的路由，实质就是我们权限所控制的最小粒度范围。那为什么要写角色、权限和路由呢？角色，可以理解为可为其分配的是角色更大级别的，权限，可以理解为角色的浓缩版，实质就是一个角色，只不过关联的是最小粒度-路由。

需要提醒的是：4张数据表的表名分别对应着authManager组件类yii\rbac\DbManager的4个属性，也就是说如果我们在authManager中配置了不同的属性值，生成的数据表名也会随之改动，可自行尝试！

下一章节，我们利用刚刚配置的authManager组件，直接手把手带你飞，手动敲出一个简单强大的权限管理，让rbac变的so easy，期待吧！

Yii2 RBAC用到的四张auth表位于 vendor/yiisoft/yii2/rbac/migration文件夹里面，可以用migration生成

yii migrate --migrationPath=@yii/rbac/migrations/

或者使用下面的sql语句

CREATE TABLE `auth_assignment` (`item_name` varchar(64) NOT NULL,`user_id` varchar(64) NOT NULL,`created_at` int(11) DEFAULT NULL,PRIMARY KEY (`item_name`,`user_id`),CONSTRAINT `auth_assignment_ibfk_1` FOREIGN KEY (`item_name`) REFERENCES `auth_item` (`name`) ON DELETE CASCADE ON UPDATE CASCADE) ENGINE=InnoDB DEFAULT CHARSET=utf8 CREATE TABLE `auth_item` (`name` varchar(64) NOT NULL,`type` int(11) NOT NULL,`description` text,`rule_name` varchar(64) DEFAULT NULL,`data` text,`created_at` int(11) DEFAULT NULL,`updated_at` int(11) DEFAULT NULL,PRIMARY KEY (`name`),KEY `rule_name` (`rule_name`),KEY `type` (`type`),CONSTRAINT `auth_item_ibfk_1` FOREIGN KEY (`rule_name`) REFERENCES `auth_rule` (`name`) ON DELETE SET NULL ON UPDATE CASCADE) ENGINE=InnoDB DEFAULT CHARSET=utf8 CREATE TABLE `auth_item_child` (`parent` varchar(64) NOT NULL,`child` varchar(64) NOT NULL,PRIMARY KEY (`parent`,`child`),KEY `child` (`child`),CONSTRAINT `auth_item_child_ibfk_1` FOREIGN KEY (`parent`) REFERENCES `auth_item` (`name`) ON DELETE CASCADE ON UPDATE CASCADE,CONSTRAINT `auth_item_child_ibfk_2` FOREIGN KEY (`child`) REFERENCES `auth_item` (`name`) ON DELETE CASCADE ON UPDATE CASCADE) ENGINE=InnoDB DEFAULT CHARSET=utf8 CREATE TABLE `auth_rule` (`name` varchar(64) NOT NULL,`data` text,`created_at` int(11) DEFAULT NULL,`updated_at` int(11) DEFAULT NULL,PRIMARY KEY (`name`)) ENGINE=InnoDB DEFAULT CHARSET=utf8

阅读全文

0 0

yii自带rbac数据表分析

RBAC(基于角色的访问控制权限)表结构