Yii2.0中文开发向导——RBAC(基于角色的访问控制权限)表结构原理分析 - yiifans

Yii2.0中文开发向导——RBAC(基于角色的访问控制权限)表结构原理分析 - yiifans

这里有几个概念很重要，我简单用大白话说一下;

权限：
就是指用户是否可以执行哪些操作。

如：小张可以发帖、回帖、浏览，小红只能回帖、浏览

角色：
就是上面说的一组操作的集合。

如：高级会员有发帖、回帖、删贴、浏览的权限，普通会员只有回帖、浏览的权限。
比如小张是高级会员，那么他就可以执行发帖、回帖、删贴、浏览。而小红是普通会员，所以它就只能回帖、浏览。

另外角色还可以继承，中级会员除了普通会员的回帖、浏览功能外，还可以发帖。也就是说在普通会员的基础上又增加了一个发帖的权限。


在Yii2.0中

    yiirbac: Item 为角色或者权限的基类，其中用字段type来标识
    yiirbac: Role 为代表角色的类
    yiirbac: Permission 为代表权限的类
    yiirbac: Assignment 为代表用户角色或者权限的类
    yiirbac: Rule 为代表角色或权限能否执行的判定规则表


存储角色或权限的表：auth_item

由于它们的数据存储在一张表[auth_item]里面，所以他们有一个共同的基类yiirbac：Item，用$type字段来标识是角色还是权限。

从上面可以看到，上面的三个是用户角色，下面的五个是权限。

这个表里面，每一个记录，可能是权限，也可能是角色，为什么存一个表里？
他们之间是有关联的，一个角色可以继承于另一个角色，一个角色对应一个或者多个权限。


角色权限关联表：auth_item_child

上面我们说过，角色是一组权限的集合，所以还有一个表[auth_item_child]用来保存角色和权限的关系。
写几个测试数据会看的更明白，现在我们在表auth_item_child中指定它们的关系
parent child
hight_user add
hight_user edit
hight_user delete
......
low_user reply
low_user view
..................
middle_user low_user
middle_user add

hight_user和low_user的关系我们容易理解，middle_user就不一样了，它指定了另外一个角色：low_user和一个权限：add。
这个意思就是说middle_user包含了low_user的权限，另外又添加了一个add权限。

除了角色可以包含角色外，权限也是可以包含权限的。也就是说这个表里面有三个关系：

    角色 包含 权限
    角色 包含 角色
    权限 包含 权限


如果要得到一个角色的所有的权限，要做两方面的查找，一个是递归查找当前权限所有的子权限， 一个是查看所包含的角色的所有的权限以及子权限。
所以在使用中不建议让权限继承，只让角色继承。而且继承深度也不宜太深。

最重要的也就是上面这两个表，具体的代码是怎么实现的会在后面源码分析里面说明。

角色由一个或者多个权限组成，角色继承角色，这样就足以构成权限的体系。





用户角色（权限）表：[auth_assignment]

这个表用来存储用户的角色或者权限。

为什么是角色或者权限？

如上面，给角色指定权限有两种办法

    一种是直接给角色指定相应的权限
    一种是让一个角色继承（我始终觉的继承这个词要好于包含）自另外一个角色，另外还可以再单独指定其它的权限。


所以对用户而言也有两种方法。

    一种是给用户指定相应的角色

    一种是给用户指定相应的权限。

这样一个用户的权限包含两部分，一部分是所指定的角色代表的权限，一部分就是直接所指定的权限。

这个表就三个字段，就是指明用户和权限的对应关系，1个用户有多个权限。
权限这里有两种，一种是存角色名，一种是存权限名，都是对应item表中的item名。








规则表：[auth_rule]

一个用户要执行一个操作除了要看他有没有这个权限外，还要看他的这个权限能不能执行。

在上面的表：auth_item中还有一个字段：[rule_name]。这个字段用来标明这个角色或者权限能不能成功执行。

那么规则这个表里面的数据是从哪里来的呢？
下面这个是规则的基类：
abstract class Rule extends Object
{
/**
* @var string name of the rule
*/
public $name;
/**
* @var integer UNIX timestamp representing the rule creation time
*/
public $createdAt;
/**
* @var integer UNIX timestamp representing the rule updating time
*/
public $updatedAt;

/**
* Executes the rule.
*
* @param Item $item the auth item that this rule is associated with
* @param array $params parameters passed to [[ManagerInterface::allow()]].
* @return boolean a value indicating whether the rule permits the auth item it is associated with.
*/
abstract public function execute($item, $params);
}

 
$name为规则的名称。
也就是说如果要在规则表：[auth_rule]中增加一条规则就得要有对应的规则类，并实现方法abstract public function execute($item, $params)具体的逻辑来判定$item（角色或者权限）是否可执行。

主要的分析也就完成了。关于这一部分的源码分析，过几天也会出来的。
哪一部分没说清楚或者还有其它问题都可以留言讨论。谢谢各位。喜欢的就顶一下。