Reprinted from: http://www.cnblogs.com/yukaizhao/archive/2007/04/15/user_role_action_permission.html
When we develop the system, we often encounter that the system needs permission control, and the degree of permission control has different design schemes.
1. Role-based permission design
This kind of scheme is the most common and relatively simple scheme, but usually this kind of design is enough, so Microsoft has designed a general practice of this kind of scheme. This kind of scheme does not control each operation, but only in the program according to the Roles control whether they have permissions to operate; we won't go into details here
2. Operation-based permission design
In this mode, each operation is recorded in the database, and whether the user has the permission for the operation is 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, please see Scheme 3
3. Permission design based on roles and operations
As shown in the figure above, we have added the Role and RoleACTION tables, which can reduce the records in USERACTION and make the design more flexible.
However, this solution may not be flexible enough under the test of user needs. For example, when a user requests to temporarily grant an operation permission to an ordinary employee, we need to add a new user role, but this kind of user The role is unnecessary, because it is only a temporary role, if adding a role also needs to delete this role when the ordinary employee permission is revoked, we need to design a more suitable structure to meet the user's requirements for permission settings .
4. The authority design of the combination of 2 and 3, its structure is as follows:
We can see that the UserAction table is added in the above figure. Use this table to add permissions for special users. There is a field HasPermission in the table to determine whether the user has permission for a certain operation, and the priority of the permissions recorded in the table is changed. To be higher than the user rights recorded in UserRole . In this way, in the application, we need to judge the permissions through the records in the UserRole and UserAction tables.
This is not the end of the story. It is possible that users will also give such requirements: some records have permissions for the objects operated by a certain action , but no permissions for other records, such as a content management system, For some channels, a user has permission to modify, but for other channels, there is no permission to modify. At this time, we need to design a more complex permission mechanism.
5. For the same entity (resource) user can have permission to some records, but no permission to other records:
For such a requirement, we need to create a permission table for each different resource. In the above figure , the UserActionContent and UserActionChannel tables are created for the Content and Channel resources respectively to define whether the user has permission to a certain record; This design can meet the needs of users but is not very economical. There will be many records in UserActionChannel and UserActionContent . In actual applications, it is not necessary to record the permission information of all records. Sometimes it may be just a rule. For example, for The level of the root channel has permissions; at this time, we can define some rules to judge user permissions, and the following is this design.
6. Permission design involving resources, permissions and rules
In this design, the concept of roles is gone, and only the Rule class in the program defines whether the user has the authority to operate a certain object.
The above is just an analysis of ideas, if there is something wrong, please correct me.