An interface permission control method and system based on a SpringCloud architecture combined with roles

Abstract

The application discloses a role-based interface permission control method and system based on a SpringCloud architecture. The method comprises the following steps: S1, receiving an interface request initiated by a client, and the interface request enters an API gateway in the SpringCloud system; S2, performing unified authentication operation by the API gateway layer; if the authentication is passed, the next step is entered; if the authentication is not passed, information that the authentication is not passed is returned; and S3, performing fine-grained authorization operation by the micro-service layer. The device comprises the following modules: a core dependency configuration module, which is used for introducing core dependencies in pom.xml files of API gateway services and micro-services; an API gateway layer core configuration module, which is used for configuring interface white lists in the gateway services; a gateway verification and transmission module, which is used for token verification, permission analysis and request forwarding; and a micro-service permission verification module. The application has the advantages of centralized unified control, fine-grained permission control, dynamic scalability, front-end and back-end permission linkage and performance optimization.

Description

Technical Field

[0001] This invention relates to the field of microservice architecture security technology, specifically to an interface permission control method and system based on Spring Cloud architecture and user roles. Background Technology

[0002] With the popularization of microservice architecture, Spring Cloud, as the mainstream microservice development framework, is widely used in various distributed systems. In a microservice architecture, the system is broken down into multiple independent microservice modules, which interact with each other and collaborate on business logic through interfaces. However, as the core carrier of communication between microservices, the security control of these interfaces becomes crucial to ensuring the stable operation of the system.

[0003] In existing technologies, interface permission control under the Spring Cloud architecture has the following drawbacks: First, some solutions use independent permission verification for each microservice, resulting in scattered permission rules, high maintenance costs, and inconsistencies in permission data, which affect system security. Second, traditional permission control is mostly focused on the identity authentication level, lacking a layered permission management system that combines coarse and fine granularity, making it difficult to meet permission requirements in different scenarios, such as path-level interception at the gateway layer and precise permission verification at the microservice interface level. Third, permission verification suffers from duplicate authentication and significant performance overhead, and the flexibility of permission rule adjustments is poor, requiring code modifications to update permission configurations, resulting in insufficient adaptability.

[0004] Therefore, there is an urgent need for an improved interface permission control scheme under the Spring Cloud architecture to address the shortcomings of existing technologies. Summary of the Invention

[0005] The purpose of this invention is to address the problems of repetitive development, insufficient security, poor scalability, and low flexibility in existing Spring Cloud interface permission control schemes. This invention provides an interface permission control method and system that combines user roles under Spring Cloud. It adopts a two-layer control architecture to achieve a combination of unified authentication and fine-grained authorization, while supporting stateless extension and dynamic permission configuration, thereby improving the security, efficiency, and flexibility of permission control.

[0006] To achieve the above objectives, this application provides an interface access control method based on Spring Cloud architecture and roles, characterized by comprising: Step S1: Receive the interface request initiated by the client. The interface request enters the API Gateway in the Spring Cloud system. Step S2: The API gateway layer performs a unified authentication operation; if authentication passes, proceed to the next step; if authentication fails, a failure message is returned. Step S3: The microservice layer performs fine-grained authorization operations.

[0007] As one aspect of the above method, step S2 specifically includes: Check if the requested URL is in the preset whitelist. If it is, the interface returns parameters to the client, allowing the request to proceed directly to the corresponding microservice; otherwise, proceed to the next step, Token verification. The system retrieves the token information corresponding to the Authorization field from the request header of the API request. It verifies whether the token exists and whether the format conforms to the specification of "Bearer + token string". If not, it returns a token authentication failure message to the client, denies access, and returns an unauthorized response. If the token exists, it uses a preset key to parse the token and verify its validity. If the token is invalid, it denies access and returns an unauthorized response. If the token is valid, it extracts the user identifier and the user's role information from the token to construct an authentication information object, stores it in the Reactor context, and then allows the request to be passed to the corresponding microservice.

[0008] As another embodiment of the above method, the step S3 specifically includes: S31: After receiving the gateway's request to allow access, the microservice obtains the authentication information object from the Reactor context; S32: Verify the role or permission information in the authentication information object according to the preset permission rules of the interface; S33: If the verification passes, execute the business logic corresponding to the interface and return the parameter result; if the verification fails, deny access and return an insufficient interface permission response message.

[0009] As another aspect of the above method, the whitelist in step S2 includes at least the request addresses of the login interface, registration interface, and service monitoring interface; the whitelist is stored in a database to enable dynamic configuration updates.

[0010] As another way of the above method, the feature is that the permission rules in step S32 are defined on the method of the microservice interface through the @PreAuthorize annotation, and the permission rules include at least one of role verification rules, permission identifier verification rules and dynamic expression verification rules.

[0011] As another approach to the above method, in a scenario where the Reactor context cannot be shared between the gateway and the microservice, step S2 further includes a cross-service permission transfer step: the gateway layer transmits the parsed user identifier and role information to the microservice through a custom request header; meanwhile, step S3 further includes: the microservice obtains relevant information by parsing the custom request header and constructs an authentication information object, and then performs verification.

[0012] As a further embodiment of the above method, the feature is that step S3 further includes a permission caching step: the mapping relationship between roles and permissions is cached in Redis. When the microservice layer performs permission verification, it first retrieves the mapping relationship from Redis. If the cache is invalid, it queries the database and updates the mapping relationship between roles and permissions in the cache.

[0013] To achieve the above objectives, the present invention also provides an interface permission control device based on the Spring Cloud architecture and combined with roles, characterized in that it includes: The core dependency configuration module is used to import core dependencies in the pom.xml files of the API gateway service and microservices, including gateway, security, JWT core support, and cache middleware dependencies. The core configuration module of the API gateway layer is used to configure the interface whitelist in the gateway service. The gateway verification and pass-through module is used for token verification, permission parsing, and request forwarding. The gateway verification and pass-through module is built on Spring Cloud Gateway and includes: a token verification unit, a permission parsing unit, and a request forwarding unit; the token verification unit verifies the validity of the JWT token through the OAuth2 resource server component; the permission parsing unit parses the permission information in the token through a custom filter and encapsulates it into the request header; the request forwarding unit is used to forward the verified request to the corresponding microservice, while intercepting invalid requests and returning a prompt. The microservice permission verification module is deployed in each microservice. It is used to receive requests that have passed the verification by the gateway verification and pass-through module, perform verification, and handle verification exceptions.

[0014] As one embodiment of the above-mentioned apparatus, it is characterized by further comprising: The caching and refresh module implements permission data caching based on data caching middleware; The caching and refresh module includes a cache query unit, a cache update unit, and a cache refresh unit. The cache query unit first obtains user permission data from the cache middleware. If the cache is not hit, it queries the database and updates the permission data in the cache. The cache update unit updates the cached permission data when the user logs in for the first time. The cache refresh unit receives permission change notifications from the message queue and deletes the cached permission data for the corresponding user.

[0015] As a further embodiment of the above-described apparatus, it is characterized by further comprising: The front-end menu linkage module is deployed on the client side and uses the menu permission verification result to realize the front-end and back-end permission linkage. The front-end menu linkage module includes: The menu rendering unit is used to call the backend menu interface, obtain the mapping relationship of "user-menu-role-interface permission", and dynamically render the client menu; and The route guard unit is used to intercept route jumps, verify the menu permissions corresponding to the route, and send a prompt to the menu rendering unit if there are no permissions, so as to realize the linkage between front-end and back-end permissions.

[0016] This invention is an improved interface permission control scheme based on the Spring Cloud architecture and combined with user roles, which takes into account the hierarchical mapping of "user-role-menu-interface", layered management, unified coordination, flexibility and efficiency.

[0017] Compared with the prior art, the present invention has the following advantages: 1. Centralized and unified management and control: The unified authentication and authorization center realizes centralized management of user authentication and permission data for the entire system, replacing the independent permission logic of each microservice, reducing redundant development, lowering maintenance costs, and achieving consistency in permission configuration.

[0018] 2. Fine-grained access control: Supports three-level access verification based on roles, access codes, and menus. The access codes enable fine-grained management at the interface level, which can precisely control the access permissions of each interface and meet the access requirements of complex business scenarios.

[0019] 3. Dynamic and Scalable: Permission relationships are implemented through database table associations, supporting dynamic configuration of user roles, role menus, and role interface permissions through the management interface. No code modification or service redeployment is required, making it highly scalable and adaptable to scenarios with frequent changes in business permissions.

[0020] 4. Front-end and back-end permission linkage: By linking the menu with the interface, the system achieves strict linkage between dynamic rendering of the front-end menu and permission verification of the back-end interface, avoiding the problem of displaying unauthorized menus on the front-end and improving the user experience.

[0021] 5. Performance optimization: By caching user-role-permission association data in Redis, the frequency of database queries is reduced. At the same time, JWT tokens carry permission information, and microservices can complete permission verification without additional database queries, which greatly improves system response speed.

[0022] 6. High security: RSA asymmetric encryption is used to generate JWT tokens to prevent token tampering; the gateway layer intercepts all requests and verifies the validity of the tokens, forming a front-end security protection; secondary permission verification within microservices builds a double security barrier to ensure interface access security. Attached Figure Description

[0023] Figure 1 This is a flowchart illustrating the process after a user sends a login request, as described in a specific embodiment of the present invention. Figure 2 This is a flowchart of an interface permission control method based on Spring Cloud architecture and roles, according to a specific embodiment of the present invention. Figure 3 This is a timing diagram of the present invention, taking the actual interface request scenario of the production management system as an example. Detailed Implementation

[0024] The technical solutions provided in this application are further illustrated below with reference to the embodiments.

[0025] like Figure 2 As shown in the figure, a specific embodiment of the present invention provides an interface permission control method based on Spring Cloud architecture and combined with roles. It adopts a two-layer control architecture of "unified authentication at the gateway layer + fine-grained authorization at the microservice layer," and specifically includes the following steps: Step S1: Receive the interface request initiated by the client. The interface request enters the API Gateway in the Spring Cloud system. First, the client initiates an API request, which first enters the API Gateway within the Spring Cloud ecosystem.

[0026] Step S2: The API gateway layer performs a unified authentication operation; if authentication succeeds, proceed to the next step; if authentication fails, a failure message is returned to the client. Specifically, this includes: The system checks if the requested address is within a pre-defined whitelist. If it is, the API returns parameters to the client, allowing the request to proceed directly to the corresponding microservice. Otherwise, it proceeds to the next step, Token verification. "API" refers to the API the user is currently requesting.

[0027] The system retrieves the token information corresponding to the Authorization field from the request header of the API request. It verifies whether the token exists and whether its format conforms to the "Bearer + token string" specification. If not, it returns a token authentication failure message to the client, denies access, and returns a 401 Unauthorized response. If the token exists, it uses a preset key to parse the token and verifies its validity (including whether it has expired and whether the signature is correct). If the token is invalid, it denies access and returns a 401 Unauthorized response message to the client. If the token is valid, it extracts the user identifier and the user's role information from the token. Then, it constructs an authentication information object from the extracted user identifier and role information, stores it in the Reactor context, and then allows the request to be passed to the corresponding microservice. Step S3: The microservice layer performs fine-grained authorization operations, specifically including: S31: After receiving the gateway's request to allow access, the microservice obtains the authentication information object from the Reactor context; S32: Verify the role or permission information in the authentication information object according to the preset permission rules of the interface; S33: If the validation passes, execute the corresponding business logic of the interface and return the parameter results to the client; if the validation fails, deny access and return a 403 insufficient permissions response to the client. The corresponding business logic will change according to the interface requested by the user. 403 is an HTTP status code, indicating that "the request has been authenticated, but the user does not have permission to perform the operation." Furthermore, the whitelist in step S2 includes at least the request addresses of the login interface, registration interface, and service monitoring interface; the whitelist is stored in the database to enable dynamic configuration updates, which can be modified in real time through the configuration center without restarting the gateway service.

[0028] The permission rules in step S32 are defined on the methods of the microservice interface using the `@PreAuthorize` annotation. These permission rules include at least one of role validation rules, permission identifier validation rules, and dynamic expression validation rules. The permission identifier validation rule uses the expression `hasAuthority('Permission Identifier')` to verify whether a user has the specified permissions. For example, `hasAuthority('user:edit')` means that only users with edit permissions are allowed access. The role validation rule uses the expression `hasRole('Role Identifier')` or `hasAnyRole('Role Identifier 1', 'Role Identifier 2')` to verify whether a user has a specified single role or any of multiple roles. Spring Security automatically appends the `ROLE_` prefix to the role identifier. If the original role identifier needs to be used directly, `hasAuthority('ROLE_Role Identifier')` can be used as an equivalent implementation. The dynamic expression validation rule is based on Spring EL expressions (Spring EL expressions). ExpressionLanguage allows for custom permission checks, supporting complex logic combinations, parameter values, method calls, and other dynamic validation scenarios. The expression result is a boolean type; returning true indicates successful validation, while returning false indicates failed validation. It is the most flexible permission validation rule.

[0029] Furthermore, in scenarios where the Reactor context cannot be shared between the gateway and the microservice, to ensure accurate transmission of permission information during cross-service calls, step S2 of this method also includes a cross-service permission transmission step: the gateway layer transmits the parsed user identifier and role information to the microservice through a custom request header; meanwhile, step S3 also includes: the microservice obtains relevant information by parsing the custom request header and constructs an authentication information object, and then performs verification.

[0030] The method can also include a permission caching step in step S3: the mapping relationship between roles and permissions is cached in Redis. When the microservice layer performs permission verification, it first retrieves the mapping relationship from Redis. If the cache expires, it queries the database and updates the cached mapping relationship between roles and permissions. This caching mechanism reduces the number of database queries and improves the efficiency of permission verification.

[0031] This invention provides an interface access control device based on the Spring Cloud architecture and combined with roles, implemented using Spring Cloud Gateway (API Gateway) and Spring Security, specifically including: The core dependency configuration module is used to import core dependencies into the pom.xml files of the API gateway service and microservices. These dependencies include gateway, Security, JWT core support, and caching middleware. The caching module in the system may require a specific caching middleware. Figure 2 Redis is one type of caching middleware. If a system wants to use a caching middleware, it needs to include the relevant dependency in its code.

[0032] The core configuration module of the API gateway layer is used to configure interface whitelists in the gateway service, such as login and registration interfaces. It also configures the JWT token parsing key (SECRET_KEY), which is stored in an encrypted manner to ensure security. An interface whitelist means that interfaces (interface addresses) configured in the whitelist can be called without completing a login operation. This applies to login, registration, and other similar interfaces.

[0033] The gateway verification and pass-through module is used for token verification, permission parsing, and request forwarding. The gateway verification and pass-through module is built on Spring Cloud Gateway and includes: a token verification unit, a permission parsing unit, and a request forwarding unit. The token verification unit verifies the validity of the JWT token through the OAuth2 resource server component. The permission parsing unit parses the permission information in the token through a custom filter and encapsulates it into the request header. The request forwarding unit forwards the verified request to the corresponding microservice, while intercepting invalid requests and returning a prompt.

[0034] The microservice permission verification module is deployed in each microservice and is used to receive requests that have passed the verification by the gateway verification and pass-through module, perform verification, and handle verification exceptions. Furthermore, the microservice permission verification module includes a native annotation verification unit and an exception handling unit; the native annotation verification unit parses the Spring Security native @PreAuthorize annotation to implement role and permission code verification; the exception handling unit globally captures permission verification exceptions and returns a standardized 403 permission insufficient response.

[0035] As one implementation method, the interface permission control device based on Spring Cloud architecture and combined with roles in this embodiment of the invention may further include: The caching and refresh module implements permission data caching based on data caching middleware (such as Redis).

[0036] The caching and refresh module includes a cache query unit, a cache update unit, and a cache refresh unit. The cache query unit first obtains user permission data from the cache middleware. When the cache is not hit, it queries the database and updates the permission data in the cache. The cache update unit updates the cached permission data when the user logs in for the first time. The cache refresh unit receives permission change notifications from the message queue, deletes the cached permission data of the corresponding user, and ensures the real-time nature of the permission data.

[0037] As another preferred embodiment, the interface permission control device based on Spring Cloud architecture and combined with roles in this invention may further include: The front-end menu linkage module is deployed on the client side and uses the menu permission verification result to realize the front-end and back-end permission linkage. Furthermore, the front-end menu linkage module includes: Menu rendering unit and route guard unit; the menu rendering unit calls the backend menu interface to obtain... Figure 1 The system describes the mapping relationship between "user-menu-role-interface permission" and dynamically renders the front-end menu; the route guard unit intercepts route jumps, verifies the menu permission corresponding to the route, and sends a prompt to the menu rendering unit if there is no permission, such as jumping to a 403 page, thus realizing the linkage between front-end and back-end permissions.

[0038] Figure 3 This is a sequence diagram illustrating the implementation process of the method and system of this invention using an actual interface request scenario in a production management system as an example. The following embodiment uses a production management microservice system as an example to describe the implementation flow of the invention in detail: 1. Initialize permission data: Create user (e.g., admin, user1, user2), role (e.g., ADMIN, PM_USER, EQU_USER), menu (e.g., System Management, Work Order Management, Equipment Management), and interface (e.g., Work Order Query, Equipment Information Query, System User Query) data in the system database; Configure association relationships: For example, associate the admin user with the ADMIN role, the user1 user with the PM_USER role, and the user2 user with the EQU_USER role; associate the ADMIN role with the System Management, Work Order Management, and Equipment Management menus, as well as the Work Order Query, Equipment Information Query, and System User Query interfaces; associate the PM_USER role with the Work Order Management menu and the Work Order Query interface; associate the EQU_USER role with the Equipment Management menu and the Equipment Query interface.

[0039] 2. User Login Authentication: The admin user enters their username / password on the front-end login page, and the request is sent to the unified authentication and authorization center (auth_server). In the Spring Cloud microservice architecture, the auth service is the unified authentication and authorization center, used to verify the validity of the user's login username and password and complete the login operation. After verifying the validity of the username / password, the authentication center retrieves the ADMIN role, and then retrieves the permission code list and menu list (system management, work order management, equipment management) through the ADMIN role. The user, menu, and interface permission information (["proess:query","equipment:query","sysuser:query"]) are stored in the cache. A JWT token is generated, with the user's basic information in the payload, and returned to the front end, i.e., the client.

[0040] 3. Interface Request Processing: For example, the admin user initiates a work order viewing request with a JWT token (POST http: / / gateway:8080 / proess); the gateway verification and pass-through module intercepts the work order viewing request, verifies the token's validity, and if the verification is valid, finds the user-role-permission information stored in the cached middleware through the user information and encapsulates it into the request header; then forwards the request to the work order microservice.

[0041] 4. Microservice permission verification: Add the @PreAuthorize("hasAuthority(process:query)") annotation to the new order interface method of the work order microservice. Spring Security parses the list of permission codes in the request header, including the process:query permission code. After successful verification, the order new business logic is executed, and a success result is returned.

[0042] 5. Test for unauthorized scenarios: For example, after user1 logs in, they initiate a device viewing request. The user-role-permission information stored in the cached middleware is found through the user information carried in the token. The permission code list only contains process:query. When the device microservice verifies the permission code, it finds that there is no equipment:query permission, so it returns a 403 permission insufficient prompt. At the same time, the front end only renders the work order management menu and hides the system management menu, making it impossible to initiate user query requests.

[0043] 6. Permission Change Test: For example, the administrator adds the EQU_USER role to user1 through the management interface, refreshes the permission cache and deletes user1's cache; user1 initiates another order addition request, the system re-queries the permission information, obtains the equipment:query permission code, verifies it, and executes the device viewing logic.

[0044] As can be seen from the above detailed description of this application, compared with the prior art, the present invention has the following innovative points and beneficial effects: 1. Centralized and unified management and control: The unified authentication and authorization center realizes centralized management of user authentication and permission data for the entire system, replacing the independent permission logic of each microservice, reducing redundant development, lowering maintenance costs, and achieving consistency in permission configuration.

[0045] 2. Fine-grained access control: Supports three-level access verification based on roles, access codes, and menus. The access codes enable fine-grained management at the interface level, which can precisely control the access permissions of each interface and meet the access requirements of complex business scenarios.

[0046] 3. Dynamic and Scalable: Permission relationships are implemented through database table associations, supporting dynamic configuration of user roles, role menus, and role interface permissions through the management interface. No code modification or service redeployment is required, making it highly scalable and adaptable to scenarios with frequent changes in business permissions.

[0047] 4. Front-end and back-end permission linkage: By linking the menu with the interface, the system achieves strict linkage between dynamic rendering of the front-end menu and permission verification of the back-end interface, avoiding the problem of displaying unauthorized menus on the front-end and improving the user experience.

[0048] 5. Performance optimization: By caching user-role-permission association data in Redis, the frequency of database queries is reduced. At the same time, JWT tokens carry permission information, and microservices can complete permission verification without additional database queries, which greatly improves system response speed.

[0049] 6. High security: RSA asymmetric encryption is used to generate JWT tokens to prevent token tampering; the gateway layer intercepts all requests and verifies the validity of the tokens, forming a front-end security protection; secondary permission verification within microservices builds a double security barrier to ensure interface access security.

[0050] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to the embodiments, those skilled in the art should understand that modifications or equivalent substitutions to the technical solutions of the present invention do not depart from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A method for interface access control based on Spring Cloud architecture and roles, characterized in that, include: Step S1: Receive the interface request initiated by the client. The interface request enters the API Gateway in the Spring Cloud system. Step S2: The API gateway layer performs a unified authentication operation; if authentication passes, proceed to the next step; if authentication fails, a failure message is returned. Step S3: The microservice layer performs fine-grained authorization operations.

2. The interface access control method according to claim 1, characterized in that, Step S2 specifically includes: Check if the requested URL is in the preset whitelist. If it is, the interface returns parameters to the client, allowing the request to proceed directly to the corresponding microservice; otherwise, proceed to the next step, Token verification. The system retrieves the token information corresponding to the Authorization field from the request header of the API request. It verifies whether the token exists and whether its format conforms to the "Bearer + token string" specification. If not, it returns a token authentication failure message to the client, denies access, and returns an unauthorized response. If the token exists, it uses a preset key to parse the token and verify its validity. If the token is invalid, it denies access and returns an unauthorized response. If the token is valid, it extracts the user identifier and the user's role information from the token to construct an authentication information object, stores it in the Reactor context, and then allows the request to be passed to the corresponding microservice.

3. The interface access control method according to claim 2, characterized in that, Step S3 specifically includes: S31: After receiving the gateway's request to allow access, the microservice obtains the authentication information object from the Reactor context; S32: Verify the role or permission information in the authentication information object according to the preset permission rules of the interface; S33: If the verification passes, execute the business logic corresponding to the interface and return the parameter result; if the verification fails, deny access and return an insufficient interface permission response message.

4. The interface access control method according to claim 2, characterized in that, The whitelist in step S2 includes at least the request addresses of the login interface, registration interface, and service monitoring interface; the whitelist is stored in the database to enable dynamic configuration updates.

5. The interface access control method according to claim 3, characterized in that, The permission rules in step S32 are defined on the methods of the microservice interface through the @PreAuthorize annotation. The permission rules include at least one of role verification rules, permission identifier verification rules, and dynamic expression verification rules.

6. The interface access control method according to claim 2, characterized in that, In scenarios where the Reactor context cannot be shared between the gateway and the microservice, step S2 also includes a cross-service permission transfer step: the gateway layer passes the parsed user identifier and role information to the microservice through a custom request header; Step S3 also includes: the microservice obtains relevant information by parsing the custom request header and constructs an authentication information object, and then performs verification.

7. The interface access control method according to claim 3, characterized in that, Step S3 also includes a permission caching step: the mapping relationship between roles and permissions is cached in Redis. When the microservice layer performs permission verification, it first retrieves the mapping relationship from Redis. If the cache is invalid, it queries the database and updates the mapping relationship between roles and permissions in the cache.

8. An interface access control device based on Spring Cloud architecture and combined with roles, characterized in that, include: The core dependency configuration module is used to import core dependencies in the pom.xml files of the API gateway service and microservices, including gateway, security, JWT core support, and cache middleware dependencies. The core configuration module of the API gateway layer is used to configure the interface whitelist in the gateway service. The gateway verification and pass-through module is used for token verification, permission parsing, and request forwarding. The gateway verification and pass-through module is built on Spring Cloud Gateway and includes: a token verification unit, a permission parsing unit, and a request forwarding unit; the token verification unit verifies the validity of the JWT token through the OAuth2 resource server component; the permission parsing unit parses the permission information in the token through a custom filter and encapsulates it into the request header; the request forwarding unit is used to forward the verified request to the corresponding microservice, while intercepting invalid requests and returning a prompt. The microservice permission verification module is deployed in each microservice. It is used to receive requests that have passed the verification by the gateway verification and pass-through module, perform verification, and handle verification exceptions.

9. The interface access control device according to claim 8, characterized in that, Also includes: The caching and refresh module implements permission data caching based on data caching middleware; The caching and refresh module includes a cache query unit, a cache update unit, and a cache refresh unit; The cache query unit first retrieves user permission data from the cache middleware. If the cache misses, it queries the database and updates the permission data in the cache. The cache update unit updates the cached permission data when a user logs in for the first time. The cache refresh unit receives permission change notifications from the message queue and deletes the cached permission data for the corresponding user.

10. The interface access control device according to claim 8 or 9, characterized in that, Also includes: The front-end menu linkage module is deployed on the client side and uses the menu permission verification result to realize the front-end and back-end permission linkage. The front-end menu linkage module includes: The menu rendering unit is used to call the backend menu interface, obtain the mapping relationship of "user-menu-role-interface permission", and dynamically render the client menu; as well as The route guard unit is used to intercept route jumps, verify the menu permissions corresponding to the route, and send a prompt to the menu rendering unit if there are no permissions, so as to realize the linkage between front-end and back-end permissions.

Images