Brief introduction to the full guide to using RBAC in Yii (user role permission control)

This article provides a detailed analysis of the full guide (user role permission control) to use RBAC in Yii. For more information, see Preface
* My feed address has been changed to: http://feeds.imdong.net, please update your reader.
* The following content is suitable for Yii 1.0.x. Other versions may be slightly different.
* Based on your comments and feedback, this article will be continuously modified and supplemented to facilitate new learners.

Start preparation
Yii provides powerful configuration mechanisms and many ready-made class libraries. It is very easy to use RBAC in Yii, and no RBAC code needs to be written at all. So the preparation is to open the editor and come with me.
Set parameters and create a database
Add the following content to the configuration array:

The code is as follows:

'Components' => array (
//......
'Authmanager' => array (
'Class' => 'cdbauthmanager', // authentication class name
'Defaultrole' => array ('guest '), // Default role
'Itemtable' => 'pre _ auth_item ', // The name of the authentication item table.
'Itemchildtable' => 'pre _ auth_item_child ', // authentication item parent-child relationship
'Assignmenttable' => 'pre _ auth_assignment ', // authorization relationship of authentication items
),
//......

How can we create these three data tables? It's easy to look at framework/web/auth/schema. SQL. Be sure to match your custom table name. For example, in the SQL file, you must change AuthItem to pre_auth_item. Then, run the statements in the SQL file in the database.

Understanding concepts
What about the remaining code? I tell you, no. The RBAC system is established in this way. But to use it, you need to understand its operating mechanism. I will try to speak a little too long ...... (The official RBAC document is here, but I have read it 4-5 times before I understand it .)

Three concepts
You need to know that authorized projects can be divided into operations, tasks, and roles ).
A user has one or more roles. for example, we have three roles: bank presidents, bank employees, and customers. Let's assume that:
* President Zhang has a role: the Bank Governor, Bank staff, and customers (who can save money themselves ).
* Mr. Wang has the roles of bank employees and customers.
* Mr. Li has a role: customer.

Then, as long as the customer can do something, Xiao Li can do it, as well as Wang and Zhang Xingchang. What bank staff can do is Wang and Zhang Xingchang can do, but Xiao Li cannot.

For example, if a "customer" can save money, Zhang, Wang, and Xiao Li, who have the "customer" role, can save money. "Bank staff" can print the customer's transaction records, so Zhang and Wang employees with "Bank staff" roles can, but Xiao Li cannot, you must find a person with a "bank clerk" role to print detailed transaction records. A "bank governor" can enter the bank's cash bank to raise money, so only President Zhang can, because it has the role of "bank governor.
This is a role-based authentication system, RBAC for short.

Role inheritance
Roles can be inherited. for example, the rules are as follows:
* All "bank presidents" are "bank employees". that is to say, as long as the bank staff can do anything, the bank governors can do.
* Any "bank employee" is a customer. the same as above, the bank employee can also do what the customer can do.
Then the role relationship becomes:
* President Zhang has the role of the bank governor.
* Wang has a role as a bank employee.
* Mr. Li has a role: customer.
This is simpler. this is the inheritance of roles.

Task inheritance
A task can contain another task. for example, "enter a bank ".
We set the "customer" role to have the "Bank access" permission. That is to say, the "customer" can execute the "entering the bank" task. Next, let's assume that "entering the counter" is the parent permission of the bank, that is, "entering the counter" includes "entering the bank ". Anyone who can "enter the counter" can "enter the bank ". We authorize the "go to the counter" task to the "bank clerk ".

In terms of roles, Mr. Wang can enter the bank because Mr. Wang is a "bank clerk" and "bank clerk" includes the "customer" role. Therefore, "tasks" that "customers" can perform can also be performed by "Bank staff. While "customers" can "enter the bank", Wang's staff can also "enter the bank ". This is brought about by the inheritance of roles.

Let's assume that there is a superior Zhao, who can go to the counter for inspection. Then, our task relationship is:
* Zhao has a task: Enter the counter.
Then, Zhao can "enter the bank ". Because "entering the bank" is a task included in "entering the counter. Anyone who can execute "Enter the counter" can execute "enter the bank ". This is the inheritance of tasks.

Action
Action is an unclassified level. That is to say. An action cannot contain other actions. Assume that we have an action called "Raising money from a bank warehouse ". We will include "entering the counter ". As long as you can perform the "withdraw money from the bank warehouse" role, you can execute the "Enter the counter" task.

Relationship
* A role can contain one or more roles.
* A role can contain one or more tasks.
* A role can contain one or more actions.
*
* A task can contain one or more tasks.
* A task can contain one or more actions.
*
* An action can only be contained by a role or task. an action cannot contain or be divided.
In this way, a permission management system is formed. You don't have to think about the literal meaning of "task" and "action. Both form two levels of permissions.

Empower
We have established RBAC permission management, and we need to manage permissions on the WEB. You need to write the code yourself.
Call one of the following methods to define an authorization project based on different types of projects:
* CAuthManager: createRole
* CAuthManager: createTask
* CAuthManager: createOperation
Once we have an authorization project, we can call the following method to establish an authorization project relationship:
* CAuthManager: addItemChild
* CAuthManager: removeItemChild
* CAuthItem: addChild
* CAuthItem: removeChild
Finally, we call the following method to assign a role Project to each user:
* CAuthManager: assign
* CAuthManager: revoke
The following example shows how to use the provided API to create an authorization level:

The code is as follows:

$ Auth = Yii: app ()-> authManager;
$ Auth-> createOperation ('createpost', 'create a Post ');
$ Auth-> createOperation ('readpost', 'Read a Post ');
$ Auth-> createOperation ('updatepost', 'update a Post ');
$ Auth-> createOperation ('deletepost', 'delete a Post ');
$ BizRule = 'return Yii: app ()-> user-> id = $ params ["post"]-> authID ;';
$ Task = $ auth-> createTask ('updateownpost', 'update a post by author himself ', $ bizRule );
$ Task-> addChild ('updatepost ');
$ Role = $ auth-> createRole ('reader ');
$ Role-> addChild ('readpost ');
$ Role = $ auth-> createRole ('author ');
$ Role-> addChild ('reader ');
$ Role-> addChild ('createpost ');
$ Role-> addChild ('updateownpost ');
$ Role = $ auth-> createRole ('editor ');
$ Role-> addChild ('reader ');
$ Role-> addChild ('updatepost ');
$ Role = $ auth-> createRole ('admin ');
$ Role-> addChild ('editor ');
$ Role-> addChild ('author ');
$ Role-> addChild ('deletepost ');
$ Auth-> assign ('reader', 'readera ');
$ Auth-> assign ('author', 'authorb ');
$ Auth-> assign ('edit', 'editorc ');
$ Auth-> assign ('admin', 'admind ');

That is to say, you need to write a management interface to list your roles, tasks, and actions, and then you can manage them on this interface. Such as add, delete, and modify.

Permission check
If you have granted permissions on your management interface, you can check the permissions in the program:

The code is as follows:

If (Yii: app ()-> user-> checkAccess ('createpost '))
{
// Operations such as form Display
} Else {
// If the check fails, you can jump to or display a warning.
}

The code above checks whether the user can execute "createPost", which may be a task or action.

Other
Many people who say that RBAC is not easy to use in the Yii permission system do not actually understand the document. Based on my experience, I feel that RBAC in the Yii Framework is the best framework I have ever used. In addition, you need to write the least code yourself.
RBAC of Yii has more advanced usage, such as "business rules" and "default roles ". You can refer to the official documentation.
I know that some people still do not understand RBAC, or do not use RBAC of Yii. It doesn't matter. you can ask a question in the comment box below.
Happy Yii!