However, network or single-machine programs involving multi-user different privileges will have permission management issues, and it is more prominent that MIS systems.
Below I want to say, the database design and implementation of MIS system rights management, of course, these ideas can also be promoted, such as the user permission to manage different levels in BBS.
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 :)
I hope that the above analysis is correct and effective (in fact, I also use these methods in more than one system implementation), but in any case, I think this implementation rights management, just considering database design and application interface two Part of the content is still very difficult for implementation. Therefore, I invited comrades who have similar designs and experiences to make constructive opinions and revision recommendations.
In addition, the idea of database design is also using two-dimensional tables, which will be discussed in the later time, regarding the design and implementation of the application interface, I will also use the different levels and everyone to discuss, the code will use class C syntax Implement (I don't like Pascal, sorry)
In addition, there are friends mentioned:
Permissions Design requirements: 1 to implement permission control for interface objects (such as menus, buttons). Abbreviation Object Level 2, is used to implement the permission control for modifying the data by a user, delete. Building data level permissions
Object level permissions are basically realized, and data level privileges are relatively special. It can achieve data rights allocation, for example: A users can assign their data to b users to modify, to C users deleted permissions.
The point of data level permissions is to add a field to the table to save the user ID of the data owner.
My thoughts are like this:
The management of data level permissions has a relatively large difference. It does not easily use a statement exact description. Notes's approach is to save the owner identity of each document, and can also be used in the relational database (or similar) The way is solved, but the situation should be complex.
If you want to implement access control of single data, I may only use the process to be implemented, this means is more common in the OA system, such as hand over a document written to B for B Approval, then B is just right Owner a an approval authority for all documents. Although it is also given a certain permission, in fact, this is not the permission management scope discussed above, but is just a business process.
However, we believe that in most systems of the non-public process, only a simple setting: User B has a modification permission to the document of the owner A, and this definition is to describe and implement the database described above. of.
In fact, in the relational database, it is impossible to accurately to the access rights of a user table, which can only be solved in the program, of course, related to the business in the program. Process design. Many OA systems claim to be able to customize the process, which is generally able to design the whole process of the process in the database through a smart database design.
Lotus-based OA system can define a user's access rights to a document, but in actual operation, in order to mitigate the burden on the developer, it is only defined the role to access access rights to a database, and will remain The content below is controlled by the front-end, which is the same as the SA login SQL Server in the ASP program. The implementation method of business processes is inherently unrelated to operational permissions, which will be another discussion topic.
