TripAdvisor Original | Architecture design and Practice of the wireless access system for the TripAdvisor cattle

Order

I wrote a story about the PHP architecture of the Authority center, mainly from the software engineering perspective, how to ensure the high availability of the privilege system by coding specification, dependency management, data source architecture, transaction processing, unit testing and so on, does not really involve the architecture of this system.

Today you are ready to share the details of the design one or two.

Hope you crossing, the heart has "empty cup", with "problem" a probe.

0. RBAC3

This is especially important because he is the foundation of the whole system design.

So the cruel copy from the previous article again ...

RBAC thinks that authority authorization is actually the problem of who, what, how. In the RBAC model, who, what and how are the three groups of access rights, that is, "what the Who which".

• Who: a user or subject of authority (e.g. principal, User, Group, Role, actor, etc.)

• What: the object or resource (Resource, Class) to which the permission is directed.

• How: Specific permissions (Privilege, positive authorization and negative authorization).

• Operator: operation. Shows how to operate on what. That's privilege+resource.

• Role: A collection of roles, a certain number of permissions. The unit and carrier of permission assignment is to isolate the logical relationship between user and privilege.

The essence of the authority system is this model (personal point of view do not spray). We have abstracted two new concepts in this core idea.

Application modeling, Privilege autonomy

The following 4 levels are described below.

• Application modeling

• Business Scenarios

• Rights Management

• Authentication Design

1. Application Modeling

System architecture on the support of the system flexible configuration, not rigid field, non-rigid behavior, based on a variety of business rights control features flexible design.

Formula One: Application = resource + behavior + role

1.1 Field Definitions

To put it simply, it is to control the property and behavior of the resource.

For example, to control the menu, the properties include menu ID, menu name, menu URL, menu icon, parent menu ID, etc., the behavior includes access, authorization and so on. (Menu permissions)

For example, to control the city, the attribute includes the area ID, the region name, the area code, the region ID, etc., and the behavior includes access, authorization, etc. (Regional permissions)

For example, to control the CMS, the field contains the page ID, page name, etc., the behavior includes access, authorization, editing, resetting and so on. (CMS data permissions)

According to the inertial thinking, here is the 3 Resource table corresponding to the role table, while there are 3 resource role relationship table, in other words, is how much resources need to control how many tables (and personal views, do not spray).

Inertia of the mind, two pain points.

1. Each resource is stored independently.

2. Each resource has a set of form layout & interaction & Storage implementations.

In order to solve this problem, we have done the following design.

Field modeling

The fields of any resource can be abstracted into the following categories.

• Resource mapping fields (Mapfield)

• Resource node field (treefiled)

• Resource system fields (Systemfields)

• Resource form fields (columns)

• Resource Behavior field (privileges)

For a chestnut: menu resources.

ClassMenuExtendsapp{PublicStatic$appMapField =' URL ';PublicStatic$appTreeField =' Name ';PublicStatic$columns =ArrayArray' id ' =' ID ',' Label ' =' Menu ID ',' type ' = =' Input ',' Format ' =' int ',' option ' =Array ()),Array' id ' =' Name ',' Label ' =' menu name ', ' type ' = ' input ', ' format ' = ' string ', ' option ' = = Array ()); public static $privileges = Array (' id ' = ' access   ', ' name ' = ' ‘ ) ); public static $systemFields = Array (' id ', ' parent_id ');}     

Dynamic forms

Forms are primarily responsible for data collection functions in Web pages. There are three basic components of a form:

1. form labels;

2. form fields, including text boxes, password boxes, hidden fields, multiline text boxes, check boxes, radio boxes, drop-down selection boxes and file upload boxes;

3. Form button.

Regular work is a static form.

To design a dynamic form model, the basic idea should be the separation of the data and presentation display. Aside from the presentation layer, a form contains several fields and fill in the data. The so-called dynamic is that these field names may change, the number may increase or decrease.

• Control the presentation layer through the Columns field of the resource.

• Control the data layer through the data fields of the resource.

Through this model, the form layout & interaction & Storage of any resource are implemented dynamically.

1.2 Data storage

The schema for the Resource table corresponds to the following:

Field name	Field Notes
App ID	/
Resource ID	/
Resource Parent ID	/
Resource data	Json

From the reflection API, get the resource store plug-in for the current app (Resource data field).

app::find($params[‘app_id‘])->getResoucePlugin()->save($params[‘data‘]);

A unified encapsulation of data storage through resource base classes.

public function save(){ $this->beforeSave($this->attributes);}protected function beforeSave(){ //check attributes}

It is obvious that the resource data field does not perform well in the task of single-resource behavior authentication.

The Resource mapping field is introduced in the design, and whenever the resource changes, the addMap field information is synchronized to the Resource Mapping relationship table (the semantic index of the resource).

Give a few chestnuts to make it easy for you to understand this field:

• For example, a menu class application, the Mapping field is a menu link.

• For example, the data class application, the mapping field is the data ID.

public function addMap(){ if ($this->map) { //sync map field } else { //create map field }}

Application modeling, relatively speaking is a more technical topic, in a different direction, the following to chat with you about the system business scenarios.

2. Business Scenarios

System architecture to support a variety of business forms of authority control.

2.1 Menu Class Business

When it comes to permissions, most scenarios think of menu permissions, but we are no exception, and the application of the menu class is the first instance of production.

For a chestnut: A System/menu permission Application

• Field

  • Menu ID, menu name, menu link, menu ancestor ID

• Behavior

  • Access, Authorization

2.2 Data class Business

Data class application, relative to the menu type, more concerned about the behavior of a row of data control, behavior is diverse.

For a chestnut: a data/data Access application

• Field

  • Data ID, data name

• Behavior

  • Access, authorization, edit, delete, add, reset, export, import

2.3 Form Category Business

Form class application, in the 2B system, the privilege design is particularly important.

Give me a chestnut: a confirmation/form permission application

• Field

  • Module ID, module name (travel module, supplier module, Order module, finance module)

• Behavior

  • Access, authorization, read-only, writable, hidden

Summarize the business scenario for permissions:

• Menu class: Single-Resource line (can "behave" current "resource")

• Data classes: Multiple behaviors for single resources

• Form class: Multi-resource multi-behavior

Can your business scenario be realized, little friends? (Message Bar)

3 Rights Management

Let's talk about some of the design paths in authority management.

3.1 Autonomy

Design reference Jira, the current application managers dominate the current application of the rights of the ecosystem.

• Resource additions and deletions

• Change of roles and additions

• Resource Field definition

• Resource Behavior Definition

• The role of resource behavior gives

3.2 Bootstrap

Each resource in the system is inherently endowed with a system behavior called "authorization."

The role behavior of any resource node is assigned by the role that owns the resource node authorization behavior.

3.3 Two-way authorization

Two dimensions authorization, easy to search, also convenient to configure.

Select a resource based on role + behavior.

Select a role based on resource + behavior.

^^^^^^^^

The next stage will support the configuration of the default permissions, non-in-app roles, and the ability to enjoy partial behavior of some of the resources within the app.

4 Authentication Design

Finally, the design of the authentication interface is simple.

The U, R, P, and s represent user collections, role sets, permission sets, and session collections, respectively.

PA PXR represents a many-to-many assignment between permissions and roles.

UA UXR represents a many-to-many assignment between users and roles.

Formula One: S=UA∩PA

4.1 Single application + single action

Collectively referred to as the resource tree interface.

For a chestnut: R role has resources for p behavior in a application.

4.2 Single Application + single resource + single action

Collectively, the ACT authentication interface.

Give a chestnut: R role has p behavior of r resources in a application.

Conclusion

Privilege system has always been an indispensable part of our application system, if each application system to re-design the system's permissions to meet the needs of different system users, will waste our valuable time, so it is very meaningful to spend time to design a relatively universal permission system.

It is meaningful to design a relatively generic system. (Not just permissions)

TripAdvisor Original | Architecture design and Practice of the wireless access system for the TripAdvisor cattle