My first Python Web development Framework (34)--Background management system permissions Design

The frame bottom and the interface was finally remodeled, and little white found the old dish again.

　　Small white: boss, the last time you on the background permission system simple to say, I have no clue, now have a complete say?

　　Old food: Speaking of the authority system, it is not easy to speak clearly, the authority system is not the more complex the better, according to the needs of the project, some systems only a few people operate, and do not have to use powerful and complex rights management system, and some large enterprises, regions exist branch offices, Business and sales data classification management, system data even need different roles to allow viewing different data columns, the data increase, delete, check, change are very detailed restrictions, this need to use the corresponding powerful Rights management module, to deal with different business needs.

Let me illustrate the evolution of the privilege system in a gradual manner with multiple graphs.

First, let's see how the simplest permission system is managed.

　　

The simplest permission system, it only needs to verify that the user account and password is correct, after entering the system by checking whether the session is invalid, to determine whether the user exits, login into the system, all the functions are open to the user operation.

Relative to the previous permission, a slightly more complex rights management, it only needs to manage to the menu level, simple access to the page does not control, complex points only need to be in all links, according to the access URL to generate the corresponding encryption string, in the interface of the access page using the same key and rules, generate the corresponding encryption string, Then compare the two encryption strings to be consistent to prevent the vast majority of illegal access.

　　

This privilege management requires the addition of the menu (primary key ID, menu name, page URL, sort, whether enabled, created time), and menu rights management functions. The encryption processing of menus and page URLs, which can be returned to the client by a server-generated unified build on the Return menu, allows the client to access the corresponding page only through a server-side URL. As for how to do the encryption string recognition, can be processed by the following way:

After the user logs in, automatically generates a unique string of uppercase and lowercase letters and numbers as the key, and then adds a timestamp, the name of the page accessed, IP, page access parameters (such as ID value, etc.), generates an encrypted string with MD5 encryption, and then combines the encrypted string and timestamp, page access parameters and other content into the URL parameters. Generates a URL that can be accessed. When the user clicks the URL to access, the accessed page receives these parameters, the same encryption sequence is processed, the same encryption string is generated and the encrypted string submitted to compare, you can identify the user has access to the page. By changing the page name or access parameters, the user can easily check the inconsistency of the encrypted string and deny access, so that the user can access the page only by specifying a URL. Because the user does not know what the key is, it is difficult for him to make false access to the page without access.

This kind of processing seems to be very complex, in fact, it is very simple to develop, and only need a menu and menu permission table, menu permissions table to bind the menu and administrator account, authorization to specify the management can access the menu items, rights Management is relatively simple and easy to implement.

For the above permission, it can not control the page button, that is, it can not control additions and deletions and other operations, so the extension of the following permissions management method.

For the front-end separation of the system, page list data viewing, adding, modifying, deleting and other operations, all need to pass AJAX data or parameters to the corresponding interface, and then the interface will return the results of the operation, so we can restrict access to the interface to achieve the page key function control.

　　

For this kind of rights management, we only need to expand in the previous menu management function can be implemented, in the menu table (primary key ID, menu name, page URL, sorting, whether to enable, create time) to add a previous menu ID, interface routing address, whether to display these fields can be.

Because of the need to increase the interface control of the page keys, in order to let the menu outline the relationship between the page and the key binding, you need to add the parent menu ID, and the interface is the address of the field, familiar with the Python bottle framework of the small partners, It is clear to know that each interface is accessed through our own set of routes, such as the previous acquisition of the product specified primary key ID entity address

@get ('/api/product/<id:int>/')def  callback (ID):      ""     gets the specified record     "" " 

@get ('/api/product/<id:int>/') This is the URL-access routing address, which is unique throughout the project, and it is easy to get to this route identifier directly when the interface is accessed. So in the development, we can do a direct interception at the bottom, by judging whether the user has checked the route corresponding to the menu item, to see whether the user has access to the interface permissions.

and whether to display the fields, mainly for the menu list output, the key items are hidden, not directly in the menu display.

and the user Rights management, as in the previous, only need the Administrator account binding can access the menu items on the line.

For more people, and people flow more frequent enterprises, the use of the preceding rights management, will be very troublesome. Since people flow, it is necessary to adjust the authority regularly, whether it is new employees or employees to change positions, you need to reset the corresponding administrator access rights. In order to simplify permissions management, it is necessary to introduce the concept of a position (role) and Department (permission group). For the enterprise, the position is easier to understand than the role, different positions have different job responsibilities, for the enterprise Management system operation is the same, different positions have different operational rights. The Department is mainly to facilitate the management of the position of the group, because there is no corresponding group of posts, query inconvenient, if there are similar positions, also easy to confuse.

For enterprises, because the flow of personnel may change frequently, and the position is relatively fixed, so the permissions from the front directly bound to the Administrator, to the menu permissions binding position. When an employee changes his or her job, he only needs to change the position he is bound to, and for the new employee, he will only have to bind him to the post, and they can have all the rights to that position.

Of course there are some special needs, such as a person and a colleague are part of the same position, but he is an old employee can have more permissions, then you can add a new position (by establishing a position level) to distinguish their rights.

Also for example, if the permissions need to restrict access to the department, and the position in the department can only set the current department corresponding permissions, if there are employees need to have other permissions across departments, you can change the management account to bind multiple positions to achieve, that is, an employee he can only bind a main department, But he can have multiple positions at the same time, and then enjoy the privileges shared by multiple positions.

　　

For common enterprise privilege requirements, this permission setting can meet the requirements of most projects, the following chapters will focus on the current rights management system.

Some projects may have other special requirements in terms of permissions, such as the previous rights management they are page access control, if you want to view the page and operational items to take a finer step of control, they can not do, then we need to introduce a new rights management system.

For example, the internal document system, all users of their own departments or have access to the content has to view, add, modify, delete, archive and other operational rights, using the keys can not be subdivided control of these permissions.

　　

At this point, you can create a document rights management table that specifically manages these operations permissions by categorizing the document with the position binding, and checking that the user has permissions to manage permissions when they view or manipulate the documents. This kind of rights management is generally the extension of the preceding rights management function, and it can flexibly manage various different permission requirements.

　　

If your system wants to apply to those large enterprises, as mentioned earlier, need to be in the regional branch, business and sales data requirements of hierarchical management, system data even need different roles to allow viewing different data columns, the data increase, delete, check, change are very detailed restrictions, We also need to extend the privilege system more to achieve finer granularity of rights management.

For example, our department code is the following rules (the actual project, the division may be very different, and to achieve cross-departmental cross-permission query, that is another algorithm):

0101  xx company       CEO        010101 Finance        Department 010201 Sales Department               01020101   South China                Branch 0102010101   Guangdong                  area 0102010102   Guangxi area                  0102010103   Hainan area             01020102   North China                Branch 0102010201   Beijing                 area 0102010202   Tianjin area                  0102010203  

All orders and sales data must be bound to the corresponding department code, so that when we do data statistics, we can use the current user location of the encoding +% way combination of SQL statement query filtering, limit the user can only view their own departments below all the data, You cannot query across departments or across permissions to data from a higher-level department. This is the simplest and easiest way to manage a project with a small amount of data.

Of course, there are many ways to implement similar data rights management functions, and this is not discussed here.

In the actual development, the business is not the same, the authority requirements may be strange, what kind of demand may be, this requires us to analyze the needs of the need, combined with the system function module, design the corresponding rights management system, to meet the needs of different enterprises ' rights management.

Copyright NOTICE: This article was originally published in the Blog Park , the author for allempty This article welcomes, but without the author's consent must retain this paragraph, and in the article page obvious location to the original link, otherwise considered infringement.

Python Development QQ Group: 669058475 Author Blog:/http