System design 1. Data management 2. Identity authentication 3

Identity deals with the question of who you are, while rights management deals with the question of what you can do. There are two key points in the “what can you do question” : one is “you”, “you” is the user; The other is “what to do”, and “what to do” is processing. In a WEB system, all processing is HTTP resource requests made by the client to the server. For HTTP resource requests, generally have the ability request and do not have the ability request, the corresponding HTTP status code is 200, 403. On the basis of access to HTTP resources, generally there are different degrees of restrictions on the data resources returned by the request, such as the number of articles that the author and the administrator can see and process.

By abstracting these HTTP and data resources into system resources, permission management is reduced to a relational mapping of users and system resources in the system.

Didn’t figure

The user group

People with the same responsibilities in the company will have the same permissions in the system, and different responsibilities are related to the organizational structure of the company, so most of the time, when designing permission management, the organizational structure of the company will also be designed. In fact, you can throw away the organizational structure of the company by mapping the same capabilities to the members of the company, which is called roles.

Using the above analysis, you can now make a mapping: User > Role > system resource. That is, by granting roles to users to achieve user -> resource mapping process.

There are generally single role and multiple role in the role of the processing of the two schemes, at the same time in these two schemes can be added to the user to reduce the permission of additional design.

In the company, there is usually one radish and one pit, that is, one person has only one role, but in the actual process, it often happens that he/she holds multiple roles, so generally I do the authority design with multiple roles at the bottom.

Resource management

As mentioned in the beginning, “HTTP” resources and “data resources” in the system are abstracted into “system resources” to deal with, in the system to check the permission check can become “have” so simple things. At the data level, what permissions users have are only one-dimensional data, and how they store it at this point is arbitrary. [MY initial design is to use the associated table for storage, and then follow the advice of others and produce sentry permission control component, using json string storage.]

Now that permission abstraction and permission persistence are pretty much solved, there is a second problem: how do you manage these permissions?

For a small system, dozen two dozen function system may only be a small form all the permissions list, the administrator according to the role to check the good, but for the system in a wide range of functions that obviously doesn’t work, who will go in a few hundreds of about the same in the name of the authority to find what you need to name!

So how these permissions are presented to the user for them to manage is another question!

presentation

Here is a review of the background menu layout, there are probably several





1. Simple functionality, just one level of navigation (image from Element.elem. IO)





2. Slightly more complex features with secondary navigation (image from Element.eleme.io)





3. For more complex systems, only the secondary menu cannot meet the system functions (image from Element.eleme.io)

The forms of 1 and 2 are simple, so there’s basically nothing to say. Just say how to deal with the background of tertiary navigation, and then the basic level two is not a problem.

When dealing with the background of a three-level navigation system, I generally follow the following principle:

  • Level 1: Services are divided. Users of the same service line are divided into namespaces at the code level under the same level navigation
  • Level 2: Classified by functional relevance, similar or related functions are grouped into a group. I’m usually not responsible for the real function of the secondary navigation, just the group merging of the tertiary menus
  • Level 3: This level is already specific function pages. Specific permission management will have menus, pages, functions and other differences
  • In addition to figure 3, where all navigation is on the left, you can also handle third-level navigation at the top and second-level navigation on the left

In dealing with only to the primary or secondary menu system, whether the menu display solved tend to rely on hard coding, because at that time function, less design instead of complicated impact modification of flexibility, but for level 3 menu system to access and synchronize the menu only by hard coding is very difficult, to do enough flexibly configurable convention regarding the need to set a rule.

The data structure

Start by writing a three-level menu data structure

[{"name":"Navigation Level 1"."url": "/nav1"."chirdren":[
            {
                "name":"Secondary navigation 1", // Generally for the menu group, only provides the folding function but does not provide navigation to the page function"url": "/nav1/nav2-1"."chirdren"[{// This level is the real menu"name":"Tertiary navigation 1"."url":"/nav1/nav2-1/path1"}, {"name":"Tertiary navigation 2"."url":"/nav1/nav2-1/path2",},]}, {"name":"Secondary navigation 2"."url": "/nav1/nav2-2"."chirdren": [{"name":"Tertiary navigation 1"."url":"/nav1/nav2-2/path1"}, {"name":"Tertiary navigation 2"."url":"/nav1/nav2-2/path2",},]}]},{... }]Copy the code

Both the upper level navigation and the second level navigation have a URL. In fact, the second level only serves as a folding function as a group. If the first level navigation is at the top, that URL is actually a third-level navigation under the group after clicking.

In addition, this data structure only deals with the first navigation > second navigation > third navigation data structure, Level 3 navigation is list page under the condition of the three-stage navigation may be associated with “new page [GET]”, “new submit [| POST operation]”, “edit page [GET]”, “submit [| operation PUT]”, “DELETE submit [| DELETE operation],” although these item does not show in the menu, But on the permission management page these are required.

  • From this paragraph on, INSTEAD of using names like first level navigation, second level navigation, and third level navigation, I useNavigation > Groups > MenusThis function is more clear name

The previous section [Presentation] mentioned how to manage but didn’t really solve the problem of how to present under the three-level menu. Now the question is: Is it possible to present permissions in the same hierarchical way as navigation layouts?

Another problem here is that when I open an edit page under the menu, the top menu and navigation should be highlighted whether I swipe the browser or not. What about this?

Here is a permission management data structure that I currently use

[{"name":Navigation "1"."index": "welcome"."groups": {
            "Group 1": [
              "home.dashboard.index1"."home.dashboard.index2",]."Group 2": [
              "home.dashboard.index3",]},"routes": {"welcome": {"name":"Secondary navigation 1"."url": "/nav1/nav2-1",},"home.dashboard.index1": {
                "name":"Menu"."url": "/home/dashboard/index1"."type":"menu"
            },
            "home.dashboard.index1-1": {
                "name":"Page 1 of 1"."url": "/home/dashboard/index1-1"."type": "page"."refer": "home.dashboard.index1",},"home.dashboard.index1-1": {
                "name":"Page 1-2"."url": "/home/dashboard/index1-2"."type": "page"."refer": "home.dashboard.index1",},"home.dashboard.index2": {
                "name":"Menu"."url": "/home/dashboard/index2"."type":"menu"
            },
            "home.dashboard.index2-1": {
                "name":"Page 3-1"."url": "/home/dashboard/index2-1"."type": "page"."refer": "home.dashboard.index2",},"home.dashboard.index2-1": {
                "name":"Page 2-2"."url": "/home/dashboard/index2-2"."type": "page"."refer": "home.dashboard.index2",},"home.dashboard.index3": {
                "name":"Menu"."url": "/home/dashboard/index3"."type":"menu"
            },
            "home.dashboard.index3-1": {
                "name":"Page 3-1"."url": "/home/dashboard/index3-1"."type": "page"."refer": "home.dashboard.index3",},"home.dashboard.index3-1": {
                "name":"Page 3-2"."url": "/home/dashboard/index3-2"."type": "page"."refer": "home.dashboard.index3",},}},{... }]Copy the code
  • Because of the Request Method, a URI does not determine a unique Request in an HTTP Request; the two together determine a unique Request. The Laravel framework provides a routing alias scheme, meaning that you can give any request an alias, and an alias can only correspond to a single HTTP request. We can generate a URL based on this alias, or we can get an alias for the Request instance. The other nice thing about aliases is that I don’t have to worry about the URL changing as long as MY naming scheme stays the same. So in practice I also use aliases to design configuration files.

In fact, in practice my configuration file routing node length looks like this

        'works'= > ['name'= >'Work Record'.'uri'= >'/system/work'.'method'= >'get'.'uses'= >'HomeController@work'.'limit-on'= >false.'log.file'= >'[{{user.name}}] access the operation log page'.'throttle'= >100,].Copy the code

Because aliases are associated with routing as well as behavior logging, access restriction, permission management, etc., they can be designed in a single configuration file so that when configuration items are added, there is no need to worry about losing one or the other.

Permission control in a single page application

The front and back ends of a single-page application are completely separated. There is no necessary connection between the front end route and the back end API route. A route like front-end /#/ POST /1234 invokes a back-end interface that might be POST? In the form id=1234, the association is only in the Ajax request part of the business logic code, usually by the back-end programmer convention. And the front-end route is relatively less than the back-end, because a complex page on the front-end corresponds to many interfaces on the back-end. So how do you control the permissions on the front and back ends?

In principle, it is possible to develop a set of rules for both front and back end routing and permission control, but this solution would be complicated by considering the issues of front and back end permission control and routing and some undefined scenarios. And if the team is working together, the front and back end members must understand the scheme and naming system before they can work together happily. In fact, one of the biggest problems in collaborative development is knowledge synchronization.

Another question, we saw in the last big section that permission control can be reduced to a situation like looking up a hash table, so who’s going to maintain the hash table, the front end? The back end? Maintain a copy of both the front and back ends. One of the inescapable problems with any of these solutions is configuration synchronization, 1. If front-end maintenance needs to synchronize the hash table to the back-end, 2. If you maintain at the same time, keep your changes in sync. Generally speaking, the implementation of (1.) is more difficult, and (2.) is implemented on the premise that the front-end must be developed on the basis of the back-end services, and in a large degree, on the premise that the front-end and back-end use the same solution. Program (3) permission table maintenance costs relatively a bit higher, but the maintenance is in the design of both sides at the same time maintain just before and after the beginning of the end, after molding, products not change more frequently, the beginning of the modified and scheme (3.) can solve a synchronization problem described in the knowledge, as long as the agreement is a key control some functions, There is basically no big problem for both parties to develop their own functions according to this convention, and the naming scheme of their routes can be solved accordingly.

Making: github.com/chen-wen/vu…