Role-based permission control (RBAC) of thinkphp

1. What is RBAC?

Role-Based Access Control (Role-Based Access Control) has been widely concerned as a promising alternative to traditional access control (autonomous access and forced access.

In RBAC, permissions are associated with roles. You can obtain permissions of these roles by becoming a member of an appropriate role. This greatly simplifies permission management.

In an organization, roles are created to complete various tasks. Users are assigned roles based on their responsibilities and qualifications, you can easily assign a role to another role. Roles can be assigned new permissions based on the new requirements and the merger of the system. permissions can also be revoked from a role as needed. The relationship between roles and roles can be established to cover a wider range of objective situations.

Ii. RBAC in thinkphp

First, let's take a look at the data table used by the official instance and implement permission control through five tables. The definition is as follows:

RBAC requires five data tables

Think_user (User table)

Think_role (user group table)

Think_node (Operation node)

Think_role_user (corresponding to the user and user group)

Think_access (corresponding to each operation and user group)

User table

Role table, which roles are associated with the corresponding userid user

The corresponding role ID is associated based on the user table ID, that is, the role is assigned to the user. For example, the role of userid 3 is 2. According to the role table, 7 represents the role of the employee.

Access Table, permission table, for example, the role ID is 2, that is, the employee's permissions, can correspond to the node

The node table represents the applications-modules-module methods and defines a relationship between them. For example, the Public module with the noteid of 30, the add method with the noteid of, and 34, insert, edit, and update all belong to public. The test method with noteid 85 belongs to the method in the game module with noteid 84.

Iii. Explanation of config configuration file

Let's take a look at the config file in the official thinkphp example:

Array ('app _ autoload_path '=> '@. taglib ', 'session _ auto_start' => true, 'user _ auth_on '=> true, 'user _ auth_type' => 1, // Default Authentication Type 1 logon authentication 2 Real-Time Authentication 'user _ auth_key '=> 'authid', // The User Authentication Session is marked 'admin _ auth_key' => 'admin ', 'User _ auth_model '=> 'user', // The data table model 'auth _ pwd_encoder' => 'md5' is verified by default ', // user authentication password encryption method 'user _ auth_gateway '=>'/public/login', // Default Authentication gateway 'not _ auth_module '=> 'public ', // The Authentication Module 'require _ auth_module '=> ''is not required by default. // The Authentication Module 'not _ auth_action' =>'' is required by default '', // The 'require _ auth_action '=> ''is not required by default. // The 'guest _ auth_on' => false is required by default, // whether to enable the authorization of visitors to access 'est _ auth_id '=> 0, // the visitor's user ID 'db _ like_fields' => 'title | remark ', 'rbac _ role_table '=> 'think _ role', 'rbac _ user_table' => 'think _ role_user ', 'rbac _ access_table' => 'think _ access ', 'rbac _ node_table '=> 'think _ node', 'show _ page_trace' => 1 // display debugging information );

The public module does not require authentication. The principle is simple. Before logon, the public module is a tourist identity. If you log on to the page, you must have permissions, where can I log on? Right, huh, huh. The default gateway address is an authentication failure. You do not have the permission to jump to this address and log on again. Admin_auth_key indicates the super administrator permission. If you create a user named admin in the User table, this user is the Super administrator, and you do not need to assign permissions to it, why do you need to set up an administrator like this, because when you assign wrong permissions, it will easily lead to confusion of system permissions and make it impossible for everyone to access them. At this time, the super administrator will come.

Iv. Several important methods of RBAC

Authenticate ($ map, $ model = ") method is used to pass in the query user's conditions and the user table's model. The returned array contains the user's information.

The saveaccesslist ($ authid = NULL) method is used to pass in the user ID. This method does not return a value, but only sets the value of $ _ session ['_ access_list, it contains all nodes with Operation permissions for all user groups corresponding to the user $ _ session ['_ access_list'] ['Project name'] ['module name'] ['operation '], after determining the permission, you can determine whether the current project, module, and operation can be found in $ _ session ['_ access_list. S

The checkaccess () method checks whether the current module and operation need to verify that the bool type is returned.

Checklogin () method to detect Logon

The accessdecision ($ appname = app_name) method is used to check whether the operations of the current project module are in the $ _ session ['_ access_list'] array, that is, in the $ _ session ['_ access_list'] array, $ _ session ['_ access_list'] ['current operation'] ['current module'] ['current operation'] whether it exists. If yes, you have the permission. Otherwise, flase is returned.

The getaccesslist ($ authid) method returns the permission list $ _ session ['_ access_list'] by querying the database.

 

(This article by talking about blog: http://tanteng.sinaapp.com/2012/11/thinkphp-rbac)