Implement user permission management in business systems
Permissions in the B/S system are more important than those in C/S. Because the C/S system has a special client, the permission detection of access users can be implemented through the client or through client + server detection. In B/S, browsers are already available to every computer. If a complete permission detection is not established, an "illegal user" is likely to easily access all functions in the B/S system through the browser. Therefore, B/S business systems need to have one or more permission systems to implement access permission detection, so that authorized users can use authorized functions normally and legally, and those unauthorized "illegal users" will completely "reject them". Let's take a look at how to design a permission system that can meet the control of user function permissions in most B/S systems.
Requirement statement
• Personnel with different responsibilities should have different permissions for system operations. Excellent business system, this is the most basic function.
• You can assign permissions to the Group. For a business system of a large enterprise, it is time-consuming and inconvenient to ask administrators to assign system operation permissions to their employees one by one. Therefore, the system proposes the concept of operating on "groups", and organizes people with consistent permissions into the same group, and then allocates permissions to the group.
• The permission management system should be extensible. It should be able to join any system with permission management capabilities. Just like components, they can be constantly reused, instead of redeveloping the permission management part for every management system developed.
• Meet functional permissions in the business system. In traditional business systems, there are two types of permission management. One is the management of functional permissions, and the other is the management of resource permissions. Between different systems, functional permissions can be reused, while resource permissions cannot.
About Design
With the help of NoahWeb's action programming concept, in the design stage, system designers do not need to consider the design of the program structure, but start with the program flow and database structure. In order to realize the requirements, the design of the database is extremely important. Whether it is the concept of "group" operation or the reusability of the entire set of permission management systems lies in the design of the database.
Let's analyze the database structure first:
First, the action table ( hereinafter referred to as "Permission Table" ), the gorupmanager table ( hereinafter referred to as "Management Group Table" ), and the master table ( hereinafter referred to as "Personnel Table" ), are three entity tables that record the information of "Permissions", the information of "Management Group" and the information of "Personnel". As shown in the figure below:
The relationship between these three tables is many-to-many. One permission may belong to multiple management groups at the same time, and one management group may also contain multiple permissions at the same time. By the same token, a person may belong to multiple management groups at the same time, and a management group may also include multiple personnel at the same time. As shown in the figure below:
Since there is a many-to-many relationship between these three tables, it is best to use the other two tables to complete the interaction. These two tables play a mapping role, namely the "actiongroup" table (hereinafter referred to as "Permission Mapping Table") and the "mastergroup" table (hereinafter referred to as "Personnel Mapping Table") . The former maps the interaction between the permission table and the management group table. The latter maps the interaction between the personnel table and the management group table. As shown in the figure below:
In addition, a table is also needed to control the permission column in the left menu of the system running time, that is, the "Permission Column Table", as shown in the figure below:
Based on the above analysis, we conduct database structure design, as shown in the figure below:
Click here to view the permission management system data table field design
In order to perform good analysis, we split the database structure chart. The role of the three entity tables is already very clear. Now let’s take a look at the role of the two mapping tables.
A permission mapping table is shown below:
First, let’s take a look at the field association between the permission mapping table and the management group table and the permission table .
Looking at the red circle in the picture, first look at the association of the gorupid field. The performance of this association method in the actual database is as follows:
As shown in the figure, the groupid of "super administrator" in the management group table is 1, so the permission with groupid of 1 in the permission mapping table is that is the permission owned by the "super administrator".
Use groupid field association to find out what permissions a management group can execute. However, the detailed information of these permissions is found in the action field association.
The behavior of the action field in the database is as follows:
Only through this association can the detailed information of those permissions in the permission mapping table be found. In summary, we know what permissions a management group can execute and what details of these permissions are.
Maybe you will ask, why not use the actionid field to associate? because:
• The id field in the permission table may change after multiple database operations.
• The permissions map table only record the permissions that one management group can execute.
• Once the id in the permission table changes, the records in the permission map table also change.
• There will be an error in the permissions that an administrative group can execute, which is very undesirable.
Considering the above situation, the action field should be associated because:
• In the permission table, the id may change, but the action field cannot change under any circumstances.
• The action fields recorded in the permission map table will not change.
• There will be no errors in the permissions that an administrative group can execute.
The two-person mapping table is as follows:
Let’s learn about the field association between the personnel mapping table , the management group table and the personnel table , as shown in the figure below:
Looking at the red circle part in the picture, first look at the groupid field association. This association method performs in the database as shown in the figure below:
As shown in the figure, the groupid of the "Super Administrator" group is 1. Let's look at the personnel mapping table . Admin belongs to the Super Administrator group, while administrator belongs to the Super Administrator group and also belongs to the Administrator group.
This association method is used to find out who is in a management group. As above, the detailed information of a person is queried by association with the id field (the masterid field in the personnel mapping table ).
The id field (masterid field in the personnel mapping table ) is related to the database as shown in the figure below:
A person may belong to multiple "management groups" at the same time. As shown in the figure, the administrator belongs to two "management groups" at the same time. Therefore, there will be two records about administrators in the personnel mapping table .
Only in this way can we query the detailed information of the personnel in the management group. Only by combining it can we know who is in a management group and the detailed information of this personnel.
Combining the permission table and permission mapping table mentioned above, the "group" operation in the requirements is realized, as shown in the figure below:
In fact, the management group table only records the basic information of the group, such as name, group id, etc. As for the details of the people in a group, as well as the details of the permissions that the group can execute, they are recorded in the personnel table and the permission table . Only the two mapping tables really record which people in a group are and what permissions can be executed. Only through the connection of two mapping tables can the interaction between the three entity tables be realized, thus completing the "group" operation mentioned in the requirements .
Let’s take a look at the interaction between the permission column table and the permission table . The fields between these two tables are as follows:
The two tables use the actioncolumnid field to be associated. The relationship method in the database is shown in the figure below:
As shown in the figure, through this association method, we can clearly see which column the permissions in the permission table belong to.
Now, the database structure is very clear, and the function of assigning permissions and "group" operations have been implemented. Let’s analyze the reusability issues of permission management systems mentioned in the requirements.
Why can a system built using this database design method be reused?
Three decisive elements in the system are recorded in the three entity tables. "Permissions", "Groups" and "People". These three elements can be added at will without being affected by each other. No matter which type of business system it is, these three decisive elements will not change, which means that the structure will not change, but only data will change.
The relationship between the three elements is recorded in the two mapping tables. But these relationships are completely created by man. When changes are needed, they only operate on the records in the database without changing the structure.
The permission column table records the columns displayed when the system is used . Whether you want to add columns, modify columns, or reduce columns, it is just an operation record.
To sum up, the system can be completely reused by designing a database in this way and can withstand the test of "change".
Summarize:
The key to this system is that the three physical tables firmly grasp the core components of the system, and the two mapping tables perfectly map the interaction between the three physical tables. The difficulty lies in understanding the work of the mapping table, which records the relationship and implements the concept of "group" operation. The overall design of the system is to meet the functional permission settings of different systems by "reusing" in different MIS systems.
appendix:
Field design of permission management system data table
Let’s take a look at the database table design of the permission management system, which is divided into six tables, as shown in the figure below:
Action table:
The action table records all actions in the system and the action-related description.
actioncolumn table:
The actioncolumn table records the action column. When the system is running, the left menu bar provides several different functions. Each block is a column. Each column is added, one record in the table will be added. Correspondingly, a new column will be added to the left menu bar.
actiongroup table:
The actiongroup table records the group where the action is located.
GroupManager table:
The groupmanager table records relevant information about the management group. For each management group added, one record will be added here.
Mastergroup table:
The mastergroup table records the management group where the administrator is located. Since an administrator may belong to multiple groups at the same time, there may be multiple records about an administrator in the table.
Master table:
The master table records the information of all administrators. For each administrator added, the table will add a record.
The above general permission management design (recommended) in Java is all the content I share with you. I hope you can give you a reference and I hope you can support Wulin.com more.