Interface access authority control method and device

Abstract

The invention provides an interface access authority control method and device, belongs to the technical field of software engineering, and can improve the flexibility of interface control. The interface access permission control method comprises the following steps: defining a permission annotation; wherein the permission annotation is used for determining permission configuration, and the parameter form of the permission annotation comprises a role identifier, a permission code and an organization; marking the permission annotation on a target interface method, and completing association between the permission annotation and the target interface to declare an access permission demand of the target interface; intercepting an interface calling request through aspect programming, and analyzing an access permission state of an interface calling party; on the basis of the user access permission state and the permission annotation, performing permission verification on the access user; and in response to permission verification passing, returning a permission verification result to the interface calling party so as to pass the interface calling request.

Description

Technical Field

[0001] The present invention relates to the technical field of software engineering, and in particular to a method and device for controlling interface access rights. Background Art

[0002] In recent years, the information technology and internet industries have flourished, becoming a significant force driving global economic growth and social progress. The internet and mobile internet are becoming increasingly popular, and data interaction is fundamental to the realization of numerous internet applications and services. Whether it's information transmission between users and systems or data sharing and collaboration between different systems, efficient and stable data interaction is essential. Interfaces, as the bridge for data interaction, play a crucial role. They define the rules and methods for data interaction, enabling seamless communication and collaboration between different software components, systems, or devices. However, in practical applications, frequent or inappropriate access to interfaces often leads to system performance degradation or resource misuse. Therefore, effectively controlling user access rights to interfaces and improving system stability and performance has become a pressing issue. Summary of the Invention

[0003] In order to solve the above technical problems, the present invention is proposed. Embodiments of the present invention provide a method and apparatus for controlling interface access rights, which can improve the flexibility of interface control.

[0004] According to one aspect of the present invention, there is provided an interface access permission control method, comprising: defining a permission annotation; wherein the permission annotation is used to determine the permission configuration, and the parameter form of the permission annotation includes a role identifier, a permission code, and an organizational structure; marking the permission annotation on the target interface method, completing the association between the permission annotation and the target interface, so as to declare the access permission requirements of the target interface; intercepting the interface call request through aspect programming, and parsing the access permission status of the interface caller; performing permission verification on the accessing user based on the user access permission status and the permission annotation; and returning the permission verification result to the interface caller in response to passing the permission verification, so as to pass the interface call request.

[0005] In one embodiment, the interface access permission control method also includes: mapping the interface identifier, user ID and access count combination into a key-value pair in Redis; storing the access count as a value in Redis, and the data type of the value is an integer type that can be atomically incremented; when the interface is called, creating or updating the corresponding counter value in Redis through the key-value pair; when the counter value is greater than or equal to a preset threshold, triggering an early warning and issuing a high-frequency access prompt message.

[0006] In one embodiment, the interface access permission control method further includes: setting a preset lifetime for each of the key-value pairs; wherein the lifetime is determined based on the user access frequency or the user access permission; when the actual lifetime of the key-value pair is greater than the preset lifetime, deleting the key-value pair to reset the user's access times to the preset times.

[0007] In one embodiment, the interface access permission control method further includes: when the permission check fails, returning a permission check result indicating that access is not permitted to the user who initiated the interface call request, and returning the missing permission type.

[0008] In one embodiment, the access request includes an immediate response task and a non-immediate response task; when the permission check fails, a permission check result that does not allow access is returned to the user who initiated the interface call request, and the missing permission type is returned, including: when the access request is the immediate response task, if the user permission check of the access request fails, a permission check result that does not allow access is returned to the user who initiated the interface call request, and the missing permission type and a preset status code are returned to inform the user that the client has insufficient permissions; when the access request is the non-immediate response task, based on the message queue mechanism, the access request with insufficient permissions is stored, and when the system load is lower than the preset load threshold, the access request is processed.

[0009] In one embodiment, the interface access permission control method also includes: setting a three-level retry mechanism for permission verification failure caused by network problems or temporary unavailability of service; wherein, the first level retry is a retry within a first preset time period after the permission verification fails, the second level retry is a retry within a second preset time period after the permission verification fails, and the third level retry is a retry within a third preset time period after the permission verification fails; the maximum value in the first preset time period is less than the minimum value in the second preset time period, and the maximum value in the second preset time period is less than the maximum value in the third preset time period; before the first level retry, the second level retry and the third level retry, a permission policy is obtained once; the permission policy includes a permission annotation, a permission verification policy and a permission expiration condition.

[0010] In one embodiment, the interface access permission control method further includes: when the number of times the permission check of the access request fails is greater than the preset number of retries, the failure information of the access request is stored in a database; wherein the failure information includes the original request parameters, the reason for failure, the stack trace and the retry history.

[0011] In one embodiment, the access permission status includes: static attributes, dynamic behavior and environmental parameters; wherein, based on the user access permission status and the permission annotation, the accessing user is verified for permissions, including: based on the static attributes, the dynamic behavior, the environmental parameters and the permission annotation, the accessing user is verified for permissions.

[0012] In one embodiment, the static attributes include: user role, user ID and user organizational structure; based on the user access permission status and the permission annotation, the accessing user is subject to permission verification, and it also includes: based on the role identifier in the permission annotation and the user role in the access permission status, the accessing user is subject to permission verification; based on the permission code in the permission annotation and the user ID in the access permission status, the accessing user is subject to permission verification; based on the organizational structure in the permission annotation and the user organizational structure in the access permission status, the accessing user is subject to permission verification.

[0013] According to another aspect of the present invention, an interface access permission control device is provided, comprising: a definition module for defining a permission annotation; wherein the permission annotation is used to determine the permission configuration, and the parameter form of the permission annotation includes a role identifier, a permission code, and an organizational structure; a marking module for marking the permission annotation on the target interface method, completing the association between the permission annotation and the target interface, so as to declare the access permission requirements of the target interface; a parsing module for intercepting interface call requests through aspect programming, and parsing the access permission status of the interface caller; a verification module for performing permission verification on the accessing user based on the user access permission status and the permission annotation; a notification module for returning the permission verification result to the interface caller in response to passing the permission verification, so as to pass the interface call request.

[0014] The interface access permission control method and device provided by the present invention, in this framework, custom annotations play the role of a declarative interface of permission rules, allowing developers to embed permission requirements directly into interface methods in an intuitive and easy-to-understand manner. By using custom annotations to control user access interface permissions, not only can the security and manageability of the system be significantly improved, but also the high availability of services and the quality of user experience can be ensured. These annotations are dynamically intercepted and processed at runtime, and permission verification operations are performed through aspect programming technology, thereby ensuring the effectiveness and reliability of permission management. The user access interface permission control mechanism implemented through permission annotation definition and aspect programming interception technology not only improves the security and performance of the system, but also reduces development costs and maintenance difficulty. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The above and other objects, features, and advantages of the present invention will become more apparent through a more detailed description of the embodiments of the present invention in conjunction with the accompanying drawings. The accompanying drawings are provided to provide a further understanding of the embodiments of the present invention and constitute a part of the specification. Together with the embodiments of the present invention, they are used to explain the present invention and are not intended to limit the present invention. In the drawings, the same reference numerals generally represent the same components or steps.

[0016] Figure 1 It is a flowchart of an interface access authority control method provided by an exemplary embodiment of the present invention.

[0017] Figure 2 It is a structural diagram of an interface access authority control device provided by an exemplary embodiment of the present invention. DETAILED DESCRIPTION

[0018] Below, the exemplary embodiments according to the present invention will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all the embodiments of the present invention, and it should be understood that the present invention is not limited to the exemplary embodiments described herein.

[0019] In recent years, with the rapid development of information technology and the internet industry, particularly the widespread adoption of the internet and mobile internet, the scale and frequency of data interactions have grown exponentially. Interfaces serve as the core channel for data exchange between different systems, services, or modules. Their performance and stability directly impact the overall system's operational efficiency and user experience. However, in real-world applications, interfaces frequently face the following challenges: Traditional interface access control relies on simple identity authentication or static rules (such as IP restrictions), making it difficult to dynamically identify abnormal behavior, leading to legitimate users being mistakenly restricted or malicious requests bypassing protection. They also lack fine-grained traffic management mechanisms, making it impossible to dynamically adjust interface access quotas based on user priority, business needs, or system load, resulting in resource waste and disruption to critical services. Currently, common solutions in the industry include token bucket-based rate limiting, fixed-frequency request interception, or basic API key verification. However, these solutions often lack flexibility and scalability, making them inflexible and unsuitable for diverse business scenarios. For example, some solutions hard-code access control rules. Adjusting these rules requires code modifications and redeployment, which is cumbersome and inefficient. Although some solutions provide dynamic adjustment functions, they often require complex configuration and management of the system, increasing the difficulty of use and operation and maintenance costs.

[0020] In order to solve the problems existing in the prior art, this application proposes an interface access permission control method. Figure 1 FIG. 1 is a flow chart of an interface access permission control method provided by an exemplary embodiment of the present invention. Figure 1As shown, first, define the permission annotation (see Figure 1 S110); wherein, the permission annotation is used to determine the permission configuration, and the parameter form of the permission annotation includes the role identifier, permission code and organization. Secondly, the permission annotation is marked on the target interface method, and the association between the permission annotation and the target interface is completed to declare the access permission requirements of the target interface (see Figure 1 Then, the interface call request is intercepted through aspect programming, and the access permission status of the interface caller is analyzed (see Figure 1 Then, based on the user access permission status and permission annotation, the access user is checked for permission (see Figure 1 Finally, in response to the permission check being passed, the permission check result is returned to the interface caller to pass the interface call request (see Figure 1 S150).

[0021] In some embodiments of S110, permission annotations are defined, that is, custom annotations can be defined. Custom annotations serve as declarative interface roles for permission rules, allowing developers to embed permission requirements directly into interface methods in an intuitive and easy-to-understand manner. The parameter form of the permission annotation can include role identification, permission code, and organizational structure, and can provide personalized configuration options to meet the specific business logic and performance requirements of different interfaces. For example, for interfaces that require different permissions to access, different permission configurations can be defined in the form of annotation parameters. For example, if interface A only requires user permissions to access, then the developer only needs to specify user in the annotation parameter of interface A. Interface B requires admin permissions to access, then the developer can add admin to the annotation parameter of interface B. Whether it is setting user roles, permission levels, or defining complex permission logic, it can be achieved by modifying annotation properties or configuration files, without the need for extensive modifications to the business code, reducing development costs and maintenance difficulties.

[0022] As a possible implementation of S110, a custom annotation, @CheckTokenRole, serves as the core of interface access control, providing developers with flexibility in adjusting access permissions. The annotation can retrieve the user's token for parsing. By pre-setting default permission rules, such as advanced permissions like SUPERADMIN, developers can implement basic permission verification simply by adding annotations to methods. This interface permission access configuration method greatly simplifies the configuration process and increases the flexibility of interface permission control. This allows developers to quickly get started and apply it to multiple interfaces without having to perform tedious parameter settings one by one.

[0023] The token mentioned above is a dynamically generated credential containing permission information. It is typically issued by an authentication service (such as Auth0 or Keycloak) when a user logs in. It can contain dynamic data such as user roles, permission lists, and expiration dates. The token serves as a carrier of user identity and permissions and is passed to the API for verification at runtime.

[0024] In some embodiments of S120 , a permission annotation is declared on a target interface or an interface method to associate the interface with access permission logic to declare the access permission requirements of the interface.

[0025] As a possible implementation approach, to address the challenges posed by large-scale concurrent requests, Redis, a high-performance in-memory database, can be chosen as the backend storage. Redis not only offers excellent scalability and persistence, but its hash structure also greatly facilitates the storage and retrieval of user access interface permissions. The interface identifier, user ID, and access count are mapped to a key-value pair in Redis. The access count is stored as an atomically incrementable integer in Redis. When the interface is called, a corresponding counter value is created or updated in Redis using the key-value pair. When the counter value exceeds or equals a preset threshold, an alert is triggered, issuing a high-frequency access notification. Atomic operations ensure accurate incrementing of the request count, and user interface calls are recorded to monitor for malicious access attacks. In the permission implementation, the efficient storage and retrieval features of distributed storage systems (such as Redis) are leveraged to store and track user access permission status. This not only ensures the real-time and accuracy of permission status, but also enables consistency and synchronization across multiple instances, thereby ensuring the effectiveness and reliability of the permission management mechanism.

[0026] The interface identifier mentioned above is a statically declared permission type identifier in an annotation. It defines the permissions required by the interface. It is typically a string, enumeration value, or unique ID, determined during the coding phase and strongly related to the interface's functionality. The interface identifier serves as a benchmark for permission verification and is matched against the permission information provided by the user.

[0027] For example, a developer may annotate an interface, declaring that it requires the admin_read permission. A user accesses the interface with a token (such as a JWT). The annotation processor parses the token to extract a list of permissions (such as ["admin_read", "user_write"]). The processor matches the permissions in the token with the admin_read permission declared in the annotation. If the permission exists, access is allowed. The interface identifier is a static declaration in the annotation, while the token is a dynamic credential at runtime. The annotation processor must read both the annotated interface identifier and the permission data in the token to complete verification.

[0028] As a possible implementation method, a monitoring and alarm system can be set up to track the dynamic changes in the number of times different users access different interfaces in real time, dynamically observe the access volume of different interfaces, prevent excessively high-frequency calls to interfaces from putting pressure on the database, and automatically trigger early warnings when necessary to provide developers with timely decision-making support.

[0029] In order to achieve precise control of user interface access and automatic management of access times, in some embodiments, a preset lifetime can be set for each key-value pair; wherein the lifetime is determined based on the user access frequency or the user access rights; when the actual lifetime of the key-value pair is greater than the preset lifetime, the key-value pair is deleted to reset the user's access times to the preset number.

[0030] For example, by leveraging Redis's key expiration mechanism and setting a reasonable expiration time for each user access record, Redis can automatically delete the key when it expires, thereby automatically resetting the access count. Furthermore, sliding window and token bucket algorithms can be introduced to further improve the accuracy and flexibility of rate limiting. These algorithms not only dynamically adjust rate limiting strategies based on system load, but also effectively respond to sudden traffic shocks, ensuring stable system operation.

[0031] To ensure operational traceability, some implementations can include logging and monitoring mechanisms to record and monitor all successful and rejected requests, as well as any operations related to rate limiting and expiration. By monitoring key metrics like Redis performance and the number of API requests in real time, developers can quickly identify potential issues and take appropriate action to ensure the continued stability of the system.

[0032] In some embodiments of S130, a permission checking aspect system built based on aspect-oriented programming (AOP) technology implements dynamic interception and access control of interface methods through annotation-driven implementation. For example, Spring AOP or AspectJ framework is used as a technical foundation to implement unified permission checking logic for target methods marked with the @CheckTokenRole annotation.

[0033] Based on the combination of custom annotations and AOP technology, each interface can customize the time period and specific permission rules of access rights when declaring annotations. In addition to providing default permission rules and time periods in the aspect, it also supports personalized customization in each interface, thereby greatly improving the flexibility and applicability of custom annotations.

[0034] In some embodiments of S140, through a pre-notification mechanism, the aspect can quickly intervene before the target method is executed to verify the permissions carried by the current user token. Once it detects that the access rights do not meet the current interface requirements, the aspect will immediately initiate the corresponding processing strategy.

[0035] For example, access permission status includes static attributes, dynamic behavior, and environmental parameters. Based on these attributes, dynamic behavior, environmental parameters, and permission annotations, access permissions are verified. Static attributes include user role, user ID, and user organizational structure. Dynamic behavior can include historical access frequency, real-time geographic location, device fingerprints, and other parameters. Environmental parameters can include request time, IP segment, API version, and other parameters.

[0036] As a possible implementation method, if the custom annotation contains basic permission rules, the user static attributes are directly matched. For example, based on the role identifier in the permission annotation and the user role in the access permission status, the access user is verified for permission; based on the permission code in the permission annotation and the user ID in the access permission status, the access user is verified for permission; based on the organizational structure in the permission annotation and the user organizational structure in the access permission status, the access user is verified for permission.

[0037] As a possible implementation, if the annotation contains context-dependent fields, the corresponding field values ​​are extracted from the context for secondary validation. If the annotation specifies a dynamic policy, the policy service is called to calculate the authentication result. The returned authentication result can be an allow, which allows the request and logs the authentication, a deny, which returns a status code and reason for the denial, or a partial allow, which filters out unauthorized fields in the request parameters.

[0038] In some embodiments of S150, if the authentication is successful, the permission verification result is returned to the interface caller to control the access permission of the interface.

[0039] If authentication fails, that is, if permission verification fails, a permission verification result indicating that access is not permitted is returned to the user who initiated the interface call, along with the missing permission type. Clearly communicating insufficient permissions to the user and specifying the specific missing permission type ensures system stability and security while maintaining the user experience, achieving a balance between security and user experience.

[0040] As a possible way to handle authentication failure, we can first divide the types of access requests. Access requests include immediate response tasks and non-immediate response tasks. When the access request is an immediate response task, if the user permission check for access fails, the permission check result indicating that access is not allowed is returned to the user who initiated the interface call request, and the missing permission type and a preset status code are returned to inform the user that the client has insufficient permissions. For example, for scenarios that require an immediate response, such as real-time data acquisition, the request is directly rejected and the HTTP 429 status code is returned to clearly inform the client that the permissions are insufficient. When the access request is a non-immediate response task, access requests with insufficient permissions are stored based on the message queue mechanism, and the access request is processed when the system load is lower than the preset load threshold. For example, for non-immediate tasks, such as batch file downloads and data exports, the message queue mechanism is used to temporarily store requests with insufficient permissions and process them after the system load is reduced.

[0041] At the same time, for resource request processing, queue length and processing speed are dynamically adjusted based on the actual system load to ensure rational resource utilization and timely processing of requests. For messages that fail to be processed, a retry mechanism and failure handling strategy are combined to ensure that each request is properly handled.

[0042] For example, a three-level retry mechanism is set up for permission verification failures caused by network problems or temporary service unavailability. The first-level retry is a retry within the first preset time period after the permission verification fails, the second-level retry is a retry within the second preset time period after the permission verification fails, and the third-level retry is a retry within the third preset time period after the permission verification fails. The maximum value in the first preset time period is less than the minimum value in the second preset time period, and the maximum value in the second preset time period is less than the maximum value in the third preset time period. Before the first-level retry, the second-level retry, and the third-level retry, a permission policy is obtained once. The permission policy includes permission annotations, permission verification policies, and permission expiration conditions.

[0043] As a possible implementation method, a hierarchical retry strategy is established. For permission verification failures caused by temporary network problems or temporary service unavailability, the system will automatically retry and establish a three-level retry mechanism. The first level retry is an immediate retry (for example, 0-1 second), the second level retry is a short-delay retry (for example, 5 seconds), and the third level retry is a long-delay retry (for example, 1 minute). Before each retry, the latest permission policy will be retrieved to ensure that there is no verification deviation due to cache expiration. The retry period can be adjusted according to actual needs.

[0044] In some embodiments of failure processing, when the number of times the permission check of an access request fails is greater than the preset number of retries, the failure information of the access request is stored in a database; wherein the failure information includes the original request parameters, the reason for failure, the stack trace and the retry history.

[0045] For example, the dead letter queue (DLQ) mechanism for handling failures provides special processing for failed requests that exceed the maximum number of retries. Failure messages are persisted in dedicated storage (such as MySQL), containing complete context information such as the original request parameters, failure cause and stack trace, and retry history, to facilitate subsequent problem location and analysis.

[0046] Figure 2 FIG. 1 is a schematic diagram of a structure of an interface access permission control device provided by an exemplary embodiment of the present invention. Figure 2 As shown, the interface access permission control device 2 includes: a definition module 21, which is used to define permission annotations; wherein, the permission annotations are used to determine the permission configuration, and the parameter form of the permission annotations includes role identification, permission code and organizational structure; a marking module 22, which is used to mark the permission annotations on the target interface method, complete the association between the permission annotations and the target interface, and declare the access permission requirements of the target interface; a parsing module 23, which is used to intercept the interface call request through aspect programming and parse the access permission status of the interface caller; a verification module 24, which is used to perform permission verification on the accessing user based on the user access permission status and permission annotations; a notification module 25, which is used to return the permission verification result to the interface caller in response to the permission verification being passed, so as to pass the interface call request.

[0047] In one embodiment, the interface access permission control device 2 may also include: mapping the interface identifier, user ID and access count into a key-value pair in Redis; storing the access count as a value in Redis, and the data type of the value is an integer type that can be atomically incremented; when the interface is called, creating or updating the corresponding counter value in Redis through the key-value pair; when the counter value is greater than or equal to a preset threshold, triggering an early warning and issuing a high-frequency access prompt message.

[0048] In one embodiment, the interface access permission control device 2 may further include: setting a preset lifetime for each of the key-value pairs; wherein the lifetime is determined based on the user access frequency or the user access permission; when the actual lifetime of the key-value pair is greater than the preset lifetime, deleting the key-value pair to reset the user's access times to the preset times.

[0049] In one embodiment, the interface access permission control device 2 may further include: when the permission check fails, returning a permission check result indicating that access is not allowed to the user who initiated the interface call request, and returning the missing permission type.

[0050] In one embodiment, the access request includes an immediate response task and a non-immediate response task; the interface access permission control device 2 may also include: when the access request is the immediate response task, if the user permission check requesting access fails, returning a permission check result that does not allow access to the user who initiated the interface call request, and returning the missing permission type and a preset status code to inform the user that the client has insufficient permissions; when the access request is the non-immediate response task, based on the message queue mechanism, storing the access request with insufficient permissions, and processing the access request when the system load is lower than the preset load threshold.

[0051] In one embodiment, the interface access permission control device 2 may further include: setting a three-level retry mechanism for permission verification failure caused by network problems or temporary unavailability of service; wherein, the first level retry is a retry within a first preset time period after the permission verification fails, the second level retry is a retry within a second preset time period after the permission verification fails, and the third level retry is a retry within a third preset time period after the permission verification fails; the maximum value in the first preset time period is less than the minimum value in the second preset time period, and the maximum value in the second preset time period is less than the maximum value in the third preset time period; before the first level retry, the second level retry and the third level retry, a permission policy is obtained once; the permission policy includes a permission annotation, a permission verification policy and a permission expiration condition.

[0052] In one embodiment, the interface access permission control device 2 may further include: when the number of times the permission check of the access request fails is greater than the preset number of retries, the failure information of the access request is stored in a database; wherein the failure information includes the original request parameters, failure reasons, stack traces and retry history records.

[0053] In one embodiment, the access permission status includes: static attributes, dynamic behaviors and environmental parameters; wherein, the verification module 24 can be configured to: perform permission verification on the accessing user based on the static attributes, the dynamic behaviors, the environmental parameters and the permission annotations.

[0054] In one embodiment, the static attributes include: user role, user ID and user organizational structure; the verification module 24 can also be configured to: perform permission verification on the accessing user based on the role identifier in the permission annotation and the user role in the access permission status; perform permission verification on the accessing user based on the permission code in the permission annotation and the user ID in the access permission status; perform permission verification on the accessing user based on the organizational structure in the permission annotation and the user organizational structure in the access permission status.

[0055] An embodiment of the present invention provides an interface access permission control device. The device embodiment can be implemented through software, hardware, or a combination of software and hardware. From a hardware perspective, in addition to the CPU, memory, network interface, and non-volatile memory, the device in the embodiment may also generally include other hardware, such as a forwarding chip responsible for processing messages, etc. Taking software implementation as an example, as a device in a logical sense, it is formed by the CPU of the device in which it is located reading the corresponding computer program instructions in the non-volatile memory into the memory and running them.

[0056] According to another aspect of the present invention, a computer-readable storage medium is provided. The storage medium stores a computer program, and the computer program is used to execute the interface access authority control method of any of the above embodiments.

[0057] In addition to the above methods and devices, an embodiment of the present invention may also be a computer program product, which includes computer program instructions. When the computer program instructions are executed by a processor, the processor executes the steps in the interface access permission control method according to various embodiments of the present invention described above.

[0058] According to another aspect of the present invention, an electronic device is provided, comprising: a processor; a memory for storing processor-executable instructions; and the processor for executing the interface access permission control method of any of the above embodiments.

[0059] In addition, an embodiment of the present invention may also be a computer-readable storage medium having computer program instructions stored thereon. When the computer program instructions are executed by a processor, the processor executes the steps of the interface access permission control method according to various embodiments of the present invention described above.

[0060] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A method for controlling interface access rights, characterized in that: include: Define permission annotations; wherein, the permission annotations are used to determine permission configuration, and the parameter form of the permission annotations includes role identification, permission code and organization structure; Mark the target interface method with the permission annotation, and associate the permission annotation with the target interface to declare the access permission requirements of the target interface; Intercept interface call requests through aspect programming and analyze the access permission status of the interface caller; Performing permission verification on the accessing user based on the user access permission status and the permission annotation; In response to the permission check being passed, the permission check result is returned to the interface caller to approve the interface call request.

2. The interface access permission control method according to claim 1, characterized in that: The interface access permission control method also includes: Map the interface identifier, user ID, and access count into a key-value pair in Redis; The access count is stored as a value in Redis, where the data type of the value is an integer type that can be atomically incremented; When the interface is called, the corresponding counter value is created or updated in Redis through the key-value pair; When the counter value is greater than or equal to a preset threshold, an early warning is triggered and a high-frequency access prompt message is issued.

3. The interface access permission control method according to claim 2, characterized in that: The interface access permission control method also includes: Setting a preset expiration time for each key-value pair; wherein the expiration time is determined according to user access frequency or user access rights; When the actual lifetime of the key-value pair is greater than the preset lifetime, the key-value pair is deleted to reset the number of user visits to the preset number.

4. The interface access permission control method according to claim 1, characterized in that: The interface access permission control method also includes: When the permission check fails, the permission check result indicating that access is not allowed is returned to the user who initiated the interface call request, and the missing permission type is returned.

5. The interface access permission control method according to claim 4, characterized in that: Access requests include immediate response tasks and non-immediate response tasks; When the permission check fails, the permission check result indicating that access is not allowed is returned to the user who initiated the interface call request, and the missing permission type is returned, including: When the access request is the instant response task, if the user permission check of the access request fails, a permission check result indicating that access is not allowed is returned to the user who initiated the interface call request, and the missing permission type and a preset status code are returned to inform the user that the client has insufficient permissions; When the access request is the non-immediate response task, the access request with insufficient authority is stored based on a message queue mechanism, and the access request is processed when the system load is lower than a preset load threshold.

6. The interface access permission control method according to claim 4, characterized in that: The interface access permission control method also includes: For permission verification failures caused by network problems or temporary service unavailability, a three-level retry mechanism is set up; wherein, the first level retry is to retry within the first preset time period after permission verification failure, the second level retry is to retry within the second preset time period after permission verification failure, and the third level retry is to retry within the third preset time period after permission verification failure; The maximum value in the first preset time period is smaller than the minimum value in the second preset time period, and the maximum value in the second preset time period is smaller than the maximum value in the third preset time period; Before the first-level retry, the second-level retry, and the third-level retry, a permission policy is obtained once; the permission policy includes permission annotations, permission verification policies, and permission expiration conditions.

7. The interface access permission control method according to claim 6, characterized in that: The interface access permission control method also includes: When the number of times that the permission check of an access request fails is greater than the preset number of retries, the failure information of the access request is stored in a database; wherein the failure information includes the original request parameters, the failure reason, the stack trace and the retry history.

8. The interface access permission control method according to claim 1, characterized in that: The access rights status includes: static attributes, dynamic behaviors and environmental parameters; The method of performing permission verification on the accessing user based on the user access permission status and the permission annotation includes: Based on the static attributes, the dynamic behavior, the environmental parameters and the permission annotation, the permission of the accessing user is checked.

9. The interface access permission control method according to claim 8, characterized in that: The static attributes include: user role, user ID and user organizational structure; Performing permission verification on the accessing user based on the user access permission status and the permission annotation also includes: Performing permission verification on the accessing user based on the role identifier in the permission annotation and the user role in the access permission status; Performing permission verification on the accessing user based on the permission code in the permission annotation and the user ID in the access permission status; Based on the organizational structure in the permission annotation and the user organizational structure of the access permission status, the permission of the accessing user is verified.

10. An interface access permission control device, characterized in that: include: A definition module is used to define permission annotations; wherein the permission annotations are used to determine permission configuration, and the parameter form of the permission annotations includes role identification, permission code and organization structure; A marking module is used to mark the permission annotation on the target interface method, complete the association between the permission annotation and the target interface, and declare the access permission requirements of the target interface; The parsing module is used to intercept interface call requests through aspect programming and parse the access permission status of the interface caller; A verification module, configured to verify the access permissions of the user based on the user access permission status and the permission annotation; The notification module is used to return the permission verification result to the interface caller in response to the permission verification being passed, so as to approve the interface call request.

Images