General permission management design in Java (recommended)

Realize user authority management in business system

Permissions in the B / s system are more important than those in the C / s system. Because the C / s system has a special client, the access permission detection of users can be realized through the client or through the client + server detection. In the B / s system, the browser is already available for every computer. If a complete permission detection is not established, Then an "illegal user" may 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 detect access rights, so that authorized users can use authorized functions normally and legally, and those unauthorized "illegal users" will be completely "shut out". Now let's learn how to design a permission system that can meet the user function permission control in most B / s systems.

Demand statement

• personnel with different responsibilities should have different permissions for system operation. Excellent business system, which is the most basic function.

• you can assign permissions to groups. For the business system of a large enterprise, it is time-consuming and inconvenient to require the administrator to assign system operation permissions to its employees one by one. Therefore, the concept of "group" operation is put forward in the system. The personnel with the same permissions are grouped into the same group, and then the permissions are assigned to the group.

• the rights management system should be extensible. It should be able to join any system with permission management function. Just like components, they can be reused continuously, instead of redeveloping the permission management part every time a management system is developed.

• meet the functional permissions in the business system. In traditional business systems, there are two kinds of permission management, one is function permission management, and the other is resource permission management. Between different systems, function permission can be reused, while resource permission 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 program structure, but start with program flow and database structure. In order to realize the requirements, the design of database is extremely important. Whether the concept of "group" operation or the reusability of the whole permission management system lies in the design of database.

Let's first analyze the database structure:

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, which record the information of "permission", "management group" and "personnel" in turn. As shown in the following figure:

The relationship between the three tables is many to many. A permission may belong to multiple management groups at the same time, and a management group may also contain multiple permissions at the same time. Similarly, a person may belong to multiple management groups at the same time, and a management group may also contain multiple persons at the same time. As shown 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 between them. The two tables play the role of mapping: ActionGroup table (hereinafter referred to as permission mapping table) and mastergroup table (hereinafter referred to as personnel mapping table). The former maps the interaction between permission table and management group table. The latter maps the interaction between personnel table and management group table. As shown in the following figure:

In addition, a table is required to control the permission column in the menu on the left when the system is running, that is, the "permission column table", as shown in the following figure:

According to the above analysis, we design the database structure, as shown in the following figure:

Click here to view the field design of the data table of the authority management system

In order to make a good analysis, we split the database structure diagram. The functions of the three entity tables are clear. Now let's take a look at the functions of the two mapping tables.

A permission mapping table is shown in the following figure:

First, let's understand the field association between permission mapping table, management group table and permission table.

Look at the red circle in the figure. First look at the gorupid Field Association. The performance of this association method in the actual database is shown in the following figure:

As shown in the figure, if the groupid of "super administrator" in the management group table is 1, the permission with groupid of 1 in the permission mapping table is the permission of "super administrator".

The groupid field is used to find out which permissions a management group can execute. However, the details of these permissions are queried by the action field association.

The performance of the action field associated in the database is shown in the following figure:

Through this association, the detailed information of those permissions in the permission mapping table can be queried. Taken together, we know what permissions a management group can execute and what the details of these permissions are.

You might ask, why not use the ActionID field to associate? Because:

• the ID field in the permission table may change after multiple database operations.

• the permission mapping table only records the permissions that can be executed by a management group.

• once the ID in the permission table changes, the records in the permission mapping table change.

• the permissions that a management group can execute are bound to go wrong, which is very undesirable.

Considering the above situation, the action field should be used for association, because:

• in the permission table, the ID may change, but the action field cannot change under any circumstances.

• the action field recorded in the permission mapping table will not change.

• the permissions that a management group can perform will not go wrong.

II. Personnel 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 following figure:

Look at the red circle in the figure. First look at the groupid Field Association. The performance of this association method in the database is shown in the following figure:

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 the administrator group.

This association method is used to find out who is in a management group. As above, personnel details are queried by association with the ID field (the masterid field in the personnel mapping table).

The association of ID field (masterid field in personnel mapping table) is shown in the following figure in the database:

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 administrator in the personnel mapping table.

Only in this way can you query the details of the personnel in the management group. To sum up, you can know who is in a management group and the details of this person.

Combined with the permission table and permission mapping table mentioned above, the "group" operation in the requirements is realized, as shown in the following figure:

In fact, the management group table only records the basic information of the group, such as name, group ID, etc. The details of the personnel in a group and the permissions that can be executed by the group are recorded in the personnel table and permission table. Only the two mapping tables can really record who is in a group and what permissions can be executed. Through the connection of the two mapping tables, the interaction between the three entity tables can be realized, thus completing the "group" operation mentioned in the requirements.

Let's look at the interaction between permission column table and permission table. The field association between the two tables is shown in the following figure:

The two tables are associated by using the actioncolumnid field. The performance of this association method in the database is shown in the following figure:

As shown in the figure, through this association method, we can clearly see which column the permission in the permission table belongs to.

Now, the database structure is very clear, and the function of assigning permissions and "group" operation have been realized. Next, let's analyze the reusability of the permission management system mentioned in the requirements.

Why can the system built with this database design method be reused?

Three entity tables record three decisive elements in the system. Permissions, groups, and people. These three elements can be added arbitrarily without affecting each other. No matter what type of business system, these three decisive elements will not change, which means that the structure will not change, but only the data.

The relationship between the three elements is recorded in the two mapping tables. However, these relationships are completely created artificially. When they need to be changed, they only operate 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 database system designed in this way can be reused and can withstand the test of "change".

Summary:

The key point of this system is that the three entity tables firmly grasp the core components of the system, and the two mapping tables perfectly map the interaction between the three entity tables. The difficulty is to understand the work of the mapping table, which records relationships and implements the concept of "group" operation. The overall design of the system is based on the principle that it can be "reused" in different MIS systems to meet the functional permission settings of different systems.

Appendix:

Field design of data table in authority management system

Let's take a look at the database table design of the permission management system, which is divided into six tables, as shown below:

Action table:

The action table records all actions in the system and their related descriptions.

Actioncolumn table:

The actioncolumn table records the action columns. When the system is running, the menu bar on the left provides several different functions. Each block is a column. Every time a column is added, a record in the table will be added. Correspondingly, a column will be added in the menu bar on the left.

ActionGroup table:

The action group table records the action group.

Groupmanager table:

The group manager table records the relevant information of the management group. Each time a management group is added, one record will be added here.

Mastergroup table:

The master group table records the management group of the administrator. 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. Each time an administrator is added, a record will be added to the table.

The above general permission management design (recommended) in Java is all the content shared by Xiaobian. I hope it can give you a reference and support programming tips.