A high-order component-based front-end routing permission control method and system

Abstract

The application discloses a front-end route forced permission control method and system based on a high-order component, is applied to a computer field React technology stack, and solves the problems of dispersed existing front-end permission control logic, no forced interception, poor adaptability and the like. The method realizes real-time updating of permission by defining a high-order component receiving permission code, a target component and the like, reading user permission from sessionStorage and listening to a storage event; all target components are wrapped with the component in a React Router route configuration stage, unified permission verification before route access is preposed, and a target component or a permission-free component is rendered according to a result. The application realizes centralized encapsulation of permission logic, reduces maintenance cost, improves code reusability, realizes forced interception from a route layer, adapts to complex verification in multiple scenes, solves the problem of page flashing, and is realized based on sessionStorage and is light, has no additional library dependence, is easy to integrate, and has low coupling degree.

Description

Technical Field

[0001] This invention relates to the field of computer technology, specifically to a front-end routing mandatory permission control method and system based on high-order components. Background Technology

[0002] Although existing solutions can achieve routing access control to some extent, they still have the following obvious shortcomings: 1. The permission verification logic is scattered, resulting in high maintenance costs. Permission checks are used in a mixed manner within components and routes, leading to developers working independently, resulting in repetitive and inconsistent logic. Once the permission rules change, extensive manual code modifications are required, which is prone to omissions and increases maintenance costs and risks.

[0003] 2. Lack of a unified permission interception mechanism: React Router does not have a built-in route guard mechanism, and there is a lack of a standardized solution in the industry. This results in each project having to re-encapsulate the code, leading to a lot of repetitive work and low code reusability.

[0004] 3. Access control is not mandatory. Many implementations rely solely on internal component judgments, which are easily bypassed; or they are only front-end presentation layer controls. Once a development oversight occurs, there are security risks, and true "forced interception" cannot be achieved.

[0005] 4. Inability to flexibly handle multi-dimensional permission verification. Most existing solutions only support single role or simple permission identifier judgment, which is difficult to support complex scenarios, such as verification of multiple permission code arrays, dynamic resource list matching, or real-time synchronization of user permission changes.

[0006] 5. Poor user experience: If access control is placed on the backend, the frontend cannot detect unauthorized access in advance, which can easily lead to a "splashing" phenomenon where the page loads first and then redirects. If the logic is scattered, it may cause inconsistent performance on different pages, affecting the overall experience.

[0007] This invention aims to address the lack of a unified, mandatory, and scalable routing permission control mechanism in the existing React technology system.

[0008] Specifically, existing technologies generally suffer from the following technical pain points: 1. The permission verification logic is scattered, with permission checks being distributed across various page components and route configurations. The lack of a unified encapsulation and reuse mechanism leads to high maintenance costs and makes it easy for omissions or inconsistencies to occur.

[0009] 2. Lack of forced interception capability: React Router does not have a built-in navigation guard. Most existing solutions only perform permission verification within the component, which is easy to bypass and has insufficient security.

[0010] 3. It is difficult to support complex permission rules in multiple scenarios, such as judgment of multiple permission codes, real-time effect of dynamic permission changes, and redirection logic for users who are not logged in. Traditional solutions lack a unified entry point for implementation.

[0011] 4. Inconsistent user experience: Due to the lack of a centralized access control mechanism, the handling of unauthorized access on different pages is not uniform, which can easily cause problems such as screen flickering and display delay.

[0012] Therefore, this invention proposes a front-end routing mandatory permission control method based on higher-order components (HOC). By encapsulating unified permission verification logic at the routing layer, it achieves centralized permission judgment and automated page redirection processing, thereby improving the security, consistency and maintainability of front-end applications. Summary of the Invention

[0013] The purpose of this invention is to provide a front-end route enforcement permission control method based on higher-order components, comprising the following steps: Step 1: Define a higher-order component for permission interception. The higher-order component is configured with three core input parameters, namely the permission code that identifies the route access permission, the business target component to be accessed, and the fallback component for unauthorized access. Step 2: During the initialization phase, the higher-order component reads the permission information of the currently logged-in user from the browser's sessionStorage and extracts the list of permission resources as the core basis for subsequent permission verification. Step 3: When the higher-order component is mounted, start listening to the browser's global storage event. When a change in the user's permission information is detected, automatically update the internal state of the higher-order component and trigger the re-execution of the permission verification logic to achieve real-time synchronous control of permissions. Step 4: In the route configuration registration phase of React Router, all target components in the front-end application that require permission control are uniformly wrapped through the higher-order component. The permission code corresponding to the route, the business target component, and the preset unpermitted component are passed to the higher-order component to achieve unified integration of the permission verification entry point of the route layer, so that all route access requests are verified by the permission of the higher-order component. Step 5: When a user initiates a route access request, the higher-order component immediately executes the permission verification logic. If the verification result shows that the current user has the required permissions for the target route, the business target component is rendered normally to respond to the user's route access request. If the verification result shows that the current user does not have the required permissions for the target route, the unauthorized component is rendered directly or the user is automatically redirected to the unified unauthorized page of the front-end application, thereby forcibly intercepting unauthorized route access requests.

[0014] Preferably, the permission code supports two verification formats: a single string format and a permission code array format. When the permission code is a single string format, it directly matches whether the user's permission resource list contains the permission code. When the permission code is an array type, it iterates through the permission resource list in the user's permission information to determine whether there is any matching item in the permission code array. If any item matches, it is determined that the user has the corresponding route access permission.

[0015] Preferably, the user's permission information is returned by the backend service after the user completes login authentication. After receiving the permission information, the frontend application serializes and stores it in the browser's sessionStorage. The permission information includes at least a unique user identifier, user role type, and a list of permission resources, and the list of permission resources is structured data with permission codes as the core identifier.

[0016] Preferably, in step 3, the scenarios in which user permission information changes include one or more of the following: user account switching, user role update, addition, deletion, and adjustment of user permission resources, and user logging out and logging back in. Furthermore, the storage event listener covers all pages under the same domain in the current browser, enabling real-time synchronization of permission information across multiple pages. After listening to the storage event, the higher-order component updates its internal state by updating its own state management data. Moreover, the process of re-executing the permission verification logic does not require refreshing the browser page, achieving seamless real-time permission updates and routing access control.

[0017] Preferably, in step 4, during the routing configuration phase of React Router, the higher-order component is called using the component property of the routing configuration item. The pre-set authCode permission code, the business target component, and the pre-set permissionless component in the front-end application are passed to the higher-order component through an anonymous function to complete the wrapping of a single target component. For the route set in the front-end application, the batch unified wrapping of all route components requiring permission control is achieved by traversing the route configuration array.

[0018] Preferably, the permission-unauthorized component is a unified permission prompt page component independently encapsulated in the front-end application. This component includes text prompts for permission-unauthorized access, operation guidance, and page styles, and supports custom configuration according to business needs. The permission-unauthorized page is a globally unified permission-unauthorized access page with separately configured routes in the front-end application, and is a fallback display method that can be replaced by the permission-unauthorized component.

[0019] This invention also provides a front-end routing enforcement permission control system based on higher-order components. The system includes a permission data storage module, a higher-order component encapsulation module, a permission monitoring module, a routing integration module, and a permission verification execution module. These modules work collaboratively to complete the entire process of routing permission control. The permission data storage module receives user permission information returned by the backend service after the user completes login authentication, serializes it, and stores it in the browser's sessionStorage. It also provides a permission information reading interface for other modules to access permission verification data and supports updating and deleting permission information. The higher-order component encapsulation module customizes a higher-order component for permission interception. The higher-order component is configured with input parameters including a permission code, a target business component, and a component without permissions. It encapsulates basic permission verification logic, component rendering logic, and state update logic within the higher-order component, forming a reusable and configurable higher-order permission control component. The permission monitoring module, integrated into the higher-order component, continuously monitors the browser's global storage event when the higher-order component completes page mounting. When sessionStorage is detected... When user permission information changes, the internal state update of the higher-order component is immediately triggered, and a re-verification trigger signal is sent to the permission verification execution module. The routing integration module, during the route configuration registration phase of React Router, iterates through all route configuration items of the front-end application. For routes requiring access control, it uniformly calls the higher-order component to wrap the business target component, passing the route's preset permission code, the business target component, and the globally unauthorized component to the higher-order component. This achieves a unified verification entry point for all permission routes, ensuring that all route access requests must pass through the permission verification step. The permission verification execution module, as the core execution unit of permission control, reads the current user's permission information from sessionStorage and extracts the list of permission resources. Based on the permission code format (single string / array) passed by the higher-order component, it performs permission verification according to preset matching rules and outputs control instructions based on the verification results: if the verification passes, the instruction renders the business target component; if the verification fails, the instruction renders the unauthorized component or redirects to the globally unauthorized page, thus forcibly intercepting unauthorized access.

[0020] Preferably, the permission codes configured in the higher-order component encapsulation module support both single string and permission code array formats. The permission verification execution module has built-in direct string matching logic and array traversal matching logic. When the permission code is an array type, the traversal matching logic is automatically started to match the user permission resource list and the permission code array item by item. If any item matches, the permission verification is considered successful. The permissionless component is a globally unified permission prompt page component independently encapsulated in the front-end application. It is preset into the default configuration of the higher-order component's input parameters by the higher-order component encapsulation module, and the business side can customize and replace the display content and style of the permissionless component according to actual needs. The user permission information stored in the permission data storage module is structured JSON data, which facilitates quick parsing and extraction of the permission resource list.

[0021] Preferably, the storage event listening scope of the permission listening module is all page instances under the same domain of the browser. When one page updates the user permission information, the higher-order components of all other pages can detect the change in real time and trigger re-verification, realizing real-time synchronization of permission information and routing control among multiple pages without refreshing the browser page.

[0022] Compared with the prior art, the beneficial effects of the present invention are: Reduce maintenance costs and improve code reusability: Unify permission verification logic within a higher-order component, replacing scattered judgment code within routes and components, avoiding logic duplication and development inconsistencies. When permission rules change, only the core logic of the higher-order component needs modification, without extensive adjustments to business code, reducing the risk of missed modifications. The standardized interception mechanism also avoids the ineffective work of redundant encapsulation within the project.

[0023] Implement mandatory permission blocking to improve application security: Complete the high-order component wrapping of all target components during the React Router route configuration phase, and move permission verification to the front end before route access, instead of only making judgments inside the component. Implement mandatory blocking of unauthorized access from the routing layer, completely avoid the security risks of permission verification being bypassed, and strengthen front-end access security control.

[0024] Adaptable to complex permission scenarios and highly scalable: The advanced component supports two validation formats: single permission code and permission code array, which can meet the complex needs of multiple permission code combination judgments; at the same time, by listening to the storage event, it can realize real-time synchronization of user permission changes, so that new permissions can take effect without refreshing the page, and can also adapt to various business scenarios such as non-login redirection.

[0025] Optimize user experience and ensure consistent interaction: Through centralized front-end access control, unauthorized access is judged and processed before the page loads, completely solving the "splashing" problem caused by back-end control; unified unauthorized access handling logic ensures that unauthorized access redirection and display are consistent across all pages, avoiding the experience fragmentation caused by differences in performance across different pages.

[0026] Lightweight implementation, reduced technical dependence: The preferred approach is to use sessionStorage + storage events to implement permission storage and updates, without relying on global state management libraries such as Redux. The solution is lightweight and versatile, easy to integrate into different React projects, and reduces the technical coupling of the project. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to specific embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0028] Example 1

[0029] A front-end route enforcement permission control method based on Higher-Order Components (HOCs) is proposed to perform unified and scalable permission verification and interception for all route access in React front-end applications, thereby achieving application-level access security control.

[0030] The core idea of ​​this solution is to uniformly encapsulate business components through higher-order components during the React route registration phase; and to perform real-time verification of the current user's permission information before component rendering. Based on the verification results, decide whether to allow access to the target route or redirect to a page where access is denied.

[0031] This solution avoids repeatedly writing validation code on various pages by abstracting the permission logic outside the component layer, achieving the goals of centralized logic, flexible use, and unified maintenance.

[0032] 1. Permission Data Preparation Phase The user permission data storage and loading system stores the user information (including roles, permission resource lists, etc.) returned by the backend in the browser's sessionStorage after the user logs in. When the front-end higher-order component is mounted, it reads the user object from sessionStorage and extracts the resources field as the basis for permission verification. Real-time updates of permission data are achieved by the higher-order component listening to the window.storage event. This allows for real-time reloading of permission data when user permission information changes (e.g., switching users, updating role permissions), taking effect without requiring a page refresh.

[0033] Optional implementation: Global state management (such as Redux or Zustand) can also be used to store user information, but this application prefers the sessionStorage + storage event implementation because it does not depend on additional libraries and is more lightweight and universal.

[0034] 2. Permission verification and route interception phase Encapsulation of higher-order components Define an `AuthWrapper` component that accepts `authCode` (authorization code), `component` (business logic component), and `noMatch` (component without authorization) as parameters. Before rendering, determine whether the current user possesses the `authCode`. If `authCode` is a string, match it directly; if `authCode` is an array, check if the user has any of the permissions listed. Process the authorization verification results. If the user has the corresponding permissions, the component will be rendered normally; if the user does not have the permissions, the noMatch component will be rendered, or the user will be redirected to a unified "No Permission" page.

[0035] 3. Summary of key steps in the technical solution User login → Backend returns permission list → Stored in sessionStorage; During route registration → Use HOCs to encapsulate business components → Pass in the required permission codes; When a page is accessed → HOC reads user permissions → compares the authCode → decides whether to render; When permissions change → storage event is triggered → HOC automatically refreshes status → real-time control of access permissions.

[0036] 4. Optimal Implementation Method Use sessionStorage as the permission cache; Real-time synchronization is achieved by listening to storage events; All service routes are uniformly wrapped using HOC during configuration; Pages without access permissions use a separate unified prompt page component; authCode supports multiple formats (single-value / multi-value arrays), improving flexibility.

[0037] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A front-end route enforcement permission control method based on higher-order components, characterized in that: Includes the following steps: Step 1: Define a higher-order component for permission interception. The higher-order component is configured with three core input parameters, namely the permission code that identifies the route access permission, the business target component to be accessed, and the fallback component for unauthorized access. Step 2: During the initialization phase, the higher-order component reads the permission information of the currently logged-in user from the browser's sessionStorage and extracts the list of permission resources as the core basis for subsequent permission verification. Step 3: When the higher-order component is mounted, start listening to the browser's global storage event. When a change in the user's permission information is detected, automatically update the internal state of the higher-order component and trigger the re-execution of the permission verification logic to achieve real-time synchronous control of permissions. Step 4: In the route configuration registration phase of React Router, all target components in the front-end application that require permission control are uniformly wrapped through the higher-order component. The permission code corresponding to the route, the business target component, and the preset unpermitted component are passed to the higher-order component to achieve unified integration of the permission verification entry point of the route layer, so that all route access requests are verified by the permission of the higher-order component. Step 5: When a user initiates a route access request, the higher-order component immediately executes the permission verification logic. If the verification result shows that the current user has the permissions required for the target route, the business target component is rendered normally to respond to the user's route access request. If the verification result indicates that the current user does not have the required permissions for the target route, the unauthorized component will be rendered directly or the user will be automatically redirected to the unified unauthorized page of the front-end application, thereby forcibly intercepting unauthorized route access requests.

2. The front-end routing mandatory permission control method based on higher-order components according to claim 1, characterized in that, The permission code supports two verification formats: a single string format and a permission code array format. When the permission code is in the single string format, it is directly matched to see if the user's permission resource list contains the permission code. When the permission code is an array, the system iterates through the list of permission resources in the user's permission information to determine if there is any matching item in the permission code array. If any item matches, the user is determined to have the corresponding route access permission.

3. The front-end routing mandatory permission control method based on higher-order components according to claim 1, characterized in that, The user's permission information is returned by the backend service after the user completes login authentication. After receiving the permission information, the frontend application serializes and stores it in the browser's sessionStorage. The permission information includes at least a unique user identifier, user role type, and a list of permission resources, and the list of permission resources is structured data with permission codes as the core identifier.

4. The front-end routing mandatory permission control method based on higher-order components according to claim 1, characterized in that, In step 3, the scenarios in which user permission information changes include one or more of the following: user account switching, user role update, addition, deletion, and adjustment of user permission resources, and user logging out and logging back in. The storage event listener covers all pages under the same domain in the current browser, realizing real-time synchronization of permission information between multiple pages. After the higher-order component listens to the storage event, it refreshes its internal state by updating its own state management data. The process of re-executing the permission verification logic does not require refreshing the browser page, realizing seamless real-time permission updates and routing access control.

5. The front-end routing mandatory permission control method based on higher-order components according to claim 1, characterized in that, In step 4, during the route configuration phase of React Router, the higher-order component is invoked using the component property of the route configuration item. The pre-set authCode permission code, the business target component, and the pre-set permissionless component in the front-end application are passed to the higher-order component through an anonymous function to complete the wrapping of a single target component. For the route set in the front-end application, the batch unified wrapping of all route components requiring permission control is achieved by traversing the route configuration array.

6. The front-end routing mandatory permission control method based on higher-order components according to claim 5, characterized in that, The "no permission" component is a unified permission prompt page component independently encapsulated in the front-end application. This component includes text prompts for unauthorized access, operation guidance, and page styles, and supports custom configuration according to business needs. The "no permission" page is a globally unified "no permission" access page with separately configured routes in the front-end application, and is an alternative fallback display method to the "no permission" component.

7. A front-end routing enforcement permission control system based on any one of claims 1-6, characterized in that, The system includes a permission data storage module, a higher-order component encapsulation module, a permission monitoring module, a routing integration module, and a permission verification execution module. These modules work collaboratively to complete the entire process of routing permission control. The permission data storage module receives user permission information returned by the backend service after user authentication, serializes it, and stores it in the browser's sessionStorage. It also provides an interface for reading permission information, allowing other modules to obtain permission verification data, and supports updating and deleting permission information. The higher-order component encapsulation module is used to customize and implement higher-order components for permission interception. The input parameters of the higher-order component are configured as permission code, target business component, and component without permission. It also encapsulates basic permission verification logic, component rendering logic, and state update logic within the higher-order component, forming a reusable and configurable higher-order component for permission control. The permission monitoring module, integrated into the higher-order component, continuously listens for global storage events in the browser when the higher-order component completes page mounting. When sessionStorage is detected... When user permission information changes, the internal state update of the higher-order component is immediately triggered, and a re-verification trigger signal is sent to the permission verification execution module. The routing integration module is used to traverse all routing configuration items of the front-end application during the routing configuration registration phase of React Router. For routes that require permission control, the higher-order component is called to wrap the business target component. The route's preset permission code, business target component, and globally unpermitted component are passed to the higher-order component to achieve a unified verification entry point for all permission routes, ensuring that route access requests must go through the permission verification process. The permission verification execution module, as the core execution unit of permission control, is used to read the current user's permission information from sessionStorage and extract the list of permission resources. According to the permission code format passed by the higher-order component, it performs permission verification according to the preset matching rules and outputs control instructions based on the verification results: when the verification passes, the instruction renders the business target component; when the verification fails, the instruction renders the unauthorized component or jumps to the global unauthorized page, thereby realizing the forced interception of unauthorized access.

8. A front-end routing enforcement permission control system based on high-order components according to claim 7, characterized in that, The permission code configured by the higher-order component encapsulation module supports single string format and permission code array format. The permission verification execution module has built-in string direct matching logic and array traversal arbitrary matching logic. When the permission code is an array type, the traversal matching logic is automatically started to match the user permission resource list and permission code array item by item. If any item matches, the permission verification is deemed to have passed. The permissionless component is a globally unified permission prompt page component independently encapsulated in the front-end application. It is preset into the default configuration of the input parameters of the higher-order component by the higher-order component encapsulation module, and the business side can customize and replace the display content and style of the permissionless component according to actual needs. The permission data storage module stores user permission information as structured JSON data, which is convenient for quick parsing and extraction of the permission resource list.

9. A front-end routing enforcement permission control system based on high-order components according to claim 7, characterized in that, The storage event listening scope of the permission listening module covers all page instances under the same domain in the browser. When one page updates the user permission information, the higher-order components of all other pages can detect the change in real time and trigger re-verification, realizing real-time synchronization of permission information and routing control among multiple pages without refreshing the browser page.