Understanding Permission Control in Frontend‑Backend Separation Architecture

In a front‑back separation model, all interactions become data, making traditional permission schemes unsuitable; permission control therefore means managing a logged‑in user's access to system resources.

A resource can be any element such as a page, data item, button, image, or even a separator, while a permission is the identifier required to access that resource; the set of permissions a user holds determines which resources they can reach.

The responsibilities are split: the server provides data APIs, and the frontend handles routing and rendering. Frontend permission control includes route filtering to block illegal requests and component‑level rendering based on permission identifiers.

Example of a permission component usage: <组件 permissionName='xxx' />

Although the frontend can render resources within a user's permission scope, it cannot guarantee API security; therefore the backend must validate permissions on each request, typically using an interceptor.

Implementation ideas include frontend route permission checks that render a 403 component when unauthorized, and a reusable BirdButton component that receives a permissionName prop and renders only when the user has the required permission.

Backend permission verification is illustrated with a Java interceptor ( public class SsoAuthorizeInterceptor extends HandlerInterceptorAdapter { ... } ) that extracts the user's ticket, reads required permissions from annotations, and throws UnAuthorizedException or ForbiddenException when checks fail.

The complete source code is hosted on GitHub (github.com/liuxx001/bird-front) and the project also offers other reusable UI components such as bird‑selector, bird‑grid, bird‑tree, bird‑form, and bird‑button to accelerate business development.