General permission management design (database structure design) and permission management structure design

General permission management design (database structure design) and permission management structure design
I. Preface

The application of the permission management system should be used in three different ways,

A. Permission

B. Assign permissions.

C. Grant Permissions

This article only analyzes the application levels of "Use Permission" and "assign permission", and does not consider "authorize permission" for the moment.

Ii. Preliminary Analysis of users and Roles

When talking about permission management, we should first think of designing a user table and a permission table. This determines what permissions a person has.

When doing this, you will find that this design is too cumbersome. If all employees in the company have such permissions, should every person be configured? It is a very painful thing. Therefore, add a role table, classify some people as one type, and then assign permissions to the role. Users under the role also have permissions.

The relationship between users and roles is that one user can correspond to multiple roles, and one role can correspond to multiple users. Multiple-to-multiple relationships.

Therefore, an intermediate table is required. I believe everyone is familiar with it and naturally there will be no doubt.

Application scenarios

With users and roles, You need to design application scenarios. For example, an application has several modules (system module, project management module, and sales module ),

Such a module is a common application scenario, including menus and operations.

Assuming that we have designed the application scenarios, including modules, menus, and operations, there should be the following six relationships:

Therefore, six tables are created to maintain these six relationships.

This design looks okay. Yes. If new relationships are not added, this can meet most of the requirements. However, new relationships (requirements) are often added to the system. In this case, you need to create a new table. The complexity of the system also increases.

We can see that such a design has several problems:

 

3. Simplify the problem

 

In different application scenarios, you may come up with different requirements. After a new requirement is raised, you may find that the original design is not implemented, so you need to add a new table. This is also the problem mentioned above.

In fact, you don't have to think so complicated. The permissions can be described as follows:

XX subjects have XX permissions in XX Fields

1. The subject can be a user, a role, or a department.

2. The domain can be a module, a page, or a button on the page.

3. The permission can be "visible", "read-only", or "available" (for example, you can click a button)

Actually, it is the question of Who, What, and How.

 

Therefore, you can design a table for the six tables mentioned above:

 

 

 

Iv. instance description

 

The following is an example of the design. "Users and roles use permissions on the page"

Detailed Design:

1. Place the menu configuration on the database. Each menu has a unique encoding MenuNo, and each "leaf node" menu item has a page (url ).

2. Put the button configuration on the database and place it on a menu item (in fact, it is hanging on a page ). There may be several button groups on a page. For example, there are two lists, both of which must be added, modified, or deleted ". Therefore, you need to add a button grouping field to distinguish.

3. Assign Menu permissions to users/roles. PrivilegeMaster is "User" or "Role", PrivilegeMasterValue is UserID or RoleID, PrivilegeAccess is "Menu", and PrivilegeAccessValue is MenuNo, privilegeOperation is "enabled"

4. Assign the Button permission to the User/Role. PrivilegeMaster is "User" or "Role", PrivilegeMasterValue is UserID or RoleID, PrivilegeAccess is "Button", and PrivilegeAccessValue is BtnID, privilegeOperation is "enabled"

5. If you need to disable the permissions of a single user, set PrivilegeOperation to "disabled ".

If you are not clear, you can see:

 

Database Design:

 

 

Iv. Conclusion

After talking about this, I recommend only the Privilege table design. This table is a prototype of who, what, and how problems. It not only provides good scalability and flexibility, but also condenses complicated permission management systems into one sentence.

PrivilegeOperation is not only used or prohibited, but can be defined by assigning and authorizing permissions. But this undoubtedly makes the design of the application more difficult, but the table design can be completed without any modifications. We can see its flexibility.

Obtain 【][Integrated shiro Security Framework] javaEE background framework SpringMVC Mybatis Shiro druid Bootstrap HTML5