One of the common permission management Designs

When developing a system, we often encounter a system that requires permission control. Different Levels of permission control have different design schemes.

 

1. Role-Based permission Design

This solution is the most common and relatively simple solution, but it is usually enough, so Microsoft has designed a general practice for this solution, which does not control every operation, in the program, you only need to control the permissions for operations based on the role. We will not detail them here.

 

2. Operation-based permission Design

In this mode, each operation is recorded in the database, and the user's permissions for this operation are also recorded in the database. The structure is as follows:

 

However, if the above design is used directly, the amount of data in the useraction table in the database will be very large, so we need to further design to improve efficiency. See solution 3.

 

3. Permission Design Based on roles and operations

 

As shown in, we have added the role and roleaction tables to reduce the records in useraction and make the design more flexible.

However, this solution may not be flexible enough to meet the user's needs. For example, when a user requests temporary operation permissions for an ordinary employee, we need to add a new user role, but this user role is not necessary because it is only a temporary role, if a role needs to be deleted when the general employee's permissions are revoked, we need to design a more appropriate structure to meet the user's requirements for permission settings.

 

4. Permission design in combination with. Its structure is as follows:

 

We can see that the useraction table is added in. This table is used to add special user permissions. The table has a field haspermission that determines whether a user has certain operation permissions, the permission to change records in the table is higher than the user permission recorded in userrole. In this way, we need to judge the permission through the records in the userrole and useraction tables in the application.

This is not an end. It is possible that the user will also give the following requirement: the user will have permissions for some records of objects operated by an action, but will not have permissions for other records, for example, a content management system has the modification permission for a user of a certain channel, but has no modification permission for other channels. At this time, we need to design a more complex permission mechanism.

 

5. Users of the same entity (Resource) can have permissions on some records, while those who do not have permissions on other records are designed as follows:

 

To meet this requirement, we need to create a permission table for each resource, the useractioncontent and useractionchannel tables are created for the content and channel resources respectively to define whether the user has permissions on a record. This design can meet user needs but is not very economical, there are many records in useractionchannel and useractioncontent, but in actual applications, it is not necessary to record the permission information of all records. Sometimes it may be just a rule, for example, if you have permissions for the root channel, you can define rules to determine user permissions. The following is the design.

 

6. Permission design involving resources, permissions, and rules

 

In this design, the role concept is no longer available. You only need to define whether the user has the permission to operate an object in the class of the program.

 

 

This article Reprinted from: http://qingfeng825.javaeye.com/blog/363283