The authority part of general enterprises is divided into function authority and data authority.
1. Functional authority
Functional permissions are the permissions of which menus, buttons, and operations that users can see after logging in.
In general, functional permissions already have very mature industry solutions and frameworks.
For example, there is the idea of RBAC (Role-Based Access Control, role-based access control).
There are three concepts: users, roles, resources.
A user is a user, and a role is assigned to the user and resources are assigned to the role. The access rights of these menus are resources.
In this way, five watches are enough. User table, role table, resource table, user role relationship table, role resource relationship table.
There are several types of general industry solutions:
1. Based on the shiro framework
This framework has done login, authentication, and functional permissions. It is a classic, mature, and lightweight framework. Suitable for integration with spring, but not limited to spring framework.
Shiro's original intention was only to provide convenience for monolithic applications, but with the increase in popularity, no matter whether it is a monolithic application or a distributed cluster, there are a lot of introductions on the Internet, I will not say this, I can go by myself Find.
2. Based on the spring-security framework
As the name implies, the members of the spring family bucket are seamlessly connected with spring, but the order of magnitude is heavy, the learning cost is greater than shiro, and there are not too many advantages over shiro in common functions, so it should be rarely useful now. All who can use this use shiro.
3. Other solutions
You can look at a program I wrote before, based on aop and annotations, suitable for novice practice, only one idea is provided.
A simple permission system model
Second, the data permissions
Data permission is to control which data users can see and which data they cannot see. For example, the department head can only see the data in his own department by default, and some data in the department next door is generally not visible.
Because data permissions are closely related to the business, there has never been a unified framework or solution in the industry, which is generally hard-coded. I just put forward a slightly standardized idea based on the scenarios I have encountered, purely personal ideas, for reference only.
That is to use the template pattern in the design pattern, define the skeleton by using an abstract class, and then make up your own implementation for different business subclasses.
The general skeleton steps are as follows, take the example of the authority
that the user can only see the relevant data of his own department: premise: general business data, it will not be directly marked on the data to which department, because the department structure will always change, or even change greatly, Therefore, it is generally the responsible person that hangs on the business data.
Moreover, the general data permissions must also be configurable, which is like having a configuration that can be designated to allow people in department A to also see data in department B. This is a special case, and we have to have a table to maintain records.
1. Get the user ’s department
2. Get all the employee collections {a, b} under this department
3. Get the corresponding all employee collections {c, d, e} under special circumstances
4. Put the last two Collection consolidation, as the employee collection A {a, b, c, d, e} by default
5. Get all the responsible person collection B {a, b, c, x, y, z} in this business data, And merge with the above set A to find the data set that contains set A in set B. We call the final set C {a, b, c}
6. Finally, use employee set C as a condition to find the corresponding business data.
The first step to the fifth step above can be used as an interface to subclass, delay implementation, and the final execution is the sixth step.
In this way, the procedures for using data permissions for all businesses are completely regulated, and each business can be implemented. The above steps can be fine-tuned, just see the truth.
Template mode, you can refer to an introduction I wrote before
[design mode] ------ template mode
Note: Using the template mode to achieve data permissions, I personally feel that it is not the optimal solution. The reason why the template is used is to regulate the logical order of each business.
3. Summary
To do permissions, you must first distinguish the boundaries between functional permissions and data permissions. It is best not to have an intersection. For coding convenience, do not rub the two together. For example, when it comes to data permissions, it is easy to think of the role of the functional permissions. At first glance, it seems a lot more convenient at first glance, but for future maintenance and the learning cost of new employees in the future, it is very large, because once it is rubbed up, it is equivalent to coupling functional permissions and data permissions. We know that Decoupling is a particularly troublesome thing after the project is enlarged, so if you can avoid coupling at the beginning of the project, try to avoid it. Therefore, if the project is a collaborative development by multiple people in a team, it is possible to hand over the functional permissions and data permissions to two people at the same time. Do your own to avoid coupling.
