RBAC is still a common permission control in today’s system, so it is necessary to master it

The address of this article http://yangjianyong.cn/?p=171 is reproduced without authorization of the author

What is the RBAC

RBAC. Role-based Access Control. As the name suggests, it is a role-based permission control system. The basic idea is to assign permissions to roles based on roles, and then set the administrator to the corresponding role to obtain permissions for the administrator. When an administrator requests a service right, the administrator is queried from the database and compared with the database for the requested service right. This is used for permission control

Implementation approach

RBAC is typically implemented through a database. This means that the permission data is kept in the database and then compared when requested

RBAC was designed with the following permission tables:

adminThe administrator table

The role administrator table is used to store all the administrators needed in the system. Such as user administrators, financial administrators, operation and maintenance personnel and so on

roleCharacter sheet

Role The role table is used to store the roles needed in the system. For example, user management roles, financial management roles, and operation and maintenance roles

permissionPermissions on the table

The Permission table is used to store the entry for permission requests in the entire system. In common development, this is an API interface or URI address. Is used to save the entire system exposed business operations of the interface

role_permissionRole permission association table

Role_permission The role association table is used to store the permissions of different roles

role_adminThe association table of the role administrator

Role_admin The roLE_ADMIN role association table is used to save the role to which the administrator belongs

menuThe menu list

Menu The menu table is actually not needed from RBAC’s perspective. This table is only from the business level to represent, not the real sense of the logical control of permissions. Most of the time, many developers equate the Menu table with the Role table, which is not correct from the PERSPECTIVE of RBAC

Table structure

adminAdministrator table structure

#code start

CREATE TABLE `backend_admin` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'on the id',
  `username` varchar(255) DEFAULT ' ' COMMENT 'Username',
  `password` varchar(255) DEFAULT ' ' COMMENT 'password',
  `register_time` int(11) DEFAULT '0' COMMENT 'Registration Time',
  `update_time` int(11) DEFAULT '0' COMMENT 'Update Time',
  `status` tinyint(1) DEFAULT '1' COMMENT 'Account status 0= Disabled 1= Normal'.PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Administrator table';

#code end
Copy the code

roleRole table structure

#code start

CREATE TABLE `rbac_role` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'on the id',
  `role_name` varchar(255) DEFAULT ' ' COMMENT 'Role Name',
  `status` tinyint(1) DEFAULT '1' COMMENT 'Role status 0= Disabled 1= enabled',
  `create_time` int(11) DEFAULT '0' COMMENT 'Add time',
  `update_time` int(11) DEFAULT '0' COMMENT 'Update Time'.PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Role table';

#code end
Copy the code

permissionPermission table structure

#code start

CREATE TABLE `rbac_permission` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'on the id',
  `permission_name` varchar(255) DEFAULT ' ' COMMENT 'Permission Name',
  `route_controller` varchar(255) DEFAULT ' ' COMMENT 'Controller',
  `route_action` varchar(255) DEFAULT ' ' COMMENT 'Perform action',
  `parent_id` int(11) DEFAULT '0' COMMENT 'the parent id',
  `status` tinyint(1) NOT NULL DEFAULT '1' COMMENT 'Status 0= Disabled 1= enabled'.PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Permission table';

#code end
Copy the code

role_permissionRole permission association table structure

#code start

CREATE TABLE `rbac_permission_role` (
  `permission_id` int(11) DEFAULT '0' COMMENT 'authorization id',
  `role_id` int(11) DEFAULT '0' COMMENT 'character id'
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Role Permission Association Table';

#code end
Copy the code

role_adminThe role administrator associates the table structure

#code start

CREATE TABLE `rbac_admin_role` (
  `role_id` int(11) DEFAULT '0' COMMENT 'character id',
  `admin_id` int(11) DEFAULT '0' COMMENT 'Administrator ID'
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Role Administrator association Table';

#code end
Copy the code

menuMenu list structure

#code start

CREATE TABLE `rbac_menu` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'on the id',
  `menu_name` varchar(255) DEFAULT ' ' COMMENT 'Menu name',
  `visible` tinyint(1) DEFAULT '1' COMMENT 'Visible 0= not visible 1= visible',
  `parent_id` int(11) DEFAULT '0' COMMENT 'the parent id',
  `status` tinyint(1) DEFAULT '1' COMMENT 'State 0= available 1= unavailable',
  `admin_id` int(11) NOT NULL DEFAULT '0' COMMENT 'Administrator ID',
  `sort` int(11) NOT NULL DEFAULT '0' COMMENT 'order',
  `permission_id` int(11) DEFAULT '0' COMMENT 'authorization id',
  `icon` varchar(255) DEFAULT ' ' COMMENT 'icon'.PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Menu list';

#code end
Copy the code

How does the actual development work

In the conventional background development, the authority actually corresponds to the control of the business, and further refined is the business development, corresponding to the implementation of business code. For example, in MVC mode, it is the Action of each Controller, because the Action implements the control entry exposed to the outside world. So the implementation process is to list each code interface [control entry] of these business implementations, and each interface is a **permission, save these interfaces topermissionTable; inadminSet a default administrator in the table. Such as:super_admin; inroleSet a role with all permissions in the table. Such as:super_role; inrole_adminAdd the data associated with the role administrator to the table. inrole_permissionAdd the permissions of the role to the table. When the administrator logs in to perform operations on a service in the background, the service interface of the operation is obtained. inrole_adminTo obtain the role of the administrator. inrole_permissionQuery the permissions of the role in the ** table. Finally, check whether the requested service interface permission exists in the queried data to know whether the administrator has the operation permission

How do you do that in a PHP project

I’m just going to give you a general idea of how to do this in a PHP project. There are several main knowledge concepts to master, one is namespace; One is PHP’s reflection mechanism. How is this implemented? Will you give detailed examples in other posts

Welcome to visit my blogJianyong Yang’s personal blog is http://yangjianyong.cn