Realization of user Rights Management in business system--design article

　　The authority in B/s system is more important than C/S, c/s system because of a special client, so access to the user's rights detection can be implemented through the client or through the client + server detection, and b/s, the browser is every computer already have, if not to establish a complete permission detection, Then an "illegal user" is likely to easily access through the browser to the B/s system of all functions. Therefore, b/s business system needs to have one or more permission systems to achieve access detection, so that authorized users can legitimately use the authorized function, and the unauthorized "illegal users" will be their complete "shut out". Below let us know how to design to meet the majority of B/s system in the user function rights control of the rights system.

Requirements Statement people with different responsibilities should have different permissions for system operations. Excellent business system, this is the most basic function.

You can assign permissions to groups . For a large enterprise business system, it is time-consuming and inconvenient to ask the administrator to assign the system operation permissions to the employees. Therefore, the concept of "group" is put forward in the system, the people who have the same rights are programmed into the same group, and then the group is assigned permissions.

The Rights management system should be extensible . It should be added to any system with rights management capabilities. Just as a component can be reused continuously, rather than developing a set of management systems, it is necessary to restart the Rights Management Section.

to meet the functional permissions in the business system. in the traditional business system, there are two kinds of rights management, one is the management of the function authority, and the other is the management of the resource rights, which can be reused in the different systems, and the resource rights cannot.

About Design

　　With the help of Noahweb's action programming idea, in the design stage, the system designers need not consider the design of the program structure, but start with the program process and the database structure. In order to realize the requirement, the design of database is important, whether it is the concept of "group" operation or the reusability of the whole set of Rights management system, it is the design of database.

Let's first analyze the database structure:

　　First, the Action table (hereinafter referred to as "permission Table"), Gorupmanager table (hereinafter referred to as "Administrative Group table"), and master table (hereinafter referred to as "people table"), is a three entity table. They record information about permissions, information about administrative groups, and information about people. The following figure:

　　The relationships between the three tables are Many-to-many, one of which may belong to multiple administrative groups, and one administrative group may contain multiple permissions at the same time. In the same way, one person may belong to more than one administrative group, and one administrative group may contain multiple people at the same time. The following figure:

　　Since there is a many-to-many relationship between the three tables, the interaction between them is best done using the other two tables. These two tables play the role of mapping, respectively, "Actiongroup" table (hereinafter referred to as "Rights mapping Table") and "Mastergroup" table (hereinafter referred to as "personnel map"), the former map of the rights table and administrative Group table interaction. The latter maps the interaction between the person table and the Administrative Group table. The following figure:

　　In addition, a table is needed to control the permission compartment in the left menu of the system runtime, which is "permission compartment table", as shown below:

　　According to the above analysis, we carry on the database structure design, the following diagram:

Click here to view Rights Management system data table field design

　　In order to be able to perform good analysis, we split the database structure diagram, the role of three entity table is already very clear, now we look at the role of two mapping table.

A Rights mapping table is shown below:

　　First, let's take a look at the relationship between the permission map and the administrative group tables , and the fields between the permission tables .

　　Look at the red circle in the picture, first look at the Gorupid field associated, this association method in the actual database performance as shown in the following figure:

　　As shown in the figure, the groupid of "super Administrator" in the Admin Group table is 1, so the groupid of 1 in the rights map is the privilege that "super Administrator" has.

　　The GroupID Field Association is used to find out what permissions an administrative group can perform. However, the details of these permissions are queried by the Action Field Association.

　　The action field is associated with the performance of the database in the following illustration:

　　This association is used to query the details of those permissions in the permission mapping table . In combination, we know what permissions an administrative group can perform, and what the details of those permissions are.

　　You might ask, why not use the ActionId field to relate to it. Because: the ID field in the permission table may change after several database operations. The Permission mapping table only records the permissions that an administrative group can perform. Once the ID in the permission table changes, the records in the permission map table are changed as well. It is highly desirable that an administrative group can execute permissions that are bound to go wrong.

　　In view of the above, you should use the action field to relate because the ID may change in the permission table , and the action field will not change in any case. The action field for the record in the permission mapping table will not change. There is no error in the permissions that an administrative group can perform.

The two-person mapping chart is as follows:

　　Let's take a look at the relationship between the personnel mapping table and the Administrative Group table and the people table , as shown in the following figure:

　　Look at the red circle part of the picture, first look at the GroupID Field Association, this association in the database performance as shown in the following figure:

　　As shown in the "Super admins" group, the GroupID is 1, we look at the people mapping table , admin belongs to the Super Administrators group, and the administrator belongs to the Super Administrator group and also to the Administrators group.

　　This association is used to find out who the people in an administrative group are. As above, the details of the person are associated with the ID field (the MasterID field in the Personnel Mapping table ).

　　The ID field (the MasterID field in the Personnel map table ) is associated with the form shown in the database as follows:

　　A person may belong to more than one "administrative group", as in the figure, the administrator belongs to two "administrative groups". Therefore, the record of the administrator in the People mapping table will be two.

　　This association is the way to query the details of people in the administrative group. Together, you can know who the people in an administrative group are and the details of this person.

　　In combination with the permission table and the Permission mapping table mentioned above, the "group" operation in the requirement is implemented, as shown in the following figure:

　　In fact, the Admin Group table only records the basic information of the group, such as name, group ID, and so on. Details about the person in a group, and the permissions that the group can perform, are recorded in the people table and the permission table . Two mapping tables really record which people a group has and what permissions they can perform. Through the convergence of the two mapping tables, the interaction between the three entity tables is realized, thus completing the "group" operation mentioned in the requirements.

　　Let's take a look at the interaction between the Permissions column table and the permission table . The fields between the two tables are associated with the following figure:

　　The two tables are associated with the Actioncolumnid field, which behaves as shown in the database as follows:

　　As shown in the diagram, this association allows us to see very clearly which columns the permissions in the permission table belong to.

　　Now that the database structure is clear, the function of assigning permissions and the "group" operation has been implemented. Let's analyze the reusability of the privilege management system mentioned in the requirements.

　　Why the system built with this database design can be reused. the three entity tables record three decisive elements in the system. permissions, groups, and people. These three elements can be arbitrarily added and unaffected by each other. Regardless of the type of business system, these three decisive elements do not change, meaning that the structure does not change, but only the data. the relationship between three elements is recorded in the two mapping table. but these relationships are entirely man-made, and when they need to change, they operate on records in the database without changing the structure. the columns that are displayed when the system is in use are recorded in the Permissions columns table . Whether you want to add columns, modify columns or reduce columns, it's just an operation record.

　　To sum up, this design database, the system is completely reusable, and can withstand the "change" test.

Summary:

　　The focus of this system is that three entity tables firmly capture the core components of the system, while the two mapping tables perfectly map the interaction between three entity tables. The difficulty is to understand the work of the mapping table, which records relationships and implements the concept of "group" operations. and the overall design of the system is based on the different MIS system can be "reused" to meet the different functions of the system permission settings.

Appendix:

field design of data table for Rights management system

　　Here we look at the Rights Management System database table design, a total of six tables, the following figure:

Action table:

　　The action table records all the actions in the system and the description of the action.

Actioncolumn table:

　　The Actioncolumn table records the columns of the action, system running, the left menu bar provides a few different functions, each piece is a column, each add a column, the table will add a record, the corresponding, the left menu bar will also add a column of the machine.

Actiongroup table:

　　The Actiongroup table records the group in which the action is located.

Groupmanager table:

　　The Groupmanager table records information about the management group and adds one to each administrative group.

Mastergroup table:

　　The Mastergroup table records the administrative group in which the administrator is located, and because an administrator may belong to more than one group at a time, there may be more than one administrator record in the table.

Master table:

The

master table records the information for all administrators, adding one record for each administrator.