Garden: author: don’t hum ha blog cnblogs.com/myindex/p/9116177.html

The most common is role-based access control, where users are associated with permissions through roles. Simply put, a user has multiple roles, and a role has multiple permissions. Thus, a user-role-permission authorization model is constructed. In this model, there is usually a many-to-many relationship between users and roles, and between roles and permissions. The diagram below:

Based on that, what is the character? We can understand it as a set of a certain number of permissions, is a carrier of permissions. For example: a forum “administrator”, “moderator”, they are roles. But what you can do is not exactly the same. Moderators can only manage the posts, users, etc., and these are permissions. If you want to grant these permissions to a user, you don’t need to directly grant the permissions to the user, just give the role of “moderator” to the user.

But from the above we also found the problem, if the number of users is very big, you need to the system of authorized (assign roles) each user one by one, this is a very complicated thing, at this moment can increase a group of users, each user group with multiple users, except for a single user authorization, can also be authorized to the user group, as a result, By granting the same permission to multiple users at the same time, all the permissions of a user are the sum of the permissions of the individual user and the permissions of the group to which the user belongs. The following figure shows the relationship among user groups, users, and roles:

Usually in the application system, we show it as menu access (page level), function module operation (function level), file upload deletion, and even a button on the page, whether the picture is visible, etc., belong to the scope of permissions. Some permission designs treat functional operations as one class and files, menus, page elements as another, which constitutes a “user-role-authority-resource” authorization model. In the data table modeling, the functional operations and resources can be unified management, that is, they are directly associated with the permission table, which may be more convenient and easy to expand. The diagram below:

It is important to note that the following permissions table has a list of “PowerType”, which is defined by its value. Think of it as an enumeration. For example, MENU indicates the access permission of menus, OPERATION indicates the OPERATION permission of function modules, FILE indicates the modification permission of files, and ELEMENT indicates the visibility control of page elements.

The benefits of this design are twofold. One, do not need to distinguish which is the permission operation, which is a resource, (in fact, sometimes it is not easy to distinguish, such as menu, it is understood as a resource or function module permissions?) ; Second, convenient extension, when the system wants to control the permission of new things, I just need to create a new associated table “permission XX associated table”, and determine the permission type string of this kind of permission.

It should be noted that there is a one-to-one relationship between the permission table and the permission menu association table, and between the permission menu association table and the menu table. (The same is true for files, page permission points, and function operations). This means that every time you add a menu, you have to insert a record into each of the three tables simultaneously. In this way, the permission table can be directly associated with the menu table without the need of the permission menu association table. At this time, a new column should be added to the permission table to save the ID of the menu. The permission table uses the “permission type” and the ID to distinguish the records under the type. The complete design of the expanded model is as follows:

Notice that I added an additional operation log table above;

As the system grows larger, you can introduce role groups to manage roles by category if necessary. Different from user groups, role groups do not participate in authorization. For example, when there are multiple subsidiaries and each subsidiary has multiple departments, we can interpret departments as roles and subsidiaries as role groups. Role groups are not involved in permission allocation. In addition, in order to facilitate the above main table itself management and search, can use the tree structure, such as menu tree, function tree, of course, these do not need to participate in the permission allocation.

The data dictionary

1. User table:

2. Role Table:

3. Association table between users and roles

4. User group table

5. Association table of user groups and user information

6. Association table between user groups and roles

7. The menu list

8. Table of page elements

9. The file table

10. Permissions table

11. Permissions associated with menus

Permissions are associated with page elements

13. Permission and file association table

14. Function operation table

15. Associated table of permissions and functional operations

16. Role and permission association table

17. Operation log table

Learning Materials sharing

Collected and prepared 12 sets of core technology data of microservices, Spring Boot and Spring Cloud. This is part of the data directory:

  • Spring Security authentication and authorization
  • Actual Practice of Spring Boot Project (Background service architecture and operation and maintenance architecture of small and medium-sized Internet companies)
  • Spring Boot Project practice (enterprise rights management project)
  • Spring Cloud Microservice Architecture Project (Distributed transaction solution)
  • Spring Cloud + Spring Boot + Docker
  • Spring Cloud Website project (real estate sales)
  • Actual practice of Spring Cloud Microservice project (large-scale e-commerce architecture system)
  • Single sign-on basic to actual combat
  • Spring Boot Project practice (Enterprise wechat ordering system) (primary practice)
  • Spring Cloud Internet Application Project (weather forecasting system)
  • Spring source depth analysis + annotations development of a full set of video tutorials
  • Actual Practice of Spring Boot Project (Financial product system)

Directory screenshot:

Public account background replyarch028Information obtained: :