The permission control of the management system in the middle and backend is very important. I personally think it is the core. Rich text editor and some table export functions are considered page-level difficulty. Let’s share some of my favorite views on permission control.
Enterprise-level middle and backend permission control (vue）
Note: The information is referenced from the Public Course of B Station
In the web system, permissions have been controlled by the backend program for a long time. Why? Because the essence of the web system revolves around data, and the backend program that is most closely related to the database is the backend program. So for a long time, permissions have been just a topic that backend programs need to consider. But with theFront and back end separationWith the popularity of architecture, more and more projects are also exercising permission control on the front end.
1. Permission-related concepts
1.1. Category of permissions
Backend permissions
Basically speaking, the front-end is just a display of view layers. The core of permissions lies in the data changes in the server, so the back-end is the key to permissions. Back-end permissions can control whether a user can query data, whether it can modify data, etc. How does the back-end know which user sends the request to the back-end permission design RBAC
Front-end permissions
In essence, the control of front-end permissions is to control the display of the front-end view layer and the requests sent by the front-end. However, it is absolutely absolutely necessary to only control the front-end permissions without back-end permissions. Front-end permissions can only be said to be the icing on the cake.
1.2. The significance of front-end permissions
If only from the perspective of being able to modify the data in the database in the server, it is indeed enough to only control the backend, then why more and more projects have also controlled the front-end permissions? This is mainly due to the benefits of reducing the possibility of illegal operations. It is not afraid of thieves but afraid of thieves being concerned about. Showing a button on the page that will eventually fail even if you click it, it will inevitably increase the possibility of illegal operations by those who are interested.
Eliminate unnecessary requests as much as possible to relieve server pressure. Unnecessary requests, requests that fail to operate, requests that do not have permissions, should not be sent at all. If there are fewer requests, it will naturally reduce the pressure on the server and improve user experience.
Cookie，session，token
User
⻆⾊
Permissions
According to the permissions the user has, display the content within the scope of his/her permissions, avoiding the user's trouble on the interface, and allowing the user to focus on his/her duties.
2. Front-end permission control idea
2.1. Menu control
In the login request, permission data will be obtained. Of course, this requires the support of the backend to return data. The frontend displays the corresponding menu based on the permission data. Click the menu to view the relevant interface.
2.2. Interface control
If the user is not logged in, manually type the address of the management interface in the address bar, you need to jump to the login interface. If the user is already logged in, but manually type the address that is not in permissions, you need to jump to the 404 interface.
2.3. Button control
In the interface of a certain menu, you must also display buttons that can be operated based on permission data, such as deletion, modification, and addition
2.4. Request and response control
If the user uses unconventional operations, such as through browser debugging tools, the request sent at this time should also be intercepted by the front-end
3. Vue's permission control implementation
3.1. Menu control
View the data obtained after logging in
{
"data": {
"id": 500,
"rid": 0,
"username": "admin",
"mobile": "13999999999",
"email": "123999@",
"token": "Bearer
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1aWQiOjUwMCwicmlkIjowLCJpYXQiOjE1M
-
tPsO9r_pxHIQ5i5L1kX9RX444uwnRGaIM"
},
"rights": [{
"id": 125,
"authName": "User Management",
"icon": "icon-user",
"children": [{
"id": 110,
"authName": "User List",
"path": "users",
In this part of the data, in addition to the user's basic information, there are two fields that are very critical tokens, which are used to maintain the status of the front-end user: the user has permission data, the first-level permission corresponds to the first-level menu, and the ⼆ level permission corresponds to the ⼆ level menu. According to the data in the rights, dynamically render the left menu bar. The data is obtained, but it is only used, so the data can be maintained using vuex for the code in vuex
"rights": ["view", "edit", "add", "delete"]
}]
}, {
"id": 103,
"authName": "Lottery Management",
"icon": "icon-tijikongjian",
"children": [{
"id": 111,
"authName": "Role List",
"path": "roles",
"rights": ["view", "edit", "add", "delete"]
}]
}, {
"id": 101,
"authName": "Product Management",
"icon": "icon-shangpin",
"children": [{
"id": 104,
"authName": "Product List",
"path": "goods",
"rights": ["view", "edit", "add", "delete"]
}, {
"id": 121,"authName": "Product Category","path": "categories","rights": ["view", "edit", "add", "delete"]
}]
}],
"meta": {"msg": "Login successfully","status": 200}
}
export default new ({
state: {
rightList:[]
},
mutations: {
setRightList(state, data) {
= data
Because the menu data is obtained after logging in, after obtaining the menu data, it is stored in Vuex. Once the interface is refreshed, the data in Vuex will be re-initialized, so it will become empty.ArrayTherefore, it is necessary to store permission data in sessionStorage and keep it in sync with the data in Vuex
},
Logic of exit button
3.2. Interface control
1. The normal logic is to jump to the management platform interface through the login interface after successful login. However, if the user directly enters the management platform address, the login step can also be skipped. Therefore, you should determine whether the user is logged in at a certain time, such as determining whether to log in when to use the routing navigation guard.
2. Although the menu item has been controlled, the routing information still exists in the browser. For example, the user zhangsan does not have the role menu. However, if he typed in the address of /roles in the address bar, he can still ask the role interface route navigation guard. Although the route navigation guard can take out the rightList from vuex every time the routing address changes, determine whether the user will access the interface. However, from another perspective, should this route that does not have permissions do not exist at all?
Dynamic routing Dynamically added after successful login
3.3. Button control
Button control
Although the user can see some interfaces, the user may not have permission to some buttons in this interface. Therefore, we need toComponentsSome buttons in the control. Buttons that the user does not have permissions are hidden or disabled, and in this section, the logic can be placed in a custom command
3.4. Request and response control
Request control
In addition to login requests, you must bring a token, so that the server can identify your identity. If a non-permission request is issued, it should be organized directly within the front-end access. Although this request will be denied to the server, the response control will be obtained. The status code 401 returned by the server means that the token has timed out or has been tampered with. At this time, you should forcefully jump to the login interface.
4. Summary
The implementation of front-end permissions must provide data support by the backend, otherwise it cannot be implemented. The structure of the returned permission data needs to be communicated and negotiated by the front-end. What kind of data is the most convenient to use.
// Permissions available in the current module
// View get request
// Add post request
// Modify the put request
// Delete delete request
// According to the request, what kind of operation is it
// Determine whether the action exists in the current route permissions
// permission denied
4.1. Menu control
Permission data needs to be shared among multiple components, so vuex is used to prevent refreshing interfaces and permission data is lost, so it needs to be stored in sessionStorage, and the synchronization of the two is ensured.
4.2. Interface control
The route's navigation guard can prevent skipping the login interface dynamic routing can make the routing rules for interfaces that do not have permissions do not exist at all.
4.3. Button control
The routing rules can be added to the routing rules. The current routing rules can be obtained through the routing object, and the metadata custom instruction stored in this rule can be easily implemented.
4.4. Request and response control
Use of request interceptors and response interceptors
Restful contract for request method