Permission design usually includes a database design, an application interface (API) design, and a program implementation three parts.
These three parts are interdependent, unparalleled, to achieve a complete permission management system, must take into account each link feasibility and complexity or even perform efficiency.
We will classify the permissions, first of all, usually have four types of access, browsing, modification, and delete, followed by the function, which may include, for example, all non-direct data access operations such as statistics, and we may also Some key data tables are restricted by the access of certain fields. In addition, I don't think there is another kind of authority category.
Perfect permission design should have sufficient scalability, that is, the system adds new other features that should not change the entire permissions management system. To achieve this, the first is reasonable database design, followed by Application interface specification.
Let's discuss the database design first. Usually we use a relational database that does not discuss the permission management based on Lotus products.
Permissions and related content can be described in six tables, as follows: 1 Role (ie, user group) table: including three fields, ID, role names, descriptions for this role; 2 user table: including three or more Field, ID, user name, description of the user, other (such as address, telephone, etc.); 3 Role-User Correspondence: This table records the correspondence between users and roles, one user can belong to multiple roles A role group can also have multiple users. Includes three fields, ID, role ID, user ID; 4 Limit content list: This table records all data sheets, functions, and fields that need to be permissions limitations and descriptions, including three fields, ID, name, description 5 Permissions list: This table records all permissions to be controlled, such as entry, modification, deletion, execution, etc., including three fields, ID, name, description; 6 permissions - role - user correspondent table: Under normal circumstances, We have the following privileges that have the permissions owned by the role / users, and the role has the permissions allowed by the characters. Other prohibits all permissions to which the user is inherited, and the permissions within this range are prohibited to allow all permissions, and the range external weight limit Allow all prohibited to be prohibited. The design is the focus of authority management, and there are many ideas for design. It can be said that there are thousands of autumn, and you can't give hard to say some way. In this regard, my opinion is to find someone to solve the problem.
First, the first kind is also the most easily understood method, design five fields: ID, limit content ID, permission ID, role / user type (Boolean field, used to describe a record record is role permission or user rights), Role / User ID, Permissions Type (Boolean field, is used to describe a record indication to be allowed or disabled)
Ok, there is such a table, according to Table 6, we can know that a role / user has / prohibits some permissions.
Or, this is sufficient, we fully realize the features required: the role and the user must perform the right to qualify and have considerable scalability, such as adding new features, we only need to add one or a few The record can be recorded, and the application interface does not require changes, it has considerable feasibility. However, in the process of program implementation, we found that it is not very scientific, for example, when browsing the permissions owned by a user, you need to perform multiple times (even recursive) queries for the database, which is extremely inconvenient. So we need to think other ways. People who have used UNIX systems know that UNIX file systems divide three types of operations for files: read, write, and execution, with 1, 2, 4 three code identifiers, and files with read and write access to users The recorded 3, 1 2. We can also solve this problem with a similar approach. The initial idea is to modify the right list, add a field: identification code, for example, we can identify the entry permission to 1, browse the permission identifier is 2, the modification permission ID is 4, the delete permission ID is 8, the execution authority identifier is 16, In this way, we can easily put the permissions that the permission to be divided into several records will be placed together. For example, if a user ID is 1, the inventory table corresponds to 2, and the role is specified Type is 0, the user type is 1, we can have the user with an entry, browse, modify, and delete the inventory table. Description is: 2, 15, 1, 1. It's really simple, isn't it? There is even more excited approach, and the list of restrictions is also plus a column, which defines the identification code, so that we can even describe all the privileges with all the contents of the entire content. Of course, the premise of this is that the limit is small, otherwise, huh, 2 N times have increasing, but quantity is amazing, not easy to analyze.
From the surface, the above method is sufficient to achieve functionality, simplifying the complexity of database design and implementation, but there is a drawback, the list of permissions we involve is not independent of each other but interdependence, such as modifying permissions, In fact, it includes browsing permissions, for example, we may just set the user's access value to the stock access to the entry modification delete (1 4 8 = 13), but in fact, the user has (1 2 4 8 = 15) permission, that is, in this scheme, 13 = 15. Then when we call the API asking if a user has a browsing permissions, it must be determined whether the user has a modification permission to the data table, so if the relationship is not included in the program, the application interface cannot be utilized. Simple judgment. But this is contradictory with our purpose "full scalability".
How to solve this problem? I thought of another way to set identification codes, that is, using the number of prime. We may wish to enter, browse, modify, delete, execute the basic flag code of 2, 3, 5, 7, 11, when we encounter permissions, we set its identification code to two (or Multiple) The product of the basic flag code, for example, the flag code of the "Modify" function can be set to 3 * 5 = 15, and then all permissions are multiplied, and the final permission identifier value we need is obtained. In this way, we only need to decompose the final value to the mass factor, for example, we can define a user with entry modification delete the stock of 2 * 15 * 7 = 2 * 3 * 5 * 7, that is, the user has an entry entry browsing modification delete permission. Of course, the premise of using the above method is the premise of the above method is that the number of permissions will not be too much and the relationship is not very complicated. Otherwise, the light is parsing the permission code to be machine flicker half-hour :)
