Interface permission control method and device

Abstract

The embodiment of the invention discloses an interface permission control method and device, and the method comprises the steps: setting a user-defined permission annotation on at least one target API method of a business API interface, and enabling the user-defined permission annotation to comprise a preset permission code used for uniquely identifying the target API method; obtaining a permission configuration file deployed along with the plug-in, wherein the permission configuration file records a declaration permission list which is declarated by the plug-in and is formed by one or more permission codes which are allowed to be called by the plug-in; during running of the plug-in, when it is detected that the plug-in tries to call a target API method, intercepting the call request through a aspect programming mechanism; in response to interception, a preset permission code is extracted from a user-defined permission annotation of the called target API method to serve as a target permission code, a declaration permission list is obtained, and whether the target permission code exists in the declaration permission list or not is checked; and according to a verification result, if the verification is passed, allowing the call request to continue to be executed, and if the verification is not passed, stopping the execution of the call request.

Description

Technical Field

[0001] This application relates to the field of software development technology, and in particular to a method and apparatus for controlling interface permissions. Background Technology

[0002] In modern SaaS (Software as a Service) platforms, to meet the personalized needs of different customers, platform providers typically allow third-party developers to extend platform functionality by developing plugins. In this process, plugins inevitably need to call the platform's core business APIs (Application Programming Interfaces) to obtain data or perform business operations. However, these APIs often involve sensitive business data. Ensuring that plugin calls to these APIs are legal, secure, and controlled, and preventing data leaks and unauthorized access, becomes a challenge for platform providers.

[0003] Currently, existing technologies primarily employ manual review mechanisms to control plugin API call permissions. The specific process is as follows: Before developing a plugin, third-party developers must submit a list of API permission requests they plan to make to the platform. After plugin development is complete, the full source code must be submitted to the platform for review. Platform reviewers manually read through the entire plugin source code, checking the code logic line by line to extract all actually called API interfaces. Then, the extracted list of actual calls is manually compared with the permission request list submitted by the developer. If the actual calls exceed the requested scope, the review fails, and the plugin must be returned for modification. However, this existing technical solution relying on manual review has the following prominent problems: First, the review process is extremely inefficient. Manually reviewing source code is a tedious and time-consuming task, especially when plugin logic is complex and the codebase is large. Reviewers may spend hours or even days reviewing a single plugin, severely hindering plugin deployment speed and platform ecosystem development. Second, the review process is inaccurate and prone to oversights. Manual comparison is highly susceptible to errors due to human fatigue or distraction, particularly regarding API usage hidden in complex business logic, conditional branches, or dynamic calls. Reviewers struggle to comprehensively and accurately identify these vulnerabilities. Once an oversight occurs, it means the plugin has gained unauthorized API access, posing a serious security risk to the platform and user data. Finally, there is a lack of real-time security protection. Existing manual reviews are static, pre-emptive security measures that only take effect before plugin deployment. If unauthorized calls are not detected during the review phase, existing solutions lack a mechanism to intercept and block unauthorized API calls in real-time during plugin operation. This means any oversight in the review process will directly translate into real security risks at runtime, which cannot be detected and contained immediately.

[0004] Therefore, there is an urgent need in this field for an interface permission control scheme that can overcome the above-mentioned defects, so as to achieve automation, precision and real-time runtime verification of plugin API call permissions, thereby improving the efficiency and security of permission management. Summary of the Invention

[0005] This specification provides an interface permission control method and apparatus to solve at least one of the technical problems mentioned above.

[0006] According to a first aspect of the present invention, a method for controlling interface permissions is provided, applied to an electronic device including a business API interface and a plug-in that calls the business API interface, the method comprising: Set a custom permission annotation on at least one target API method of the business API interface, wherein the custom permission annotation contains a preset permission code for uniquely identifying the target API method; Obtain the permission configuration file deployed with the plugin, which records a list of declared permissions consisting of one or more permission codes that the plugin is allowed to invoke; During the operation of the plugin, when it is detected that the plugin attempts to call the target API method, the call request is intercepted through aspect programming. In response to the interception, the preset permission code is extracted from the custom permission annotation of the called target API method as the target permission code, the declared permission list is obtained, and the target permission code is verified to exist in the declared permission list. Based on the verification result, if the verification passes, the call request is allowed to continue execution; if the verification fails, the execution of the call request is blocked and a preset permission exception is thrown. The permission exception carries the unique identifier of the plugin and the target permission code.

[0007] In some optional implementations, the custom permission annotation is defined using a runtime retention policy of the Java reflection mechanism to ensure that the permission code can be extracted via reflection when the call request is intercepted.

[0008] In some optional implementations, the permission configuration file is in structured text format; The step of obtaining the permission configuration file deployed with the plugin includes: Locate and load the structured text-based permission configuration file from the plugin's resource files; The structured text-formatted permission configuration file is parsed to extract and cache the declared permission list, wherein the data structure of the declared permission list is a collection class.

[0009] In some optional implementations, during system initialization, an aspect-oriented access control interception mechanism is pre-established, including: Define a pointcut to match all methods marked with the custom permission annotation; Based on the aforementioned pointcut, a dynamic proxy is created for the Bean containing the target API method using an AOP framework; Define the surrounding notification that is triggered before the target API method is executed; The interception of the call request via aspect programming includes: When the plugin calls the target API method, the call request is captured by the dynamic proxy. The dynamic proxy routes the call request to the surround advice for processing based on the pointcut matching result. The surround advice performs the checksum and execution control of the call request.

[0010] In some optional implementations, extracting the preset permission code as the target permission code from the custom permission annotation of the invoked target API method includes: The signature of the invoked method is obtained based on the surrounding advice; The Method object corresponding to the method signature is obtained through Java reflection. Obtain an instance of the custom permission annotation through the Method object; The preset permission code value is read from the instance of the custom permission annotation as the target permission code.

[0011] In some optional implementations, obtaining the list of declared permissions includes: Obtain the unique identifier of the currently executing plugin through the current thread context; Use the plugin's unique identifier to retrieve the corresponding list of declared permissions from the cache.

[0012] In some optional implementations, the current thread context is implemented through thread-local variables. The value of the thread-local variables is set when the platform starts executing the logic of the plugin, and the value of the thread-local variables is cleared when the plugin logic finishes executing.

[0013] In some optional implementations, the permission code in the custom permission annotation adopts a modular encoding rule, where the first half of the permission code represents the business module identifier and the second half represents the specific function identifier.

[0014] According to a second aspect of the present invention, an interface permission control device is provided, applied in an electronic device including a business API interface and a plug-in that calls the business API interface, the device comprising: The permission definition module is used to set custom permission annotations on at least one target API method of the business API interface, wherein the custom permission annotation contains a preset permission code for uniquely identifying the target API method; A configuration loading module is used to obtain the permission configuration file deployed with the plugin. The permission configuration file records a list of declared permissions consisting of one or more permission codes that the plugin declares and allows it to call. An interception module is invoked to intercept the call request during the operation of the plugin when the plugin attempts to call the target API method, using an aspect programming mechanism. The permission verification module is used to respond to the interception by extracting the preset permission code from the custom permission annotation of the called target API method as the target permission code, obtaining the declared permission list, and verifying whether the target permission code exists in the declared permission list. The execution control module is used to, based on the result of the verification, allow the call request to continue execution if the verification passes, and prevent the execution of the call request and throw a preset permission exception if the verification fails. The permission exception carries the unique identifier of the plugin and the target permission code.

[0015] The technical solution of this application has several significant technical advantages, as detailed below: 1. In the technical solution of this application, by setting a custom annotation containing a unique permission code on the target API method of the business API interface and obtaining the permission configuration file deployed with the plugin, a precise mapping relationship between permission identifiers and API methods and a declarative description of the plugin's permission requirements can be established. This permission definition and declaration mechanism based on annotations and configuration files can transform the implicit API call relationship that originally required manual review into machine-readable structured data, thereby providing a data foundation for the automation of permission verification and replacing the cumbersome and inefficient manual source code review process.

[0016] 2. The technical solution in this application dynamically intercepts API call requests during plugin runtime using aspect-oriented programming (AOP). At the interception point, the target permission code is extracted in real time and compared with the declared permission list. This runtime interception and verification mechanism based on AOP ensures that every API call must undergo permission verification. Because the verification process occurs before method execution and is automatically completed through programmatic logic, it can not only accurately identify unauthorized access but also immediately block call execution when unauthorized behavior occurs, thereby establishing a real-time, dynamic security protection system and effectively preventing data leakage risks.

[0017] 3. The technical solution in this application, by throwing permission exceptions carrying the unique identifier of the plugin and the target permission code information during the execution control stage, can provide accurate traceability basis for system operation and maintenance and security auditing. This fine-grained exception information recording mechanism can quickly locate the responsible party and specific operation for unauthorized access, thereby facilitating problem investigation and system monitoring.

[0018] 4. The technical solution in this application decouples the access control logic into three independent layers: annotation definition, configuration declaration, and AOP validation, enabling the solution to have good scalability. When the platform needs to add a new controlled API, it only needs to add a permission annotation to the target method to automatically include it in the permission system. When a plugin needs to access a new API, it only needs to append the corresponding permission code to its configuration file. This configuration-based extension mechanism does not require modification of the core validation logic, thus achieving configuration-as-a-service for access control, reducing system maintenance costs and iteration complexity. Attached Figure Description

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

[0020] Figure 1 A flowchart illustrating the interface permission control method provided in this application embodiment; Figure 2 A complete flowchart of the interface permission control method provided for the technical solution of this application; Figure 3 A schematic diagram of the interface permission control device provided in the embodiments of this application. Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of one or more embodiments of this specification clearer, the technical solutions of one or more embodiments of this specification will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the protection scope of one or more embodiments of this specification.

[0022] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another.

[0023] As described in the background section, existing technologies primarily employ manual review mechanisms to control API call permissions for plugins. This approach suffers from low review efficiency, poor accuracy, and a lack of real-time security protection. To address this issue, this application provides a method for controlling interface permissions, particularly suitable for multi-tenant SaaS (Software as a Service) platforms developed using Java and the Spring framework. This method manages the API call permissions of third-party developers or plugins. The technical concept of this application is briefly described below, followed by a detailed explanation. This solution statically defines API permissions through annotation metadata, declares plugin permission requirements through configuration files, and seamlessly integrates into business logic at runtime using AOP (Aspect-Oriented Programming) technology. It obtains real-time permission identifiers through reflection and quickly compares them with pre-declared permission sets, thus completing permission decisions before method execution. This solution decouples permission control logic from business logic, transforming the traditional, inefficient, and error-prone manual pre-review into efficient, accurate, and real-time automated runtime verification. This improves the API access security and management efficiency of SaaS platforms within a multi-tenant plugin ecosystem.

[0024] The technical solution of this application will be described in detail below with reference to the accompanying drawings, such as... Figure 1 As shown, Figure 1 A flowchart illustrating an interface permission control method provided in this application embodiment. This method, applied to an electronic device containing a business API interface and plugins that call the business API interface, may include the following steps: Step 102: Set a custom permission annotation on at least one target API method of the business API interface, wherein the custom permission annotation contains a preset permission code for uniquely identifying the target API method.

[0025] This step involves setting a custom permission annotation on at least one target API method of the business API interface. This annotation contains a preset permission code to uniquely identify the target API method. Specifically, this step can be performed when the platform develops the business API, implemented through Java's custom annotation mechanism. For example, an annotation named `@AuthCode` can be used. This annotation is defined as runtime-retained using `@Retention(RetentionPolicy.RUNTIME)` to ensure that the permission code can be extracted via reflection during subsequent interception calls. Simultaneously, `@Target(ElementType.METHOD)` restricts its application to the method level. In practical applications, platform developers can directly add this annotation to the API methods that need protection and assign a unique permission code string. For example, in the `IEmployeeDetailService` interface, the `getEmployeeBasic` method might be marked with `@AuthCode("0201")`, where "0201" is a preset permission code. Its encoding rules may adopt a modular approach, thus assigning each target API method a unique permission identifier.

[0026] Step 104: Obtain the permission configuration file deployed with the plugin, which records a list of declared permissions consisting of one or more permission codes that the plugin is allowed to invoke.

[0027] The purpose of this step is to obtain the permission configuration file deployed with the plugin. This file records a list of declared permissions consisting of one or more permission codes that the plugin is allowed to invoke. Specifically, this permission configuration file can be a structured text file placed in the root directory of the plugin's resource files, such as a JSON file named apiAuth.json. This configuration file can contain explicit structured content, such as an array field named "authCodes," whose elements are the permission code strings declared by the plugin, thus clearly defining the scope of APIs that the plugin is permitted to invoke. When the platform loads the plugin, a specific configuration loading module (such as a SpringBean implemented as AuthConfigManager) is responsible for finding and loading this permission configuration file from the plugin's resource files. Then, a JSON parsing library (such as Jackson or Gson) is used to parse the file, extract the permission code array, and convert it into a permission code set (e.g., a Set in Java). <string>The cached set is the plugin's declared permission list, providing a basis for comparison during subsequent runtime permission verification.

[0028] It is important to emphasize that in this step, the permission configuration file and the plugin have a subordinate, bundled, and lifecycle-synchronized relationship. It is not a remote configuration that can be dynamically distributed by the platform, but rather static metadata carried by the plugin itself, used to declare its permission requirements. For example, the loading, activation, and cleanup of the configuration file are completely synchronized with the plugin's lifecycle. When the platform loads or installs the plugin, the system (e.g., SaaS software that needs to manage plugins and provide business APIs) simultaneously locates and parses this configuration file from the plugin package and loads its contents into the cache. Correspondingly, when the plugin is uninstalled or stopped, the associated permission configuration is also cleared and removed from the cache. When the plugin is updated, the permission configuration file must also be updated because the APIs to be called may change. This design in the technical solution of this application ensures that the source of the permission declaration is authentic and reliable (originating from the plugin package itself), and that the permission scope of each plugin instance is clearly defined at the time of its deployment, thereby providing a reliable and isolated decision basis for subsequent runtime permission verification.

[0029] Step 106: During the operation of the plugin, when it is detected that the plugin attempts to call the target API method, the call request is intercepted through aspect programming.

[0030] In this step, when a plugin attempts to call a target API method, the call request is intercepted using aspect-oriented programming (AOP). The specific implementation can rely on an aspect-oriented access control interception mechanism pre-established during system initialization (described in detail later). Its core is defining an aspect class and using a specific pointcut expression to match all methods annotated with the custom access control annotation, such as using `@Pointcut("@annotation(com.example.auth.AuthCode)")`. Based on this pointcut, an AOP framework (such as Spring AOP) creates dynamic proxies for the beans containing these target API methods. When the plugin's code executes and attempts to call a target API method annotated with `@AuthCode`, it actually calls its dynamic proxy object. Based on the pointcut matching result, this proxy object automatically routes the call request to its associated around advice method, thus successfully intercepting the call request before the actual business logic of the target API method is executed.

[0031] Step 108: In response to the interception, extract the preset permission code from the custom permission annotation of the called target API method as the target permission code, obtain the declared permission list, and verify whether the target permission code exists in the declared permission list.

[0032] This step first extracts the preset permission code as the target permission code from the custom permission annotation of the target API method being called. This operation can be completed within the around advice using Java reflection. Based on the intercepted call request, the system obtains its method signature, thus obtaining the corresponding Method object. Then, it obtains the instance of the custom permission annotation (e.g., @AuthCode) on this Method object, and finally reads its value attribute from this annotation instance. Next, this step obtains the declared permission list corresponding to the current plugin. This list has been parsed and cached when the plugin is loaded. By accessing the current thread context, the unique identifier of the currently executing plugin can be obtained. This identifier is then used as the key to retrieve the set of pre-declared permission codes for this plugin from the cache. Finally, it checks whether the target permission code obtained in the previous steps exists in the newly obtained declared permission list.

[0033] Step 110: Based on the verification result, if the verification passes, the call request is allowed to continue execution; if the verification fails, the execution of the call request is blocked and a preset permission exception is thrown. The permission exception carries the unique identifier of the plugin and the target permission code.

[0034] In this step, if the permission verification passes (meaning the target permission code exists in the plugin's declared permission list), the call request is allowed to continue its normal execution flow. In a Spring AOP-based implementation, this permission action is specifically manifested by calling the `proceed()` method of the `ProceedingJoinPoint` object within the around advice. This call allows the program execution flow to leave the permission control aspect and instead execute the original business logic of the target API method. Thus, the plugin's API call is successfully completed.

[0035] If the permission verification fails, meaning the target permission code is not found in the plugin's declared permission list, the execution of the call request will be immediately blocked. This can be achieved by throwing a pre-defined, specific type of permission exception, such as a defined ThirdAuthException. Throwing this exception will forcibly terminate the execution flow of the current method and send a clear error signal to the upper-level caller. This permission exception object can carry the following information: first, the unique identifier of the plugin that initiated this unauthorized call; and second, the target permission code that was attempted to be called. This provides direct traceability for system operation and security auditing, enabling rapid identification of the responsible party and specific operation. This step ensures that all intercepted API calls strictly adhere to the permission scope declared by the plugin, thereby enforcing permission control policies at the runtime level.

[0036] The technical solution of this application has several significant technical advantages, specifically as follows: 1. By setting custom annotations containing unique permission codes on the target API methods of the business API interface and obtaining the permission configuration file deployed with the plugin, a precise mapping relationship between permission identifiers and API methods, as well as a declarative description of the plugin's permission requirements, can be established. This permission definition and declaration mechanism based on annotations and configuration files can transform the implicit API call relationships that originally required manual review into machine-readable structured data, thereby providing a data foundation for automating permission verification and replacing the cumbersome and inefficient manual source code review process. 2. The technical solution of this application uses aspect-oriented programming (AOP) to dynamically intercept API call requests during plugin execution and extracts the target permission code in real time at the interception point, comparing it with the declared permission list. This runtime interception and verification mechanism based on AOP ensures that every API call must undergo permission verification. Since the verification process occurs before method execution and is automatically completed through programmatic logic, it can not only accurately identify unauthorized access but also immediately block call execution when unauthorized behavior occurs, thereby establishing a real-time, dynamic security protection system and effectively preventing the risk of data leakage. 3. The technical solution in this application throws permission exceptions carrying the plugin's unique identifier and target permission code information during the execution control phase, providing accurate traceability for system operation and maintenance and security auditing. This fine-grained exception information recording mechanism can quickly locate the responsible party and specific operation for unauthorized access, thus facilitating problem investigation and system monitoring. 4. The technical solution in this application decouples the permission control logic into three independent layers: annotation definition, configuration declaration, and AOP validation, enabling the solution to have good scalability. When the platform needs to add a controlled API, it only needs to add a permission annotation to the target method to automatically include it in the permission system. When a plugin needs to access a new API, it only needs to append the corresponding permission code to its configuration file. This configuration-based extension mechanism does not require modification of the core validation logic, thus achieving configuration-as-a-service for permission control, reducing system maintenance costs and iteration complexity.

[0037] Based on the technical solutions described above, this specification also provides some specific implementation schemes, which are described below.

[0038] In an optional embodiment, the custom permission annotation can be defined using the runtime retention strategy of the Java reflection mechanism to ensure that the permission code can be extracted through reflection when the call request is intercepted.

[0039] In this embodiment, the custom permission annotation is defined using the runtime retention policy of Java reflection. Specifically, when defining the custom annotation (e.g., named @AuthCode), it is explicitly declared using the meta-annotation @Retention(RetentionPolicy.RUNTIME). This meta-annotation specifies that the retention policy of the custom permission annotation is "runtime retention," ensuring that the annotation's metadata information is not only recorded by the compiler in the compiled class file but also retained by the Java Virtual Machine (JVM) during program loading and execution. Because the annotation information remains available during program runtime, when API call requests are intercepted via aspect-oriented programming, the permission verification logic can utilize the Java reflection API to successfully obtain an instance of the custom permission annotation from the Method object corresponding to the intercepted method, and then extract the preset permission code value from it.

[0040] In an optional embodiment, the file format of the permission configuration file can be structured text; The step of obtaining the permission configuration file deployed with the plugin may include: Locate and load the structured text-based permission configuration file from the plugin's resource files; The structured text-formatted permission configuration file is parsed to extract and cache the declared permission list, wherein the data structure of the declared permission list is a collection class.

[0041] In this embodiment, the permission configuration file can be defined and stored using a structured text format. Specifically, this configuration file is a specific file created by the plugin developer and deployed along with the plugin package. For example, it can be named apiAuth.json and placed in the root directory of the plugin's resource files, making it a component of the plugin so that the system can automatically discover and read it when loading the plugin.

[0042] Meanwhile, the process of obtaining this permission configuration file mainly includes two stages: locating and loading, and parsing and caching. First, the system searches for and loads this structured text configuration file in the plugin's resource files. This task can be performed by a dedicated configuration management component. When the plugin is loaded onto the platform, this component locates the `apiAuth.json` file from its predefined resource path and loads its content as a text resource into memory. Subsequently, the system parses the loaded structured text to extract the list of permissions declared by the plugin and converts it into an internal data structure for caching. During parsing, a suitable JSON processing library can be used to deserialize the text content into a Java object. The system extracts the crucial `authCodes` field from this configuration object, whose value is an array of permission code strings. This permission code array is then converted into a collection-like data structure for storage. For example, illustratively, the content of a plugin's `apiAuth.json` file might be: json { "apiAuth": true, "authCodes": ["0201", "0202"] } After parsing, the permission list corresponding to this plugin is constructed as a Set containing the strings "0201" and "0202". <string>Example.

[0043] In optional embodiments, during system initialization, a perspective-oriented access control interception mechanism is pre-established, which may include: Define a pointcut to match all methods marked with the custom permission annotation; Based on the aforementioned pointcut, a dynamic proxy is created for the Bean containing the target API method using an AOP framework; Define the surrounding notification that is triggered before the target API method is executed; The interception of the call request via aspect programming may include: When the plugin calls the target API method, the call request is captured by the dynamic proxy. The dynamic proxy routes the call request to the surround advice for processing based on the pointcut matching result. The surround advice performs the checksum and execution control of the call request.

[0044] In this embodiment, a complete aspect-oriented access control interception mechanism can be pre-established during system initialization. This decouples access control logic from business API logic, thereby enabling interception, permission verification, and execution control of API methods with custom permission annotations, improving system maintainability and scalability. Specifically, a pointcut can be defined to match all methods in the program marked with custom permission annotations, such as the annotation named @AuthCode. This can be achieved using a method annotated with @Pointcut, whose pointcut expression can directly match based on the annotation type. This expression ensures that any execution flow entering a method with the specified annotation will be captured by this pointcut. Subsequently, the AOP framework will automatically create dynamic proxy objects for Spring Beans containing the target API methods during Spring application context initialization based on this pointcut. These proxy objects will be injected into plugins or other callers at runtime, replacing the original Bean instances. Next, an AroundAdvice needs to be defined. This is a method that contains specific permission verification and execution control logic. It uses the @Around annotation and specifies its pointcut as the previously defined pointcut method. This advice is explicitly set to be triggered before the target API method is executed, thus allowing complete control over its execution flow.

[0045] When a plugin attempts to call a target API method during runtime, the actual call flow changes due to the presence of a dynamic proxy. The plugin code holds a reference to a dynamic proxy object created by the Spring container, rather than the original bean. Therefore, the call request is first captured by this dynamic proxy object. The proxy's internal mechanism is then activated, determining whether permission verification is required for this call based on the predefined pointcut matching results. Since the called method has specific annotations, a successful match occurs, and the proxy routes the call request to the associated around advice method for processing. At this point, control is completely transferred to the around advice, which is fully responsible for executing subsequent operations, including extracting the target permission code from the method annotations via reflection, retrieving the current plugin's declared permission list from the cache, performing permission code comparison and verification, and ultimately deciding whether to allow the call to continue or block the call and throw a permission exception based on the verification result.

[0046] In this embodiment, the AOP established through a series of initialization processes, such as defining pointcuts, creating proxies, and defining notifications, ensures that all API calls marked with permission annotations are automatically and forcibly introduced into the permission verification process at runtime. This design can separate permission control from business logic, thereby achieving real-time and automated verification actions.

[0047] In an optional embodiment, extracting the preset permission code as the target permission code from the custom permission annotation of the called target API method may include: The signature of the invoked method is obtained based on the surrounding advice; The Method object corresponding to the method signature is obtained through Java reflection. Obtain an instance of the custom permission annotation through the Method object; The preset permission code value is read from the instance of the custom permission annotation as the target permission code.

[0048] In this embodiment, when the plugin's API call request is captured by the AOP dynamic proxy and routed to the around advice, the system immediately initiates the permission code extraction process. First, the around advice obtains the method signature of the currently called method through its join point parameters. This signature contains key metadata such as the method name, class, and parameter types. Then, based on this method signature, this solution obtains the corresponding Method object through Java reflection. This conversion allows the program to dynamically access all metadata of the method at runtime, especially its annotations. Next, the `getAnnotation` method of the Method object can be used, passing in the type parameter of a custom permission annotation, to obtain the annotation instance annotated on the target API method. Finally, the preset permission code value can be directly read from this annotation instance, which can be achieved by calling its defined `value` method. The string obtained, such as "0201" in the previous example, is determined as the target permission code for this call and is then sent to the subsequent verification stage to be compared with the plugin's declared permission list to complete authentication.

[0049] In an optional embodiment, obtaining the list of declared permissions may include: Obtain the unique identifier of the currently executing plugin through the current thread context; Use the plugin's unique identifier to retrieve the corresponding list of declared permissions from the cache.

[0050] This embodiment describes the process of obtaining the declared permission list, which is detailed below. First, the unique identifier of the currently executing plugin can be obtained through the current thread context. This mechanism is relevant to the multi-tenant, multi-plugin concurrent execution environment of a SaaS platform. Since the platform may process requests from multiple plugins simultaneously, and each request executes in an independent thread, the system must establish a mechanism to associate the execution thread with a specific plugin. Specifically, this mechanism can be implemented using thread-local variables. Before the platform begins executing the business logic of a plugin, the system can use a dedicated plugin context manager to set the unique identifier of the current plugin in a thread-local variable. Logically, this setting is equivalent to labeling the execution thread with a clear plugin identity. When subsequent permission verification logic is triggered in the same execution thread, the current plugin identity can be accurately obtained by accessing this thread-local variable, without confusion with requests from other concurrently executing plugins.

[0051] After successfully obtaining the plugin's unique identifier, the system proceeds to the second stage: retrieving the corresponding declared permission list from the cache using this identifier. During system initialization or plugin loading, the configuration loading module pre-parses the permission configuration file for each plugin and converts the permission code list into a set data structure. This data is then organized into key-value pairs and stored in the cache, where the key is the plugin's unique identifier and the value is the set of permission codes declared by that plugin. When permission verification requires retrieving the declared permission list, the system only needs to use the current plugin identifier as the key to quickly retrieve the corresponding permission set from the cache. This memory-cached query mechanism avoids the performance overhead of re-parsing the configuration file for each permission verification, while the characteristics of the set data structure ensure efficient execution of subsequent permission code existence checks.

[0052] In an optional embodiment, the current thread context can be implemented using thread-local variables. The value of the thread-local variable is set when the platform starts executing the logic of the plugin, and the value of the thread-local variable is cleared when the plugin logic finishes executing.

[0053] In this technical solution, when the platform begins executing the business logic of a plugin, the system immediately sets the unique identifier of the current plugin into a predefined thread-local variable through a dedicated context management component. This setting operation logically assigns a clear identity label to the currently executing thread, allowing any code in the subsequent execution path of that thread to accurately identify the plugin being executed by accessing this thread-local variable. Conversely, when the plugin's business logic is completed, the system must promptly clear the plugin identifier stored in the thread-local variable to prevent the identity information of the completed plugin from being incorrectly passed to subsequent unrelated execution flows.

[0054] The technical solution of this embodiment enables the system to accurately associate each API call request with its corresponding plugin identity even in highly concurrent multi-tenant scenarios.

[0055] In an optional embodiment, the permission code in the custom permission annotation adopts a modular encoding rule, where the first half of the permission code represents the business module identifier and the second half represents the specific function identifier.

[0056] In this embodiment, the permission codes used in the custom permission annotations follow a structured modular coding rule. The core feature of this rule is that each permission code is clearly divided into two parts, each carrying a different identification function. The first part of the permission code is designed as a business module identifier, used to distinguish different core business domains at the system level. For example, in the code example, the three permission codes `@AuthCode("0201")` on the `getEmployeeBasic` method, `@AuthCode("0202")` on the `getEmployeeInfo` method, and `@AuthCode("0203")` on the overloaded `getEmployeeBasic` method all begin with "02", which here uniformly represents the specific business module "employee".

[0057] The latter half of the permission code is defined as a specific function identifier, used to distinguish different operations or data access granularities within the same business module. Similarly, based on the above code, "01" in permission code "0201" corresponds to the "basic query" function, "02" in "0202" corresponds to the "detailed query" function, and "03" in "0203" corresponds to the "ID query" function.

[0058] The example code is as follows: public interface IEmployeeDetailService { / ** * Query employee basic information * Permission Code: 0201 (Module 02-Employees, Function 01-Basic Query) / @AuthCode("0201") EmployeeBasicQueryResult getEmployeeBasic(EmployeeSearchParamemployeeSearchParam); / ** * Query employee details * Access code: 0202 (Module 02-Employees, Function 02-Detailed Inquiry) / @AuthCode("0202") EmployeeDetailQueryResult getEmployeeInfo(EmployeeSearchParamemployeeSearchParam); / ** * Retrieve basic information about current employees (another overloaded method) * Access code: 0203 (Module 02-Employee, Function 03-ID Query) / @AuthCode("0203") EmployeeBasicQueryResult getEmployeeBasic(String companyId, StringemployeeId); } The following is based on Figure 2 The complete process of the interface permission control method provided by the technical solution of this application is described, such as... Figure 2 As shown, the method may specifically include the following steps: Step S1: Permission Definition When developing business APIs, platform developers assign unique permission codes to API methods that require access protection. Specifically, developers can annotate target methods with the `@AuthCode` annotation. For example, defining the `IEmployeeDetailService` interface and adding the `@AuthCode("0201")` annotation to its `getEmployeeBasic(EmployeeSearchParam)` method, the `@AuthCode("0202")` annotation to its `getEmployeeInfo(EmployeeSearchParam)` method, and the `@AuthCode("0203")` annotation to its `getEmployeeBasic(String, String)` method. These annotated interfaces will be packaged into the plugin SDK for use by third-party plugin developers.

[0059] Step S2: Permission Declaration and Loading When developing a plugin (such as "PluginA"), third-party plugin developers need to create an apiAuth.json file within the plugin to declare the required permission codes if they need to call the aforementioned permission-enabled API methods. For example, the apiAuth.json file for "PluginA" could be set to { "apiAuth": true, "authCodes": ["0201", "0202"]}. When the plugin is uploaded and deployed to the SaaS platform, the platform reads and parses this JSON file when loading the plugin, caching and storing the plugin identifier and the corresponding list of permission codes (e.g., the permission code set {"0201", "0202"} for "PluginA").

[0060] Step S3: The plugin initiates an API call. During the plugin runtime phase, after a SaaS platform user triggers the plugin function, the plugin code sets the thread context when it executes (e.g., by specifying the current plugin identifier through PluginContextHolder.setCurrentPluginId("PluginA")), and then the plugin code calls the target business API method (e.g., myEmployeeService.getEmployeeBasic(param)).

[0061] Step S4: Dynamic AOP Interception Because the API method being called has the @AuthCode annotation, it will be intercepted by the AOP proxy mechanism, and then the pre-defined around advice method (such as the checkAuth method) will be executed.

[0062] Step S5: Extract the target permission code Within the around advice method, the signature information of the called method is obtained through reflection, and then the @AuthCode annotation on the method is read to extract the target permission code. For example, when calling the getEmployeeBasic(EmployeeSearchParam) method, the target permission code "0201" can be extracted.

[0063] Step S6: Obtain the list of declaration permissions Get the current plugin ID (e.g., "PluginA") from the thread context, and retrieve the corresponding declaration permission list (e.g., {"0201", "0202"} corresponding to "PluginA") from the platform cache based on the ID.

[0064] Step S7: Execution Permission Comparison Determine whether the declared permission list contains the extracted target permission code, that is, perform the collection inclusion check operation of authorizedCodes.contains(targetAuthCode).

[0065] Step S8: Processing the permission verification result If the permission comparison result is true (e.g., the target permission code "0201" exists in the declared permission list {"0201", "0202"}), then the execution of the original API method call is allowed (e.g., the getEmployeeBasic(EmployeeSearchParam) method is executed via joinPoint.proceed()), and the process ends normally.

[0066] If the permission comparison result is false (for example, the plugin "PluginA" incorrectly calls the getEmployeeBasic(String, String) method and extracts the target permission code "0203", while its declared permission list is {"0201", "0202"}), then an exception (such as ThirdAuthException) is thrown, preventing the execution of the original API method, terminating the plugin execution thread, and the platform records this unauthorized behavior.

[0067] Based on the foregoing technical solution, the present invention also provides an interface permission control device, applied in an electronic device containing a business API interface and a plug-in that calls the business API interface, such as... Figure 3 As shown, the device may include: The permission definition module 302 is used to set a custom permission annotation on at least one target API method of the business API interface, wherein the custom permission annotation contains a preset permission code for uniquely identifying the target API method; The configuration loading module 304 is used to obtain the permission configuration file deployed with the plugin, wherein the permission configuration file records a list of declared permissions consisting of one or more permission codes that the plugin declares and allows it to call. The interception module 306 is invoked to intercept the call request via aspect programming when the plugin attempts to call the target API method during the plugin's operation. The permission verification module 308 is used to respond to the interception by extracting the preset permission code from the custom permission annotation of the called target API method as the target permission code, obtaining the declared permission list, and verifying whether the target permission code exists in the declared permission list. The execution control module 310 is used to, based on the result of the verification, allow the call request to continue execution if the verification passes, and prevent the execution of the call request and throw a preset permission exception if the verification fails. The permission exception carries the unique identifier of the plugin and the target permission code.

[0068] This invention also provides an electronic device for controlling the aforementioned interface permissions; see [link to related documentation]. Figure 4 The diagram shows the structure of an electronic device, which includes a memory 400 and a processor 401. The memory 400 stores one or more computer instructions, which are executed by the processor 401 to implement the aforementioned interface permission control method.

[0069] Furthermore, Figure 4 The electronic device shown also includes a bus 402 and a communication interface 403. The processor 401, the communication interface 403 and the memory 400 are connected via the bus 402.

[0070] The memory 400 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 403 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc. The bus 402 can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus. Processor 401 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 401 or by instructions in software form. The processor 401 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this invention can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a readily available storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 400, and processor 401 reads information from memory 400 and, in conjunction with its hardware, completes the steps of the method described in the foregoing embodiments. This invention also provides a computer-readable storage medium storing computer-executable instructions. When these computer-executable instructions are called and executed by a processor, they cause the processor to implement the aforementioned interface permission control method. For specific implementation details, please refer to the method embodiments, which will not be repeated here.

[0071] The computer program product of the interface permission control method provided in the embodiments of the present invention includes a computer-readable storage medium storing non-volatile program code executable by a processor. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation, please refer to the method embodiments, which will not be repeated here. Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection may be through some communication interface; the indirect coupling or communication connection of apparatuses or units may be electrical, mechanical, or other forms.

[0072] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0073] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0074] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0075] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.< / string> < / string>

Claims

1. A method for controlling interface permissions, applied to an electronic device containing a business API interface and plug-ins that call the business API interface, characterized in that, The method comprises: setting a custom permission annotation on at least one target API method of the business API interface, the custom permission annotation containing a preset permission code for uniquely identifying the target API method; obtaining a permission configuration file deployed with the plug-in, the permission configuration file recording a declared permission list of one or more permission codes declared by the plug-in and allowed to be called by the plug-in; intercepting, through an aspect programming mechanism, a calling request generated when the plug-in attempts to call the target API method during execution of the plug-in; in response to the interception, extracting the preset permission code from the custom permission annotation of the called target API method as a target permission code, obtaining the declared permission list, and verifying whether the target permission code exists in the declared permission list; according to a result of the verification, if the verification is passed, allowing the calling request to continue execution, and if the verification is not passed, preventing execution of the calling request and throwing a preset permission exception, the permission exception carrying information of a unique identifier of the plug-in and the target permission code.

2. The method of claim 1, wherein, The custom permission annotation is defined through a runtime retention policy of a Java reflection mechanism to ensure that the permission code can be extracted through the reflection mechanism when the calling request is intercepted.

3. The method of claim 1, wherein, The file format of the permission configuration file is structured text; the obtaining of the permission configuration file deployed with the plug-in comprises: finding and loading a permission configuration file in structured text format in a resource file of the plug-in; parsing the permission configuration file in structured text format to extract and cache the declared permission list, wherein a data structure of the declared permission list is a collection class.

4. The method of claim 1, wherein, During system initialization, a permission control interception mechanism oriented to an aspect is established in advance, comprising: defining a pointcut for matching all methods marked by the custom permission annotation; based on the pointcut, creating a dynamic proxy for a Bean containing the target API method through an AOP framework; defining a surrounding notification triggered before execution of the target API method; the interception of the calling request through the aspect programming mechanism comprises: when the plug-in calls the target API method, the calling request is captured by the dynamic proxy, the dynamic proxy routes the calling request to the surrounding notification for processing according to a matching result of the pointcut, and the surrounding notification performs the verification and execution control of the calling request.

5. The method of claim 4, wherein, the extraction of the preset permission code from the custom permission annotation of the called target API method as the target permission code comprises: obtaining a method signature of the called method based on the surrounding notification; obtaining a Method object corresponding to the method signature through a Java reflection mechanism; obtaining an instance of the custom permission annotation through the Method object; reading a preset permission code value from the instance of the custom permission annotation as the target permission code.

6. The method of claim 1, wherein, the obtaining of the declared permission list comprises: obtaining a unique identifier of the plug-in being executed through a current thread context; The unique identifier of the plug-in is used to query the corresponding declared permission list from the cache.

7. The method of claim 6, wherein, The current thread context is implemented by a thread local variable, and the value of the thread local variable is set when the platform starts to execute the logic of the plug-in, and the value of the thread local variable is cleaned up when the plug-in logic is executed.

8. The method of claim 1, wherein, The permission code in the custom permission annotation adopts a modular coding rule, and the first half of the permission code represents a business module identifier, and the second half represents a specific function identifier.

9. An interface permission control apparatus, applied to an electronic device comprising a service API interface and a plug-in calling the service API interface, characterized in that, The device comprises: A permission definition module is configured to set a custom permission annotation on at least one target API method of the business API interface, and the custom permission annotation contains a preset permission code for uniquely identifying the target API method. A configuration loading module is configured to obtain a permission configuration file deployed with the plug-in, and the permission configuration file records a declared permission list of one or more permission codes declared by the plug-in. An invocation interception module is configured to intercept an invocation request generated when the plug-in attempts to invoke the target API method during the execution of the plug-in by an aspect programming mechanism. A permission verification module is configured to extract the preset permission code from the custom permission annotation of the invoked target API method as a target permission code, obtain the declared permission list, and verify whether the target permission code exists in the declared permission list in response to the interception. An execution control module is configured to allow the invocation request to continue execution if the verification passes, or prevent the execution of the invocation request and throw a preset permission exception if the verification fails, and the permission exception carries information of the unique identifier of the plug-in and the target permission code.

Images