1. Definition Explanation
- User: refers to the login user of the system, which can be understood as a series of operators, such as operation colleague Xiao Zhang, salesman Xiao Wang, etc.;
- Role: refers to the role played by the user in the system, which is the title given to the user by the system, such as general manager, operation, test, etc., which are more than linked to positions and responsibilities, and are used to configure various permissions for corresponding positions;
- Permission: the authorization qualification to be able to access a certain interface or perform certain operations;
- Menu permission: refers to the page access permission corresponding to the first-level menu/second-level menu in the background, such as order management-group order list;
- Operation authority: refers to the authority to add, delete, modify, view, export and other operations on data in the background;
- Data permission: refers to the range of data that the role can view or operate. For example, if a salesperson enters customer information, each salesperson can only see the data created by himself, and cannot see the data of other sales. This is a common Data permission scope.
2. Permission model - RBAC
After introducing the definitions of nouns, the following explains the RBAC permission model.
RBAC permission model: RBAC, or Role-Based Access Control (Role-Based Access Control), is an excellent permission control model. It mainly establishes and manages roles and permissions, and then assigns users different roles to achieve the goal of permission control.
The direct advantage of using this model to configure permissions is that the number of roles is less than the number of users. First assign permissions to roles to complete the assignment of permissions; and then assign
corresponding roles to users to directly obtain the permissions owned by the roles.
A boon for interaction design, simply define which menu permissions a limited role has. It can even be refined to the permission operation of a role in a certain page.
3. Front-end permission control ideas
3.1. Menu control
In the login request, the permission data will be obtained. Of course, this needs the support of the data returned by the backend. (vuex+localstorage)
The front end displays the corresponding menu according to the permission data (dynamic routing). Click the menu to view the relevant interface.
3.2. Interface control
If the user has not logged in and manually enters the address of the management interface in the address bar, it needs to jump to the login interface. If the user has already logged in, if the address is manually entered without permission, it needs to jump to the 404 interface. (Routed Navigation Guards）
3.3. Button control
In the interface of a certain menu, buttons that can be operated, such as delete, modify, and add, must be displayed according to the permission data.
The routing metadata meta can be added to the routing rules, and the current routing rules and the meta data stored in this rule can be obtained through the routing object
custom directiveButton control can be realized very conveniently.
3.4. Control of requests and responses
If the user uses unconventional operations, such as turning some disabled buttons into an enabled state through browser debugging tools, the request sent at this time should also be intercepted by the front end. (Request Interceptor and Response Interceptor）
To be continued. . .
Refer to
Analysis of Permission Module of Mini Program Background Management System https://www.toutiao.com/article/6885879554905375246
Permission System Design https://www.cnblogs.com/iceblow/p/11121362.html
Talking about Front-end Permission Design Scheme https: //blog.csdn.net/brokenkay/article/details/115579833
B station authority video https://www.bilibili.com/video/BV15Q4y1K79c/
B station authority video corresponding document 1 https://blog.csdn.net/ m0_62118859/article/details/124275448
Correspondence document of B station authority video 2 https://blog.csdn.net/weixin_44157964/article/details/108420759