Designing Dynamic Role‑Based Permission Management for Front‑End/Back‑End Separated Admin Systems

Summary

With the rise of front‑end frameworks such as React, Angular, and Vue, front‑end/back‑end separation has become popular, but it also introduces complex permission‑control challenges that cannot be solved by static role definitions alone.

Scenario

The system is a back‑office management platform where users can be created, deleted, and have their roles and permissions adjusted dynamically; therefore a user‑role‑page permission model is required.

Page

A page refers to a front‑end view (e.g., home, user‑management, resource‑management). The strategy keeps front‑end routes unchanged while storing menu structures and page‑level permissions in a database; the front‑end renders menus based on the stored data and enforces route‑guard checks.

Front‑end routes (vue‑router) must define pages.

The database stores menu hierarchy and page‑permission information.

Menu items can be created independently of routes; pages must correspond to existing routes.

Menu and page attributes include title, name, path, parent, type, visibility, and permission‑validation flag.

Routes that do not require permission control (e.g., 404) can be ignored.

After login, the client fetches the full menu/structure, filters it according to the user’s permissions, and renders only authorized items. Route guards prevent manual URL access to unauthorized pages.

Function

Fine‑grained function permissions are needed for cases where a page is visible to many roles but specific actions (e.g., "Create User") are restricted to a single role. Each function is given a unique identifier and linked to its page.

When a user logs in, the backend returns a permission map such as {user: ['userdelete', 'userquery']} ; the front‑end uses v‑if="hasPermission('user_delete')" to show or hide controls.

Role

A role represents an identity or position and can own multiple page and function permissions.

Front‑End Effect

Illustrates the rendered menu based on the current user’s permissions.

Backend Permission

In monolithic architectures, a single prefix (e.g., /user/) could guard all related endpoints, but with front‑end/back‑end separation each page may call multiple services, requiring a mapping from pages/functions to specific APIs.

Interface

Manage protected APIs via an admin UI.

Associate multiple APIs with a page or function.

Backend checks user‑>role‑>page/function‑>API chain to decide access.

Front‑end routing constraints make traditional prefix checks insufficient.

One API may be used by many pages.

Backend Interface Permission Control

User requests an API.

Backend evaluates the user’s permission list against the requested path.

If unauthorized, the request is rejected and the front‑end displays an error.

Database Example

Shows entity tables (red) and relationship tables (blue) that model the user‑role‑page/function‑API hierarchy.