Redglove permission management system (1)-Permission Overview

I recently updated and optimized the redglove permission management system. After the release, I found that many of my friends still cannot understand my design ideas, in order to make it easier for a friend in need to use the system, I decided to share my design ideas and development process with you here. I hope you can give more comments.

First, let me introduce the main components of the system. Because it is a permission system, it consists of three parts: module permission, role permission, and user permission, the following describes in detail the roles of the three permissions and their dependencies.

To put it bluntly, the module permission is to manage functional modules in the system. In these modules, they have various specific operations. These specific operation permissions are module permissions, for example, a new user management function module is added. In this module design, you need to perform operations such as browsing, adding, modifying, deleting, reviewing, and querying, not all users have these permissions when the system is running. The following role permissions are generated as needed.

Role permission is an identity. A user with this identity can do something in the system and cannot do anything. The user must follow this identity and cannot pass through the interface, this is also a permission restriction. There are many users in a management system. We cannot assign the permissions in the module to the users one by one. Now the role has solved this problem, it is like a permission group, which assigns permissions of a module to a role so that users with this role can have the operation permissions corresponding to the module. However, there may be tens of thousands of users in a system, but I think there can be a maximum of dozens of roles. It is much easier to grant module permissions to dozens of roles than to tens of thousands of users, although a role is a permission group and has a limited range of roles, when exceptions occur, if a user has a role that operates the user module, but there is a special requirement for it, that is, it cannot operate the deletion or other functions in the user module, and it also has the permission to operate another module, but its roles can only access the user module. What should I do? Do you want to create another role for this user? My answer is no.

Now I will introduce the last permission in our system, which is the user permission. I think many of my friends have used this permission mode in the development and management systems. Although this method is primitive, however, it can solve the problems we encountered above. Of course, we still need to make some small improvements. In the role, we only tell the user what to do, and we can't do anything without telling them, it is enough to determine the permissions of roles in batches, and the user's separate permission judgment is a bit special, it has to jump out of the role. Its permissions take precedence over the role permissions. It has the function of allowing and disabling operations on a certain permission. For example, a user's role permissions can operate on all functions of the user module, if the user has the permission to disable a function of this module, the user cannot perform this function on this module. On the contrary, the user role does not authorize this function, if the user permission is granted the permission of this function module, it can operate the function. The flowchart is as follows:

The above describes the most basic concepts in the redglove permission system and the process of permission judgment and processing. In the days to come, I will continue to explain the detailed function development process.