Clever Geek Handbook

How can we use the auth_rule table in Yii2 RBAC?

Yii 2 RBAC has a new table called auth_rule. Can anyone explain its use with a small example

create table [auth_rule]
(
[name]  varchar(64) not null,
[data]  text,
[created_at]           integer,
[updated_at]           integer,
primary key ([name])
);
+3


source to share


2 answers


The main parts of the yiis RBAC-cconcept remain unchanged. In both Yii1 and Yii2, you have the following tables:

  • auth_item

    : contains actual rights, groups, roles, etc.
  • auth_item_child

    : defines a graph / hierarchy of elements
  • auth_assignement

    : assigns the element to the user

In Yii2, you now have a fourth table:

  • auth_rule

    : Contains reuse rules to check if the right is actually granted.

Why is this?

Yii1

The concept of this rule was already in Yii1 ... at least. In Yii1, you had the ability to define "bizrule" in auth_item

and auth_assignement

. "bizrule" and "data" were columns in both tables.

The content of the columns was as follows:

  • bizrule

    : containing php code that should have returned a boolean value. This code was executed during a permissions check with eval()

    . This way, you could control whether the right was granted or not, even if the user had an assigned item. Example: it makes no sense, but you can give the user the right only on the even hours of this BizRule: return date('h') % 2 == 0

    .
  • data

    : held parameters that can be passed to bizrule at runtime. Then this data was made available in the bizrule volume.


Yii2

The above solution works great, except that the bizrule code cannot be reused. Therefore, this functionality has been extracted into its own table.

If you look at the migration file that creates the base rbac ( yii\rbac\migrations\m140506_102106_rbac_init.php

) tables , you can see that the item table is now related to the rules table instead of placing the code in one of its own columns.

However auth_assignement

, auth_rule

there is no relationship between and . In Yii1, this allowed you to turn off rights groups right away. Since you can reuse the rule and attach it to all matching elements, this is no longer necessary and has therefore been removed.

Example

If you look at the actual implementation yii\rbac\DbManager

and yii\rbac\BaseManager

, no example is needed. The following options are interesting:

  • DbManager::addRule()

    : serializes and stores an instance of the rule
  • DbManager::getRule()

    : here you can see how the rule is fetched, non-serialized and returned. This means that the rule is stored in serialized format in the data column auth_rule

    .
  • BaseManager::executeRule()

    : the above rule is executed through Rule::execute()

If you want to add a rule, just create an instance yii\rbac\Rule

and call DbManager::addRule($rule)

with it as its parameter. This will serialize and save your rule, making it reusable elsewhere. Fine!

Voilà ... should be pretty clear. If you have open questions or would like more information, just post a comment. Smile and get good!

+1


source


The rule attribute data is serialized. What does this data look like? Is it similar to the array below as it is not unserialized yet?



[
'allow' => true,
'actions' => ['view'],
'roles' => ['viewPost'],
],
0


source






More articles:


All Articles