Lightweight Implementation of permission Design
In a variety of systems, permission design is essential. Now, it is basically based on the concept of a role, that is, a user may belong to a role or multiple roles, then, confirm the corresponding permissions based on the role to further verify its validity and finally perform the operation. many people may perform permission verification before a user enters a module of the system. Later, they know that the SPS of Microsoft are not like this, and all users can perform operations, for example, when you submit an application for approval, you can verify whether the application has been submitted successfully. I think this is advantageous because it is fast and does not need to be verified once the user enters the system, of course, the user experience is not good. the following is a reference article. I will repeat it myself. It mainly refers to the database design. below is the database diagram, which is designed with PD.
In fact, after I posted the figure, you can see it clearly. For a brief description, I didn't add additional fields to the table, such as the address in the User table, in the field User Role table such as email, the role value in the role table corresponds to the function number field in the function list to determine whether a role has this function (operation) the key issue is that the preceding module table is used to determine a function set between modules. For example, the document upload function in the document management module and the document attribute modification function. the following is an example of the relationship between them. Let's take document management to illustrate it. Recently, J is also being developed.
Module table(, Document management, doclibmanage, 3); // specify the database. Note that the first database ID is automatically generated.
Menu(0, 0, new directory, createfloder, 0); // same as above
Menu(0, 1, upload file, uploadfile, 0); // same as above
Menu(, Modify attributes, modiattr, 0); // Let's take a look at the same time. The role corresponds to the function principle.
Role table(0, operator, 010, routine maintenance) the key is the role value 010 in the role table, which represents the following meaning:
| |
|
|
|
|
| Role Value |
010 |
Description |
|
Description |
| 0th bits |
0 |
Corresponding to the function number 0 in the menu, that is, creating a directory |
0 indicates no permission |
This role cannot create a directory |
| 1st bits |
1 |
Corresponding to function 1 in the function list, that is, uploading files |
1 indicates that you have permissions. |
This role can upload files |
| 2nd bits |
0 |
Corresponds to function 2 in the function list, that is, modifying attributes. |
0 indicates no permission |
This role cannot modify attributes. |
In this way, a lightweight permission design system can be implemented.
