Make writing a habit together! This is the 9th day of my participation in the “Gold Digging Day New Plan · April More text Challenge”. Click here for more details

In the last article we covered Angular component communication. In this article, we will talk about whether or not you have encountered a requirement during project development:

Please restrict users’ access to content based on their login.

So, this is about access control.

For user permission restrictions, we generally have the following handling methods:

  1. Control the menu for user login
  2. Restrict user behavior

Let’s talk about this in conjunction with Angular.

Menu routing control

During system development, there will be a lot of menus. At this time, it is necessary for the backend to judge the role of the user and return different menu routes according to the user’s permissions.

The format of the returned data requires that we correspond to the routing path we wrote in app-routing.module.ts.

For example, we have the following routing file:

// app-routing.module.ts

const routes: Routes = [
  {
    path: 'user-manage'.component: AuthLayoutComponent, // Authenticated components
    children: [{path: ' '.redirectTo: 'user'.pathMatch: 'full'
      },
      {
        path: 'user'.// List of users
        component: UserComponent
      },
      {
        path: 'user/detail/:uuid'.// User details, such as this will not appear in the menu
        component: UserDetailComponent
      },
      {
        path: 'department'.// List of departments
        component: DepartmentComponent
      }
    ]
  },
  // ...
]
Copy the code

On the page, our menu displays data like this:

<! -- demo.component.html -->

<ul nz-menu nzMode="inline" [nzInlineCollapsed] ="isCollapsed">
  <li *ngFor="let submenu of menu_data" nz-submenu [nzTitle] ="isCollapsed ? '' : submenu.title" [nzIcon] ="submenu.icon"
    [nzOpen] ="submenu.is_open" (nzOpenChange) ="selectMenu(submenu)">
    <ul>
      <li *ngFor="let child of submenu? .children" nz-menu-item nzMatchRouter>
        <a [routerLink] ="['/' + child.url]">{{ child.title }}</a>
      </li>
    </ul>
  </li>
</ul>
Copy the code

Defines a second-level menu with the following fields:

  • titleField – The title of the menu
  • urlField – Menu route, correspondingapp-routing.module.tsComplete inpath
  • iconField – small icon in front of title, not secondary title
  • is_openField – Indicates whether the menu is expanded

At this point, the backend menu interface should return data similar to the following:

// demo.component.ts

public menu_data:any= [{title: "Member Management".url: "user-manage".icon: "user-switch".Angular Ant Design icon is used here
    is_open: false.children: [{title: "User".url: "user-manage/user".icon: undefined.is_open: false
      },
      {
        title: "Department".url: "user-manage/department".icon: undefined.is_open: false}},// ...
]
Copy the code

You may wonder 🤔️ : icon and is_open fields are not used in the secondary title, why write them?

Well, the reader can request the backend return, but in order to keep the data readable and easy to manipulate, it is better to keep it…

User behavior control

User behavior control, this is a very fine-grained behavior. As small as the display of a button to control the user, but in essence, it is a restriction on the backend interface request 🚫. For example, if you ask for a list, but you don’t have access to it, then you can’t request it and report an error for 401.

Users can be restricted from viewing or performing other operations based on their roles. However, this does not make sense. Users can initiate requests through tools such as Postman, rather than through the system. So, we have to —

Put a layer of restrictions on the back end

We get the interface permissions returned from the back end, such as receiving the following data:

{
  code: 0,
  msg: 'ok',
  results: {
    getUserList: {
     url: '/api/get/user/list', // You can return the url as specified on the front and back end, not necessarily the real url...
     enable: true
    },
    editUser: {
      url: '/api/edit/:uuid',
      enable: false}}}Copy the code

After we get the data, we compare the content saved at the front end, and then control it according to the conditions. The interface needs to make corresponding restricted access, rather than simple front-end judgment.

<! -- demo.component.html -->

<button *ngIf="userObj.editUser.enable">Edit</button>
Copy the code

Simple front-end judgment: 1. Bad maintenance 2. Unsafe, users can cross the browser request

【 the 】 ✅