📖 blog post:Xxoo521.com system Design: Role-based Permission Management Design and Implementation

background

Many APIS of the internal operation system involve the change of user information in the formal environment of the external network. For safety reasons, all operation records are kept at the beginning of the design, but this is for later review; To really avoid the occurrence of online accidents, also need permission management.

Currently, the system code consists of three parts: front end, middle stage and back end. Among them, the front end is responsible for the interaction logic, the middle stage is responsible for the main business logic, the background is responsible for providing the database read and write API. All the checksum service logic is implemented by the central network, so the central network needs to participate in the transformation of permission management.

Role-based permission design

Suppose the system supports four roles:

  • Role A: Super administrator
  • Role B: Operations personnel
  • Role C: Developer
  • Role D: Tourist (general user)

Each API is divided into a corresponding set of apis according to its function:

  • Set A: User management-related apis
  • A collection of b:
    • Log related API
    • API related to environment information
  • A collection of c:
    • Resource Tuning API
    • The blacklist API

Each role can be tuned to a single/multiple/full set of apis:

  • Role A: Set of all apis
  • Role B:
    • A collection of b
    • A collection of c
  • Role C: Collection of all apis
  • Part D:
    • A collection of b

It is important to note that each user can only be one role, and roles can correspond to multiple collections, and each collection can correspond to multiple apis. In short, a role is a user identity that is unique.

For example, for certain users (such as interns), you can create a role and arrange and combine the set of apis required by that role.

Center stage and servitization

The background provides the most basic database read and write API in the way of service, so that the future change cost is low, operation and maintenance cost is low, and can provide services for other applications.

And the main logic is handed over to the center for splicing and combination, the center does not need to save the state. At the same time, the change of business logic does not involve the database and the background, and the middle and background are completely coupled, simplifying the release and deployment process.

👇 scan code to pay attention to the “xin Tan blog”, view the “front-end atlas” & “algorithm problem solving”, adhere to sharing, grow together 👇