Interface access processing method and device, equipment and medium

Abstract

The embodiment of the invention discloses an interface access processing method and device, equipment and a medium. The method comprises the following steps: when a user initiates an interface access request to a service, intercepting the interface access request through an interface permission verification interceptor, and determining whether user permission needs to be verified according to the interface access request; if yes, whether verification information of the user exists in a local permission cache or not is inquired; if the verification information for the user exists in the local permission cache, verifying the permission of the user according to the verification information in the permission cache; and if not, querying the database to obtain verification information for the user, and verifying the authority of the user according to the queried verification information. According to the scheme, the interface access performance and safety are optimized through a multi-level permission verification mechanism, the access throughput is improved while the permission verification accuracy is guaranteed through a cache mechanism, and the method is particularly suitable for a high-concurrency scene.

Description

Technical Field

[0001] This application relates to the field of interface access technology, and in particular to an interface access processing method, apparatus, device and medium. Background Technology

[0002] With the deepening of enterprise informatization and digital transformation, microservice architecture and distributed systems are widely used, leading to a significant increase in the frequency of interface calls. Permission verification has become one of the key bottlenecks in system performance. In high-concurrency scenarios, traditional permission verification solutions typically rely on real-time database queries or centralized permission services, resulting in increased interface response latency and decreased system throughput. Simultaneously, as business scale expands, permission rules become increasingly complex, posing a severe challenge to the storage and retrieval efficiency of permission data.

[0003] Traditional API permission management solutions, such as token-based access control (e.g., JWT), while stateless and suitable for distributed systems, suffer from difficulties in token revocation. Role-based access control (RBAC), while simple to manage, can lead to a surge in the number of roles in complex business scenarios, increasing management costs and creating database performance bottlenecks. API key + signature authentication offers high security but lacks user context and key management is complex. Fine-grained permission control, while precise, is complex to implement and can incur performance overhead. In high-frequency permission verification scenarios, these solutions often require frequent access to the database or centralized permission services, leading to system performance degradation. Summary of the Invention

[0004] This application provides an interface access processing method, apparatus, device, and medium to reduce redundant verification and improve the efficiency and security of access verification.

[0005] According to one aspect of this application, an interface access processing method is provided, the method comprising:

[0006] When a user initiates an interface access request to the service, the interface access request is intercepted by an interface permission verification interceptor, and it is determined whether user permission verification is required based on the interface access request.

[0007] If necessary, check the local permission cache to see if the user's verification information exists;

[0008] If the local permission cache contains verification information for the user, then the user's permissions are verified based on the verification information in the permission cache.

[0009] If it does not exist, the database is queried to obtain the verification information for the user, and the user's permissions are verified based on the queried verification information.

[0010] According to one aspect of this application, an interface access processing apparatus is provided, the apparatus comprising:

[0011] The interception module is used to intercept the interface access request when a user initiates an interface access request to the service through an interface permission verification interceptor, and determine whether user permission verification is required based on the interface access request.

[0012] The cache query module is used to query the local permission cache to see if the user's verification information exists, if necessary.

[0013] The verification module is used to verify the user's permissions based on the verification information in the local permission cache if such verification information exists in the local permission cache.

[0014] The database query module is used to query the database to obtain the verification information for the user if the information does not exist, and to verify the user's permissions based on the queried verification information.

[0015] According to another aspect of this application, an electronic device is provided, the electronic device comprising:

[0016] At least one processor; and,

[0017] A memory that is communicatively connected to at least one processor; wherein,

[0018] The memory stores a computer program that can be executed by at least one processor, such that the at least one processor is able to perform the interface access processing method of any embodiment of the present application.

[0019] According to another aspect of this application, a computer-readable storage medium is provided, which stores computer instructions for causing a processor to execute and implement the interface access processing method of any embodiment of this application.

[0020] According to another aspect of this application, a computer program product is provided, which includes a computer program that, when executed by a processor, implements the interface access processing method of any embodiment of this application.

[0021] The technical solution of this application embodiment intercepts the interface access request by a user when the user initiates an interface access request to the service. Based on the interface access request, it determines whether user permissions need to be verified. If so, it queries the local permission cache to see if the user's verification information exists. If the local permission cache contains the verification information for the user, it verifies the user's permissions based on the verification information in the permission cache. If not, it queries the database to obtain the verification information for the user and verifies the user's permissions based on the retrieved verification information. This solution optimizes interface access performance and security through a multi-level permission verification mechanism. The interface permission verification interceptor dynamically determines whether a request requires permission verification, avoiding redundant verification for all requests. When verification is required, the local permission cache is queried first, utilizing its millisecond-level response characteristic to reduce the time consumed by permission verification for high-frequency users. If the cache misses, it degrades to a database query, and the result is written to the local cache through a cache backfilling mechanism, accelerating subsequent requests. This layered strategy of "cache priority + database fallback" improves overall throughput while ensuring the accuracy of permission verification, making it suitable for high-concurrency scenarios. By unifying the management of permission logic through interceptors, code duplication is reduced, maintenance costs caused by fragmented permissions are lowered, and an efficient and scalable permission control solution is provided for microservice architectures.

[0022] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 A flowchart illustrating an interface access processing method provided in an embodiment of this application;

[0025] Figure 2 A flowchart illustrating an interface access processing method provided in another embodiment of this application;

[0026] Figure 3 This is a first schematic diagram of the new permission interface provided in another embodiment of this application;

[0027] Figure 4 This is a second schematic diagram of the newly added permission interface provided in another embodiment of this application;

[0028] Figure 5 This is a first schematic diagram of an interface for assigning permissions provided in another embodiment of this application;

[0029] Figure 6 This is a second schematic diagram of the permission allocation interface provided in another embodiment of this application;

[0030] Figure 7 A schematic diagram of an architecture provided for an embodiment of this application;

[0031] Figure 8 This is a schematic diagram of the structure of an interface access processing device provided in an embodiment of this application;

[0032] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0033] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0034] It should be noted that the terms "first," "second," "third," "fourth," "actual," "preset," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0035] The acquisition, storage, use, and processing of data in this application comply with relevant national laws and regulations. The acquired data is obtained with authorization and will not be disclosed without permission, used for illegal purposes, purposes detrimental to the interests of others, or for personalized analysis or product promotion. It should be noted that certain software, components, models, and other existing industry solutions may be mentioned in the embodiments of this application. These should be considered exemplary and intended only to illustrate the feasibility of implementing the technical solution of this application, but do not imply that the applicant has already used or necessarily used the relevant content of such solutions.

[0036] Figure 1 This is a flowchart illustrating an interface access processing method provided in an embodiment of this application. This embodiment is applicable to situations requiring verification processing of interface access. The method can be executed by an interface access processing device, which can be implemented in hardware and / or software and can be configured in an electronic device. Figure 1 As shown, the method includes:

[0037] S110. When a user initiates an interface access request to the service, the interface access request is intercepted by an interface permission verification interceptor, and it is determined whether user permissions need to be verified based on the interface access request.

[0038] An API access request is a request message initiated by a user to a service, with the purpose of instructing the service to perform a specific operation or return data. The API permission verification interceptor is used to intercept and verify user-initiated API access requests.

[0039] When a user initiates an interface access request to a service, the service may fully trust the user and grant unconditional access, or it may grant the user partial permissions, allowing access within the limitations of those permissions. In this embodiment, an interface permission verification interceptor is loaded upon service startup. If a user initiates an interface access request, the interface permission verification interceptor intercepts the user's request and determines whether permission verification is required based on the request. Specifically, the interceptor determines whether the user is fully trusted and can directly access the service, or whether permission verification is necessary. If the user is fully trusted and can directly access the service, access can be granted directly without further permission verification.

[0040] S120. If necessary, query the local permission cache to see if the user's verification information exists.

[0041] For example, if the interface permission verification interceptor determines that user permissions need to be verified, it first queries the local permission cache to determine if the user's verification information exists. This allows for quick access to the cache and a rapid response, enabling a preliminary retrieval of the user's verification information. The local permission cache only stores a portion of the user's verification information, typically caching verification information accessed within a recent period. Therefore, the local permission cache may or may not contain the user's verification information.

[0042] Specifically, the user's identifier can be matched with the identifiers of existing users in the local permission cache to determine whether there is an identifier of an existing user in the local permission cache that matches the user's identifier. If it exists, it is determined that the user's verification information exists in the local permission cache. If it does not exist, it is determined that the user's permission verification information does not exist in the local permission cache, and the user's verification information is stored in the database.

[0043] S130. If the local permission cache contains verification information for the user, then the user's permissions are verified according to the verification information in the permission cache.

[0044] For example, if user verification information exists in the local permission cache, the user's permissions are verified based on this information. This could involve determining whether the user has permission to access the service, and which functions within the service they are authorized to access, based on the verification information. Furthermore, the content the user needs to access is determined based on the interface access request initiated locally by the user, and the user's current access is verified against the permissions retrieved from the verification information to ensure it is within their authorized scope.

[0045] S140. If it does not exist, query the database to obtain the verification information for the user, and verify the user's permissions based on the queried verification information.

[0046] For example, since the verification information of all registered users is stored in the database, as long as a user has at least partial access rights, the corresponding verification information can definitely be retrieved from the database. If the user's verification information is not found in the local permission cache, the database is queried to retrieve the user's verification information and verify the user's permissions.

[0047] The technical solution of this application embodiment intercepts the interface access request by a user when the user initiates an interface access request to the service. Based on the interface access request, it determines whether user permissions need to be verified. If so, it queries the local permission cache to see if the user's verification information exists. If the local permission cache contains the verification information for the user, it verifies the user's permissions based on the verification information in the permission cache. If not, it queries the database to obtain the verification information for the user and verifies the user's permissions based on the retrieved verification information. This solution optimizes interface access performance and security through a multi-level permission verification mechanism. The interface permission verification interceptor dynamically determines whether a request requires permission verification, avoiding redundant verification for all requests. When verification is required, the local permission cache is queried first, utilizing its millisecond-level response characteristic to reduce the time consumed by permission verification for high-frequency users. If the cache misses, it degrades to a database query, and the result is written to the local cache through a cache backfilling mechanism, accelerating subsequent requests. This layered strategy of "cache priority + database fallback" improves overall throughput while ensuring the accuracy of permission verification, making it suitable for high-concurrency scenarios. By unifying the management of permission logic through interceptors, code duplication is reduced, maintenance costs caused by fragmented permissions are lowered, and an efficient and scalable permission control solution is provided for microservice architectures.

[0048] Figure 2 This is a flowchart illustrating an interface access processing method according to another embodiment of this application. This embodiment is an optimization based on the above embodiment; solutions not described in detail in this embodiment are found in the above embodiment. Figure 2 As shown, the method in this embodiment of the application specifically includes the following steps:

[0049] S210. When a user initiates an interface access request to the service, the interface access request is intercepted by an interface permission verification interceptor.

[0050] S220. The interface access request is parsed to determine the interface parameters and access content to be accessed.

[0051] For example, after the interface access request is intercepted by the interface permission verification interceptor, the interface access request can be parsed to determine the interface parameters and access content to be accessed. The interface parameters are used to specify which interface is being accessed, and the access content is used to determine the specific content, functional modules, information, etc. to be accessed for that interface.

[0052] S230. If it is determined from the interface parameters that the interface requested by the user is an open interface and the content accessed by the user is open content, then it is determined that no user permission verification is required.

[0053] For example, if the interface parameters determine that the user's requested interface is an open interface—meaning it's accessible to any user—and the content the user accesses is also open (meaning it doesn't involve security issues and is allowed to be accessed by any user), then it's determined that no permission verification is needed for the user. The user can then have unrestricted access to the interface and its content. In this case, there's no need to query the local permission cache or database to determine the user's verification information, thus reducing redundant and unnecessary verification processes.

[0054] S240. If it is determined from the interface parameters that the interface requested by the user is not an open interface, or the content accessed by the user is not open content, then it is determined that the user's permissions need to be verified.

[0055] For example, if the interface parameters determine that the interface requested by the user is not an open interface, but requires the user to have access permissions to access it, and that an interface cannot be accessed without access permissions, or if the content the user requests is not open content, and the user can only access it if the user has access permissions to the content, and is not allowed to access it if the user does not have access permissions to the content, then it is necessary to verify the user's permissions to determine whether the user has permission to access the requested interface and permission to access the requested content.

[0056] S250. If necessary, query the local permission cache to see if the user's verification information exists.

[0057] S260. If the local permission cache contains verification information for the user, then the user's permissions are verified according to the verification information in the permission cache.

[0058] S270. If it does not exist, query the database to obtain the verification information for the user, and verify the user's permissions based on the queried verification information.

[0059] The solution in this embodiment parses the interface access request to determine the interface parameters and access content. If the interface parameters indicate that the requested interface is an open interface and the accessed content is open content, then user permission verification is not required. If the interface parameters indicate that the requested interface is not an open interface or the accessed content is not open content, then user permission verification is required. The system automatically extracts interface parameters and access content by parsing the URL, request headers, and request body of the HTTP request. Combined with a predefined open interface whitelist and public content policy, it achieves millisecond-level prediction of permission requirements. For example, for requests to public APIs and public data, the system skips permission verification, improving response speed and reducing redundant computing resource consumption. For non-open interfaces or restricted content, the system automatically triggers a permission verification process. This mechanism can intercept unauthorized access requests, effectively preventing data leakage and unauthorized operations. Real-time logging and anomaly alerts also improve the speed of security event response. By reducing unnecessary permission verification steps, the system significantly improves user experience while ensuring security.

[0060] As a non-limiting implementation, the method also includes:

[0061] The response time for verifying the user's permissions is detected;

[0062] If the response time exceeds the preset response time, the cache space of the permission cache will be expanded.

[0063] After expanding the cache space, a preset amount of verification information is extracted from the database and added to the local permission cache.

[0064] In this embodiment, the response time can be monitored during each query of the local permission cache, or during the process of querying the local permission cache and then querying the database to verify user permissions. This means the time from querying the local permission cache to retrieving the user's verification information. A preset response time can be set to reflect the longest acceptable response time for the user. If the response time exceeds the preset response time, i.e., the response time is too long, it does not meet the user's requirements. Generally, access to the local permission cache is faster than access to the database. Therefore, the permission information in the local permission cache can be adaptively increased, allowing more user verification information to be obtained by querying the local permission cache, thus improving response speed. The permission cache space can be expanded. After expanding the cache space, a preset amount of verification information is extracted from the database and added to the local permission cache. In this case, the local permission cache contains more user verification information, which can be obtained by querying the local permission cache, reducing database access queries and thus improving response speed.

[0065] The aforementioned solution achieves a dual improvement in permission verification efficiency and system stability by monitoring permission verification response time in real time and dynamically optimizing caching strategies. By tracking the time consumed at each stage of permission verification through event tracking, when the response time exceeds a preset threshold, a cache expansion mechanism is automatically triggered. This expands the local permission cache space as needed and preloads frequently accessed verification information from the database into the expanded cache. This dynamic optimization process increases the hit rate of subsequent permission verification requests, shortens the average response time, and reduces the real-time query pressure on the database through the preloading mechanism, avoiding the risk of system avalanche due to cache breakdown in high-concurrency scenarios. Furthermore, the solution supports automatic adjustment of cache capacity and preloading amount based on business load without manual intervention, reducing operational complexity while ensuring the real-time performance and reliability of permission verification, providing a flexible and scalable permission management solution for microservice architectures.

[0066] As a non-limiting implementation, a preset amount of verification information is extracted from the database and added to the local permission cache, including:

[0067] For the verification information in the database, count the number of times the verification information is hit during the process of verifying the permissions of the user who initiated the access within the most recent historical time period.

[0068] Select the preset amount of verification information with the most hits and add it to the local permission cache.

[0069] In this embodiment, during the process of expanding the local permission cache space and transferring user verification information from the database to the permission cache, the specific user verification information to be transferred can be adaptively selected based on historical information. Specifically, the most recent historical time period can be determined, and the number of times each verification information in the database is hit during the permission verification process for the user initiating the access within that historical time period can be counted. This reflects the number of times the verification information corresponding to that verification information initiates interface access within the historical time period, and thus the number of times that verification information is queried for permission verification. A preset amount of verification information with the highest hit count can be added to the local permission cache. The cache space occupied by this preset amount of verification information must be less than or equal to the increase in cache space due to expanding the permission cache space. Since the verification information added to the local permission cache is the verification information with the highest hit count within the historical time period, it can be predicted that the number of queries using this part of the verification information will also be relatively high in future time periods. Therefore, adding this part of the verification information to the local permission cache is a reliable indicator. In subsequent queries of the local permission cache to retrieve verification information, a larger amount of verification information can be used to improve the recall rate, thereby reducing database access and improving response time.

[0070] The above solution significantly improves the efficiency and resource utilization of system permission verification by intelligently analyzing historical access data and dynamically optimizing permission caching strategies. It statistically analyzes the number of times each user's permission verification information is hit in the database within a recent time period, accurately identifying frequently accessed verification data. The solution proactively preloads a preset amount of verification information with the highest hit count into the local permission cache, increasing the cache hit rate of subsequent permission verification requests and shortening the average response time. This data-driven approach avoids resource waste caused by blind caching and reduces real-time database query pressure, thus lowering database load in high-concurrency scenarios.

[0071] As a non-limiting implementation, the method also includes:

[0072] For the correspondence between registered users and verification information in the permission cache, count the number of times this correspondence is matched and the time of the match during the permission verification process for the user initiating the access within the most recent historical time period.

[0073] The hit score for this correspondence is determined based on the number of hits and the hit time.

[0074] The corresponding relationships in the permission cache are sorted in descending order of their hit scores.

[0075] For example, in the permission cache, registered users and their verification information are stored in a corresponding manner. For each correspondence, the number of times the correspondence is hit and the hit time can be counted during the permission verification process for the user initiating the access within a historical time period. For example, for registered user A and verification information a, and registered user B and verification information b, if the user initiating the access matches registered user A within a historical time period, meaning that the user's permissions need to be verified based on verification information a, then the correspondence between registered user A and verification information a is hit once, and the hit time is recorded. The number of hits reflects how often the correspondence is used, and the hit time reflects how long ago the event of using the correspondence occurred. The hit score of the correspondence can be determined based on the number of hits and the hit time. The permissions cache is sorted in descending order of the hit scores of each relation. This means that the positions of the relations in the permissions cache are reorganized so that frequently hit and recently hit relations are moved forward, and infrequently hit or recently unhit relations are moved backward. This speeds up the retrieval process in subsequent searches based on the most frequently used relations, allowing for faster retrieval of results based on the most frequently used relations.

[0076] The above solution achieves highly efficient optimization of permission verification by statistically analyzing the number of hits and time intervals of the correspondence between registered users and verification information in the permission cache within the most recent historical time period, calculating dynamic hit scores, and sorting them. It accurately identifies frequently accessed user permission combinations, significantly improving cache hit rate and reducing real-time database queries; the time-decay-based scoring mechanism ensures the timeliness of results and avoids interference from outdated data; and prioritizing high-value cached items after descending sorting accelerates the permission verification process, reduces system latency, and provides data basis for resource allocation, enhancing overall security and response speed.

[0077] As a non-limiting implementation, querying the local permission cache to see if the user's verification information exists includes:

[0078] The mapping relationship between registered users and verification information in the local permission cache is traversed in reverse order to check whether the user's verification information exists in the local permission cache.

[0079] For example, during the process of querying the permission cache, the correspondence between registered users and verification information in the local permission cache is traversed in a forward order. During the traversal, the user representation of the user initiating the access is matched with the user representation of the currently traversed registered user. If the match is successful, the verification information of the registered user is extracted and used to verify the permissions of the currently initiating user.

[0080] In the case of sorting by hit score in descending order, the test information that is used more frequently and recently is listed first. Traversing from front to back can quickly traverse the most likely matching relationships, thus improving retrieval efficiency.

[0081] As a non-limiting implementation, determining the hit score of the correspondence based on the number of hits and the hit time includes:

[0082] The time decay parameter is determined based on the hit time and the current time;

[0083] The product of the number of hits and the time decay parameter is used as the hit score of the corresponding relationship;

[0084] Determining the time decay parameter based on the hit time and the current time includes:

[0085] Determine the time difference between the hit time and the current time;

[0086] Substituting the negative value of the time difference into the natural exponential function yields the time decay parameter.

[0087] In this embodiment of the application, the process of determining the hit score based on the number of hits and the hit time can specifically involve determining a time decay parameter based on the hit time and the current time. This can be achieved by calculating the time difference between the hit time and the current time, and the decay parameter should be negatively correlated with the time difference. Specifically, this can be expressed as follows: .in, The time difference is used as the basis for the hit score. The product of the number of hits and the time decay parameter can be used as the corresponding hit score. In other words, the hit score should be positively correlated with the number of hits.

[0088] The above-mentioned solution dynamically adjusts the permission cache score through a time decay parameter. It quantifies the timeliness of permission access using a time decay factor, ensuring that frequently accessed permission combinations receive higher weights, making the cache sorting more closely match actual user usage patterns. By calculating the score through the product of the hit count and time decay, it retains the characteristics of high-frequency access while avoiding interference from historical data, significantly improving the hit efficiency and query speed of the permission cache. Ultimately, it achieves intelligent resource allocation, reduces database query pressure, enhances system responsiveness, and provides stable and efficient permission verification support for high-concurrency scenarios.

[0089] In this application embodiment, a specific implementation method for adding new interface permission resources and assigning interface permissions to users is also provided, specifically as follows:

[0090] Add new interface permission resources:

[0091] Log in to the system and go to System Management – ​​Permission Management – ​​System Application Management. In the application tree on the left, select the application module for which you need to isolate interface permissions.

[0092] like Figure 3 As shown, in the "Add Sub-resource" button in the application resource list on the right: select "Add Sub-resource Request" (it is recommended to select the menu containing the request before adding the sub-resource request). Enter the relevant information in the form box: "Request Name" is defined by your business logic, "Request Code" is the full path of the method to which the intercepting interface belongs, and "Authorization Required" is selected as "Yes". Click the "Save" button to complete the addition. Figure 4 As shown.

[0093] Assign interface permissions to users:

[0094] Go to System Management – ​​Permission Management – ​​Role Management, and add users who need authorized interface permissions within the roles. For example... Figure 5 As shown.

[0095] Go to System Management – ​​Access Control – Role Management, and associate the requested resources that require authorization with the roles. For example... Figure 6 As shown.

[0096] Figure 7 An architecture diagram for interface access permission verification is provided, and the specific process is as follows:

[0097] When the service starts, an interface permission verification interceptor is loaded. Whenever a user initiates a request to the service, the interceptor first determines whether the current URL's interface needs to be intercepted based on the interception path. If not, the request is allowed and the result is returned directly. If so, the full path of the current method is obtained through reflection and used as an encoded parameter to initiate a remote permission verification to the server. Then, the system first checks if there is a permission verification result in the cache. If so, it returns the result directly. If not, it queries the database to check if the user has the permissions for the requested resource, and caches the result back to Redis with a reasonable expiration time. Subsequent identical requests prioritize retrieving the interface permission verification result from Redis to avoid repeated database queries. If the cache expires, a database query is automatically triggered to update the cache, balancing performance and real-time requirements.

[0098] Figure 8 This is a schematic diagram of an interface access processing device provided in an embodiment of this application. This device can execute the interface access processing method provided in any embodiment of this application, and has corresponding functional modules and beneficial effects for executing the method. For example... Figure 8 As shown, the device includes:

[0099] The interception module 310 is used to intercept the interface access request by the interface permission verification interceptor when the user initiates an interface access request to the service, and determine whether the user's permission needs to be verified based on the interface access request.

[0100] The cache query module 320 is used to query the local permission cache to see if the user's verification information exists if needed.

[0101] The verification module 330 is used to verify the user's permissions based on the verification information in the local permission cache if verification information for the user exists in the local permission cache.

[0102] The database query module 340 is used to query the database to obtain the verification information for the user if the information does not exist, and to verify the user's permissions based on the queried verification information.

[0103] In this embodiment of the application, the interception module 310 determines whether user permissions need to be verified based on the interface access request, including:

[0104] The interface access request is parsed to determine the interface parameters and access content to be accessed.

[0105] If, based on the interface parameters, it is determined that the interface requested by the user is an open interface, and the content accessed by the user is open content, then it is determined that no user permission verification is required.

[0106] If, based on the interface parameters, it is determined that the interface requested by the user is not an open interface, or the content accessed by the user is not open content, then it is determined that user permissions need to be verified.

[0107] In this embodiment of the application, the device further includes an expansion module, used for:

[0108] The response time for verifying the user's permissions is detected;

[0109] If the response time exceeds the preset response time, the cache space of the permission cache will be expanded.

[0110] After expanding the cache space, a preset amount of verification information is extracted from the database and added to the local permission cache.

[0111] In this embodiment, the expansion module extracts a preset amount of verification information from the database and adds it to the local permission cache, including:

[0112] For the verification information in the database, count the number of times the verification information is hit during the process of verifying the permissions of the user who initiated the access within the most recent historical time period.

[0113] Select the preset amount of verification information with the most hits and add it to the local permission cache.

[0114] In this embodiment of the application, the apparatus further includes a sorting module, used for:

[0115] For the correspondence between registered users and verification information in the permission cache, count the number of times this correspondence is matched and the time of the match during the permission verification process for the user initiating the access within the most recent historical time period.

[0116] The hit score for this correspondence is determined based on the number of hits and the hit time.

[0117] The corresponding relationships in the permission cache are sorted in descending order of their hit scores.

[0118] In this embodiment of the application, the sorting module queries whether the user's verification information exists in the local permission cache, including:

[0119] The mapping relationship between registered users and verification information in the local permission cache is traversed in reverse order to check whether the user's verification information exists in the local permission cache.

[0120] In this embodiment of the application, the sorting module determines the hit score of the corresponding relationship based on the number of hits and the hit time, including:

[0121] The time decay parameter is determined based on the hit time and the current time;

[0122] The product of the number of hits and the time decay parameter is used as the hit score of the corresponding relationship;

[0123] Determining the time decay parameter based on the hit time and the current time includes:

[0124] Determine the time difference between the hit time and the current time;

[0125] Substituting the negative value of the time difference into the natural exponential function yields the time decay parameter.

[0126] The interface access processing apparatus provided in this application embodiment can execute an interface access processing method provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects of executing the method.

[0127] Figure 9A schematic diagram of an electronic device 10, which can be used to implement embodiments of this application, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein.

[0128] like Figure 9 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0129] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0130] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as interface access processing methods.

[0131] In some embodiments, the interface access processing method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or mounted on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the interface access processing method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the interface access processing method by any other suitable means (e.g., by means of firmware).

[0132] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0133] Computer programs used to implement the methods of this application may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable interface access processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0134] In the context of this application, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium can be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0135] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0136] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0137] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0138] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the interface access processing method provided in any embodiment of this application.

[0139] In implementing the computer program product, computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0140] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired information of the technical solution of this application can be achieved, and this is not limited herein.

[0141] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. An interface access processing method, characterized in that, The method includes: When a user initiates an interface access request to the service, the interface access request is intercepted by an interface permission verification interceptor, and it is determined whether user permission verification is required based on the interface access request. If necessary, check the local permission cache to see if the user's verification information exists; If the local permission cache contains verification information for the user, then the user's permissions are verified based on the verification information in the permission cache. If it does not exist, the database is queried to obtain the verification information for the user, and the user's permissions are verified based on the queried verification information.

2. The method according to claim 1, characterized in that, Determining whether user permissions need to be verified based on the interface access request includes: The interface access request is parsed to determine the interface parameters and access content to be accessed. If, based on the interface parameters, it is determined that the interface requested by the user is an open interface, and the content accessed by the user is open content, then it is determined that no user permission verification is required. If, based on the interface parameters, it is determined that the interface requested by the user is not an open interface, or the content accessed by the user is not open content, then it is determined that user permissions need to be verified.

3. The method according to claim 1, characterized in that, The method further includes: The response time for verifying the user's permissions is detected; If the response time exceeds the preset response time, the cache space of the permission cache will be expanded. After expanding the cache space, a preset amount of verification information is extracted from the database and added to the local permission cache.

4. The method according to claim 3, characterized in that, Extract a preset amount of verification information from the database and add it to the local permission cache, including: For the verification information in the database, count the number of times the verification information is hit during the process of verifying the permissions of the user who initiated the access within the most recent historical time period. Select the preset amount of verification information with the most hits and add it to the local permission cache.

5. The method according to claim 1, characterized in that, The method further includes: For the correspondence between registered users and verification information in the permission cache, count the number of times this correspondence is matched and the time of the match during the permission verification process for the user initiating the access within the most recent historical time period. The hit score for this correspondence is determined based on the number of hits and the hit time. The corresponding relationships in the permission cache are sorted in descending order of their hit scores.

6. The method according to claim 5, characterized in that, Check if the user's verification information exists in the local permission cache, including: The mapping relationship between registered users and verification information in the local permission cache is traversed in reverse order to check whether the user's verification information exists in the local permission cache.

7. The method according to claim 5, characterized in that, The hit score for this correspondence is determined based on the number of hits and the hit time, including: The time decay parameter is determined based on the hit time and the current time; The product of the number of hits and the time decay parameter is used as the hit score of the corresponding relationship; Determining the time decay parameter based on the hit time and the current time includes: Determine the time difference between the hit time and the current time; Substituting the negative value of the time difference into the natural exponential function yields the time decay parameter.

8. An interface access processing apparatus, characterized in that, The interface access processing device includes: The interception module is used to intercept the interface access request when a user initiates an interface access request to the service through an interface permission verification interceptor, and determine whether user permission verification is required based on the interface access request. The cache query module is used to query the local permission cache to see if the user's verification information exists, if necessary. The verification module is used to verify the user's permissions based on the verification information in the local permission cache if such verification information exists in the local permission cache. The database query module is used to query the database to obtain the verification information for the user if the information does not exist, and to verify the user's permissions based on the queried verification information.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the interface access processing method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the interface access processing method according to any one of claims 1-7.

Images