简单的RBAC基于角色的用户权限的实现

RBAC基于角色的用户权限在实际应用中广泛使用，尤其是在复杂的多用户环境下，同一个后台会用不同角色的用户，而每个角色用户所拥有的操作权限是不同的，RBAC巧妙的解决了这个问题：

这里先介绍下以前用到过的，THinkphp中内置了RBAC解决方案，这里不再多说简单说下实现思路：

要实现不同用户的权限操作，关键要对权限分类，哪些类别拥有相同的权限，哪个用户属于这个类，哪个操作对应相对权限，把这些搞清楚了，RBAC就解决了；这里涉及到的权限就是操作，比如管理员类登陆后，添加，修改了文章；添加，修改了文章就是权限或者叫操作，管理员就是这个类或者组；有了组的概念就必须有成员也称用户，假如张三，李四都属于管理员这个组；那么他们就拥有了管理员这个类的所有权限，这里张三，李四表示我拥有了添加，修改了文章的权限；理解起来来有点像类的继承。

这里举例来说明，包括四个表：角色【分组】表，权限【操作】表，用户表，角色权限表

角色表：role

id	role	desc
1	admin	管理员组
2	editor	编辑组
3	user	注册用户组

权限操作表：privilege

id	name	desc
1	article/list	读取文章列表
2	article/edit	编辑文章信息
3	article/create	创建文章内容
4	article/update	更新文章信息
5	article/delete	删除文章信息

用户表：user

id	user	role_id	bz
1	zfeig	2	编辑组
2	admin	1	管理员组
3	lisi	3	注册用户组

角色权限操作表：role_privilege

role_id	privilege_id
1	1,2,3,4,5
2	1,3,4
3	1

思路实现：

用户登陆后执行每个操作都要检查操作权限【可以一个公共函数或者过滤器实现】：


1、用户登录，获取用户表信息，通过role_id,获取role_privilege表中的privilege；以数组方式存储在session中；


2、用户执行某个操作，检查权限，通过当前操作名称如index/create，获取privilege表中对应权限id,然后对比
用户session里面的privilege数组；如果存在，说明有权限操作，否则无权操作！

下面看看yii2是怎么实现的：【转】

这里有几个概念很重要，我简单用大白话说一下; 
权限： 
就是指用户是否可以执行哪些操作。 
如：小张可以发帖、回帖、浏览，小红只能回帖、浏览 
角色： 
就是上面说的一组操作的集合。 
如：高级会员有发帖、回帖、删贴、浏览的权限，普通会员只有回帖、浏览的权限。 
比如小张是高级会员，那么他就可以执行发帖、回帖、删贴、浏览。而小红是普通会员，所以它就只能回帖、浏览。 
另外角色还可以继承，中级会员除了普通会员的回帖、浏览功能外，还可以发帖。也就是说在普通会员的基础上又增加了一个发帖的权限。 
在Yii2.0中

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

存储角色或权限的表：auth_item 
由于它们的数据存储在一张表 [auth_item] 里面，所以他们有一个共同的基类 yii\rbac：Item ，用 $type 字段来标识是角色还是权限。 
<ignore_js_op>  
从上面可以看到，上面的三个是用户角色，下面的五个是权限。 
角色权限关联表：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] 
这个表用来存储用户的角色或者权限。 
为什么是 角色或者权限 ？ 
如上面，给角色指定权限有两种办法

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

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

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

<ignore_js_op>  
这样一个用户的权限包含两部分，一部分是所指定的角色代表的权限，一部分就是直接所指定的权限。 
规则表：[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（角色或者权限）是否可执行。 
主要的分析也就完成了。关于这一部分的源码分析，过几天也会出来的。 
哪一部分没说清楚或者还有其它问题都可以留言讨论。谢谢各位。喜欢的就顶一下。 
原文链接： http://www.yiifans.com/forum.php?mod=viewthread&tid=74#lastpost