Pluggable RBAC authority management middleware based on shared low-resource technology stack and RBAC authority management method

Abstract

The invention relates to the technical field of authority management, and discloses a pluggable RBAC authority management middleware based on a shared low-resource technology stack and an RBAC authority management method.The middleware adopts a Vue.js-Node. Js-Sequelize-MySQL lightweight technology stack, and the middleware is packaged into an independent pluggable assembly through a layered architecture of a presentation layer, a service logic layer and a data persistence layer. According to the method, a MySQL memory table and a Redis multi-level cache mechanism are adopted to optimize resource consumption, and memory occupation of single-machine deployment is smaller than or equal to 500 MB; a full-link permission verification system of front-end routing interception-UI control-rear-end interface verification is constructed, and the permission bypassing risk is completely eradicated; and through decoupling of a standardized RESTfull / Grpc interface and a service system, seamless adaptation of multi-language technology stacks such as Java / Python / . NET and the like is supported. According to the method, the defects that an existing distributed scheme is poor in reusability, a centralized scheme is high in resource consumption, and an open source scheme is insufficient in safety are overcome, the method can be widely applied to small and medium-sized applications and multi-technology stack service systems, the authority management efficiency and safety are remarkably improved, and the deployment cost is reduced.

Description

Technical Field

[0001] This invention relates to the field of access control technology, and more particularly to a role-based access control system, and more specifically to a pluggable RBAC access control middleware and RBAC access control method based on a shared low-resource technology stack. Background Technology

[0002] Role-based access control (RBAC) is currently the mainstream access control model. Its core principle is to use "roles" as an intermediary to associate "users" with "permissions," enabling batch allocation and management of permissions. It is widely used in enterprise management systems, educational information platforms, competition data collaboration systems, and other scenarios. Existing RBAC-related technical solutions mainly fall into three categories, but all of them have certain shortcomings and cannot meet the requirements of low-resource, high-reusability, and high-security access control. (1) Development scheme for distributed RBAC permission module This approach is commonly used in small and medium-sized systems. The permission module is deeply coupled with the business system: the permission table structure needs to be strongly bound to the business database (such as field type and primary key rule matching), and the permission verification logic is embedded into the business interface through hard coding (such as the @PreAuthorize annotation in Java system and the [Authorize] feature in .NET system). It is packaged together with the business system during deployment. Its drawbacks are: poor cross-system reusability, requiring repeated design of permission tables and verification logic for each new system development; policy adjustments require modification of the database, backend code, and frontend logic, recompiling the entire package and restarting the service, resulting in low resource (human / time) utilization.

[0003] (2) Centralized RBAC Unified Permission Service Solution This solution is the mainstream choice for multi-system management and control in medium and large enterprises. It requires the independent deployment of a permission service cluster (including configuration nodes, service nodes, and access nodes), and relies on a Redis cluster to store tokens and an Oracle database to store permission data.

[0004] Its drawbacks are: extremely high resource consumption, requiring ≥3 application servers (each node with ≥4GB of memory), a Redis cluster (≥3 nodes), and an Oracle database (≥2 nodes) per cluster, with a total memory requirement of ≥20GB, resulting in severe resource idleness in small and medium-sized systems; multi-language access requires the development of dedicated SDKs (such as Java JAR packages and Python libraries), with an adaptation cycle of ≥1 week per system, which is prone to interface compatibility issues; permission policy modifications require manual synchronization to Redis, resulting in a 1-3 minute delay and poor timeliness.

[0005] (3) Open source lightweight RBAC module solution This solution, represented by Node.js open-source modules (such as rbac-auth), only supports front-end permission verification: permission data is stored in a front-end JSON file, and the back-end interface needs to develop permission logic separately; policy modifications require repackaging the front-end project and restarting the service.

[0006] Its drawbacks are: low security, as users can bypass front-end interception through browser debugging tools and directly access unauthorized interfaces; lack of database persistence, resulting in easy loss of permission data after system restart; poor multi-system collaboration capabilities, making it impossible to share permission data and ensuring data consistency.

[0007] Furthermore, patents disclosed in publication numbers CN118432882A and CN109688120A are strongly bound to specific technology stacks (such as the Java Spring framework), or are positioned as gateway infrastructure (high resource consumption), or have a single function focusing only on performance optimization. None of these can simultaneously solve the comprehensive needs of low resource consumption, pluggable integration, multi-language adaptation, real-time policy adjustment, and end-to-end security verification. Summary of the Invention To address the problems and shortcomings of the existing technologies, this invention proposes a pluggable RBAC permission management middleware based on a shared low-resource technology stack. This middleware aims to overcome the deficiencies of existing solutions in terms of resource consumption, system reuse, security protection, and real-time performance, thereby achieving low-cost, efficient, and secure permission control.

[0008] To achieve the above-mentioned objectives, the technical solution of the present invention is as follows: On one hand, this invention discloses a pluggable RBAC permission management middleware based on a shared low-resource technology stack. The RBAC permission management middleware adopts a layered architecture design, consisting of a presentation layer, a business logic layer, a data persistence layer, and an external interface layer. Each layer has clearly defined responsibilities and collaborates efficiently, achieving inter-layer communication through standardized interfaces. The entire middleware uses MySQL in-memory tables to store high-frequency permission data, combined with Redis multi-level caching; it achieves adaptive load reduction through a resource monitor, prioritizing cached results under high load; and the front end uses route guards and dynamic UI control for interception, while the back end uses interface middleware for secondary verification, forming a three-tiered protection system.

[0009] The specific design scheme for the multi-layer architecture of the middleware of this invention is as follows: (1) Presentation layer This is a single-page application built on the Vue.js 3.x framework and the Element Plus component library. It provides a visual permission management interface, routes and permissions control, and generates the target UI. It communicates with the backend via the Axios library and receives permission policy change notifications via WebSocket. For the visual interface provided by the presentation layer, administrators can configure role permissions through drag-and-drop and checkboxes without writing any code. The core components and configuration of the presentation layer are as follows: The permission management interface provides a visual operation entry and UI for role creation / editing, permission allocation, and policy configuration; The Vue Router routing control module uses Vue Router's beforeEach guard to intercept routes without proper permissions based on a Vuex cached permission set. The Vuex state management module stores user information and permission sets through Vuex, and internally encapsulates the $has() global permission verification method for page-level permission verification. The communication module communicates with the backend via Axios using a RESTful API and receives policy change notifications via WebSocket.

[0010] In this invention, the target UI interface generated by the presentation layer is formed based on the Element Plus UI component library. The front-end UI elements are dynamically adapted according to permissions, and users can only see the functions they have permission to use.

[0011] (2) Business Logic Layer The API server, built on the Node.js runtime environment and the Express framework, is the core of permission verification, containing an authentication manager, permission verifier, and resource monitor; among them, The authentication manager is responsible for issuing and verifying JWT tokens and encrypting passwords. The JWT token contains user ID (i.e., user identifier), role information, etc., and is verified by checking its signature and validity period. The JWT token is signed using the HS256 algorithm, and the password encryption is performed by hashing the password using bcrypt in Node.js and salting it 10 times to prevent the leakage of identity authentication information. The permission validator is used to perform dynamic permission matching decisions based on information such as user roles and request context. It typically queries the role-permission mapping relationship through a Sequelize join table, compares the resource operation of the current request with the permission identifier, and returns the verification result. The resource monitor is used to obtain the system's CPU utilization through os.cpus() and the system's memory utilization through process.memoryUsage(), and triggers an adaptive load reduction mechanism when the CPU utilization exceeds a preset threshold (e.g., CPU utilization > 80%). The business logic layer of this invention supports defining data permission scope through pre-configured dynamic expressions.

[0012] (3) Data persistence layer The data persistence layer connects to the system's MySQL database and Redis cache through the Sequelize 6.X module under the Node.js ORM framework, and manages the data persistence operations of the MySQL database and Redis cache in a unified manner.

[0013] In the data persistence layer, the ORM model defines User, Role, Permission, and RolePermission models through Sequelize and maps them to the database table structure; The MySQL database stores core permission data (including user ID, role, permission relationship, etc.) and supports regular backups. The high-frequency access permission table (role-permission association table (role_permission)) is stored using the MEMORY engine, which can improve read and write speed by more than 10 times. Redis caches temporary permission verification results and sets an expiration time (usually 5 minutes). When the system is in a high-frequency access state, if there are the same requests, the most recent permission verification results in the Redis cache can be used first to reduce the number of database queries.

[0014] Connection pool optimization: Sequelize configuration optimizes database connection pool management (max:10, min:2), reducing the overhead of establishing database connections.

[0015] In general, the data persistence layer is used for permission data persistence, high-frequency data caching, database connection optimization, and data backup and recovery.

[0016] (4) External interface layer The external interface layer serves as the port for the entire middleware to interface and communicate with external systems. It connects with external business systems through standardized RESTful or GPRS interfaces, supporting multi-protocol adaptation. The core interfaces are as follows: Authentication interfaces: / api / auth / login (login to generate token), / api / auth / verify (token verification); Role-based interfaces: / api / roles (role CRUD), / api / roles / {id} / permissions (role permission assignment); Permission interfaces: / api / permissions (CRUD operations), / api / permissions / check (permission verification).

[0017] In the middleware system architecture of this invention, front-end route interception, front-end UI control, and back-end interface verification form a three-layer, end-to-end closed-loop protection; wherein... The first layer of protection: front-end route interception. Before the route jump, Vue Router's beforeEach guard calls Vuex's $has() method to verify the meta.auth permission identifier of the target route. If there is no permission, it will jump to the specified page (such as the competition list page). The second layer of protection: front-end UI control. Page components use the v-if directive in conjunction with the $has() method to dynamically hide unauthorized operation buttons (such as "Add Competition" and "Delete Participation Record"), ensuring that users cannot see unauthorized functions; The third layer of protection: backend interface verification. Before processing the interface, the Express middleware re-executes the permission verification process (even if the frontend interception fails). If there is no permission, a 403 error is returned, eliminating the risk of direct access through the API.

[0018] The protective closed loop formed by the above-mentioned multi-layered interception ensures that even if a certain layer of protection is bypassed, other layers can still provide effective protection, which greatly improves the overall security of the system and also enhances the user experience and system interaction efficiency. Furthermore, the permission data cached by Vuex on the front end is uniformly synchronized by the back end. When a user logs in or permissions change, the back end returns the latest permission set through the API, and the front end updates the cache to ensure that the permission data of the front end and the back end is consistent.

[0019] For the standardized interface design of the pluggable RBAC permission management middleware of this invention, the following solutions are available: RESTful API: Follows resource-oriented design, such as GET / api / roles (query roles), POST / api / permissions (create permissions), DELETE / api / roles / {id} (delete roles), and returns standard HTTP status codes (200 Success, 401 Unauthenticated, 403 No Permission). Grpc interface: Provides .proto definition files, supports binary communication in high-concurrency scenarios, and is adapted to high-performance business systems.

[0020] On the other hand, this invention also discloses an RBAC permission management method implemented using the aforementioned pluggable RBAC permission management middleware based on a shared low-resource technology stack, comprising the following steps: Request interception steps: The middleware is mounted at the API request entry point of the external business system. When the external business system accesses the protected API interface via an HTTP request, the middleware's Vue Router routing control module intercepts the incoming access request. Token verification steps: The authentication manager extracts the Authorization field from the access request to obtain the authentication information (JWT token) in the request, and then proceeds to the next permission verification process; the jsonwebtoken.verify() method is used to verify the signature and validity period of the JWT token in the authentication information in combination with the pre-configured key verification; if the verification passes, the user identifier is decoded and obtained; if the verification fails, a 401 Unauthorized error is returned. Role acquisition steps: Based on the user identifier, the permission verifier calls the UserModel.findByPk() method through Sequelize ORM to query the user's basic information and associated static roles from the MySQL database, thereby obtaining one or more basic role identifiers for the user. These basic role identifiers will serve as inputs for the permission verification and decision-making steps. Context information acquisition steps: Extract the following context information from the request object, including IP address, user agent (used to identify device type), request time (used to determine whether it is within a specific time window), request path and method, etc. Package the above information into a context information object, which serves as another input for the permission verification and decision-making steps; Dynamic strategy engine calculation steps: Based on the user's basic role and context information object, the engine loads a pre-set rule set, uses the rule engine to perform pattern matching and logical reasoning, and outputs a final set of dynamic roles, which may include basic roles and dynamically added temporary roles. Permission verification and decision-making steps: Based on the dynamic role set, the permission verifier uses a Sequelize join query to retrieve all permission identifiers corresponding to the dynamic role set from the role_permission table in the MySQL database; it then matches the resource operation (API path and method) of the current request with the permission identifiers; if the match is successful, the next() method is called to allow the request to the external business system; if the match fails, a permission-prohibited error is returned (403 Forbidden status code and error message); Adaptive load reduction execution steps: During system operation, the resource monitor in the business logic layer monitors system resource load in real time, including CPU utilization and memory utilization. When executing the permission verification and decision-making step, the CPU load status maintained and monitored by the resource monitor is read first. If the CPU utilization exceeds a preset threshold, a load reduction strategy is triggered. The permission verification will directly query and call the historical permission verification results stored in the Redis cache for decision-making, skipping the query operation on the MySQL database (i.e., the role acquisition step and the permission verification and decision-making step), or only performing critical permission verification. If the load returns to normal, the regular cache + database dual-source query logic is executed.

[0021] In this invention, the aforementioned dynamic strategy engine specifically utilizes regular expressions and string template parsing rules (such as IP whitelists and time window rules) to standardize the input user roles and context information into "fact" data that the rule engine can recognize; and matches and judges the input data according to rule conditions (such as "whether the IP is on the whitelist", "whether the request time is between 9:00 and 18:00", "the user role is a regular user and the device is a mobile device").

[0022] For the execution of dynamic policy engine operations, after receiving the user's basic role and context information, the permission verifier embeds rule parsing logic internally to directly complete the calculation of dynamic role set, reducing the complexity caused by module splitting.

[0023] In this invention, the acquisition of context information occurs in the business logic layer, typically performed by the authentication manager. While parsing the JWT token, the authentication manager extracts and encapsulates the request context and directly passes it to the permission validator.

[0024] Furthermore, the present invention also discloses an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the aforementioned RBAC access control method. The beneficial effects of this invention are: 1. The middleware system architecture of this invention adopts full-stack lightweight technology and optimizes data storage and access strategies, enabling the middleware to run stably on a single server with limited memory resources, which greatly reduces hardware and operation and maintenance costs. 2. This invention constructs a full-link verification barrier from front-end routing and UI components to back-end interfaces. Front-end routing interception blocks unauthorized operations at the page access point, UI control hides unauthorized functions at the visual interaction layer, and back-end interface verification serves as the last line of defense. The protection loop formed by these multiple layers of interception ensures that even if one layer of protection is bypassed, other layers can still provide effective protection, greatly improving the overall security of the system, as well as enhancing user experience and system interaction efficiency. 3. The protection closed loop achieved by the multi-layered interception of this invention can realize both coarse-grained control at the page level and fine-grained control at the function button level, adapt to the permission differences of different roles, and meet the permission subdivision needs of complex business scenarios.

[0025] 4. This invention creates an independent, pluggable middleware through a standardized interface design, decoupling it from the technology stack of business systems. It can be embedded into business systems using any technology stack, such as Java, Python, .NET, and Vue. Therefore, business systems can quickly integrate without extensive modifications or dependence on specific SDKs, significantly improving development efficiency and system reusability. 5. This invention utilizes WebSocket to achieve real-time push and cache update of configuration changes, enabling administrators to make changes to permission policies within seconds without restarting the application, thus improving operational efficiency and user experience. 6. The adaptive load reduction mechanism built into this invention enables the system to automatically optimize resource allocation under high concurrency pressure, prioritizing the availability and response speed of core services, and enhancing the robustness of the system. 7. This invention configures the high-frequency access table using the MEMORY storage engine, with the data stored entirely in memory and the table structure stored on disk, significantly improving read and write speed throughout the process. Attached Figure Description

[0026] The foregoing and hereinafter detailed description of the invention becomes clearer when read in conjunction with the following drawings, in which: Figure 1 This is a diagram of the middleware architecture for the permission management system of this invention. Figure 2 This is a flowchart of the permission management method of the present invention. Detailed Implementation To enable those skilled in the art to better understand the technical solutions of this invention, several specific embodiments will be used to further illustrate the technical solutions for achieving the objectives of this invention. It should be noted that the technical solutions claimed by this invention include, but are not limited to, the following embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without inventive effort should fall within the scope of protection of this invention.

[0027] The present invention discloses a pluggable RBAC permission management middleware based on a shared low-resource technology stack and an RBAC permission management method implemented using the pluggable RBAC permission management middleware. The middleware adopts a lightweight Vue.js-Node.js-Sequelize-MySQL technology stack and is encapsulated as an independent pluggable middleware through a layered architecture design. Figure 1 This diagram illustrates the architecture of a pluggable RBAC permission management middleware based on a shared low-resource technology stack according to the present invention. In this embodiment, the pluggable RBAC permission management middleware is deployed in a competition data collaborative management system. Based on a practical application scenario, the deployment of the middleware and the process of using the middleware for permission management after deployment are explained in detail.

[0028] (a) Implementing environmental preparation 1. Hardware Environment Server: 1 Alibaba Cloud ECS instance, configured with 2 cores, 4GB memory, and 40GB SSD; Database: MySQL 8.0 single instance (deployed on the same server), Redis 6.0 single instance (deployed on the same server).

[0029] 2. Software Environment Front-end: Vue.js 3.2.45, Element Plus 2.3.6, Vue Router 4.1.6, Vuex 4.1.0, Axios 1.3.4; Backend: Node.js 16.19.0, Express 4.18.2, jsonwebtoken 9.0.0, bcryptjs 2.4.3, node-cron 3.0.2, Sequelize 6.31.0; The front-end uses npm 9.6.4, the back-end uses npm 9.6.4, and the database uses MySQL Workbench 8.0.

[0030] 3. Deployment and Configuration Middleware deployment: Packaged via Docker container, configured in configuration file (config.js): JWT key: rbac-middleware-secret-key-2025; Token validity period: 7 days (604,800 seconds); Adaptive load reduction threshold: CPU utilization > 80%; MySQL memory table: role_permission table (ENGINE=MEMORY); Port configuration: Middleware API service port 8080, WebSocket service port 8081; Database connection: Configure the connection pool in Sequelize (max:10, min:2, idle:30000ms) (ii) Permission policy configuration 1. Front-end configuration operations The administrator logs into the permission management module of the competition data collaborative management system, enters the role list page, and clicks "Add Role"; Enter the role name (e.g., "Competition Administrator"), role description ("Responsible for managing competition information and reviewing participation records"), and check the permission identifiers (e.g., "race:add (create competition)", "race:delete (delete competition)", "record:check (review record)"). When the save button is clicked, the front end sends a POST request to the middleware's " / api / roles" interface via Axios, carrying role information and permission set.

[0031] 2. Backend persistence processing After the middleware backend receives the request, the authentication manager verifies the validity of the administrator's JWT token; The role-permission mapping table is written to the MySQL database using Sequelize ORM: Role information is written to the "roles" table (id: 101, name: "Competition Administrator", desc: "Responsible for competition information management..."). Permission association information is written to the "role_permission" table (role_id: 101, permission_id: "race:add"; role_id: 101, permission_id: "race:delete"). Configure the "role_permission" table with the MEMORY storage engine, where data is stored directly in memory and the write latency is ≤1ms.

[0032] In this invention, all configuration operations are persisted to a MySQL database via the middleware's API. The role-permission relationships are stored in a table configured with the MEMORY engine.

[0033] 3. The strategy takes effect in real time. The backend pushes the "role_updated" event via WebSocket to all connected middleware instances (including the frontend instance currently logged in by the administrator), carrying the role ID (101). After each middleware instance receives an event, it clears the local role-permission cache (such as the cache in Redis with the key "role:101:permissions"). Subsequent permission verification requests will re-query the MySQL database to obtain the latest permissions, ensuring that the policy takes effect in real time without requiring a service restart.

[0034] (iii) User login authentication 1. Login request submission Teacher users (e.g., employee ID ps2025) enter their account (ps2025), password (123456), and verification code (8866) on the competition system login page and click login; The front end sends a POST request to the middleware's " / api / auth / login" interface via Axios, carrying login parameters (account: "ps2025", password: "123456", captcha: "8866").

[0035] 2. Backend verification processing After receiving the request, the middleware backend first verifies the validity of the verification code (by comparing it with the verification code stored in Redis). After the verification code is passed, the user information is retrieved from the users table in the MySQL database (id:2025, account:"ps2025", password_hash: "$2a$10$...", role_ids:

[101] ). The password is verified using the bcryptjs.compareSync() method (the system hashes the entered password and compares it with the password_hash in the database). If the verification is successful, a JWT token is generated. Token Payload: { "sub": "2025", "roles": ["101"], "exp": 1740000000} (exp is a timestamp 7 days later); Token signing: Signed using the HS256 algorithm with a pre-configured JWT key (rbac-middleware-secret-key-2025).

[0036] 3. Token Return and Storage The backend returns the JWT token to the frontend in the response, and sets a cookie (name: "rbac_token", value: token, maxAge: 604800000ms). After receiving the token, the frontend stores it in localStorage (backup) and calls the " / api / auth / me" interface to retrieve the user's permission set (returning ["race:add", "race:delete", "record:check"]). The frontend stores the permission set in the Vuex cache (store.state.user.permissions = ["race:add", ...]) to complete the login process.

[0037] (iv) Permission verification and decision-making (taking the "delete competition" operation as an example) 1. Request interception and token verification When a user clicks the "Delete Competition" button, the front end sends a DELETE request to the competition system's " / api / races / 1001" interface (competition ID is 1001). The middleware is mounted before the routing of the competition system, intercepts the request, and extracts the Authorization field (with the value "Bearer token") from the request header. The authentication manager uses the jsonwebtoken.verify() method to verify the token, including its signature and validity period. Verify signature: Verify the validity of the signature using a pre-configured key; Verify validity period: Check if the current time is less than the exp field in the payload; Decoding result: User ID (2025) and Role ID (101) are obtained.

[0038] 2. Character lookup and context gathering The permission validator queries the user's basic role through Sequelize: it calls UserModel.findByPk(2025, { include: RoleModel}), which returns the role name "Competition Administrator" corresponding to role ID 101; The resource monitor collects the current system load: CPU utilization is 75% (not exceeding the threshold of 80%), memory utilization is 60%, no need to trigger load reduction; The context collection module extracts request context information: ip: "192.168.1.105", userAgent: "Mozilla / 5.0 (Windows NT 10.0; ...)", requestTime: "2025-05-20T14:30:00Z", requestPath: " / api / races / 1001", requestMethod: "DELETE".

[0039] 3. Role and permission matching The permission validator queries the role-permission mapping through Sequelize join table, calls RolePermissionModel.findAll({ where: { roleId: 101}, attributes: ["permissionId"]}), and returns the permission identifier ["race:add", "race:delete", "record:check"]; The resource operation matching the current request is: the request path " / api / races / 1001" and the permission identifier "race:delete" corresponding to the method "DELETE" exist in the returned permission set, so the match is successful.

[0040] 4. Request for clearance and return of results The middleware calls the next() method to pass the request to the business logic layer of the competition system; The competition system executes the "delete competition" business logic, deleting the record with ID 1001 in the MySQL database races table; The competition system returned a 204 No Content response to the front end, and the front end displayed "Deletion successful", indicating that the operation was completed.

[0041] (v) Adaptive load reduction in high-concurrency scenarios 1. High load trigger During peak competition registration periods (such as the competition registration deadline), when high concurrency requests occur (1000+ requests per second), the middleware's resource monitor detects that the system CPU utilization has risen to 85% (exceeding the threshold of 80%). At this time, an adaptive load shedding strategy is triggered, and a global load shedding flag (load_shedding: true) is set.

[0042] 2. Prioritize cache verification The new "Delete Competition" request (User ID 2025, Competition ID 1002) was intercepted by the middleware; The permission validator detected that the deload flag was true and directly queried the Redis cache: the key is "user:2025:permissions" and the cached value is ["race:add", "race:delete", "record:check"]; Skip the database query steps (role query, permission join query), directly match the permission identifier "race:delete", and allow the request if the match is successful.

[0043] 3. Load recovery After 30 minutes, the number of concurrent requests decreased, and the resource monitor detected that the CPU utilization dropped to 65% (below the recovery threshold of 60%). The resource monitor clears the load shedding flag (load_shedding: false), the permission verification process returns to normal, and the database query steps are re-executed to ensure that the permission data is up-to-date.

[0044] The above description is merely a preferred embodiment of the present invention and is not intended to hinder the present invention in any way. Any simple modifications or equivalent changes made to the above embodiments based on the technical essence of the present invention shall fall within the protection scope of the present invention.

Claims

1. A pluggable RBAC permission management middleware based on a shared low-resource technology stack, characterized in that, The layered architecture is adopted, and the standardized RESTful interface or Grpc interface is used to connect with external business systems, including: The presentation layer is a single-page web based on the Vue.js 3.x framework and the Element Plus component library, which is used to provide a permission configuration interface, route permission control, and generate a target UI interface, and communicate with the backend through the Axios library and receive permission policy change notifications through WebSocket. The business logic layer is built based on the Node.js runtime environment and the Express framework, which is used to generate and verify JWT tokens and execute dynamic permission matching decisions. The data persistence layer connects the MySQL database and Redis through the Sequelize module for permission data persistence, wherein the core permission data is stored in the MySQL database, and the temporary permission verification result is stored in the Redis cache.

2. The pluggable RBAC permission management middleware based on a shared low-resource technology stack according to claim 1, characterized in that, The presentation layer encapsulates a global permission verification method for controlling the dynamic display and hiding of page UI components based on the cached permission set. In addition, a global front guard is configured to intercept unauthorized route jumps based on the cached permission set. 3.The shared low resource technology stack based pluggable RBAC permission management middleware of claim 1, wherein, The adaptive load shedding mechanism is configured to prioritize querying the permission verification result in the Redis cache and skip querying the MySQL database when the system CPU usage exceeds the preset threshold.

4. The pluggable RBAC permission management middleware based on a shared low-resource technology stack according to claim 1, characterized in that, The high-frequency access permission data table in the MySQL database is stored using the MEMORY engine.

5. A RBAC permission management method, characterized in that, The RBAC permission management method is implemented based on the RBAC permission management middleware of any one of claims 1-4, and includes the following steps: Request interception step: mount the middleware at the API request entrance of the external business system, intercept incoming access requests, and extract identity authentication information from the request; Token verification step: verify the signature and validity period of the JWT token in the identity authentication information, and if the verification is passed, decode the user identifier; Role acquisition step: according to the user identifier, query the user's associated basic static role from the MySQL database; Permission verification and decision step: according to the basic static role, query the corresponding permission identifier set, and match the current request resource operation with the permission identifier set; if the matching is successful, the request is released to the external business system; if the matching fails, a permission prohibited error is returned.

6. The use method of claim 5, wherein, The resource monitor monitors system resource load in real time; when executing the permission verification and decision step, if the CPU usage exceeds the preset threshold, the load shedding strategy is triggered, the historical permission verification result in the Redis cache is directly queried for decision, and the query operation on the MySQL database is skipped.

7. The use method of claim 5, wherein the method is characterized in that, In the token verification step, the JWT token is stored in the Cookie, and the token's Payload contains the user identifier, role information, and expiration time. 8.The method of claim 5, wherein the method further comprises: The permission identifier is defined in the standardized format of "resource type: operation type". 9.The method of claim 5, wherein the method further comprises: The method further comprises a permission policy real-time synchronization step: when the administrator modifies the permission configuration through the presentation layer, the business logic layer persists the updated policy to the MySQL database, and broadcasts a policy change notification to all online clients through WebSocket, and the clients update the local permission cache after receiving the notification.

10. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor implements the RBAC permission management method in any one of claims 5 to 9 when executing the computer program.

Images