Shulou(Shulou.com)06/01 Report--

What is the permission design of Matrxi-Web, many novices are not very clear about it. In order to help you solve this problem, the following editor will explain it in detail. People with this need can come and learn. I hope you can get something.

Matrxi-Web permission design

For a back-end system, permissions are infrastructure and security. Without permissions, the system may face all kinds of risks at any time, so permission design is very important to the back-end system. In Javaweb development, there are many frameworks with permission to develop, such as shrio and Spring security, but they are all heavyweight. As a back-end management system, developing a framework with such permissions will slow down the progress of development. So in this project, I wrote a simpler access control framework, which is very easy to use.

The idea of authority design

In the Matrxi-Web project, the request needs to carry a Token, and when the request passes through the Filter (the actual project is a HandlerInterceptor using Spring MVC), it will determine whether the request Url has a Token. If there is a Token, parse the Token to get the user information. If the parsing of the Token fails, the logic of whitelist judgment is entered. If the parsing is successful, the request is passed. If the request does not carry Token or fails to parse Token, determine whether it is in the Url whitelist (such as login API, swagger document, etc.). If the request is not in the url whitelist, you will be prompted with no permission to access it.

In the filter layer, if the request is passed, the request goes into the method of the specific class, such as the method of Controller. If a custom annotation @ HasPermission is added to the class method, the class will generate an aroud-type aspect (that is, the aop of spring) when it is loaded. Before executing the method of the specific class, it will determine whether the user has the permission to call the method, thus playing the role of permission control.

RBAC

At the data level of privilege control, the most commonly used method is RBAC (Role-Based Access Control), that is, role-based permission control. In RBAC, permissions are associated with roles, and users get permissions for those roles by becoming members of the appropriate roles. This greatly simplifies the management of permissions.

RBAC believes that authorization is actually the relationship among Who, What, and How triples, that is, the operation of Who to How to What, that is, the operation of "subject" to "object".

Who: is the owner or principal of the permission (e.g. User,Role). What: is an operation or operation,object. How: specific permissions (Privilege, positive authorization and negative authorization).

In the Matrix-Web project, the classic RBAC is also used, that is, each user has one or more roles, and the role gives specific menu operation rights. The database design for Martrix-Web is shown in the following figure:

[external link image transfer failed. The origin server may have hotlink protection mechanism. It is recommended to save the image and upload it directly (img-ziItvtN3-1590667416151) (https://static.javajike.com/img/2020/05/matrix/matrix-web009.jpg)])

The user Id (user_id) is bound with the role Id (role_id), and the role Id (role_id) and menu_code (menu coding binding), so the user's role needs to be entered when the user is created, and the role needs binding permission. The input permission button on the front-end interface shows the following figure: [external link image transfer failed. The origin server may have hotlink protection mechanism. It is recommended to save the image and upload it directly (https://static.javajike.com/img/2020/05/matrix/mw010.jpg)]).

The user binds the role as shown below: [external link image transfer failed. The origin server may have hotlink protection mechanism. It is recommended to save the image and upload it directly (https://static.javajike.com/img/2020/05/matrix/mw011.jpg)]).

Token design

One important thing in the system setup is that Token,Token represents the user, and almost all requests need to carry Token. So where did Token come from? It is generated based on the user name. So what kind of situation will be produced? After the user logs in successfully, a Token is generated and returned to the browser. The browser is stored in LocalStorage, and all subsequent requests must carry Token. In this way, according to the Token, the server can know who the user of each request is, thus determining whether the user of the request has permission or not.

The above summary describes the idea of access control implemented by Matrix-web as a whole. Now let's make a summary:

First of all, the user needs to log in, fill in the user name and password, and the backend receives the login request to verify the user and password. After the verification is successful, the Token is generated according to the user name and returned to the browser. After the browser receives the Token, it will be stored in the local LocalStorge. Subsequent browsers will carry the Token when they initiate requests. After the request reaches the backend, the Filter will determine whether it is whitelisted url (such as login API url), and if so, it will be released; otherwise, it will enter Token verification. If there is a Token and the resolution is successful, it will be released, otherwise, no permission access will be returned. After Filter judgment, the request reaches the specific Controller layer, and if a comment on permission judgment is added to the Controller layer, a proxy class is generated. The proxy class determines permissions based on Token before executing the specific method. The user's Token is extracted and the requested userId is parsed, and the user's right point is obtained from the storage layer according to the userId. Access control is implemented in this way by RBAC. After obtaining the user permission point, get the permission information of the permission judgment annotation to see whether the user permission point contains the permission information of the permission annotation. If so, the permission verification is passed, otherwise the request returns no permission. Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.