Designing Dynamic Role‑Based Permissions for Front‑Back End Separation

Introduction

With the rise of front‑end frameworks such as React, Angular, and Vue, front‑back end separation has become common, but it also brings new challenges for permission control.

Scenario

The system is a back‑office management platform that includes user creation, login, and resource management. Users are frequently added or removed, and their page and feature permissions must be adjustable at any time, so a user‑role‑page permission model is adopted.

Why Traditional Front‑End Permission Is Insufficient

Using the front‑end router to generate the left‑side menu is inflexible because router definitions are meant for code organization, not menu structure.

Determining whether a route is a menu or a page, and which roles can access it, requires frequent code changes when permissions evolve.

Hard‑coding permissions in the front end assumes static roles and users, which does not fit dynamic business scenarios.

Page Concept

A page refers to a front‑end view such as the home page, user‑management page, or resource‑management page.

Basic Idea

Keep front‑end routes unchanged and store menu structures and page permissions in the database. The front end fetches this data, renders only the menus the current user is allowed to see, and uses route guards to prevent unauthorized navigation.

Implementation Steps

Create normal Vue‑router pages and routes.

Store menu hierarchy, page attributes (title, name, path, parent, type, visibility, permission‑check flag) and function identifiers in the database.

When the front end loads, retrieve all menus and pages; if the user is logged in, filter them according to the user's permission list and render the resulting menu.

After a successful login, fetch the user's permission list (pages and functions) and store it in Vuex; the UI then shows only authorized menus, improving user experience and reducing exposure of irrelevant features.

In route guards, compare the target path with the user's permitted interfaces; if unauthorized, redirect to a 404 or “no permission” page.

Function‑Level Permissions

Some features require finer‑grained control than whole pages. Define each function with a unique identifier (e.g., userdelete, roledisable) and associate it with the relevant page. Roles can be granted specific function identifiers regardless of page permissions.

Role Management

A role represents an identity or position and can own multiple page and function permissions. Role‑page and role‑function relationships are stored in the database, allowing administrators to assign or revoke permissions per role.

User Management

Users can be created or deleted at any time and may hold multiple roles. A user's effective permissions are the union of all permissions from their assigned roles.

Front‑End Effect

Menu rendering based on permissions is illustrated by the following screenshots:

Backend Permission Challenges

In monolithic applications, a single route prefix (e.g., /user/) can be used to guard all related APIs. After front‑back separation, each page may call multiple APIs across different modules, making this approach infeasible.

Therefore, a mapping between pages/functions and the APIs they invoke is required so that granting a page permission implicitly grants access to its associated APIs.

Interface Management

Upload and manage APIs that require permission control.

Associate multiple APIs with each page or function (e.g., the user page may link to user‑query and user‑edit APIs; the “create user” function links to the user‑create API).

When a request arrives, the backend checks the user‑role‑page‑function‑API chain to determine if the user has permission for the requested path.

Database Example

The following diagram shows entity tables (red) and relationship tables (blue) that implement the user‑role‑page/function‑API model.