Dynamic verification method and device for interface permission

Abstract

The embodiment of the invention provides an interface permission dynamic verification method and device, and the method comprises the steps: determining a target service interface which is used for executing a call request and comprises a predefined permission annotation through the call request, and carrying out the verification of the target permission before the target service interface executes a request service corresponding to the call request; intercepting calling of the target service interface through the permission verification aspect; acquiring a user identity and a client type, querying a corresponding interface permission set in a server memory, and matching the permission identifier with the interface permission set to determine a permission state corresponding to the current calling request; and under the condition that the permission state is an authorized state, enabling the permission verification aspect to release the calling request and execute the calling request according to the target service interface to obtain an execution result, and returning the execution result to the client. According to the method, the defect that permission isolation is difficult to realize according to different client types is effectively overcome, and the convenience and the flexibility of permission vertical management of multiple client types are remarkably improved.

Description

Technical Field

[0001] This application relates to the field of network security technology, specifically to a method and apparatus for dynamic verification of interface permissions. Background Technology

[0002] Software application systems need to provide services to various types of clients, such as browsers, desktops, mobile applications, and mini-programs.

[0003] In existing technologies, conditional statements can be inserted into the method body of each business interface to query the current user's role or permissions and compare them with the permissions required by the current business interface. Alternatively, unified permission verification can be performed through filters or interceptors, that is, the verification logic can be extracted from the business method of the target interface.

[0004] However, inserting conditional statements into the method body can easily lead to a high degree of coupling between permission verification logic and business logic. Repeatedly writing similar business interfaces generates a lot of code redundancy. When the permission policy needs to be adjusted, the maintenance cost is high and errors are easy to occur. Using filters or interceptors for unified interception makes it difficult to accurately obtain the metadata information of the business interface and cannot support fine-grained permission control. This makes it difficult to perform differentiated management and fine-grained control of the permissions of the same user on different clients in actual business scenarios. Summary of the Invention

[0005] To address the problems in the existing technology, this application provides a method and apparatus for dynamic verification of interface permissions, which can effectively solve the shortcomings of traditional technologies such as insufficient verification granularity and inability to adapt to the differentiated permission requirements in multi-client scenarios, and significantly improve the fineness of permission granularity and the convenience of multi-client permission management in multi-client scenarios.

[0006] To solve at least one of the above problems, this application provides the following technical solution: Firstly, this application provides a method for dynamic verification of interface permissions, including: Receive a call request sent by the client, respond to the call request, determine the target business interface with predefined permission annotations to execute the call request, and intercept the call to the target business interface through the permission verification aspect before the target business interface executes the request business corresponding to the call request. The predefined permission annotations include permission annotation type and permission identifier. The permission verification aspect obtains the user identity and client type from the context of the session corresponding to the call request. Based on the user identity and client type, it queries the corresponding interface permission set in the server memory, matches the permission identifier and the interface permission set to obtain the matching result, and determines the permission status corresponding to the current call request based on the matching result. The permission status includes authorized status and unauthorized status. When the permission status is authorized, the permission verification aspect allows the call request to be passed and executes the call request according to the target business interface, obtains the execution result, and returns the execution result to the client.

[0007] Furthermore, it also includes: when the permission annotation type includes a single permission identifier, or when the permission annotation type includes multiple permission identifiers and the logical operator between the multiple permission identifiers is AND, matching all permission identifiers and the interface permission set to obtain the matching result; If the matching result shows that all permission identifiers exist in the interface permission set, the permission status corresponding to the current call request is determined to be authorized. If the matching result is that at least one permission identifier does not exist in the interface permission set, the permission status corresponding to the current call request is determined to be unauthorized.

[0008] Furthermore, it also includes: when the permission annotation type includes multiple permission identifiers and the logical operator between the multiple permission identifiers is OR, matching each permission identifier and the interface permission set to obtain the matching result; If the matching result shows that at least one permission identifier exists in the interface permission set, the permission status corresponding to the current call request is determined to be an authorized status; If the matching result shows that none of the permission identifiers exist in the interface permission set, the permission status corresponding to the current call request is determined to be unauthorized.

[0009] Furthermore, after determining the permission status corresponding to the current call request based on the matching results, it also includes: When the permission status is unauthorized, the permission verification aspect throws the corresponding permission exception status and blocks the execution of the call request; The system captures permission exception states through a global exception handler, which then generates an exception message based on the captured exception state and returns it to the client. Unauthorized access records are asynchronously generated based on the permission exception state and stored in the database. The unauthorized access record includes the user identity, client type, interface path corresponding to the target business interface, permission identifier, and timestamp of the call request.

[0010] Furthermore, it also includes the following steps: obtaining the method signature information of the target business interface through the preset join point in the permission verification aspect, parsing the method signature information to obtain the predefined permission annotation of the target business interface, and performing the matching of permission identifier and interface permission set to obtain the matching result; By using permission verification aspects, all public methods with preset annotations are intercepted to block calls to the target business interface.

[0011] Furthermore, before intercepting calls to the target business interface through the permission verification aspect, it also includes: Obtain the long-connection status information of the current client user from the context of the current session. If the long-connection status information is active, execute the step of intercepting the call to the target business interface. If the long-lived connection status information is inactive, a prompt message is sent to the client and the processing of the call request is terminated. The prompt message is used to indicate to the client that the current session status is invalid or abnormal.

[0012] Secondly, this application provides an interface permission dynamic verification device, comprising: The processing module is used to receive the call request sent by the client, respond to the call request, determine the target business interface with predefined permission annotations to execute the call request, and intercept the call to the target business interface through the permission verification aspect before the target business interface executes the request business corresponding to the call request. The predefined permission annotations include permission annotation type and permission identifier. The matching module is used to obtain the user identity and client type from the context of the session corresponding to the call request through the permission verification aspect. Based on the user identity and client type, it queries the corresponding interface permission set in the server memory, matches the permission identifier and the interface permission set to obtain the matching result, and determines the permission status corresponding to the current call request based on the matching result. The permission status includes authorized status and unauthorized status. The execution module is used to enable the permission verification aspect to allow the call request when the permission status is authorized, execute the call request according to the target business interface, obtain the execution result, and return the execution result to the client.

[0013] Thirdly, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the interface permission dynamic verification method.

[0014] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the aforementioned dynamic interface permission verification method.

[0015] Fifthly, this application provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the aforementioned dynamic interface permission verification method.

[0016] As can be seen from the above technical solution, this application provides a method and apparatus for dynamic verification of interface permissions. It innovatively receives a call request sent by a client, responds to the call request, determines the target business interface with predefined permission annotations for executing the call request, and intercepts the call to the target business interface through a permission verification aspect before the target business interface executes the request business corresponding to the call request. The predefined permission annotations include permission annotation type and permission identifier. The permission verification aspect obtains the user identity and client type from the context of the session corresponding to the call request, queries the corresponding interface permission set in the server memory based on the user identity and client type, matches the permission identifier and the interface permission set to obtain a matching result, and determines the permission status corresponding to the current call request based on the matching result. The permission status includes authorized status and unauthorized status. If the permission status is authorized, the permission verification aspect allows the call request to proceed and executes the call request according to the target business interface, obtaining the execution result, and returning the execution result to the client. By using predefined permission annotations, access permission requirements for business interfaces are decoupled from business code in the form of declarative metadata. Through AOP aspects, accurate interception and permission verification are performed before the execution of methods in the target business interface, preventing vertical privilege escalation vulnerabilities. Thus, the combination of predefined permission annotations and AOP aspects constructs an efficient, accurate, secure, and easily maintainable dynamic interface permission verification method. This method effectively addresses the shortcomings of traditional technologies, such as insufficient granularity of verification and inability to adapt to differentiated permission requirements in multi-client scenarios, significantly improving the fineness of permission granularity and the ease of management in multi-client scenarios. Attached Figure Description

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

[0018] Figure 1 This is a flowchart illustrating the dynamic interface permission verification method in the embodiments of this application; Figure 2 A schematic diagram of the interface permission dynamic verification system provided in the embodiments of this application; Figure 3 This is a flowchart illustrating another dynamic interface permission verification method in an embodiment of this application. Figure 4 This is a structural diagram of the interface permission dynamic verification device in the embodiments of this application; Figure 5 This is a schematic diagram of the structure of the electronic device in the embodiments of this application.

[0019] Figure label: Electronic device 9600, central processing unit 9100, memory 9140, communication module 9110, input unit 9120, audio processor 9130, display 9160, power supply 9170, buffer memory 9141, application / function storage unit 9142, data storage unit 9143, driver storage unit 9144, antenna 9111, speaker 9131, microphone 9132. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] The acquisition, storage, use, and processing of data in this application comply with relevant laws and regulations.

[0022] To effectively address the shortcomings of traditional technologies, such as insufficient granularity of verification and inability to adapt to differentiated permission requirements in multi-client scenarios, and to significantly improve the granularity of permissions and the ease of management in multi-client scenarios, this application provides an embodiment of a dynamic interface permission verification method. See [link to embodiment]. Figure 1 The interface permission dynamic verification method specifically includes the following: Step S101: Receive the call request sent by the client, respond to the call request, determine the target business interface with predefined permission annotations to be used to execute the call request, and intercept the call to the target business interface through the permission verification aspect before the target business interface executes the request business corresponding to the call request.

[0023] Among them, the predefined permission annotations include permission annotation types and permission identifiers.

[0024] Optionally, this embodiment receives a call request sent by the client, identifies and locates the target business interface for processing the call request based on the call request, wherein the target business interface includes predefined permission annotations, the predefined permission annotations include permission annotation type and permission identifier, the predefined permission annotations can be regarded as security labels affixed to each target business interface, which can clearly indicate the permission requirements to be met when calling the target business interface, the predefined permission annotations can be defined on the method of the target business interface in the form of metadata, and user identity is used to identify user identity information, such as user ID.

[0025] In addition, before the target business interface executes the request corresponding to the call request, the call to the target business interface is intercepted by the permission verification aspect. The interception of the permission verification aspect occurs before the business code of the target business interface runs, thus forming a secure verification barrier. The permission verification aspect is a dedicated component based on aspect-oriented programming, used to insert permission verification logic at specific execution points.

[0026] Furthermore, calls to the target business interface can be intercepted through a priority interception chain, allowing multiple permission verification aspects to be executed in a predetermined order. Additionally, an annotation inheritance mechanism can be added, allowing subclasses to automatically inherit the permission annotation configuration of the parent interface or parent class.

[0027] This embodiment implements a pre-interception mechanism for the target business interface, which prevents unauthorized call requests from accessing core business resources, providing a security protection network. The annotation-based configuration method of the target business interface can decouple the security policy from the business implementation logic, so that permission adjustments no longer depend on code modifications, reducing maintenance complexity and risk.

[0028] Step S102: Obtain the user identity and client type from the context of the session corresponding to the call request through the permission verification aspect. Based on the user identity and client type, query the corresponding interface permission set in the server memory, match the permission identifier and the interface permission set to obtain the matching result, and determine the permission status corresponding to the current call request based on the matching result.

[0029] The permission status includes authorized status and unauthorized status.

[0030] Optionally, in this embodiment, after successfully intercepting a request, the permission verification aspect obtains the user identity and client type from the context of the session corresponding to the call request. The user identity and client type are mainly used for permission verification, and the session context represents the set of user authentication information and environment variables stored in the current request lifecycle.

[0031] In addition, once the user identity and client type are obtained, the permission verification aspect enters the memory data query stage. Based on the combination key of user identity and client type, the corresponding set of interface permissions in the server memory can be quickly located. The set of interface permissions is preloaded into the server memory when the user logs in, and includes all interface permission identifiers that the current user identity is allowed to access under the client type.

[0032] In addition, the permission identifier in the predefined permission annotation and the set of interface permissions are matched to obtain the matching result. The permission status corresponding to the current call request is determined based on the matching result. The permission status includes authorized status and unauthorized status.

[0033] Furthermore, the corresponding interface permission set can be queried in server memory. A multi-level caching strategy can be used to cache frequently used permission data locally in memory and less frequently used data in a distributed cache. It can also degrade to basic authentication mode when the caching service fails to ensure its availability.

[0034] This embodiment enables permission queries to be performed in server memory, avoiding frequent database accesses and improving verification efficiency. By confirming user identity and client type from multiple dimensions, it ensures the accuracy of permission verification and prevents permission confusion between different client types.

[0035] Step S103: When the permission status is authorized, enable the permission verification aspect to allow the call request and execute the call request according to the target business interface, obtain the execution result, and return the execution result to the client.

[0036] Optionally, in this embodiment, when the permission status is authorized, the permission verification aspect is deactivated from intercepting the current call request, and execution control is returned to the target business interface. At the same time, it is necessary to ensure that the target business interface can receive complete request parameters and context.

[0037] The "allow" option indicates that the permission verification aspect has been unblocked, allowing the call request to execute subsequent business logic control operations.

[0038] In addition, after obtaining execution rights for the target business interface, the call request is processed according to the established business logic in the target business interface. The process of processing the call request may include data query, calculation and analysis, transaction operation, etc. The execution result is determined as the end data of the execution and the execution result is returned to the client.

[0039] The execution result refers to the data object or operation result returned after the target business interface has completed processing.

[0040] Furthermore, the execution results can be adaptively compressed, automatically adjusting the size and format of the data returned to the client based on real-time network conditions and client type.

[0041] This embodiment enables accurate control over the interception and approval of permission verification aspects, allowing for transparent processing of legitimate requests. This ensures that the business experience corresponding to the call request is unaffected, guaranteeing both smoothness and security.

[0042] This embodiment provides a login management system, wherein the login management method provided in this embodiment is applied to the login management system, and the login management system is as follows: Figure 2 As shown, it includes a platform business system (i.e., the server of this application) and various types of client applications. The platform business system is a monolithic service built on the Spring Boot framework or a microservice backend service built on the Spring Cloud framework. It uses a public permission verification module JAR to implement permission verification. Various types of client applications include, but are not limited to, BS clients, CS clients, mobile APP clients, and mini-program clients.

[0043] The platform's business system also includes a database, the remote dictionary service Redis, and the microservice management platform Nacos. The permission verification JAR includes network management services, authentication services, and other services.

[0044] This embodiment implements a security protection chain by receiving call requests sent by clients, having the permission verification aspect intercept the requests for permission verification, and allowing the call request to proceed only if the permission status is authorized. This enables the target business interface to process the call request and return the execution result to the client, thus achieving complete decoupling of permission verification and business logic. Furthermore, it ensures the high efficiency of the permission verification process through memory-level operations. While maintaining high security, it also considers processing performance and user experience, providing reliability and flexibility for access control of the target business interface, improving development efficiency, reducing the number of database accesses, and improving overall performance.

[0045] In some embodiments, a matching result is obtained by matching a permission identifier and an interface permission set, and the permission status corresponding to the current call request is determined based on the matching result, including: If the permission annotation type includes a single permission identifier, or if the permission annotation type includes multiple permission identifiers and the logical operator between the multiple permission identifiers is AND, then all permission identifiers and the interface permission set are matched to obtain the matching result. If the matching result shows that all permission identifiers exist in the interface permission set, the permission status corresponding to the current call request is determined to be authorized. If the matching result is that at least one permission identifier does not exist in the interface permission set, the permission status corresponding to the current call request is determined to be unauthorized.

[0046] Optionally, this embodiment involves the verification of one or more permission identifiers, and also includes the processing of logical operators, so as to accurately determine the permission status of the call request.

[0047] The configuration structure of the permission annotation type is parsed. If a single permission identifier is detected in the permission annotation type, the permission identifier is matched in the interface permission set to obtain the matching result. In other words, it is enough to verify whether the permission identifier exists in the interface permission set.

[0048] If the permission annotation type is found to contain multiple permission identifiers and the logical operator between the multiple permission identifiers is AND, then all permission identifiers are matched in the interface permission matching set to obtain the matching result, that is, to verify whether all permission identifiers exist in the interface permission set.

[0049] Logical operators are used to define the logical relationships between multiple permission identifiers, including basic logical types such as AND and OR.

[0050] Furthermore, the matching algorithm in the matching process can incorporate a short-circuit evaluation optimization method, that is, immediately stop subsequent verification if any required permission identifier is detected to be missing. It can also support the group management of permission identifiers, organizing related permission identifiers into permission groups, thus simplifying the configuration of complex permission rules.

[0051] In addition, if all permission identifiers are found to have a corresponding item in the interface permission set, the authorization status confirmation process is triggered. The authorization status confirmation process can be a state transition process or the generation of an authorization token. The authorization token includes the matching result, the matching timestamp, and a list of permission identifiers used.

[0052] Furthermore, if at least one permission identifier is detected as not existing in the interface authorization set, the permission status of the current call request is determined to be unauthorized, indicating that the call request has not passed permission verification and the call request will be rejected, effectively preventing unauthorized access and enhancing security.

[0053] The unauthorized state may include the collection of diagnostic information, which records the specific content of missing permission identifiers, and saves a complete permission verification snapshot, which includes permission identifiers that have been matched in the interface authorization set and permission identifiers that have not been matched.

[0054] Furthermore, if any permission identifier is detected as not existing in the interface authorization set, the unauthorized state process can be triggered immediately, that is, the information of the first missing permission identifier is recorded and subsequent matching is terminated.

[0055] This embodiment achieves a matching result by matching permission identifiers and interface permission sets, and determines the permission status corresponding to the current call request based on the matching result. It realizes an accurate, flexible and efficient multi-client permission management mechanism, which can effectively prevent unauthorized call requests from accessing the system and protect data security. At the same time, it supports AND operations between multiple permission identifiers, enabling relevant personnel to flexibly configure more complex permission requirements and meet the permission requirements of different client types in different scenarios.

[0056] In some embodiments, a matching result is obtained by matching a permission identifier and an interface permission set, and the permission status corresponding to the current call request is determined based on the matching result, including: When the permission annotation type includes multiple permission identifiers and the logical operator between the multiple permission identifiers is OR, the matching result is obtained by matching each permission identifier and the interface permission set. If the matching result shows that at least one permission identifier exists in the interface permission set, the permission status corresponding to the current call request is determined to be an authorized status; If the matching result shows that none of the permission identifiers exist in the interface permission set, the permission status corresponding to the current call request is determined to be unauthorized.

[0057] Optionally, in this embodiment, if the permission annotation type includes multiple permission identifiers and the logical operator between the multiple permission identifiers is OR, it means that as long as any one permission identifier is satisfied, the permission status can be determined as an authorized status. Here, the OR logical operator represents the selective relationship between multiple permission identifiers. Matching any permission identifier in the interface permission set can be regarded as a matching result of authorization.

[0058] The OR operation of multiple permission identifiers and logical operators provides users with a variety of possible access paths, allowing users to gain access by satisfying any one of these paths.

[0059] Furthermore, different weight values ​​can be configured for different permission identifiers to automatically check the permission identifiers most likely to pass, thereby improving matching efficiency. The matching order of permission identifiers can also be dynamically adjusted based on the user's historical access patterns.

[0060] In addition, if the matching results show that at least one permission identifier exists in the interface permission set, the permission status of the current call request is determined to be authorized, that is, the call request has passed the permission verification and can continue to be executed. Thus, among multiple possible permissions, the user only needs to have one permission to access the interface of the call request, which improves availability, makes permission management closer to actual business needs, and provides users with a more convenient access experience.

[0061] Furthermore, if the matching results show that none of the permission identifiers exist in the interface permission set, the permission status of the current call request will be determined as unauthorized, indicating that the call request has not passed the permission verification and will be rejected. This ensures that only explicitly authorized users can access the corresponding resources, effectively preventing unauthorized access and protecting data security.

[0062] Furthermore, it can analyze unauthorized status pattern recognition, detect frequently attempted permission paths by users and provide corresponding configuration schemes, implement an intelligent fallback mechanism, provide alternative access methods when all permission identifiers do not match, and send notifications to administrators when permission verification of important target business interfaces fails repeatedly.

[0063] This embodiment achieves strict access control by matching permission identifiers and interface permission sets, and determining the permission status of call requests based on the OR of logical operators. It can also avoid excessive restrictions through flexible matching strategies, thus adapting to access control needs in different scenarios and providing a reliable access control solution for diverse business requirements.

[0064] In some embodiments, after determining the permission status corresponding to the current invocation request based on the matching result, the method further includes: When the permission status is unauthorized, the permission verification aspect throws the corresponding permission exception status and blocks the execution of the call request; The system captures permission exception states through a global exception handler, which then generates an exception message based on the captured exception state and returns it to the client. Unauthorized access records are asynchronously generated based on the permission exception state and stored in the database. The unauthorized access record includes the user identity, client type, interface path corresponding to the target business interface, permission identifier, and timestamp of the call request.

[0065] Optionally, in this embodiment, when the permission status is unauthorized, the permission verification aspect constructs a permission exception instance. The permission exception instance can represent the permission exception status. The permission exception instance may include, but is not limited to, the permission verification failure result, the permission identifier that caused the failure, the set of matching interface permissions, and the original information of the call request. When the permission exception status is thrown, the permission verification aspect actively blocks the execution link of the call request, so that the business logic of the target business interface will not continue to run in the unauthorized state.

[0066] Furthermore, different subclasses of permission exception states can be thrown based on the reasons for different permission verification failures. The blocking strategy can be configured as a flexible blocking mode, allowing logging but not immediate blocking for low-risk target business interfaces. It can also implement exception chain tracing, that is, establishing a correlation between lower-level permission verification exceptions and upper-level business exceptions, facilitating problem tracking.

[0067] In addition, the global exception handler captures permission exception states. After the global exception handler captures a permission exception, it enters the user prompt generation stage. The global exception handler parses the detailed information in the permission exception state, including but not limited to the specific reason for the failure, the specific permission items involved, the solution, the user identity, the client type, the interface path corresponding to the target business interface, the permission identifier, and the timestamp of the call request. Based on the above information, a structured error response, namely an unauthorized access record, is generated asynchronously. The unauthorized access record includes, but is not limited to, machine-readable error codes and readable descriptions suitable for end users to understand. At the same time, the unauthorized access record is stored in the database.

[0068] This embodiment implements a permission verification aspect to throw permission exceptions and block the execution of call requests. It captures permission exceptions through a global exception handler and generates exception prompts to return to the client. At the same time, it asynchronously generates unauthorized access records and stores them in the database. This achieves a secure, transparent and efficient permission management strategy, which can effectively prevent unauthorized access. In addition, by providing clear permission exceptions and unauthorized access records, it improves the user experience and facilitates subsequent security audits and analyses by relevant personnel, thus enhancing traceability.

[0069] In some embodiments, intercepting calls to the target business interface through a permission verification aspect includes: The method signature information of the target business interface is obtained by using the preset join point in the permission verification aspect, parsing the method signature information to obtain the predefined permission annotation of the target business interface, and then performing the steps of matching permission identifier and interface permission set to obtain the matching result. By using permission verification aspects, all public methods with preset annotations are intercepted to block calls to the target business interface.

[0070] Optionally, in this embodiment, upon receiving a call request, the permission verification aspect obtains the method signature information of the target business interface through a preset join point. The preset join point, in AOP (Aspect-Oriented Programming), refers to a point where additional logic can be inserted, and this join point is set as the call point of the target business interface. By parsing the method signature information, predefined permission annotations on the target business interface can be determined.

[0071] The method signature information is a set of metadata used to uniquely identify a method, including but not limited to the declaration class, method name, parameter types, and return type.

[0072] In addition, predefined permission annotations for the target business interface are extracted from the parsed method signature information. These predefined permission annotations are a mechanism for declaring the permissions of the target business interface, including but not limited to permission annotation types and permission identifiers. This allows for clear definition of the permissions required for each target business interface and enables accurate permission verification before the call request is executed.

[0073] Furthermore, the permission verification aspect also intercepts all public methods with predefined annotations. Public methods are those that can be called externally and typically provide services to the outside world. By comprehensively intercepting public methods, it ensures that all externally exposed target permission interfaces undergo unified permission verification, guaranteeing consistency in permission management.

[0074] Furthermore, multiple related annotations can be merged and parsed into a unified permission rule through an annotation parser. The annotation parser can support combined annotation processing, and can also realize dynamic calculation of annotation attributes, and can determine the specific permission identifier at runtime based on the context.

[0075] This embodiment intercepts calls to the target business interface through a permission verification aspect, obtains the method signature information of the target business interface, parses the method signature information to obtain predefined permission annotations, and intercepts all public methods with preset annotations. It can centralize the permission verification logic scattered in various target business interfaces for processing in the permission verification aspect, ensuring the consistency of security policies while significantly reducing code duplication. Moreover, the interception process remains transparent to the business code, improving development efficiency and maintainability.

[0076] In some embodiments, before intercepting calls to the target business interface through the permission verification aspect, the method further includes: Obtain the long-connection status information of the current client user from the context of the current session. If the long-connection status information is active, execute the step of intercepting the call to the target business interface. If the long-lived connection status information is inactive, a prompt message is sent to the client and the processing of the call request is terminated. The prompt message is used to indicate to the client that the current session status is invalid or abnormal.

[0077] Optionally, this embodiment obtains the long-connection status information of the current client user from the context of the current session. This long-connection status information reflects whether the client maintains a valid and active connection with the server. If the long-connection status information indicates an active state, the step of intercepting calls to the target business interface will continue, ensuring that further permission verification and business logic processing are only performed if the client maintains a valid connection with the server.

[0078] When the persistent connection status information shows an inactive state, a notification message is sent to the client, and the processing of the call request is terminated. The content of the notification message can be customized to clearly inform the client that the current session status is invalid or abnormal, thus preventing invalid or abnormal sessions from continuing to occupy resources. It also provides timely notification of the client's session status, improving transparency and user experience.

[0079] Furthermore, anomaly handling can be designed as a progressive response, taking different intensities of processing measures based on the duration of the anomaly, which can achieve intelligent recovery guidance and provide customized recovery solutions for different types of connection anomalies.

[0080] This embodiment, before intercepting calls to the target business interface through permission verification aspects, also includes obtaining the current client's long-connection status information from the context of the current session. If the long-connection status is active, the call to the target business interface is intercepted; if inactive, a notification message is sent to the client and the call request is terminated. This achieves in-depth security control, improves security, effectively identifies and blocks malicious requests on abnormal connections, optimizes resource utilization, and avoids wasting processing power on unreliable connections. Simultaneously, clear status feedback and exception handling guidance improve the user experience, enabling the client to promptly perceive and resolve connection problems.

[0081] This embodiment provides another method for dynamic verification of interface permissions. See [link to relevant documentation] Figure 3 When user A+ client type is logged in, the HTTP request carries a token. The platform business system (i.e., the server in this application) verifies the token (by retrieving user and client type information from Redis using the token). Requests without a token or with a token not in Redis will return an API call failure.

[0082] If the HTTP request token verification passes, the system retrieves the WebSocket connection from memory to check if it is online (for user A+ client type connections). This is the second layer of verification. If it is online, the system begins to verify the permissions of the target business interface.

[0083] Before introducing the API permission verification, let's describe the code logic: A custom annotation (a method type annotation) is added to the method of the target business interface. For example: @PreAuthorize(hasPermi = "system:role:list"), where @PreAuthorize represents the annotation name; The expression `(hasPermi = "system:role:list")` indicates that the `hasPermi` annotation variable passes the parameter "system:role:list", where "system:role:list" represents the permission identifier for the target business interface. You can define `hasPermi` to pass an array of permission identifiers; as long as an identifier exists in the array, the user has the required permission. The above is the first step.

[0084] The second step is to write an AspectJ aspect using AOP (Aspect-Oriented Programming). The pointcut can be represented as `@Around("@annotation(com.fullsee.cmp.common.security.annotation.PreAuthorize)")` to define a predefined permission annotation. Whenever a method has this predefined permission annotation, permission checks will be performed in the pointcut method body before and after entering the method. Permission checks take place here (this is the common permission verification JAR).

[0085] This aspect program can obtain the permission identifier from the method. It matches the interface permission identifier loaded into memory when logging in (user A + client type) with the permission identifier on this method. If they match, it means that the user has the necessary permissions, and the target business interface is called normally and a normal result is returned.

[0086] If no match is found, it indicates insufficient permissions. The system records the request source IP address, user information, the specified business interface, and the request timestamp in the database, and returns a failure message to the client. This logic achieves multi-client interface permission control, resolving the issue of vertical privilege escalation across multiple clients.

[0087] To effectively address the shortcomings of traditional technologies, such as insufficient granularity of verification and inability to adapt to differentiated permission requirements in multi-client scenarios, and to significantly improve the fineness of permission granularity and the ease of management of multi-client permissions, this application provides an embodiment of an interface permission dynamic verification device for implementing all or part of the aforementioned interface permission dynamic verification. See [link to embodiment]. Figure 4 The interface permission dynamic verification device specifically includes the following components: Processing module 10 is used to receive a call request sent by the client, and in response to the call request, determine the target business interface with predefined permission annotations to execute the call request. Before the target business interface executes the request business corresponding to the call request, the call to the target business interface is intercepted through the permission verification aspect. The predefined permission annotations include permission annotation type and permission identifier. The matching module 20 is used to obtain the user identity and client type from the context of the session corresponding to the call request through the permission verification aspect, query the corresponding interface permission set in the server memory based on the user identity and client type, match the permission identifier and the interface permission set to obtain the matching result, and determine the permission status corresponding to the current call request based on the matching result. The permission status includes authorized status and unauthorized status. The execution module 30 is used to enable the permission verification aspect to allow the call request and execute the call request according to the target business interface when the permission status is authorized, obtain the execution result, and return the execution result to the client.

[0088] As described above, the interface permission dynamic verification device provided in this application embodiment can innovatively receive a call request sent by a client, respond to the call request, determine the target business interface with predefined permission annotations for executing the call request, and intercept the call to the target business interface through a permission verification aspect before the target business interface executes the request business corresponding to the call request. The predefined permission annotations include permission annotation type and permission identifier. The permission verification aspect obtains the user identity and client type from the context of the session corresponding to the call request, queries the corresponding interface permission set in the server memory according to the user identity and client type, matches the permission identifier and the interface permission set to obtain a matching result, and determines the permission status corresponding to the current call request based on the matching result. The permission status includes authorized status and unauthorized status. When the permission status is authorized, the permission verification aspect allows the call request to be allowed and executes the call request according to the target business interface to obtain the execution result, and returns the execution result to the client. By using predefined permission annotations, access permission requirements for business interfaces are decoupled from business code in the form of declarative metadata. Through AOP aspects, accurate interception and permission verification are performed before the execution of methods in the target business interface, preventing vertical privilege escalation vulnerabilities. Thus, the combination of predefined permission annotations and AOP aspects constructs an efficient, accurate, secure, and easily maintainable dynamic interface permission verification method. This method effectively addresses the shortcomings of traditional technologies, such as insufficient granularity of verification and inability to adapt to differentiated permission requirements in multi-client scenarios, significantly improving the fineness of permission granularity and the ease of management in multi-client scenarios.

[0089] From a hardware perspective, in order to effectively address the shortcomings of traditional technologies, such as insufficient granularity of verification and inability to adapt to differentiated permission requirements in multi-client scenarios, and to significantly improve the granularity of permissions and the ease of management of multi-client permissions, this application provides an embodiment of an electronic device for implementing all or part of the dynamic verification method for interface permissions. The electronic device specifically includes the following components: The system comprises a processor, memory, a communications interface, and a bus; wherein the processor, memory, and communications interface communicate with each other via the bus; the communications interface is used to realize information transmission between the dynamic interface permission verification device and core business systems, user terminals, and related databases and other related devices; the logic controller can be a desktop computer, tablet computer, or mobile terminal, etc., and this embodiment is not limited to these. In this embodiment, the logic controller can be implemented with reference to the embodiments of the dynamic interface permission verification method and the dynamic interface permission verification device in the embodiments, the contents of which are incorporated herein, and repeated details will not be described again.

[0090] It is understood that the user terminal may include smartphones, tablet computers, network set-top boxes, portable computers, desktop computers, personal digital assistants (PDAs), in-vehicle devices, smart wearable devices, etc. Among these, the smart wearable devices may include smart glasses, smartwatches, smart bracelets, etc.

[0091] In practical applications, the dynamic verification method for interface permissions can be partially executed on the electronic device side as described above, or all operations can be completed on the client device. The choice can be made based on the processing power of the client device and the limitations of the user's usage scenario. This application does not impose any limitations on this. If all operations are completed on the client device, the client device may further include a processor.

[0092] The aforementioned client device may have a communication module (i.e., a communication unit) that can communicate with a remote server to achieve data transmission with the server. The server may include a server on the task scheduling center side; in other implementation scenarios, it may also include a server on an intermediate platform, such as a server on a third-party server platform that has a communication link with the task scheduling center server. The server may include a single computer device, a server cluster consisting of multiple servers, or a distributed server structure.

[0093] Figure 5 This is a schematic block diagram illustrating the system configuration of the electronic device 9600 according to an embodiment of this application. Figure 5 As shown, the electronic device 9600 may include a central processing unit 9100 and a memory 9140; the memory 9140 is coupled to the central processing unit 9100. It is worth noting that... Figure 5 This is an example; other types of structures can also be used to supplement or replace this structure to achieve telecommunications functions or other functions.

[0094] In one embodiment, the dynamic verification method for interface permissions can be integrated into the central processing unit 9100. The central processing unit 9100 can be configured to perform the following controls: Step S101: Receive the call request sent by the client, respond to the call request, determine the target business interface with predefined permission annotations to be used to execute the call request, and intercept the call to the target business interface through the permission verification aspect before the target business interface executes the request business corresponding to the call request. The predefined permission annotations include permission annotation type and permission identifier. Step S102: Obtain the user identity and client type from the context of the session corresponding to the call request through the permission verification aspect. Based on the user identity and client type, query the corresponding interface permission set in the server memory, match the permission identifier and the interface permission set to obtain the matching result, and determine the permission status corresponding to the current call request based on the matching result. The permission status includes authorized status and unauthorized status. Step S103: When the permission status is authorized, enable the permission verification aspect to allow the call request and execute the call request according to the target business interface, obtain the execution result, and return the execution result to the client.

[0095] As described above, the electronic device provided in this application embodiment innovatively receives a call request sent by a client, responds to the call request, determines the target business interface with predefined permission annotations for executing the call request, and intercepts the call to the target business interface through a permission verification aspect before the target business interface executes the request business corresponding to the call request. The predefined permission annotations include permission annotation type and permission identifier. The permission verification aspect obtains the user identity and client type from the context of the session corresponding to the call request, queries the corresponding interface permission set in the server memory based on the user identity and client type, matches the permission identifier and the interface permission set to obtain a matching result, and determines the permission status corresponding to the current call request based on the matching result. The permission status includes authorized status and unauthorized status. If the permission status is authorized, the permission verification aspect allows the call request to proceed and executes the call request according to the target business interface, obtaining the execution result, and returning the execution result to the client. By using predefined permission annotations, access permission requirements for business interfaces are decoupled from business code in the form of declarative metadata. Through AOP aspects, accurate interception and permission verification are performed before the execution of methods in the target business interface, preventing vertical privilege escalation vulnerabilities. Thus, the combination of predefined permission annotations and AOP aspects constructs an efficient, accurate, secure, and easily maintainable dynamic interface permission verification method. This method effectively addresses the shortcomings of traditional technologies, such as insufficient granularity of verification and inability to adapt to differentiated permission requirements in multi-client scenarios, significantly improving the fineness of permission granularity and the ease of management in multi-client scenarios.

[0096] In another embodiment, the interface permission dynamic verification device can be configured separately from the central processing unit 9100. For example, the interface permission dynamic verification device can be configured as a chip connected to the central processing unit 9100, and the interface permission dynamic verification method function can be implemented through the control of the central processing unit.

[0097] like Figure 5 As shown, the electronic device 9600 may further include: a communication module 9110, an input unit 9120, an audio processor 9130, a display 9160, and a power supply 9170. It is worth noting that the electronic device 9600 does not necessarily need to include these components. Figure 5 All components shown; in addition, the electronic device 9600 may also include Figure 5 For components not shown, please refer to existing technology.

[0098] like Figure 5As shown, the central processing unit 9100, sometimes also referred to as a controller or operating control, may include a microprocessor or other processor device and / or logic device, which receives inputs and controls the operation of various components of the electronic device 9600.

[0099] The memory 9140 may be, for example, one or more of a cache, flash memory, hard drive, removable media, volatile memory, non-volatile memory, or other suitable devices. It may store the aforementioned failure-related information, and also store a program for executing that information. The central processing unit 9100 may execute the program stored in the memory 9140 to perform information storage or processing, etc.

[0100] Input unit 9120 provides input to central processing unit 9100. Input unit 9120 may be, for example, a keypad or touch input device. Power supply 9170 provides power to electronic device 9600. Display 9160 displays images and text. Display may be, for example, an LCD display, but is not limited thereto.

[0101] The memory 9140 can be a solid-state memory, such as a read-only memory (ROM), random access memory (RAM), a SIM card, etc. It can also be a memory that retains information even when power is off, can be selectively erased, and contains more data; examples of this type of memory are sometimes referred to as EPROMs. The memory 9140 can also be some other type of device. The memory 9140 includes a buffer memory 9141 (sometimes referred to as a buffer). The memory 9140 may include an application / function storage unit 9142 for storing application programs and function programs or processes for executing the operation of the electronic device 9600 via the central processing unit 9100.

[0102] The memory 9140 may also include a data storage unit 9143 for storing data, such as contacts, digital data, pictures, sounds, and / or any other data used by the electronic device. The driver storage unit 9144 of the memory 9140 may include various drivers for the electronic device for communication functions and / or for performing other functions of the electronic device (such as messaging applications, address book applications, etc.).

[0103] The communication module 9110 is a transmitter / receiver that sends and receives signals via the antenna 9111. The communication module 9110 (transmitter / receiver) is coupled to the central processing unit 9100 to provide input signals and receive output signals, which is the same as in a conventional mobile communication terminal.

[0104] Based on different communication technologies, multiple communication modules 9110 can be configured in the same electronic device, such as cellular network modules, Bluetooth modules, and / or wireless LAN modules. The communication module 9110 (transmitter / receiver) is also coupled to a speaker 9131 and a microphone 9132 via an audio processor 9130 to provide audio output via the speaker 9131 and receive audio input from the microphone 9132, thereby realizing typical telecommunications functions. The audio processor 9130 may include any suitable buffer, decoder, amplifier, etc. Additionally, the audio processor 9130 is coupled to a central processing unit 9100, enabling on-device recording via the microphone 9132 and on-device playback of stored audio via the speaker 9131.

[0105] Embodiments of this application also provide a computer-readable storage medium capable of implementing all steps of the interface permission dynamic verification method with the execution subject being a server or client in the above embodiments. The computer-readable storage medium stores a computer program that, when executed by a processor, implements all steps of the interface permission dynamic verification method with the execution subject being a server or client in the above embodiments. For example, when the processor executes the computer program, it implements the following steps: Step S101: Receive the call request sent by the client, respond to the call request, determine the target business interface with predefined permission annotations to be used to execute the call request, and intercept the call to the target business interface through the permission verification aspect before the target business interface executes the request business corresponding to the call request. The predefined permission annotations include permission annotation type and permission identifier. Step S102: Obtain the user identity and client type from the context of the session corresponding to the call request through the permission verification aspect. Based on the user identity and client type, query the corresponding interface permission set in the server memory, match the permission identifier and the interface permission set to obtain the matching result, and determine the permission status corresponding to the current call request based on the matching result. The permission status includes authorized status and unauthorized status. Step S103: When the permission status is authorized, enable the permission verification aspect to allow the call request and execute the call request according to the target business interface, obtain the execution result, and return the execution result to the client.

[0106] As described above, the computer-readable storage medium provided in this application embodiment innovatively receives a call request sent by a client, responds to the call request, determines the target business interface with predefined permission annotations for executing the call request, and intercepts the call to the target business interface through a permission verification aspect before the target business interface executes the request business corresponding to the call request. The predefined permission annotations include permission annotation type and permission identifier. The permission verification aspect obtains the user identity and client type from the context of the session corresponding to the call request, queries the corresponding interface permission set in the server memory based on the user identity and client type, matches the permission identifier and the interface permission set to obtain a matching result, and determines the permission status corresponding to the current call request based on the matching result. The permission status includes authorized status and unauthorized status. If the permission status is authorized, the permission verification aspect allows the call request to proceed and executes the call request according to the target business interface, obtains the execution result, and returns the execution result to the client. By using predefined permission annotations, access permission requirements for business interfaces are decoupled from business code in the form of declarative metadata. Through AOP aspects, accurate interception and permission verification are performed before the execution of methods in the target business interface, preventing vertical privilege escalation vulnerabilities. Thus, the combination of predefined permission annotations and AOP aspects constructs an efficient, accurate, secure, and easily maintainable dynamic interface permission verification method. This method effectively addresses the shortcomings of traditional technologies, such as insufficient granularity of verification and inability to adapt to differentiated permission requirements in multi-client scenarios, significantly improving the fineness of permission granularity and the ease of management in multi-client scenarios.

[0107] Embodiments of this application also provide a computer program product capable of implementing all steps of the interface permission dynamic verification method with the execution subject being a server or client in the above embodiments. When the computer program / instruction is executed by a processor, it implements the steps of the interface permission dynamic verification method. For example, the computer program / instruction implements the following steps: Step S101: Receive the call request sent by the client, respond to the call request, determine the target business interface with predefined permission annotations to be used to execute the call request, and intercept the call to the target business interface through the permission verification aspect before the target business interface executes the request business corresponding to the call request. The predefined permission annotations include permission annotation type and permission identifier. Step S102: Obtain the user identity and client type from the context of the session corresponding to the call request through the permission verification aspect. Based on the user identity and client type, query the corresponding interface permission set in the server memory, match the permission identifier and the interface permission set to obtain the matching result, and determine the permission status corresponding to the current call request based on the matching result. The permission status includes authorized status and unauthorized status. Step S103: When the permission status is authorized, enable the permission verification aspect to allow the call request and execute the call request according to the target business interface, obtain the execution result, and return the execution result to the client.

[0108] As described above, the computer program product provided in this application innovatively receives a call request sent by a client, responds to the call request, determines the target business interface with predefined permission annotations for executing the call request, and intercepts the call to the target business interface through a permission verification aspect before the target business interface executes the request business corresponding to the call request. The predefined permission annotations include permission annotation type and permission identifier. The permission verification aspect obtains the user identity and client type from the context of the session corresponding to the call request, queries the corresponding interface permission set in the server memory based on the user identity and client type, matches the permission identifier and the interface permission set to obtain a matching result, and determines the permission status corresponding to the current call request based on the matching result. The permission status includes authorized status and unauthorized status. If the permission status is authorized, the permission verification aspect allows the call request to proceed and executes the call request according to the target business interface, obtains the execution result, and returns the execution result to the client. By using predefined permission annotations, access permission requirements for business interfaces are decoupled from business code in the form of declarative metadata. Through AOP aspects, accurate interception and permission verification are performed before the execution of methods in the target business interface, preventing vertical privilege escalation vulnerabilities. Thus, the combination of predefined permission annotations and AOP aspects constructs an efficient, accurate, secure, and easily maintainable dynamic interface permission verification method. This method effectively addresses the shortcomings of traditional technologies, such as insufficient granularity of verification and inability to adapt to differentiated permission requirements in multi-client scenarios, significantly improving the fineness of permission granularity and the ease of management in multi-client scenarios.

[0109] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0110] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (devices), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0111] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0112] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0113] Specific embodiments have been used to illustrate the principles and implementation methods of this invention. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.

Claims

1. A method for dynamic verification of interface permissions, characterized in that, The method includes: The system receives a call request sent by a client, and in response to the call request, determines a target business interface with predefined permission annotations for executing the call request. Before the target business interface executes the request business corresponding to the call request, the system intercepts the call to the target business interface through a permission verification aspect. The predefined permission annotations include permission annotation type and permission identifier. The user identity and client type are obtained from the context of the session corresponding to the call request through the permission verification aspect. Based on the user identity and the client type, the corresponding interface permission set is queried in the server memory. The permission identifier and the interface permission set are matched to obtain the matching result. Based on the matching result, the permission status corresponding to the current call request is determined, wherein the permission status includes authorized status and unauthorized status. When the permission status is the authorized status, the permission verification aspect allows the call request to be passed and executes the call request according to the target business interface to obtain the execution result, and returns the execution result to the client.

2. The method according to claim 1, characterized in that, The process of matching the permission identifier and the interface permission set to obtain a matching result, and determining the permission status corresponding to the current call request based on the matching result, includes: If the permission annotation type includes a single permission identifier, or if the permission annotation type includes multiple permission identifiers and the logical operator between the multiple permission identifiers is AND, then all the permission identifiers and the interface permission set are matched to obtain a matching result. If the matching result shows that all the permission identifiers exist in the interface permission set, the permission status corresponding to the current call request is determined to be an authorized status; If the matching result indicates that at least one of the permission identifiers does not exist in the interface permission set, the permission status corresponding to the current call request is determined to be unauthorized.

3. The method according to claim 1, characterized in that, The process of matching the permission identifier and the interface permission set to obtain a matching result, and determining the permission status corresponding to the current call request based on the matching result, includes: When the permission annotation type includes multiple permission identifiers and the logical operator between the multiple permission identifiers is OR, the permission identifiers and the interface permission set are matched to obtain the matching result; If the matching result shows that at least one of the permission identifiers exists in the interface permission set, the permission status corresponding to the current call request is determined to be an authorized status; If the matching result is that none of the aforementioned permission identifiers exist in the interface permission set, the permission status corresponding to the current call request is determined to be unauthorized.

4. The method according to claim 1, characterized in that, After determining the permission status corresponding to the current invocation request based on the matching result, the method further includes: If the permission status is unauthorized, the permission verification aspect will throw the corresponding permission exception status and block the execution of the call request; The global exception handler captures the permission exception state and generates an exception prompt based on the captured permission exception state, which is then returned to the client. An unauthorized access record is asynchronously generated based on the permission exception state and stored in the database. The unauthorized access record includes the user identity, the client type, the interface path corresponding to the target business interface, the permission identifier, and the timestamp of the call request.

5. The method according to claim 1, characterized in that, The interception of calls to the target business interface through the permission verification aspect includes: The method signature information of the target business interface is obtained by obtaining the method signature information through the preset connection point in the permission verification aspect, and the predefined permission annotation of the target business interface is obtained by parsing the method signature information, so as to execute the step of matching the permission identifier and the interface permission set to obtain the matching result; The permission verification aspect intercepts all public methods with preset annotations to block calls to the target business interface.

6. The method according to claim 1, characterized in that, Before intercepting calls to the target business interface through the permission verification aspect, the method further includes: Obtain the long connection status information of the current client user from the context of the current session; if the long connection status information is active, execute the step of intercepting the call to the target business interface. If the long connection status information is inactive, a prompt message is sent to the client and the processing of the call request is terminated. The prompt message is used to indicate to the client that the current session status of the session is invalid or abnormal.

7. A dynamic interface permission verification device, characterized in that, The device includes: The processing module is configured to receive a call request sent by the client, and in response to the call request, determine a target business interface with predefined permission annotations for executing the call request. Before the target business interface executes the request business corresponding to the call request, the module intercepts the call to the target business interface through a permission verification aspect. The predefined permission annotations include permission annotation type and permission identifier. The matching module is used to obtain the user identity and client type from the context of the session corresponding to the call request through the permission verification aspect, query the corresponding interface permission set in the server memory based on the user identity and the client type, match the permission identifier and the interface permission set to obtain the matching result, and determine the permission status corresponding to the current call request based on the matching result, wherein the permission status includes authorized status and unauthorized status; The execution module is configured to, when the permission status is the authorized status, enable the permission verification aspect to allow the call request and execute the call request according to the target business interface, obtain the execution result, and return the execution result to the client.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the interface permission dynamic verification method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the interface permission dynamic verification method according to any one of claims 1 to 6.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instruction is executed by the processor, it implements the steps of the interface permission dynamic verification method according to any one of claims 1 to 6.

Images