In any system design is the most basic rights of things, a good permissions system, developers can enhance the development progress; but they can provide users with perfect scalability rights management, rather than a simple custom permissions.
In this paper, the realization of functions: the role-based permissions granularity + module + the rights management related concepts:
(1) the role: It is a collection of a class of functions, such as the role of news editor, who may be the drafting of news, editorial features such as the news set, and the responsibility he may have more to edit the permissions, for example, in addition to the functions of news editors, but also assesses news, delete news operation-level granularity; this can be understood as the design of the group process.
(2) permissions granularity: it is the smallest units, such as the drafting of news, editorial news, review news, delete news
(3) users: is a system of end-use customers (including managers and managers)
(4) resources: Managed Object
The following simulation of an information system for the control of data:
(Figure 1. Permissions diagram)
User information table:
Role as follows:
The role of the user table:
Permissions size table:
Note: This table has the resources there to add (module) information
The role of authority as follows:
Determine whether a user has permissions to the realization of a module:
Add a new classification at the same time also increase the authority table corresponding records (of course not in the database to add it directly from the function and powers related to add).
The use of such solutions can be simply applied for the classification (such as the forum system) for each classification of different control (such as the VIP section, we only have the role of VIP users can browse, published, etc., while the other plate as long as it is Registered users can use it).
PrivilegeID in practical applications is not just a string, but a code, the code contains a module ID, as well as to reflect the relationship between father and son, To give an example: For the forum system, we give it a module ID for "30", the forum permissions, we first divided into 2 categories, category management (such as the deletion of posts), is the use of a class (for example, post replies, post views, etc.), to the management of a code: 01, the use of type a code: 02, we carried out on PrivilegeID the following code:
300101: Delete post
300201: Posting
300202: replies
300203: View Posts
Resources (such as a plate 1, plate ID is: 01), we can mix the following Privileges (Of course, this combination you can not have a comma-separated, use of other combinations can also be, but not ambiguous):
300101,01: plate 1, the function of deleted posts
300201,01: the function of plate 1 post
... ...
RoleID is also used for encoding, but also reflect the role of the father and son relationship, but also can function in the role of inheritance, etc. (Of course, the role of functional access to the list of SQL statements is not so simple now). Application in which I now do not inherit the realization of the role (although the role of encoding reflects the relationship between the roles of father and son).
In this paper, the realization of functions: the role-based permissions granularity + module + the rights management related concepts:
(1) the role: It is a collection of a class of functions, such as the role of news editor, who may be the drafting of news, editorial features such as the news set, and the responsibility he may have more to edit the permissions, for example, in addition to the functions of news editors, but also assesses news, delete news operation-level granularity; this can be understood as the design of the group process.
(2) permissions granularity: it is the smallest units, such as the drafting of news, editorial news, review news, delete news
(3) users: is a system of end-use customers (including managers and managers)
(4) resources: Managed Object
The following simulation of an information system for the control of data:
(Figure 1. Permissions diagram)
User information table:
UserID | UserName |
U1 | San |
U2 | Li |
Role as follows:
RoleID | RoleName |
R1 | News Editor |
R2 | Editor |
The role of the user table:
RoleID | UserID |
R1 | U1 |
R2 | U2 |
Permissions size table:
PrivilegeID | ResourceType | PrivilegeTitle |
P1 | NTA | Drafting News: Category A |
P2 | NTA | Editor News: Category A |
P3 | NTA | Audit News: Category A |
P4 | NTA | Delete News: Category A |
P1 | NTB | Drafting News: Category B |
P2 | NTB | Editor News: Category B |
P3 | NTB | Audit News: Category B |
P4 | NTB | Delete News: Category B |
Note: This table has the resources there to add (module) information
The role of authority as follows:
RoleID | PrivilegeID |
R1 | P1 |
R1 | P2 |
R2 | P1 |
R2 | P2 |
R2 | P3 |
R2 | P4 |
Determine whether a user has permissions to the realization of a module:
| # Access privileges (Privileges) statement: Select PrivilegeID + `,` + ResourceType From role permissions table Where RoleID In (Select RoleID From the user role table Where UserID = 'U1') # Permission of the judge Privileges.Contain ( 'F1, NTA'); |
Add a new classification at the same time also increase the authority table corresponding records (of course not in the database to add it directly from the function and powers related to add).
The use of such solutions can be simply applied for the classification (such as the forum system) for each classification of different control (such as the VIP section, we only have the role of VIP users can browse, published, etc., while the other plate as long as it is Registered users can use it).
PrivilegeID in practical applications is not just a string, but a code, the code contains a module ID, as well as to reflect the relationship between father and son, To give an example: For the forum system, we give it a module ID for "30", the forum permissions, we first divided into 2 categories, category management (such as the deletion of posts), is the use of a class (for example, post replies, post views, etc.), to the management of a code: 01, the use of type a code: 02, we carried out on PrivilegeID the following code:
300101: Delete post
300201: Posting
300202: replies
300203: View Posts
Resources (such as a plate 1, plate ID is: 01), we can mix the following Privileges (Of course, this combination you can not have a comma-separated, use of other combinations can also be, but not ambiguous):
300101,01: plate 1, the function of deleted posts
300201,01: the function of plate 1 post
... ...
RoleID is also used for encoding, but also reflect the role of the father and son relationship, but also can function in the role of inheritance, etc. (Of course, the role of functional access to the list of SQL statements is not so simple now). Application in which I now do not inherit the realization of the role (although the role of encoding reflects the relationship between the roles of father and son).