Yii中 RBAC(基于角色的访问控制权限)表结构原理分析

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

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

如:小张可以发帖、回帖、浏览,小红只能回帖、浏览

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

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

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

在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

时间: 2024-12-24 03:54:27

Yii中 RBAC(基于角色的访问控制权限)表结构原理分析的相关文章

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

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

RBAC 基于角色的访问控制

RBAC(Role-Based Access Control,基于角色的访问控制),就是用户通过角色与权限进行关联.简单地说,一个用户拥有若干角色,每一个角色拥有若干权限.这样,就构造成"用户-角色-权限"的授权模型.在这种模型中,用户与角色之间,角色与权限之间,一般者是多对多的关系.(如下图) 角色是什么?可以理解为一定数量的权限的集合,权限的载体.例如:一个论坛系统,"超级管理员"."版主"都是角色.版主可管理版内的帖子.可管理版内的用户等,

RBAC基于角色的访问控制

RBAC(Role-Based Access Control,基于角色的访问控制),就是用户通过角色与权限进行关联.简单地说,一个用户拥有若干角色,每一个角色拥有若干权限.这样,就构造成"用户-角色-权限"的授权模型.在这种模型中,用户与角色之间,角色与权限之间,一般者是多对多的关系.(如下图) 角色是什么?可以理解为一定数量的权限的集合,权限的载体.例如:一个论坛系统,"超级管理员"."版主"都是角色.版主可管理版内的帖子.可管理版内的用户等,

RBAC 基于角色的访问控制演示

RBAC rbac:Role Based Access Controll,基于角色的访问控制. 今天理一理RBAC,话不多说,直接切入主题 功能需求: 权限管理(无限极) 角色管理(可以分配权限) 管理员管理(管理员属于哪些角色) 后台左侧显示当前登录用户所拥有的权限 超级管理员拥有所有权限 实现 建表(我们需要三个表,管理员表.角色表.权限表,tip:也可用其它建表方式) 管理员表 权限表 角色表 我制作完的三张表的CRUD,后台首页效果展示(具体的增删改查就不列步骤了): 管理员表 权限表

RBAC: 基于角色的访问控制(Role-Based Access Control)

本文只讨论两种基于角色的访问控制的不同点,不涉及权限设计的数据库设计. 基于角色的访问控制(Role-Based Access Control)可分为隐式角色访问控制和显式角色访问控制. 隐式角色访问控制:没有明确定义一个角色到底包含了哪些可执行的行为. 显式角色访问控制:也称为"基于资源的访问控制",因为这种权限设计的粒度细化到了资源层面,资源有很多种,比如数据库表的增删查改.url.菜单.按钮等等. 来看一个隐式角色访问控制的例子: if (user.hasRole("P

基于角色的访问控制 (RBAC)权限管理

RBAC(Role-Based Access Control,基于角色的访问控制),就是用户通过角色与权限进行关联.简单地说,一个用户拥有若干角色,每一个角色拥有若干权限.这样,就构造成“用户-角色-权限”的授权模型.在这种模型中,用户与角色之间,角色与权限之间,一般者是多对多的关系. 在系统访问中,最终判断的是当前用户拥有哪些权限,以使用相关的权限进行业务处理. 在RBAC中,共有用户.部门.权限.角色四个概念,部门是用户的集合,角色是权限的集合:用户可以拥有不同的权限和角色,部门也可以拥有不

基于角色的访问控制RBAC

------------------------------------------------------------------------------------------------------- RBAC(Role Based Access Control),意为基于角色的访问控制,这里用户不再拥有单独权限,而是与角色相关联,通过赋予角色权限,那么该用户也就拥有了这个角色的权限; 这里的角色可以也理解为用户组. 权限控制位置:在公共的控制器类的构造方法内,这样子类均需进行权限验证; 

Azure ARM (16) 基于角色的访问控制 (Role Based Access Control, RBAC) - 使用默认的Role

<Windows Azure Platform 系列文章目录> 今天上午刚刚和客户沟通过,趁热打铁写一篇Blog. 熟悉Microsoft Azure平台的读者都知道,在老的Classic Portal里面,我们可以设置共同管理员(Co-admin). 参考:Windows Azure Active Directory (3) China Azure AD增加新用户 但是Co-Admin和服务管理员(Service Admin)的权限是一样的. 比如上图的admin创建的任何资源,是可以被ne

RBAC(Role-Based Access Control)基于角色的访问控制

RBAC(Role-Based Access Control,基于角色的访问控制),就是用户通过角色与权限进行关联.简单地说,一个用户拥有若干角色,每一个角色拥有若干权限.这样,就构造成"用户-角色-权限"的授权模型.在这种模型中,用户与角色之间,角色与权限之间,一般者是多对多的关系.(如下图) 角色是什么?可以理解为一定数量的权限的集合,权限的载体.例如:一个论坛系统,"超级管理员"."版主"都是角色.版主可管理版内的帖子.可管理版内的用户等,