Business execution method and electronic device

Abstract

The application provides a business execution method and an electronic device. First, a business method marked with an access domain filtering configuration annotation is intercepted by an AOP aspect. Then, a request parameter object of the business method is obtained. Next, an access domain range of a current user is queried, the access domain range including a data identifier list of at least one dimension, each dimension corresponding to an access permission range of a type of data resource. Further, the access domain range is injected into the request parameter object to obtain an injected request parameter object. Finally, the business method is executed according to the injected request parameter object. Thus, the business method marked with the access domain filtering configuration annotation is intercepted by the AOP aspect, the multi-dimensional access domain range of the user is automatically queried and injected into the request parameter object, and then the business method is executed, so that the permission control logic and the business processing logic are decoupled, the permission check code is prevented from being repeatedly written in each business method, and unified management and non-intrusive application of permission control are realized.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and in particular relates to a business execution method and electronic device. Background Technology

[0002] In various business systems, access control for data resources is a core aspect of ensuring data security. Typically, systems need to restrict the range of data that users can access based on their identity, organization, and role permissions, ensuring that users can only view and manipulate data within their authorized scope.

[0003] In related technologies, access control is typically implemented using hard-coding. Developers must manually write permission check code within each business method to obtain the current user's permission scope and pass this scope as a query condition to the data access layer. This implementation tightly couples access control logic with business processing logic.

[0004] However, because each business method needs to repeatedly write similar permission check code, the permission control logic is scattered across various business methods, making it difficult to manage and maintain uniformly. When permission rules change, a large amount of business code needs to be modified, resulting in high code redundancy and a high risk of errors. Summary of the Invention

[0005] This application provides a business execution method and an electronic device that can avoid repeatedly writing permission check code in each business method, thereby achieving unified management of permission control and non-intrusive application.

[0006] The first aspect of this application provides a business execution method, comprising: intercepting a business method annotated with access domain filtering configuration through an aspect-oriented programming (AOP) aspect; obtaining a request parameter object of the business method; querying the access domain scope of the current user, wherein the access domain scope includes a data identifier list of at least one dimension, each dimension corresponding to the access permission scope of a type of data resource; injecting the access domain scope into the request parameter object to obtain an injected request parameter object; and executing the business method according to the injected request parameter object.

[0007] In the technical solution of this application, AOP aspects are mainly used to intercept business methods marked with access domain filtering configuration annotations, automatically query the user's multi-dimensional access domain range and inject it into the request parameter object, and then execute the business method. This decouples the permission control logic from the business processing logic, avoids repeatedly writing permission check code in each business method, and achieves unified management and non-intrusive application of permission control.

[0008] Optionally, in one possible implementation of the first aspect, the above-mentioned querying of the current user's access domain includes: obtaining the user identifier associated with the current request, and querying whether the current user has administrator privileges based on the user identifier; if the current user has administrator privileges, determining a preset list of full data identifiers as the access domain, wherein the list of full data identifiers is used to indicate that the current user has the right to access all data resources; if the current user does not have administrator privileges, determining an organization identifier list based on the user identifier, and determining the access domain based on the organization identifier list. Thus, by distinguishing between the permission query paths for administrators and non-administrators, differentiated permission acquisition strategies are adopted for users with different identities, improving processing efficiency in administrator scenarios while ensuring the accuracy of permissions for ordinary users.

[0009] Optionally, in another possible implementation of the first aspect, the above-mentioned determination of the organization identifier list based on the user identifier and the determination of the access domain scope based on the organization identifier list includes: querying the current user's permission type based on the user identifier; if the permission type is only self-permission, determining the current user's own identifier list as the access domain scope; if the permission type is multiple organization permission type, querying the organization identifier list to which the current user belongs based on the user identifier, and querying the corresponding first resource identifier list and second resource identifier list based on the organization identifier list, wherein the first resource identifier list is used to represent the identifier set of data resources belonging to the organization identifier list, and the second resource identifier list is used to represent the identifier set of user resources belonging to the organization identifier list; adding the organization identifier to which the current user belongs to the organization identifier list to obtain the final organization identifier list; and determining the organization identifier list, the first resource identifier list, and the second resource identifier list as the access domain scope. Thus, by processing the only self-permission and multiple organization permission scenarios separately, and automatically including the user's own organization in the permission scope in the multiple organization permission scenario, fine-grained adaptation to multiple permission types is achieved, avoiding permission omissions caused by organizational hierarchy.

[0010] Optionally, in another possible implementation of the first aspect, the above-mentioned injection of the access domain scope into the request parameter object includes: traversing each dimension in the access domain scope and obtaining the field name and field value corresponding to each dimension; converting the field name into a field setting method name according to a preset naming rule; if a field setting method matching the field setting method name exists in the class corresponding to the request parameter object, calling the field setting method and passing the field value as an input parameter to the field setting method to complete the injection; if no field setting method matching the field setting method name exists in the class corresponding to the request parameter object, obtaining the field object corresponding to the field name in the request parameter object through reflection, setting the accessibility of the field object, converting the field value according to the type of the field object, and setting the type-converted field value into the field object. Therefore, by prioritizing the use of standard field setting methods for injection and directly manipulating fields through reflection when the method does not exist, it is compatible with multiple parameter object structures, improving the universality and robustness of the injection process and reducing injection failures caused by differences in parameter structures.

[0011] Optionally, in another possible implementation of the first aspect, before injecting the access domain scope into the request parameter object, the method further includes: if the data identifier list for all dimensions in the access domain scope is empty, determining the empty handling method for the access domain scope based on the empty return strategy configured in the access domain filtering configuration annotation; if the empty return strategy is enabled, directly returning an empty result and terminating the execution of the business method; if the empty return strategy is disabled, setting the field value of the corresponding dimension in the request parameter object to a preset special flag value, wherein the special flag value is used to instruct the business method to skip data query operations during execution. Thus, by detecting empty access domains and adopting a preset empty handling strategy before injection, queries can be terminated or query interception flags can be set in advance when the user has no data permissions, avoiding invalid full table scans and improving system performance and security.

[0012] Optionally, in another possible implementation of the first aspect, before querying the access domain scope of the current user, the method further includes: converting the request parameter object into a key-value pair mapping table, wherein the key of the key-value pair mapping table is the field name in the request parameter object, and the value of the key-value pair mapping table is the field value in the request parameter object; obtaining the first expression and the second expression configured in the access domain filtering configuration annotation, wherein the first expression is used to control whether access domain filtering for the first resource dimension is enabled, and the second expression is used to control whether access domain filtering for the second resource dimension is enabled; using the key-value pair mapping table as the expression parsing context, parsing the first expression to obtain a first parsing result, and determining whether access domain filtering for the first resource dimension is enabled based on the first parsing result; using the key-value pair mapping table as the expression parsing context, parsing the second expression to obtain a second parsing result, and determining whether access domain filtering for the second resource dimension is enabled based on the second parsing result; wherein the first resource dimension and the second resource dimension correspond to two different dimensions in the access domain scope. Therefore, by using expressions to dynamically parse request parameters, the system can determine in real time whether to enable filtering based on specific dimensions according to the current request content, thereby achieving flexible control over filtering conditions and adapting to the permission configuration requirements of different business scenarios without modifying the code.

[0013] Optionally, in another possible implementation of the first aspect, before injecting the access domain scope into the request parameter object, the method further includes: obtaining the organization identifier list and the first resource identifier list in the request parameter object; if the organization identifier list is empty and the first resource identifier list is not empty, performing an intersection operation on the first resource identifier list in the access domain scope and the first resource identifier list in the request parameter object to obtain the first resource identifier list for injection; if the organization identifier list is not empty and the first resource identifier list is not empty, performing a union operation on the first resource identifier list associated with the organization identifier list in the access domain scope and the first resource identifier list in the request parameter object to obtain the first resource identifier list for injection. A resource identifier list is generated. If the organization identifier list is not empty and the first resource identifier list is empty, the operation method configured in the access domain filtering configuration annotation is used to perform an intersection or union operation on the first resource identifier list associated with the organization identifier list within the access domain scope and an empty set, resulting in the first resource identifier list for injection. If both the organization identifier list and the first resource identifier list are empty, the operation method configured in the access domain filtering configuration annotation is used to perform an intersection or union operation on the first resource identifier list within the access domain scope and an empty set, resulting in the first resource identifier list for injection. This first resource identifier list for injection is then used as the data identifier list for the first resource dimension within the access domain scope. Therefore, by intelligently selecting intersection or union operations based on the null value combination of organization identifiers and resource identifiers, the optimal set operation method is automatically adopted for different business scenarios, maximizing the range of data accessible to users while ensuring access security.

[0014] Optionally, in another possible implementation of the first aspect, the above-mentioned execution of the business method based on the injected request parameter object includes: querying the parent organization identifiers corresponding to each organization identifier to which the current user belongs, based on the organization identifier list in the injected request parameter object; merging the parent organization identifiers with each organization identifier in the organization identifier list to remove duplicates, obtaining an expanded organization identifier list; and querying the data resources belonging to the expanded organization identifier list, obtaining a data object list. Thus, by automatically querying the parent organization identifiers and merging them with the original organization identifiers, upward inheritance of permissions can be achieved without additional configuration, simplifying permission management in multi-level organizational structures.

[0015] Optionally, in another possible implementation of the first aspect, the above-mentioned execution of business methods based on the injected request parameter object includes: obtaining a list of data objects whose permissions are to be determined; checking each permission source sequentially according to a preset permission priority order, wherein the permission priority order is: first resource dimension permission, second resource dimension permission, and organization dimension permission; if any permission source matches successfully, determining the current permission level of the current data object and stopping the checking of subsequent permission sources; if the current permission level has been determined to be edit permission, prohibiting subsequent read-only permissions from overriding edit permissions. Thus, by checking permission sources according to a preset priority order and prohibiting lower permissions from overriding higher permissions after higher permissions have taken effect, the correctness and stability of permission determination are ensured, avoiding permission downgrade problems caused by multi-source permission conflicts.

[0016] A second aspect of this application provides a service execution apparatus, including: The business interception module is used to intercept business methods annotated with access domain filtering configuration annotations through AOP aspects.

[0017] The object retrieval module is used to retrieve the request parameter object of the business method.

[0018] The scope query module is used to query the access scope of the current user. The access scope includes a list of data identifiers with at least one dimension, and each dimension corresponds to the access permission scope of a type of data resource.

[0019] The scope injection module is used to inject the access domain scope into the request parameter object, resulting in the injected request parameter object.

[0020] The business execution module is used to execute business methods based on the injected request parameter object.

[0021] A third aspect of 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 computer program to implement the business execution method of the first aspect described above.

[0022] A fourth aspect of this application provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the business execution method of the first aspect described above.

[0023] The fifth aspect of this application provides a computer program product that, when run on an electronic device, causes the electronic device to execute the business execution method of the first aspect described above.

[0024] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

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

[0026] Figure 1 This is a schematic diagram of the architecture of a business execution system provided in an embodiment of this application; Figure 2 This is a flowchart illustrating a business execution method provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a business execution device provided in an embodiment 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

[0027] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0028] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0029] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0030] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0031] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0032] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0033] It should be understood that the sequence number of each step in this embodiment does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of this application embodiment.

[0034] In related technologies, access control is typically implemented using hard-coding. Developers must manually write permission check code within each business method to obtain the current user's permission scope and pass this scope as a query condition to the data access layer. This approach tightly couples access control logic with business processing logic. However, because each business method needs to repeatedly write similar permission check code, access control logic is scattered across various business methods, making unified management and maintenance difficult. When permission rules change, a large amount of business code needs to be modified, resulting in high code redundancy and a high risk of errors.

[0035] In view of this, embodiments of this application provide a business execution method and an electronic device. The method first intercepts business methods annotated with access domain filtering configuration annotations using AOP aspects; then, it obtains the request parameter object of the business method; next, it queries the current user's access domain scope, which includes a data identifier list with at least one dimension, each dimension corresponding to the access permission scope of a type of data resource; further, it injects the access domain scope into the request parameter object, obtaining the injected request parameter object; finally, it executes the business method based on the injected request parameter object. Thus, by intercepting business methods annotated with access domain filtering configuration annotations using AOP aspects, automatically querying the user's multi-dimensional access domain scope and injecting it into the request parameter object before executing the business method, it decouples the permission control logic from the business processing logic, avoiding the repetitive writing of permission check code in each business method, and achieving unified management and non-intrusive application of permission control.

[0036] The following provides an example illustrating the application scenarios of the business execution method provided in this application. Taking an organizational business system as an example, when a user initiates a "query resource list" request on the front end, the traditional solution requires manually writing permission check code within each query business method to obtain the user's organization, managed resources, and other permission scope, and then concatenating the query conditions, resulting in duplicate permission logic in a large number of business methods. With the solution provided in this application, only an access domain filtering configuration annotation needs to be added to the query resource list business method. The system will then automatically intercept the method through AOP aspects, query the user's multi-dimensional access domain scope (including a list of accessible organizations, resources, personnel, etc.), and automatically inject this scope into the request parameter object. The business method can directly use the injected parameters to execute the query without any permission processing code, thereby achieving complete decoupling of permission control logic and business logic, unified management of permission rules, and significantly reducing code redundancy and maintenance costs.

[0037] To illustrate the technical solution of this application, specific embodiments are described below.

[0038] Reference Figure 1 The diagram illustrates the architecture of a business execution system provided in an embodiment of this application. Figure 1 As shown, the system is divided into five layers from top to bottom: AOP aspect layer, intelligent processing layer, access domain query layer, permission control layer, and business layer.

[0039] In this embodiment, the AOP aspect layer includes a Domain FilterConfiguration Annotation, a Domain Auto-Injection AspectEngine, a Spring Expression Language Expression ResolutionEngine, and a Reflection Parameter Injection Engine. The Domain FilterConfiguration Annotation marks business methods that require automatic domain injection. The Domain Auto-Injection AspectEngine uses an AOP surround interception mechanism to intercept annotated business methods before execution, uniformly triggering the domain query and injection process. The Spring Expression Language Expression ResolutionEngine parses the expressions configured in the annotations and dynamically determines whether to enable specific-dimensional domain filtering based on the current request parameters. The Reflection Parameter Injection Engine uses reflection to write the queried domain range into the request parameter object of the business method.

[0040] The intelligent processing layer includes the Intelligent Set Operation Engine, the Filter Field Unified Management Engine, and the Empty Access Domain Detection Engine. The Intelligent Set Operation Engine intelligently selects intersection or union operations to merge multi-dimensional access domains based on the combinations of empty values ​​in the organization identifier list and resource identifier list in the request parameters. The Filter Field Unified Management Engine is responsible for uniformly managing the field information of each dimension. The Empty Access Domain Detection Engine, when detecting that all data identifier lists in all dimensions within the access domain are empty, directly returns an empty result or sets a special flag value according to the empty return strategy configured in the annotation, avoiding invalid data queries.

[0041] The access domain query layer includes a User Access Domain Query Engine, a Permission Inheritance Query Engine, and a special handling module for administrator permissions. The User Access Domain Query Engine queries the user's access domain scope based on the user identifier associated with the current request. The access domain scope includes a list of data identifiers with at least one dimension, each dimension corresponding to the access permission scope of a type of data resource. The Permission Inheritance Query Engine automatically queries the parent organization identifier of the user's organization when needed and merges it with the existing organization identifier to achieve upward inheritance of permissions. The special handling module for administrator permissions identifies the administrator's identity and grants full data access permissions, or identifies the "self-only permission" type and returns only the user's own data identifier.

[0042] The access control layer includes an Evidence Permission Intelligent Processing Engine, a Permission Non-Degradation Protection Mechanism, and a State-Aware Permission Adjustment Engine. The Evidence Permission Intelligent Processing Engine checks each permission source sequentially according to a preset priority order, stopping further checks upon a match. The Permission Non-Degradation Protection Mechanism prevents subsequent read-only permissions from overriding edit permissions once edit permissions have been determined. The State-Aware Permission Adjustment Engine dynamically adjusts permission levels based on the data resource's state, downgrading permissions for data resources in a specific state to read-only permissions.

[0043] The business layer includes business methods and data access mechanisms. Business methods receive the injected request parameter object, which has been processed by the aforementioned layers and already contains the user's access scope. Data access mechanisms perform data queries based on the access scope in the request parameter object and return data results that meet the permission requirements.

[0044] Through the collaborative work of the above five-layer architecture, this application achieves the decoupling of access control logic and business processing logic, enabling access control to be applied to various business methods in a unified and non-intrusive manner.

[0045] exist Figure 1 Based on the system architecture shown, Figure 2 A flowchart illustrating a business execution method provided in an embodiment of this application is shown. Figure 2 As shown, the business execution method may include the following steps: Step 201: Intercept business methods annotated with access domain filtering configuration annotations using AOP aspects.

[0046] In this embodiment, AOP is a programming paradigm used to separate cross-cutting concerns (such as access control and logging) from business logic. The system predefines access domain filtering configuration annotations, which are used to annotate business methods that require automatic access domain injection. These annotations support configuring multiple parameters, including field names for each dimension, whether filtering is enabled, and whether to return empty data. When developers need to apply automatic permission injection in a business method, they only need to annotate that method; no permission checking code needs to be written inside the method.

[0047] In one possible implementation, after system startup, the AOP aspect engine, i.e., the access domain auto-injection aspect engine, uses a surround interception aspect to scan all annotated business methods and generate proxy objects for them. When a user initiates a business request (e.g., querying a resource list in an organizational business system), the request is routed to the corresponding business method. Since the business method has been proxied, it will first enter the AOP aspect engine's surround interception logic before actual execution.

[0048] Specifically, the surround interception logic can perform the following operations: First, parse the access domain filtering configuration annotations on the business method to obtain the names of the fields and filtering conditions configured in the annotations. Second, extract the request parameter object of the current business method. If the parameter is wrapped by a request wrapping object, extract the actual data object from it as the parameter object for subsequent operations. Then, convert the request parameter object into a key-value pair mapping table for subsequent processing. Next, call the access domain query layer to query the access domain range of the current user. The access domain range includes a data identifier list of at least one dimension, and each dimension corresponds to the access permission range of a type of data resource (e.g., organization identifier list, first resource identifier list, second resource identifier list, etc., which will be described in detail in subsequent embodiments). If all data identifier lists for all dimensions within the queried access domain are empty, the empty return strategy configured in the access domain filtering configuration annotation will be applied: if the empty return strategy is enabled, an empty result will be returned directly, and the execution of the original business method will be terminated—an empty list will be returned for list types, and an empty result with pagination information will be returned for pagination information types; if the empty return strategy is disabled, the field value of the corresponding dimension in the request parameter object will be set to a preset special flag value (such as -1), and the data query operation will be skipped after subsequent business methods detect this.

[0049] If the access domain is not empty, the access domain information can be injected into the request parameter object through a reflection parameter injection engine. This engine prioritizes setting field values ​​via field setting methods: converting field names to field setting method names (e.g., converting "Organization Identifier List" to "Set Organization Identifier List"). If the method exists, it is called, passing the field value as a parameter to complete the injection. If the field setting method does not exist, reflection is used to directly manipulate the field, obtain the field object, set its accessibility, and automatically perform type conversion based on the field type (integer or string). Finally, the field value is set in the field object. After injection, the injected request parameter object is obtained, the aspect engine allows it to proceed, and the original business method continues execution. At this point, the parameter object already contains the user's access domain information.

[0050] It should be noted that, through the above embodiments, the access control logic is completely extracted from the business methods, realizing non-intrusive access control, avoiding the duplication of access control code, and ensuring the uniformity and maintainability of the access control logic.

[0051] Step 202: Obtain the request parameter object of the business method.

[0052] In this embodiment, after the AOP aspect engine intercepts a business method annotated with an access domain filtering configuration annotation, it first needs to obtain the request parameter object of the business method in order to extract query conditions and inject access domain scopes. Specifically, the aspect engine can obtain all input parameters of the currently intercepted method through reflection. Typically, the first parameter of the business method is the request parameter object, which encapsulates the query conditions carried by the user's current request, such as a list of organization identifiers, a list of first resource identifiers (e.g., a list of vehicle identifiers), a list of second resource identifiers (e.g., a list of user identifiers), and pagination parameters, etc.

[0053] In actual system implementations, request parameter objects may be wrapped by request wrapper objects. For example, in some frameworks, the request object passed from the front end is encapsulated as a wrapper object of a specific type, rather than being directly used as an input parameter for business methods. In such cases, the aspect engine further detects the type of the obtained parameter: if the parameter is a request wrapper object, it extracts the actual data object from it using reflection or framework-provided utility methods, using it as the parameter object for subsequent operations; if the parameter itself is a data object, it is used directly. Through this processing, regardless of the form in which the request parameters are passed, the aspect engine can accurately locate the data object carrying the business data.

[0054] In one possible implementation, after obtaining the request parameter object (i.e., the actual data object), the aspect engine can convert the object into a key-value pair mapping table. A key-value pair mapping table is a data structure where the keys are the field names in the request parameter object, and the values ​​are the corresponding field values. For example, if the request parameter object contains the fields "Organization Identifier List" (orgIds) and "First Resource Identifier List" (resourceIds), then two key-value pairs will be created in the mapping table: "orgIds" → the value of "Organization Identifier List", and "resourceIds" → the value of "First Resource Identifier List". This mapping table will serve as the context for subsequent SPEL expression parsing, allowing the expression to dynamically read field values ​​from the request parameters at runtime.

[0055] In one embodiment, before querying the current user's access domain scope, the request parameter object can be converted into a key-value pair mapping table. The keys in the key-value pair mapping table are the field names in the request parameter object, and the values ​​are the field values. The first and second expressions configured in the access domain filtering configuration annotation are retrieved. The first expression controls whether access domain filtering for the first resource dimension is enabled, and the second expression controls whether access domain filtering for the second resource dimension is enabled. The key-value pair mapping table is used as the expression parsing context to parse the first expression, obtaining a first parsing result. Based on the first parsing result, it is determined whether to enable access domain filtering for the first resource dimension. Similarly, the key-value pair mapping table is used as the expression parsing context to parse the second expression, obtaining a second parsing result. Based on the second parsing result, it is determined whether to enable access domain filtering for the second resource dimension. The first and second resource dimensions correspond to two different dimensions within the access domain scope. Therefore, by dynamically parsing request parameters using expressions, the system can determine in real-time whether to enable filtering for a specific dimension based on the current request content, thereby achieving flexible control over filtering conditions and adapting to the permission configuration requirements of different business scenarios without modifying the code.

[0056] It should be noted that after converting the request parameter object into a key-value pair mapping table, the SPEL expression parsing engine will retrieve the first and second expressions configured in the access domain filtering configuration annotation. The first expression controls whether access domain filtering for the first resource dimension is enabled, and the second expression controls whether access domain filtering for the second resource dimension is enabled. The first and second resource dimensions correspond to two different dimensions within the access domain scope. Taking an organizational business system as an example, the first resource dimension could correspond to the vehicle resource dimension, and the second resource dimension could correspond to the user resource dimension; however, this application is not limited to this, and other dimensions can be configured according to actual business needs.

[0057] Furthermore, the SPEL expression parsing engine can use the aforementioned key-value pair mapping table as the context for expression parsing (i.e., the variable environment for expression runtime), parsing the first and second expressions separately. During parsing, the expression can read the field values ​​of request parameters from the mapping table by key name and calculate a Boolean result based on these values ​​(for example, the expression can be written as "whether the request parameters contain a specific condition"). The first parsing result is used to determine whether to enable access domain filtering for the first resource dimension: if the result is true, filtering for that dimension is performed when querying access domains subsequently; if the result is false, filtering for that dimension is not enabled. Similarly, the second parsing result is used to determine whether to enable access domain filtering for the second resource dimension. If an expression is not configured in the annotation, or the expression parsing result is false, filtering for the corresponding dimension is not enabled by default.

[0058] For example, when a user queries a resource list, they might include an identifier field indicating "only query resources related to themselves". The system can be configured in the first expression to "enable the first resource dimension filtering when the 'only themselves' identifier field in the request parameters is true", thereby dynamically controlling whether to restrict permissions for that dimension. Through this mechanism, whether to enable access domain filtering for a specific dimension can be dynamically determined based on the specific content of the request, adapting to the permission requirements of different business scenarios without modifying the code.

[0059] It should be noted that step 202 completes the acquisition of the request parameter object, the unpacking of the wrapper object, the construction of the key-value pair mapping table, and the dynamic parsing of the SPEL expression. Afterward, the system will proceed to the access domain query stage based on the parsing results (i.e., whether filtering by dimension is enabled) and information such as the organization identifier in the request parameters.

[0060] Step 203: Query the access domain range of the current user. The access domain range includes a list of data identifiers of at least one dimension, and each dimension corresponds to the access permission range of a type of data resource.

[0061] In this embodiment, after extracting the request parameter object, constructing the key-value pair mapping table, and dynamically parsing the SPEL expression, the system enters the access domain query stage. This stage is executed by the access domain query layer and includes sub-components such as the user access domain query engine, the permission inheritance query engine, and the administrator permission special processing module. Based on the user identifier associated with the current request, the system queries the user's access domain scope. The access domain scope includes at least one dimension of data identifier list, such as an organization identifier list, a first resource identifier list, and a second resource identifier list. Each dimension corresponds to the access permission scope of a type of data resource.

[0062] In one embodiment, the step of querying the access domain scope of the current user may specifically include: obtaining the user identifier associated with the current request, and querying whether the current user has administrator privileges based on the user identifier; if the current user has administrator privileges, determining a preset list of full data identifiers as the access domain scope, wherein the list of full data identifiers is used to indicate that the current user has the right to access all data resources; if the current user does not have administrator privileges, determining an organization identifier list based on the user identifier, and determining the access domain scope based on the organization identifier list. Therefore, by distinguishing the permission query paths for administrators and non-administrators, differentiated permission acquisition strategies are adopted for users with different identities, improving processing efficiency in administrator scenarios while ensuring the accuracy of permissions for ordinary users.

[0063] Specifically, the user access domain query engine first obtains the user identifier and application identifier associated with the current request. Based on the user identifier and application identifier, it queries whether the current user has administrator privileges. If the current user has administrator privileges, the preset list of all data identifiers is determined as the access domain scope. The list of all data identifiers indicates that the current user has the right to access all data resources, that is, the administrator can view all data in the system without restriction.

[0064] It should be noted that if the current user does not have administrator privileges, the user access domain query engine will query the current user's permission type based on the user identifier. Permission types include "self-only permissions" and "multi-organization permissions." In the case of "self-only permissions," the system determines the access domain scope based on the current user's own identifier list; that is, the user can only access data resources related to themselves (e.g., only view resources created or belonging to themselves). In the case of "multi-organization permissions," the system queries the list of organization identifiers to which the current user belongs based on the user identifier, and then queries the corresponding first resource identifier list and second resource identifier list based on the organization identifier list. The first resource identifier list represents the set of identifiers for data resources belonging to the organization identifier list (e.g., the list of vehicle identifiers belonging to these organizations), and the second resource identifier list represents the set of identifiers for user resources belonging to the organization identifier list (e.g., the list of user identifiers belonging to these organizations).

[0065] Furthermore, after retrieving the list of organization identifiers to which the user belongs, the system also adds the identifier of the user's own organization to the organization identifier list, resulting in the final organization identifier list. This is because in actual business operations, the user's own organization should usually also be included in their permission scope; automatic addition avoids permission gaps due to omissions in organization affiliation. Finally, the system determines the access domain scope based on the organization identifier list, the first resource identifier list, and the second resource identifier list.

[0066] In this embodiment, the path distinguishing between administrators and non-administrators enables differentiated permission acquisition strategies for users with different identities. For administrators, a full list of data identifiers is returned directly, eliminating the need for subsequent fine-grained queries and improving processing efficiency. For ordinary users, the specific access domain is further determined based on their organizational affiliation, ensuring the accuracy of permissions.

[0067] In one embodiment, the step of determining an organization identifier list based on a user identifier and determining the access domain scope based on the organization identifier list may specifically include: querying the current user's permission type based on the user identifier; if the permission type is a self-only permission type, determining the current user's own identifier list as the access domain scope; if the permission type is a multi-organization permission type, querying the organization identifier list to which the current user belongs based on the user identifier, and querying the corresponding first resource identifier list and second resource identifier list based on the organization identifier list, wherein the first resource identifier list is used to represent the identifier set of data resources belonging to the organization identifier list, and the second resource identifier list is used to represent the identifier set of user resources belonging to the organization identifier list; adding the organization identifier to which the current user belongs to the organization identifier list to obtain the final organization identifier list; and determining the organization identifier list, the first resource identifier list, and the second resource identifier list as the access domain scope. Therefore, by handling self-only and multi-organization permission scenarios separately, and automatically including the user's own organization in the permission scope in the multi-organization permission scenario, fine-grained adaptation to multiple permission types is achieved, avoiding permission omissions due to organizational hierarchy.

[0068] It's worth noting that by further distinguishing between "user-only permissions" and "multi-organization permissions," fine-grained control of permissions is achieved. In the "user-only permissions" scenario, users can only access their own data, effectively isolating data from different users. In the "multi-organization permissions" scenario, the system automatically queries the user's organization and its resources, automatically including the user's own organization within the permission scope, avoiding permission omissions due to organizational hierarchies. In this way, the system can adapt to the permission requirements of different business scenarios, ensuring both data security and the convenience of organizational collaboration.

[0069] In this embodiment, after completing the access domain range query, the system enters the empty access domain detection phase. The empty access domain detection is performed by the empty access domain intelligent processing engine. If the data identifier list for all dimensions within the queried access domain range is empty (i.e., the user has no authorized data range under the current request conditions), then processing is performed according to the empty return strategy configured in the access domain filtering configuration annotation. This processing has been described in detail in step 201 and will not be repeated here. If the access domain range is not empty, subsequent intelligent set operations continue to be performed.

[0070] In one embodiment, prior to step 204 below, if the data identifier lists for all dimensions within the access domain are empty, the empty handling method for the access domain can be determined based on the empty return policy configured in the access domain filtering configuration annotation. If the empty return policy is enabled, an empty result is returned directly, terminating the execution of the business method. If the empty return policy is disabled, the field value of the corresponding dimension in the request parameter object is set to a preset special flag value, where the special flag value is used to instruct the business method to skip data query operations during execution. Therefore, by detecting empty access domains and adopting a preset empty handling policy before injection, queries can be terminated or query interception flags can be set in advance when the user has no data permissions, avoiding invalid full table scans and improving system performance and security.

[0071] It should be noted that this application avoids the potential full table scan problem caused by executing business methods when users have no data permissions by introducing a null access domain detection and intelligent processing mechanism. For interfaces configured with a null return policy, an empty result is returned directly, which improves response speed and prevents the risk of unauthorized access. For interfaces without a null return policy, a special flag value (such as -1) is set to prompt the business method to skip the query, which also avoids invalid database operations. This mechanism effectively improves system performance and security.

[0072] Furthermore, after the empty access domain detection passes, the system enters the intelligent set operation stage. This stage is executed by the intelligent set operation engine in the intelligent processing layer. Based on the combination of empty values ​​in the organization identifier list and the first resource identifier list in the request parameter object, it intelligently selects intersection or union operation to merge the multi-dimensional access domains and obtain the first resource identifier list for injection.

[0073] In one embodiment, before step 204 below, the organization identifier list and the first resource identifier list in the request parameter object can be obtained; if the organization identifier list is empty and the first resource identifier list is not empty, the intersection operation of the first resource identifier list in the access domain scope and the first resource identifier list in the request parameter object is performed to obtain the injection first resource identifier list; if the organization identifier list is not empty and the first resource identifier list is not empty, the union operation of the first resource identifier list associated with the organization identifier list in the access domain scope and the first resource identifier list in the request parameter object is performed to obtain the injection first resource identifier list; in the organization identifier column When the list is not empty and the first resource identifier list is empty, according to the operation method configured in the access domain filtering configuration annotation, the first resource identifier list associated with the organization identifier list in the access domain scope is selected to perform an intersection or union operation with the empty set to obtain the first resource identifier list for injection. When both the organization identifier list and the first resource identifier list are empty, according to the operation method configured in the access domain filtering configuration annotation, the first resource identifier list in the access domain scope is selected to perform an intersection or union operation with the empty set to obtain the first resource identifier list for injection. The first resource identifier list for injection is used as the data identifier list of the first resource dimension in the access domain scope. Thus, by intelligently selecting intersection or union operation based on the null value combination of organization identifier and resource identifier, the optimal set operation method is automatically adopted for different business scenarios, maximizing the range of data accessible to users while ensuring permission security.

[0074] Specifically, the intelligent collection computing engine first obtains the list of organization identifiers (i.e., the organizations selected by the user on the front end) and the list of first resource identifiers (i.e., the resources selected by the user on the front end) from the request parameter object. Based on the combination of null values ​​in both, the system determines the current business scenario and accordingly determines the computing method. The business scenarios include the following four: Organization with vehicle (organization identifier list and first resource identifier list are both non-empty), Organization without vehicle (organization identifier list is both non-empty and first resource identifier list is empty), No organization with vehicle (organization identifier list is empty and first resource identifier list is both non-empty), No organization without vehicle (organization identifier list is empty and first resource identifier list is empty). Here, "vehicle" is an example of the first resource dimension; in actual applications, it can be replaced with other resource types according to business needs.

[0075] For example, the intelligent ensemble computing engine adopts the following computing rules for different scenarios: In the "organized and vehicle-based" scenario, the first resource identifier list associated with the organization identifier list in the access domain (i.e., the complete set of resources under the organization) is combined with the first resource identifier list in the request parameter object (i.e., the resources selected by the user) to obtain the first resource identifier list for injection. The purpose of this operation is to expand the scope of permissions, allowing users to access both resources under their organization and resources they individually select.

[0076] In the "organized but vehicle-less" scenario, based on the calculation method configured in the access domain filtering configuration annotation, the first resource identifier list associated with the organization identifier list within the access domain scope is either intersected or unioned with an empty set to obtain the first resource identifier list for injection. If configured as union, the injection list is the complete set of resources under the organization; if configured as intersection, the injection list is empty.

[0077] In the "unorganized but with access to resources" scenario, a mandatory intersection operation is employed: the first resource identifier list (i.e., the user's full resource permissions) within the access domain is intersected with the first resource identifier list in the request parameter object to obtain the first resource identifier list for injection. This mandatory intersection rule is one of the key innovations of this application. When a user selects a specific resource without choosing any organization, the intersection must be taken to prevent the expansion of permissions, ensuring that the user can only access the resources they have permissions for and have explicitly selected, and cannot degenerate into accessing all resources due to the "unorganized" condition.

[0078] In the "no organization, no vehicle" scenario, based on the operation method configured in the access domain filtering configuration annotation, the first resource identifier list in the access domain range is selected to perform an intersection operation or a union operation with the empty set to obtain the first resource identifier list for injection.

[0079] After completing the above calculations, the intelligent collection calculation engine uses the resulting list of first resource identifiers for injection as the list of data identifiers for the first resource dimension in the access domain, for use in subsequent injection steps.

[0080] It should be noted that the intelligent intersection and union switching algorithm described above automatically selects the optimal set operation method for different business scenarios. In the "unorganized but with vehicles" scenario, forced intersection is used, effectively preventing the risk of accidentally expanding the scope of permissions due to a lack of organizational conditions. In the "organized but with vehicles" scenario, union is used, allowing users to simultaneously obtain the union of organizational permissions and individual selection permissions, meeting the reasonable need to expand the query scope in business operations. Through this dynamic adaptation, the system maximizes the range of data accessible to users while ensuring permission security, avoiding the expansion or reduction of permissions, and improving user experience and the accuracy of permission control.

[0081] In this embodiment, step 203 completes the query from user identifier to access domain range, empty access domain detection, and intelligent merging of multi-dimensional access domains. The next step is the access domain injection stage, where the finalized list of organization identifiers, the first resource identifier list, and the second resource identifier list are written into the request parameter object via reflection.

[0082] Step 204: Inject the access domain scope into the request parameter object to obtain the injected request parameter object.

[0083] In this embodiment, after the access domain query, empty access domain detection, and intelligent set operation described in the preceding embodiments, the system has obtained the final determined access domain range, including data identifier lists of multiple dimensions such as the organization identifier list, the first resource identifier list, and the second resource identifier list. This step is executed by the reflection parameter injection engine in the AOP aspect layer, which is responsible for writing this access domain information into the request parameter object, so that subsequent business methods can directly use the injected permission range to perform data queries.

[0084] In one embodiment, step 204 may specifically include: traversing each dimension in the access domain and obtaining the field name and field value corresponding to each dimension; converting the field name into a field setting method name according to a preset naming rule; if a field setting method matching the field setting method name exists in the class corresponding to the request parameter object, calling the field setting method and passing the field value as an input parameter to the field setting method to complete the injection; if no field setting method matching the field setting method name exists in the class corresponding to the request parameter object, obtaining the field object corresponding to the field name in the request parameter object through reflection, setting the accessibility of the field object, converting the field value according to the type of the field object, and setting the converted field value into the field object. Therefore, by prioritizing the use of standard field setting methods for injection and directly manipulating fields through reflection when the method does not exist, it is compatible with multiple parameter object structures, improving the universality and robustness of the injection process and reducing injection failures caused by differences in parameter structures.

[0085] It should be noted that the reflection parameter injection engine can employ the following strategy for injection: First, it iterates through each dimension in the access domain, retrieving the field name and value corresponding to each dimension. The field name is pre-configured in the access domain filter annotation (e.g., the field name for "Organization Identifier List" is "orgIds" in the request parameter object), and the field value is the data identifier list for that dimension (e.g., the specific set of IDs for the organization identifier list). Then, the field name is converted to the field setting method name according to camelCase naming conventions. CamelCase is a naming convention that concatenates multiple words, with the first word lowercase and the first letter of each subsequent word capitalized. For example, the field name "Organization Identifier List" is converted to the field setting method name "Set Organization Identifier List" (corresponding to the English method name "setOrgIds").

[0086] Furthermore, the reflection-based parameter injection engine searches for a field setting method in the class corresponding to the request parameter object that matches the field setting method name. If it exists, the engine calls the field setting method, passing the field value as an input parameter to complete the injection. If it doesn't exist, the engine uses reflection to obtain the field object corresponding to the field name in the request parameter object, sets the accessibility of the field object, performs type conversion on the field value according to the field object's type, and sets the type-converted field value into the field object. Type conversion supports automatic conversion between integer and string types. For example, when the field type is integer and the field value is the string "1,2,3", the engine will parse it into a list of integers before assigning the value.

[0087] In this embodiment, by prioritizing the use of standard field setting methods and then using reflection to directly manipulate fields, the system maintains code standardization (calling according to standards) while ensuring the robustness of the injection process (injection can also be completed via reflection). Furthermore, a type conversion mechanism prevents injection failures due to parameter type mismatches. Through reflection injection, automated injection of access domain scopes into request parameter objects is achieved. This mechanism eliminates the need for developers to manually assign values ​​in business code; instead, it is handled uniformly by the AOP aspect layer, further reducing code coupling. Simultaneously, by being compatible with both methods, injection can be correctly completed regardless of the structure of the request parameter object, improving the versatility of the solution.

[0088] In this embodiment, after injection, an injected request parameter object is obtained. This object already contains the current user's access domain scope in various dimensions (e.g., the organization identifier list has been set to the set of organization IDs the user has permission to access, and the first resource identifier list has been set to the set of resource IDs the user has permission to access). Subsequently, the AOP aspect engine allows access, executes the original business method, and passes the injected request parameter object as an input parameter. The business method can directly use these injected permission scopes for data querying without writing any further permission checking code. In other words, the permission control logic and business processing logic are completely decoupled.

[0089] Step 205: Execute the business method based on the injected request parameter object.

[0090] In this embodiment, after the aforementioned steps, the request parameter object already contains the current user's access domain range across various dimensions (such as the organization identifier list, the first resource identifier list, the second resource identifier list, etc.). The AOP aspect engine allows this, calls the original business method, and passes the injected request parameter object as an input parameter. When executing business logic, the business method directly uses the injected access domain range in the parameter object for data querying and permission determination, without needing to write any permission check code.

[0091] The execution process of the business method involves two main stages: data query and permission determination. In the data query stage, the system constructs query conditions based on the access domain range (e.g., a list of organization identifiers) in the request parameter object, and retrieves a list of data objects from the database that meet the permission range. Based on this, the system further determines and adjusts the permission level for each data object, ultimately returning a result containing permission identifiers.

[0092] In one embodiment, step 205 may specifically include the following steps: querying the parent organization identifiers corresponding to each organization identifier to which the current user belongs, based on the organization identifier list in the injected request parameter object; merging the parent organization identifiers with each organization identifier in the organization identifier list to remove duplicates, resulting in an expanded organization identifier list; and querying the data resources belonging to the expanded organization identifier list to obtain a data object list. Thus, by automatically querying the parent organization identifiers and merging them with the original organization identifiers, upward inheritance of permissions can be achieved without additional configuration, simplifying permission management in multi-level organizational structures.

[0093] It's important to note that to support permission inheritance in multi-level organizational structures, the system can expand the list of organization identifiers using a permission inheritance query engine before data queries. Specifically, the permission inheritance query engine retrieves the list of organization identifiers (i.e., the set of organization identifiers the current user is authorized to access) from the injected request parameter object. For each organization identifier in this list, the engine queries all its parent organization identifiers (i.e., superior organizations) in the organizational hierarchy. The query for parent organization identifiers supports multi-level upward tracing, up to the root organization. Subsequently, the engine merges all the retrieved parent organization identifiers with the original list of organization identifiers, removing duplicates, to obtain the expanded list of organization identifiers. This expanded list includes the identifiers of the user's organization and all its superior organizations, thus achieving upward inheritance of permissions: as long as the user's organization or any of its superior organizations has authorization for a certain data resource, the user can access that resource. Finally, based on the expanded list of organization identifiers, the system queries the data resources belonging to these organizations (e.g., vehicles, users, etc.) to obtain a list of data objects. This mechanism eliminates the need to configure permissions separately for each sub-organization, simplifying permission management in multi-level organizational structures.

[0094] In one embodiment, step 205 may specifically include the following steps: obtaining a list of data objects whose permissions are to be determined; checking each permission source sequentially according to a preset permission priority order, wherein the permission priority order is: first resource dimension permission, second resource dimension permission, and organization dimension permission; if any permission source matches successfully, determining the current permission level of the current data object and stopping the checking of subsequent permission sources; if the current permission level has been determined to be edit permission, prohibiting subsequent read-only permissions from overriding edit permissions. Therefore, by checking permission sources according to a preset priority order and prohibiting lower permissions from overriding higher permissions after higher permissions have taken effect, the correctness and stability of permission determination are ensured, avoiding permission downgrade problems caused by multi-source permission conflicts.

[0095] It should be noted that for the acquired list of data objects, the system can use the evidence-based intelligent processing engine in the permission control layer to determine the permission level for each data object. The evidence-based intelligent processing engine checks each permission source sequentially according to a preset permission priority order. Taking a typical business scenario as an example, the permission priority order is: first resource dimension permission (e.g., vehicle resource permission), second resource dimension permission (e.g., user resource permission), and organization dimension permission (e.g., organization permission). The design principle of the priority order is: the more direct and precise the authorization source, the higher the priority; high-priority permissions take effect first.

[0096] The evidence permission intelligent processing engine checks whether the current data object meets the authorization conditions of the permission source in priority order. For example, it first checks the first resource dimension permission: if the current data object belongs to the first resource dimension (e.g., the evidence comes from a vehicle resource that the user has permission to access), then editing permission is granted directly, and subsequent checks stop; if not, it continues to check the second resource dimension permission (e.g., the owner of the evidence is a person the user has permission to access); if still not, it continues to check the organization dimension permission (e.g., the evidence is shared with the user's organization). Once any permission source is successfully matched, the current permission level of the current data object is determined, and subsequent sources are no longer checked. This priority mechanism ensures that the most accurate permission source takes effect first.

[0097] In one possible implementation, a non-downgrade protection mechanism is simultaneously activated during the permission level determination process: if the current permission level is determined to be edit permission during the check, any subsequent read-only permission will be prevented from overriding it, thus avoiding permission downgrade due to lower-priority permissions overriding higher-priority permissions. For example, if the permission level has been determined to be edit permission based on the first resource dimension, even if it is subsequently determined to be read-only permission based on the organization dimension, the permission level of the data object will not change. This protection mechanism ensures that existing high permissions will not be downgraded by lower permissions, guaranteeing the security of permission control.

[0098] In this embodiment, the aforementioned permission determination process can be further combined with a state-aware permission adjustment engine to achieve dynamic permission downgrading based on resource status. After completing the priority determination, the state-aware permission adjustment engine obtains the resource status identifier (such as a deletion flag) of the current data object. If the resource status identifier indicates that the current data object is in the recycle bin state (i.e., it has been deleted but not completely cleared), then regardless of the priority determination result, the current permission level will be downgraded to read-only. For administrator users, the system also applies this downgrading rule: even if the administrator has editing permissions for all data, the permission level for data objects in the recycle bin will also be downgraded to read-only. By batch querying resource status identifiers and caching them in a key-value mapping table, the engine avoids repeated queries and improves processing efficiency. This mechanism achieves fine-grained permission control for resources in special states, effectively prevents accidental operations on deleted resources, and improves system security.

[0099] The business execution method disclosed in the above embodiments of this application first intercepts business methods annotated with access domain filtering configuration annotations using AOP aspects; then, it obtains the request parameter object of the business method; next, it queries the current user's access domain scope, which includes a data identifier list of at least one dimension, with each dimension corresponding to the access permission scope of a type of data resource; further, it injects the access domain scope into the request parameter object to obtain the injected request parameter object; finally, it executes the business method based on the injected request parameter object. Thus, by intercepting business methods annotated with access domain filtering configuration annotations using AOP aspects, automatically querying the user's multi-dimensional access domain scope and injecting it into the request parameter object before executing the business method, it decouples the permission control logic from the business processing logic, avoids repeatedly writing permission check code in each business method, and achieves unified management and non-intrusive application of permission control.

[0100] To facilitate understanding, the business execution method provided in this application embodiment will be fully described below with reference to a specific application scenario.

[0101] Take the "Query Resource List" function in an organizational business system as an example. The original input parameter for this function was a request parameter object, which included a list of organization identifiers selected by the user on the front end and a first resource identifier list (e.g., a resource identifier list). Traditionally, developers would need to manually write code within this function to query the current user's organization and the range of accessible resources, then combine the permission range with the query conditions before executing the data query. However, in this embodiment, developers only need to annotate the "Query Resource List" function with an access domain filtering configuration annotation and configure the field name for the organization identifier list as "orgIds" and the field name for the first resource identifier list as "resourceIds".

[0102] When a user initiates a query request, the AOP aspect engine automatically intercepts the method (see the description in step 201 above for details). The aspect engine extracts the request parameter object and converts it into a key-value pair mapping table (see the description in step 202 above). The SPEL expression parsing engine dynamically determines whether to enable access domain filtering for the first and second resource dimensions based on the first and second expressions configured in the mapping table parsing annotation (see the description in step 202 above). Subsequently, the user access domain query engine queries the user's access domain scope based on the current user identifier: if the user is an administrator, it directly returns the full list of data identifiers; if the user is a regular user, it queries the organization identifier list, the first resource identifier list, and the second resource identifier list based on the user's permission type (only self-permission or multi-organization permission), and adds the user's own organization to the organization identifier list (see the description in step 203 above).

[0103] If all data identifier lists within the access domain are empty, an empty list is returned directly according to the empty return strategy, or a special flag value is set (see the relevant description of step 203 above). If not empty, the intelligent collection operation engine obtains the organization identifier list and the first resource identifier list from the request parameter object, and intelligently selects intersection or union operation based on the combination of empty values ​​of the two. For example, if the user does not select any organization but selects a specific resource (in the scenario of having a vehicle but no organization), then the intersection is forced, and the first resource identifier list in the access domain is intersected with the first resource identifier list in the request parameter object to obtain the first resource identifier list for injection (see the relevant description of step 203 above).

[0104] The reflection parameter injection engine traverses each dimension of the access domain and injects the organization identifier list, first resource identifier list, second resource identifier list, etc., into the corresponding fields of the request parameter object by either prioritizing the invocation of field setting methods or directly manipulating fields using reflection (see the relevant description in step 204 above). After injection, the injected request parameter object is obtained.

[0105] The AOP aspect engine allows access and calls the original business method (see the relevant description in step 205 above). Inside the business method, the permission inheritance query engine queries the parent organization identifiers of each organization based on the organization identifier list, merges them with the original organization identifiers to remove duplicates, and obtains an expanded list of organization identifiers, thus implementing permission inheritance. The data access layer queries the list of data objects based on the expanded list of organization identifiers. For each data object found, the evidence-based permission intelligent processing engine checks the permission source in the order of priority: first resource dimension permission, second resource dimension permission, and organization dimension permission. If a match is found, the permission level is determined, and it is ensured that the edit permission is not overwritten by subsequent read-only permissions. The state-aware permission adjustment engine further checks the resource state of the data object. If it is in the recycle bin state, the permission level is downgraded to read-only permission. Finally, a list of data objects containing permission identifiers is returned.

[0106] As can be seen from the above examples, the embodiments of this application completely extract the permission control logic from the business methods. Developers only need to annotate to achieve automatic injection of multi-dimensional access domains and intelligent permission control, which significantly reduces code redundancy and maintenance costs.

[0107] See Figure 3 The diagram shows a schematic of a business execution device provided in an embodiment of this application. For ease of explanation, only the parts related to the embodiment of this application are shown.

[0108] The business execution device may specifically include the following modules: The business interception module 301 is used to intercept business methods marked with access domain filtering configuration annotations through AOP aspects.

[0109] Object retrieval module 302 is used to retrieve the request parameter object of the business method.

[0110] The range query module 303 is used to query the access domain range of the current user. The access domain range includes a data identifier list of at least one dimension, and each dimension corresponds to the access permission range of a type of data resource.

[0111] The range injection module 304 is used to inject the access domain range into the request parameter object to obtain the injected request parameter object.

[0112] The business execution module 305 is used to execute business methods based on the injected request parameter object.

[0113] The business execution apparatus disclosed in the above embodiments of this application first intercepts business methods annotated with access domain filtering configuration annotations using AOP aspects; then, it obtains the request parameter object of the business method; next, it queries the current user's access domain range, which includes a data identifier list of at least one dimension, with each dimension corresponding to the access permission range of a type of data resource; further, it injects the access domain range into the request parameter object to obtain the injected request parameter object; finally, it executes the business method based on the injected request parameter object. Thus, by intercepting business methods annotated with access domain filtering configuration annotations using AOP aspects, automatically querying the user's multi-dimensional access domain range and injecting it into the request parameter object before executing the business method, it decouples the permission control logic from the business processing logic, avoids repeatedly writing permission check code in each business method, and achieves unified management and non-intrusive application of permission control.

[0114] Furthermore, in one possible implementation of this application embodiment, the range query module 303 may specifically include the following units: The first acquisition unit is used to acquire the user identifier associated with the current request and query whether the current user has administrator privileges based on the user identifier.

[0115] The first determining unit is used to determine the access domain scope as a preset full data identifier list when the current user has administrator privileges, wherein the full data identifier list is used to indicate that the current user has the right to access all data resources.

[0116] The second determining unit is used to determine the list of organization identifiers based on the user identifier when the current user does not have administrator privileges, and to determine the access domain range based on the list of organization identifiers.

[0117] Therefore, by differentiating the permission query paths for administrators and non-administrators, differentiated permission acquisition strategies can be adopted for users with different identities, improving processing efficiency in administrator scenarios while ensuring the accuracy of permissions for ordinary users.

[0118] Furthermore, in another possible implementation of this application embodiment, the second determining unit can be specifically used to: query the current user's permission type based on the user identifier; if the permission type is only the user's own permission type, determine the current user's own identifier list as the access domain range; if the permission type is multiple organization permission type, query the organization identifier list to which the current user belongs based on the user identifier, and query the corresponding first resource identifier list and second resource identifier list based on the organization identifier list, wherein the first resource identifier list is used to represent the identifier set of data resources belonging to the organization identifier list, and the second resource identifier list is used to represent the identifier set of user resources belonging to the organization identifier list; add the organization identifier to which the current user belongs to the organization identifier list to obtain the final organization identifier list; and determine the organization identifier list, the first resource identifier list, and the second resource identifier list as the access domain range.

[0119] Therefore, by handling scenarios with only self-permission and multi-organizational permissions separately, and automatically including the user's own organization in the permission scope in multi-organizational permission scenarios, fine-grained adaptation to various permission types can be achieved, avoiding permission omissions caused by organizational hierarchy.

[0120] Furthermore, in another possible implementation of this application embodiment, the range injection module 304 may specifically include the following units: The second acquisition unit is used to traverse each dimension in the access domain range and obtain the field name and field value corresponding to each dimension.

[0121] The first processing unit is used to convert field names into field setting method names according to preset naming rules.

[0122] The second processing unit is used to call the field setting method when there is a field setting method in the class corresponding to the request parameter object that matches the field setting method name, and pass the field value as an input parameter to the field setting method to complete the injection.

[0123] The third processing unit is used to obtain the field object corresponding to the field name in the request parameter object through reflection when there is no field setting method matching the field setting method name in the class corresponding to the request parameter object, set the accessibility of the field object, perform type conversion on the field value according to the type of the field object, and set the type-converted field value into the field object.

[0124] Therefore, by prioritizing the use of standard field setting methods for injection, and directly manipulating fields through reflection when the methods do not exist, this approach is compatible with various parameter object structures, improving the universality and robustness of the injection process and reducing injection failures caused by differences in parameter structures.

[0125] Furthermore, in another possible implementation of this application embodiment, the above-mentioned business execution device may further include the following modules: The empty access domain processing module is used to determine the empty handling method for the access domain before injecting the access domain scope into the request parameter object, when all dimensions' data identifier lists in the access domain scope are empty, based on the empty return strategy configured in the access domain filtering configuration annotation. If the empty return strategy is enabled, an empty result is returned directly, and the execution of the business method is terminated. If the empty return strategy is disabled, the field value of the corresponding dimension in the request parameter object is set to a preset special marker value, where the special marker value is used to instruct the business method to skip the data query operation during execution.

[0126] Therefore, by detecting empty access fields before injection and adopting a preset empty handling strategy, queries can be terminated in advance or query interception flags can be set when users have no data permissions, thus avoiding invalid full table scans and improving system performance and security.

[0127] Furthermore, in another possible implementation of this application embodiment, the above-mentioned business execution device may further include the following modules: The dynamic control module converts the request parameter object into a key-value pair mapping table before querying the current user's access domain scope. The keys in the key-value pair mapping table are the field names in the request parameter object, and the values ​​are the field values. It then retrieves the first and second expressions configured in the access domain filtering configuration annotation. The first expression controls whether access domain filtering for the first resource dimension is enabled, and the second expression controls whether access domain filtering for the second resource dimension is enabled. Using the key-value pair mapping table as the expression parsing context, it parses the first expression to obtain a first parsing result and determines whether to enable access domain filtering for the first resource dimension based on the first parsing result. Similarly, it uses the key-value pair mapping table as the expression parsing context to parse the second expression to obtain a second parsing result and determines whether to enable access domain filtering for the second resource dimension based on the second parsing result. The first and second resource dimensions correspond to two different dimensions within the access domain scope.

[0128] Therefore, by using expressions to dynamically parse request parameters, the system can determine in real time whether to enable filtering based on specific dimensions according to the current request content, thereby achieving flexible control over filtering conditions and adapting to the permission configuration requirements of different business scenarios without modifying the code.

[0129] Furthermore, in another possible implementation of this application embodiment, the above-mentioned business execution device may further include the following modules: The intersection / union switching module is used to obtain the organization identifier list and the first resource identifier list in the request parameter object before injecting the access domain scope into the request parameter object; if the organization identifier list is empty and the first resource identifier list is not empty, the intersection operation is performed on the first resource identifier list in the access domain scope and the first resource identifier list in the request parameter object to obtain the first resource identifier list for injection; if the organization identifier list is not empty and the first resource identifier list is not empty, the union operation is performed on the first resource identifier list associated with the organization identifier list in the access domain scope and the first resource identifier list in the request parameter object to obtain the first resource identifier list for injection; If the organization identifier list is not empty and the first resource identifier list is empty, according to the operation method configured in the access domain filtering configuration annotation, the first resource identifier list associated with the organization identifier list in the access domain scope is selected to perform an intersection operation or a union operation with the empty set to obtain the first resource identifier list for injection; if the organization identifier list is empty and the first resource identifier list is empty, according to the operation method configured in the access domain filtering configuration annotation, the first resource identifier list in the access domain scope is selected to perform an intersection operation or a union operation with the empty set to obtain the first resource identifier list for injection; the first resource identifier list for injection is used as the data identifier list of the first resource dimension in the access domain scope.

[0130] Therefore, by intelligently selecting intersection or union operations based on the null value combination of organization identifier and resource identifier, the optimal set operation method is automatically adopted for different business scenarios, maximizing the range of data accessible to users while ensuring access security.

[0131] Furthermore, in another possible implementation of this application embodiment, the above-mentioned business execution module 305 may specifically include the following units: The third acquisition unit is used to query the parent organization identifiers corresponding to each organization identifier to which the current user belongs, based on the list of organization identifiers in the injected request parameter object.

[0132] The fourth processing unit is used to merge and deduplicate the parent organization identifier with each organization identifier in the organization identifier list to obtain an expanded organization identifier list.

[0133] The fourth acquisition unit is used to query the data resources belonging to the expanded organization identifier list based on the expanded organization identifier list, and obtain a list of data objects.

[0134] Therefore, by automatically querying the parent organization identifier and merging it with the original organization identifier, permission inheritance can be achieved without additional configuration, simplifying permission management in multi-level organizational structures.

[0135] Furthermore, in another possible implementation of this application embodiment, the above-mentioned business execution module 305 may specifically include the following units: The fifth acquisition unit is used to acquire a list of data objects whose permissions need to be determined.

[0136] The fifth processing unit is used to check the source of each permission in sequence according to the preset permission priority order, wherein the permission priority order is: first resource dimension permission, second resource dimension permission, and organization dimension permission.

[0137] The sixth processing unit is used to determine the current permission level of the current data object and stop checking subsequent permission sources if any permission source is successfully matched.

[0138] The seventh processing unit is used to prevent read-only permissions from overriding edit permissions when the current permission level has been determined to be edit permission.

[0139] Therefore, by checking the source of permissions according to a preset priority order and prohibiting low-permission overriding after high-permission permissions take effect, the correctness and stability of permission determination are ensured, and permission downgrade problems caused by multi-source permission conflicts are avoided.

[0140] The business execution apparatus provided in this application embodiment can be applied in the foregoing method embodiment. For details, please refer to the description of the above method embodiment, which will not be repeated here.

[0141] Figure 4 This is a schematic diagram of the structure of the electronic device provided in an embodiment of this application. For example... Figure 4 As shown, the electronic device 400 of this embodiment includes: at least one processor 410 ( Figure 4 The diagram shows only one processor, a memory 420, and a computer program 421 stored in the memory 420 and executable on the at least one processor 410. When the processor 410 executes the computer program 421, it implements the steps in the above-described business execution method embodiment.

[0142] The electronic device 400 can be a desktop computer, laptop, handheld computer, cloud server, or other computing device. This electronic device may include, but is not limited to, a processor 410 and a memory 420. Those skilled in the art will understand that... Figure 4This is merely an example of electronic device 400 and does not constitute a limitation on electronic device 400. It may include more or fewer components than shown in the figure, or combine certain components, or different components. For example, it may also include input / output devices, network access devices, etc.

[0143] The processor 410 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0144] In some embodiments, the memory 420 may be an internal storage unit of the electronic device 400, such as a hard disk or memory of the electronic device 400. In other embodiments, the memory 420 may be an external storage device of the electronic device 400, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the electronic device 400. Furthermore, the memory 420 may include both internal and external storage units of the electronic device 400. The memory 420 is used to store the operating system, applications, boot loader, data, and other programs, such as the program code of the computer program. The memory 420 can also be used to temporarily store data that has been output or will be output.

[0145] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments 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. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0146] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0147] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0148] In the embodiments provided in this application, it should be understood that the disclosed devices / electronic devices and methods can be implemented in other ways. For example, the device / electronic device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0149] 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.

[0150] Furthermore, the functional units in the various embodiments of this application 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. The integrated unit can be implemented in hardware or as a software functional unit.

[0151] If the integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0152] The implementation of all or part of the processes in the methods of the above embodiments can also be accomplished by a computer program product. When the computer program product is run on an electronic device, the electronic device can implement the steps in the various method embodiments described above.

[0153] The embodiments described above are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications 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 this application, and should all be included within the protection scope of this application.

Claims

1. A business execution method, characterized in that, include: Intercept business methods annotated with access domain filtering configuration annotations using Aspect-Oriented Programming (AOP) aspects; Obtain the request parameter object of the business method; Query the access domain range of the current user. The access domain range includes a data identifier list with at least one dimension, and each dimension corresponds to the access permission range of a type of data resource. The access domain is injected into the request parameter object to obtain the injected request parameter object; The business method is executed based on the injected request parameter object.

2. The method according to claim 1, characterized in that, The query of the current user's access domain range includes: Obtain the user identifier associated with the current request, and query whether the current user has administrator privileges based on the user identifier; When the current user has administrator privileges, a preset list of full data identifiers is determined as the access domain, wherein the list of full data identifiers is used to indicate that the current user has the right to access all data resources; If the current user does not have administrator privileges, an organization identifier list is determined based on the user identifier, and the access domain range is determined based on the organization identifier list.

3. The method according to claim 2, characterized in that, The step of determining the organization identifier list based on the user identifier and determining the access domain range based on the organization identifier list includes: Query the current user's permission type based on the user identifier; When the permission type is only self-permission type, the current user's own identifier list is determined as the access domain range; When the permission type is a multi-organization permission type, the organization identifier list to which the current user belongs is queried according to the user identifier, and the corresponding first resource identifier list and second resource identifier list are queried according to the organization identifier list. The first resource identifier list is used to represent the identifier set of data resources belonging to the organization identifier list, and the second resource identifier list is used to represent the identifier set of user resources belonging to the organization identifier list. Add the organization identifier to which the current user belongs to the organization identifier list to obtain the final organization identifier list; The organization identifier list, the first resource identifier list, and the second resource identifier list are determined as the access domain range.

4. The method according to claim 1, characterized in that, The step of injecting the access domain scope into the request parameter object includes: Iterate through each dimension in the access domain to obtain the field name and field value corresponding to each dimension; Convert the field name into a field setting method name according to a preset naming rule; If a field setting method with a name matching the field setting method exists in the class corresponding to the request parameter object, the field setting method is called, and the field value is passed to the field setting method as an input parameter to complete the injection; If there is no field setting method in the class corresponding to the request parameter object that matches the name of the field setting method, the field object corresponding to the field name in the request parameter object is obtained through reflection, the accessibility of the field object is set, the field value is type-converted according to the type of the field object, and the type-converted field value is set into the field object.

5. The method according to claim 1, characterized in that, Before injecting the access domain scope into the request parameter object, the method further includes: If the data identifier list for all dimensions in the access domain is empty, the empty handling method for the access domain is determined according to the empty return strategy configured in the access domain filtering configuration annotation. If the empty return strategy is enabled, an empty result is returned directly, and the execution of the business method is terminated. When the empty return strategy is not enabled, the field value of the corresponding dimension in the request parameter object is set to a preset special marker value, wherein the special marker value is used to indicate that the business method skips the data query operation during execution.

6. The method according to claim 1, characterized in that, Before querying the current user's access domain range, the method further includes: The request parameter object is converted into a key-value pair mapping table, wherein the key of the key-value pair mapping table is the field name in the request parameter object, and the value of the key-value pair mapping table is the field value in the request parameter object; Obtain the first expression and the second expression configured in the access domain filtering configuration annotation, wherein the first expression is used to control whether access domain filtering of the first resource dimension is enabled, and the second expression is used to control whether access domain filtering of the second resource dimension is enabled. The key-value pair mapping table is used as an expression parsing context to parse the first expression, obtain the first parsing result, and determine whether to enable access domain filtering for the first resource dimension based on the first parsing result. The key-value pair mapping table is used as the expression parsing context to parse the second expression, obtain the second parsing result, and determine whether to enable access domain filtering for the second resource dimension based on the second parsing result; The first resource dimension and the second resource dimension correspond to two different dimensions in the access domain range, respectively.

7. The method according to claim 1, characterized in that, Before injecting the access domain scope into the request parameter object, the method further includes: Obtain the list of organization identifiers and the list of first resource identifiers from the request parameter object; If the organization identifier list is empty and the first resource identifier list is not empty, the first resource identifier list in the access domain range and the first resource identifier list in the request parameter object are intersected to obtain the first resource identifier list for injection. If the organization identifier list is not empty and the first resource identifier list is not empty, perform a union operation between the first resource identifier list associated with the organization identifier list in the access domain range and the first resource identifier list in the request parameter object to obtain the first resource identifier list for injection. When the organization identifier list is not empty and the first resource identifier list is empty, according to the operation method configured in the access domain filtering configuration annotation, the first resource identifier list associated with the organization identifier list in the access domain range is selected to perform an intersection operation or a union operation with the empty set to obtain the first resource identifier list for injection. When the organization identifier list is empty and the first resource identifier list is empty, according to the operation method configured in the access domain filtering configuration annotation, the first resource identifier list in the access domain range is selected to perform an intersection operation or a union operation with the empty set to obtain the first resource identifier list for injection. The first resource identifier list for injection is used as the data identifier list for the first resource dimension in the access domain scope.

8. The method according to claim 1, characterized in that, The step of executing the business method based on the injected request parameter object includes: Based on the list of organization identifiers in the injected request parameter object, query the parent organization identifiers corresponding to each organization identifier to which the current user belongs; The parent organization identifier is merged with each organization identifier in the organization identifier list and deduplicated to obtain an expanded organization identifier list; Based on the expanded list of organization identifiers, query the data resources belonging to the expanded list of organization identifiers to obtain a list of data objects.

9. The method according to claim 1, characterized in that, The step of executing the business method based on the injected request parameter object includes: Get the list of data objects whose permissions need to be determined; The permissions are checked sequentially according to a preset permission priority order, wherein the permission priority order is: first resource dimension permission, second resource dimension permission, and organization dimension permission. If any permission source matches successfully, determine the current permission level of the current data object and stop checking subsequent permission sources; If the current permission level has been determined to be edit permission, subsequent read-only permissions should not be allowed to override the edit permission.

10. 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 computer program, it implements the method as described in any one of claims 1 to 9.

Images