Permission management means that users can access only authorized resources based on security rules or policies set by the system. The system that manages to authority is authority management system.
I have not developed a public authority management system, but to the background of the simple authority management function, with two sets of relatively professional authority management system. Recently, I developed a new background, which needs permission management. I found that the company already has a permission management system, which can be directly connected.
This authority management system, smooth docking, authorization operation cost is low, can meet most requirements. Therefore, this system example is mainly used to explain.
Because did not read the system code, so the code related content will be less, mainly talk about some basic operations.
The need for
Authority management system is very necessary. There are several main reasons
reuse
Companies often have a large number of background, background need to carry out authority management. The core process of authority management is similar. If each background develops a set of authority management system separately, it will repeat the wheel and be a great waste of manpower.
A set of public authority management system, just do a good job of docking work, can save a lot of manpower.
security
Each person’s development ability is not the same, it is difficult to ensure that their respective development of authority management system is rigorous enough.
unified
The first is macroscopic unification, all background systems connected to the same set of rights management system, unified technology stack.
Secondly, it is convenient for unified management. No matter maintenance, management or view, only one system is required to achieve convergence effect.
Composition analysis
The rights management system has several parts, including system, service, menu, rights, and roles.
system
The rights management system needs to connect with many platforms and must be able to mark different platforms.
The system contains the following information: system ID, system name, system description, system owner, creation time, and modification time
business
There may be different services or only one service in the system.
For example, business background, different businesses can be considered as different businesses. This is because the same consumer may operate multiple businesses, but in different roles.
As some overseas systems need to manage multiple countries, different countries can be considered different businesses. Because the same user may manage multiple country configurations in different roles; Or manage configurations for only one country.
When the system has only one service, only one service can be available.
role
The operator’s identity, different identity permissions are different, see the menu content is also different. Common roles include operation, developer, and admin.
The menu
A menu is a tree structure and contains multiple level-1 menus. A level-1 menu contains multiple level-2 menus or pages, and a level-2 menu contains multiple pages.
Menu information generally contains
permissions
The front-end menu/page needs to call the back-end interface, so you can bind the menu to the calling interface, which forms a kind of association. Owning a menu, you have the permission to request the related interface.
In permission management, only the primary and secondary directories are displayed, and no page is displayed. The main reason is that you do not want to configure multiple directories.
In a special case, different roles can operate the same interface on the same page, but the operation content is different. For example, for updating goods, merchants can only edit, while operation is responsible for reviewing. If the two operations are on the same interface, you need to perform permissions verification on the server. Another option is to split the interface, but the server still needs to do some checking.
Relationship between
The core of the rights management system is to manage the rights of roles. Relationships among roles, menus, and permissions. Now that we’ve talked about the components, the relationship is a little bit simpler
During role configuration, the menu is bound to the interface, and the menu is bound to the interface. Therefore, the corresponding relationship between role-menu-interface permissions is realized.
The premise
There are two prerequisites for using a rights management system
-
You need an account system.
Having an account system means being able to obtain user ids before the rights management system can be used.
-
There needs to be an application process
Many companies do access management systems, there is no application process. Adding new users requires the administrator to manually add them in the background, which not only needs to input a lot of information, but also is prone to error, greatly increasing the cost of the administrator.
The reasonable way is that users apply for permission, the system automatically input data, the administrator review
interface
The permission management system needs to provide interfaces for platform invocation, including:
-
Role list: Allows users to see which roles are available when applying
-
Assign a role: After a user logs in, the user can obtain the user ID and assign the system, service, and role to the user
-
Menu: Gets the menu content corresponding to the role
-
Interface permission verification: Checks whether the role can access the specified interface
Authority management system is often used in the background, although the traffic is not high, but also need to pay attention to performance issues, especially like interface authority verification, almost every time need to request, at this time you need to use caching to improve performance.
conclusion
The authority management system built according to the design can meet most business requirements. Permissions and menus are bound, and roles and menus are bound. This design is more intuitive and easy to understand, but it also requires the background to think about the relationship between permissions and roles during the design, which puts forward certain requirements for background developers.
The last
If you like my article, you can follow my public account (Programmer Malatang)
My personal blog is shidawuhen.github. IO /
Review of previous articles:
-
Design patterns
-
recruitment
-
thinking
-
storage
-
The algorithm series
-
Reading notes
-
Small tools
-
architecture
-
network
-
The Go