Cross-service link data authority control method and related equipment
By configuring global data permission rules in a distributed microservice system and working together with multiple interceptors, the redundancy and inconsistency of permission allocation are solved, and permission control and fine-grained data protection are achieved across the entire link and all domains.
Patent Information
- Application Number
- CN202510598449.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-05-09
- Publication Date
- 2025-08-08
AI Technical Summary
In distributed microservice systems, existing permission management methods lead to redundant and inconsistent permission allocation, making it difficult to achieve full-link and domain permission control, especially when cross-service calls are difficult to share and pass on permission information.
Configure global data permission rules through the permission management platform, use HTTP request interceptor, Feign interceptor and MyBatis interceptor to realize centralized management and recursive delivery of permission rules, generate row-level filtering conditions and column-level display restrictions, and invalidate the permissionless fields.
It realizes permission control across the entire link and the entire domain, improves the consistency, security and efficiency of permission management, and reduces the time overhead of permission query and update.
Smart Images
Figure CN120449187A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the technical field of data authority management, and more specifically, to a data authority control method and related equipment across service links. Background Art
[0002] Against the backdrop of today's rapidly developing digital businesses, enterprise system architectures are gradually evolving toward distributed, microservice-based systems. Different services or systems often employ independent permission management systems. Currently, the most relevant existing technologies include role-based access control (RBAC) and attribute-based access control (ABAC). RBAC binds permissions to roles, allowing users to obtain corresponding permissions by assigning roles. However, in complex and ever-changing business scenarios, the cost of role division and maintenance is high, making it difficult to flexibly respond to dynamic permission requirements. While attribute-based access control (ABAC) offers a certain degree of flexibility, it typically requires direct implementation through a single database or SQL cross-database queries. When integrated with microservices, the changes are significant and invasive, and are particularly challenging when handling permission control scenarios involving multiple RPC calls.
[0003] This independent permission management system leads to a series of problems, such as redundant permission allocation, where the same user may need to be repeatedly assigned permissions in different systems; inconsistent permissions, where permission standards and policies are not unified across different systems, which can easily lead to management chaos; permission information is difficult to transmit and share across domains, making it difficult to achieve effective permission control when data flows between different services; at the same time, centralized management of global permission policies is difficult to achieve, making it impossible to efficiently control permissions as a whole.
[0004] Therefore, a new permission management method is urgently needed to address the shortcomings of existing technologies and achieve full-link and full-domain permission control. Summary of the Invention
[0005] This application provides a data permission control method and related equipment across service links, which realizes centralized management and recursive transmission of permission information through unified configuration and global caching, and achieves full-link and global permission control across service links with the help of multiple interceptors to comprehensively improve the consistency, efficiency, security and scalability of permission management.
[0006] A data permission control method across service links, comprising:
[0007] Configure global data permission rules through the permission management platform. The global data permission rules include organizational structure permissions and field permissions, and store them in the global cache.
[0008] Receive a data access request initiated by a user through the front-end, parse the resource locator and data permission identifier in the request through the HTTP request interceptor, load the matching permission rules from the global cache, and bind the permission rules to the thread-local variables of the current service node;
[0009] When any service node in the cross-service chain calls the next service node, the Feign interceptor extracts the permission rules in the thread local variables of the current service node, attaches them to the HTTP request header and passes them to the next service node;
[0010] The next service node parses the permission rules in the HTTP request header through the Feign interceptor and saves the parsed permission rules into its thread local variables;
[0011] During the database query phase of any service node in the cross-service chain, the MyBatis interceptor is used to obtain permission rules from the thread-local variables, generate row-level filtering conditions or column-level display restriction conditions, and inject SQL query statements;
[0012] Query result data is determined based on the SQL query statement, and unauthorized fields in the query result data are invalidated according to the field permissions to generate final response data.
[0013] Optionally, the process of the HTTP request interceptor parsing the resource locator and data permission identifier in the request, loading the matching permission rules from the global cache, and binding the permission rules to the thread-local variables of the current service node includes:
[0014] Parse the resource locator in the request, and match the resource locator with a preset permission identifier mapping table to obtain the corresponding data permission identifier;
[0015] Locating matching permission rules from the global cache using a hash algorithm;
[0016] The matching permission rules are bound to the thread-local variables of the current service node in the form of key-value pairs, where the key is the data list identifier and the value is the role code and permission range.
[0017] Optionally, the process of the Feign interceptor appending the permission rule to the HTTP request header includes:
[0018] The permission rules are encapsulated as a preset HTTP request header field, wherein the HTTP request header field includes a permission identifier, a role code, and a data list identifier, and the naming of the HTTP request header field follows the naming rules agreed upon between service nodes.
[0019] Optionally, the MyBatis interceptor obtains permission rules from the thread local variables, generates row-level filtering conditions or column-level display restriction conditions, and injects SQL query statements, including:
[0020] Obtaining permission rules from the thread local variable;
[0021] Generate a row-level filtering condition based on the organizational structure permission in the permission rule, wherein the row-level filtering condition is used to limit the scope of the query result;
[0022] generating a column-level display restriction condition based on the field permission in the permission rule, wherein the column-level display restriction condition is used to restrict visibility or display content of the field in the query result;
[0023] The row-level filtering conditions and the column-level display restriction conditions are dynamically injected into the SQL query statement to implement data permission control.
[0024] Optionally, the process of invalidating the unauthorized fields in the query result data includes:
[0025] Parse the JSON structure of the query result data and filter out invalid fields according to the field permission whitelist;
[0026] The invalid field is left blank or replaced with a preset desensitizing mark.
[0027] Optionally, the configuration method of the global data permission rule includes:
[0028] The tree-shaped permission inheritance relationship of the multi-level organizational structure is configured through the visual interface, where child nodes inherit the permissions of the parent node by default, and manual setting of exception rules is supported;
[0029] Defining fine-grained combination control rules for field permissions in the visual interface, including whitelists and blacklists for field permissions;
[0030] The permission rules are updated in real time through the visual interface, and the synchronization refresh mechanism of the global cache is triggered after the update to ensure the consistency of the permission rules across all nodes in the service link.
[0031] A data permission control device across service links, comprising:
[0032] A permission configuration module is used to configure global data permission rules through the permission management platform. The global data permission rules include organizational structure permissions and field permissions, and are stored in the global cache;
[0033] The request parsing module is used to receive data access requests initiated by users through the front end, parse the resource locator and data permission identifier in the request through the HTTP request interceptor, load matching permission rules from the global cache, and bind the permission rules to the thread local variables of the current service node;
[0034] The permission transfer module is used to extract the permission rules in the thread local variables of the current service node through the Feign interceptor when any service node calls the next service node in the cross-service chain, attach them to the HTTP request header and pass them to the next service node. The next service node parses the permission rules in the HTTP request header through the Feign interceptor and saves the parsed permission rules to its thread local variables;
[0035] The permission control module is used to obtain permission rules from the thread local variables through the MyBatis interceptor during the database query phase of any service node in the cross-service chain, generate row-level filtering conditions or column-level display restriction conditions, and inject SQL query statements;
[0036] The data processing module is used to determine the query result data based on the SQL query statement, and invalidate the unauthorized fields in the query result data according to the field permissions to generate final response data.
[0037] A cross-service link data authority control device, comprising a memory and a processor;
[0038] The memory is used to store programs;
[0039] The processor is used to execute the program to implement each step of the data permission control method across service links as described in any one of the above items.
[0040] A readable storage medium having a computer program stored thereon, characterized in that when the computer program is executed by a processor, each step of the cross-service link data permission control method as described in any one of the above items is implemented.
[0041] A computer program product includes a computer program, characterized in that when the computer program is run by a processor, it executes each step of the cross-service link data permission control method as described in any one of the above items.
[0042] It can be seen from the above technical solution that the embodiment of the present application provides a data permission control method and related equipment across service links. First, global data permission rules including organizational structure permissions and field permissions are configured through the permission management platform and stored in the global cache; then, user data access requests are received, and the HTTP request interceptor is used to parse relevant information, and matching permission rules are loaded from the global cache and bound to the thread local variables of the current service node; when calling across services, permission rules are passed through the Feign interceptor; in the database query stage, filtering and restriction conditions are generated through the MyBatis interceptor and SQL query statements are injected; finally, the query result data is invalidated according to the field permissions.
[0043] This application achieves many beneficial effects: First, by uniformly configuring global data permission rules and storing them in the global cache, centralized management and unified recursive transmission of permission information are achieved, the problem of redundant and inconsistent permission allocation is solved, and the consistency of permission management is ensured; Second, in cross-service links, by utilizing components such as HTTP request interceptors, Feign interceptors, and MyBatis interceptors, efficient transmission and precise control of permission rules between service nodes are achieved, the problem of difficulty in cross-domain transmission and sharing of permission information is avoided, and full-link and full-domain permission control is achieved; Third, by generating row-level filtering conditions and column-level display restriction conditions, and invalidating unauthorized fields, fine-grained data permission control is achieved, and data security is improved; Fourth, the global cache loads and updates permission configurations at one time, reducing the time overhead of permission queries and updates, and improving the efficiency and scalability of permission management. BRIEF DESCRIPTION OF THE DRAWINGS
[0044] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without any creative work.
[0045] Figure 1 This is a flow chart of a data permission control method across service links disclosed in an embodiment of the present application;
[0046] Figure 2 A schematic diagram of a data permission control device across service links disclosed in an embodiment of the present application;
[0047] Figure 3 This is a hardware structure block diagram of a data permission control device across service links disclosed in an embodiment of the present application. DETAILED DESCRIPTION
[0048] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.
[0049] The present application can be used in a variety of general or special computing device environments or configurations, such as personal computers, server computers, handheld or portable devices, tablet devices, multi-processor devices, and distributed computing environments including any of the above devices or devices.
[0050] Next, we will introduce the application scheme. This application proposes the following technical scheme, please see below for details.
[0051] Figure 1 This is a flowchart of a data permission control method across service links disclosed in an embodiment of the present application.
[0052] like Figure 1 As shown, the method may include:
[0053] Step S1: Configure global data permission rules through the permission management platform. The global data permission rules include organizational structure permissions and field permissions, and are stored in the global cache.
[0054] Specifically, in the data permission control system across service links, global data permission rules can be configured through the permission management platform, and organizational structure permissions and field permissions can be planned in a coordinated manner and stored in the global cache. When configuring organizational structure permissions, a multi-level tree-shaped permission inheritance structure is built with the help of a visual interface. Under this structure, child nodes inherit the permissions of the parent node by default, which greatly improves the efficiency of permission allocation and is suitable for scenarios where most members of a large organization have similar permissions. At the same time, it supports manual setting of exception rules, which can flexibly respond to the permission requirements of special positions or special personnel. For example, personnel in the finance department may have different access rights to financial data than other departments. Exception rules can be accurately configured to meet the diverse permission management requirements under complex organizational structures.
[0055] Field permissions are also configured within the visual interface. By defining fine-grained combination control rules, you can set up whitelists and blacklists for field permissions. Whitelists explicitly specify fields that are allowed access, while blacklists prohibit access to certain sensitive fields, enabling precise control over data fields. For example, in a human resources management system, employee salary fields are only accessible to HR leaders and finance personnel. A blacklist can restrict access to other personnel, effectively ensuring data security and preventing the leakage of sensitive information.
[0056] When permission rules change, the visual interface supports real-time updates. Once the rules are updated, the system triggers a synchronous refresh mechanism for the global cache to ensure that all nodes across the service chain can obtain the latest permission rules in a timely manner. This mechanism avoids confusion in permission control caused by asynchronous permission rules. For example, if permissions need to be adjusted after an employee's position changes, the updated rules can be quickly synchronized to each service node to ensure the consistency and effectiveness of permission management. The configured global data permission rules are stored in the global cache for quick subsequent retrieval, providing data support for efficient permission control.
[0057] Based on this, the configuration methods of the global data permission rules include but are not limited to the following:
[0058] The first method is to configure the tree-shaped permission inheritance relationship of the multi-level organizational structure through the visual interface, where the child nodes inherit the permissions of the parent nodes by default, and support manual setting of exception rules;
[0059] The second method is to define fine-grained combination control rules for field permissions in the visual interface, including whitelists and blacklists for field permissions;
[0060] The third method is to update the permission rules in real time through the visual interface, and trigger the synchronous refresh mechanism of the global cache after the update to ensure the consistency of the permission rules across all nodes in the service link.
[0061] Step S2: Receive a data access request initiated by the user through the front end, parse the resource locator and data permission identifier in the request through the HTTP request interceptor, load the matching permission rules from the global cache, and bind the permission rules to the thread local variables of the current service node.
[0062] Specifically, when a user initiates a data access request through the front-end, the HTTP request interceptor parses the resource locator in the request. The resource locator identifies the specific resource the user is requesting access to and is an important basis for identifying user intent. The interceptor also parses the data permission identifier, which is used to determine the scope of permissions granted to the user for this request. By parsing these two key pieces of information, the user's request content and the corresponding permission level can be determined.
[0063] Next, based on the parsed resource locator and data permission identifier, the system loads matching permission rules from the global cache. The global cache stores the various global data permission rules configured in step S1. These rules cover important information such as organizational structure permissions and field permissions. Through precise matching, the system can quickly find the permission rule corresponding to the current request, providing an accurate basis for subsequent permission control.
[0064] Finally, the system binds the matched permission rules to the thread-local variables of the current service node in a specific manner. Thread-local variables are a mechanism for storing thread-private data in a multi-threaded environment. Binding permission rules to thread-local variables ensures that the permission rules remain accessible and usable throughout the entire process of the current service node processing the request. This allows subsequent operations, such as permission transfer during cross-service calls and permission control during database queries, to be performed based on accurate permission rules, thereby achieving precise permission control over user data access and ensuring data security and access compliance.
[0065] Step S2 can effectively combine the user's request with the pre-configured permission rules to ensure that requests flowing between different service nodes can be carried out under permission control, preventing unauthorized access and leakage of data.
[0066] Step S3: When any service node in the cross-service chain calls the next service node, the Feign interceptor extracts the permission rules in the thread local variables of the current service node, attaches them to the HTTP request header and passes them to the next service node.
[0067] Step S4: The next service node parses the permission rules in the HTTP request header through the Feign interceptor, and saves the parsed permission rules into its thread local variables.
[0068] Specifically, step S3 and step S4 are a recursive setting process of permission rules in a cross-service link. For any service node in the cross-service link, the permission rules can be transferred to the next service node through steps S3 and S4.
[0069] During the operation of a cross-service chain, when any service node needs to call the next service node, the Feign interceptor extracts the bound permission rules from the thread-local variables of the current service node. These rules contain key information such as the organizational structure permissions and field permissions that the user has for this data access. To prevent the permission rules from being illegally stolen or maliciously tampered with during network transmission, the Feign interceptor uses the AES algorithm to encrypt the extracted permission rules. After encryption, the Feign interceptor encapsulates the encrypted data into preset HTTP request header fields. These fields contain core information such as permission identifiers, role codes, and data list identifiers. The field naming strictly follows the pre-agreed naming rules between service nodes to ensure that the recipient can accurately identify and parse them. Finally, the Feign interceptor appends the encapsulated permission rules to the HTTP request header and passes them to the next service node, achieving efficient flow and secure transmission of permission rules between services.
[0070] The process of the Feign interceptor attaching the permission rules to the HTTP request header includes:
[0071] The permission rules are encapsulated as a preset HTTP request header field, wherein the HTTP request header field includes a permission identifier, a role code, and a data list identifier, and the naming of the HTTP request header field follows the naming rules agreed upon between service nodes.
[0072] In a cross-service chain, when a service node needs to call the next service node, the Feign interceptor appends permission rules to the HTTP request header. Specifically, the Feign interceptor encapsulates the permission rules into pre-defined HTTP request header fields. These fields act as containers for the specific information about the permission rules. These fields include a permission identifier, which indicates the type of permission granted by the request, such as read-only or read-write. The permission identifier allows the receiving service node to quickly determine the requested permission level. The role encoding is related to the user's role in the system. Different roles typically have different permission ranges. For example, an administrator role may have the highest permissions, while a user role may have relatively limited permissions. Using the role encoding, the service node can further refine its judgment of the requested permissions and determine whether the role is authorized to perform the requested operation. The data list identifier identifies the data list associated with the request. In some scenarios, a user may only have access to specific data lists. The data list identifier helps the service node accurately determine which data the user has access to. The naming of HTTP request header fields is not arbitrary and must follow the naming conventions agreed upon between service nodes. This is to ensure that different service nodes in the entire microservice architecture can identify and parse these fields in the same way, avoiding misunderstandings or incorrect processing due to inconsistent naming.
[0073] Saving permission rules to thread-local variables is of great significance. This allows the next service node to quickly and conveniently retrieve permission rules from thread-local variables in each subsequent step of processing data access requests, providing an accurate basis for further permission control. Whether performing internal business logic processing or continuing to initiate calls to other service nodes, it ensures that each service node always operates based on accurate and consistent permission rules when processing data access, thereby ensuring the accuracy and effectiveness of data permission control across the entire cross-service chain, and effectively avoiding data access security risks caused by inconsistent or missing permission rules.
[0074] Step S5: During the database query phase of any service node in the cross-service chain, the MyBatis interceptor is used to obtain permission rules from the thread local variables, generate row-level filtering conditions or column-level display restriction conditions, and inject SQL query statements.
[0075] Specifically, in a cross-service chain, when any service node enters the database query phase, step S5 uses the MyBatis interceptor to implement precise permission control for data access. The MyBatis interceptor first retrieves the saved permission rules from the thread-local variables of the current service node. These rules cover key information such as organizational structure permissions and field permissions, and are the core basis for database query permission control.
[0076] Based on the organizational structure permissions in the permission rules, the MyBatis interceptor generates row-level filtering conditions. For example, in an enterprise management system, employees in different departments can only view data within their own departments. The MyBatis interceptor adds a row-specific filtering condition to the SQL query statement based on the organizational structure permissions of the employee's department, such as "WHERE department_id=[current employee's department ID]." This limits the scope of the query results, ensuring that users can only access the data rows they are authorized to access, and preventing unauthorized access to data from other departments.
[0077] At the same time, based on the field permissions in the permission rules, the MyBatis interceptor generates column-level display restrictions. For example, in a financial system, ordinary employees can only view a subset of financial data fields, while financial management personnel can view all fields. Based on field permissions, the MyBatis interceptor sets display restrictions for fields in SQL queries, such as "SELECT field1, field2 FROM table WHERE [row-level filter condition]" (which only selects certain fields under ordinary employee permissions). This controls the visibility or display content of fields in query results, preventing users from seeing sensitive field information they don't have access to.
[0078] Finally, the MyBatis interceptor dynamically injects the generated row-level filters and column-level display restrictions into the SQL query statement. This approach integrates permission control requirements into the SQL statement before the database query is executed, enabling fine-grained data permission control at the database level. This ensures that database query results strictly comply with the user's permission range, effectively guaranteeing data security and access compliance.
[0079] Step S6: determining query result data based on the SQL query statement, and invalidating unauthorized fields in the query result data according to the field permissions to generate final response data.
[0080] Specifically, after the database completes the data query according to the SQL query statement injected with the permission control conditions in step S5, the query result data is obtained. However, not all of this information should be accessible to the user. Step S6 filters and processes the query result data based on the field permissions to generate the final response data that meets the user's permissions.
[0081] By comparing each field in the query result data with the pre-set field permissions. Field permissions are determined when configuring the global data permission rules in step S1. They clearly define the range of fields that different users or roles can access. Through this comparison, it is possible to accurately identify which fields are user-unauthorized fields. For identified unauthorized fields, invalidation operations will be performed. The specific processing method is as follows:
[0082] ① Parse the JSON structure of the query result data and filter out invalid fields according to the field permission whitelist;
[0083] ② Leave the invalid fields blank or replace them with preset desensitizing tags.
[0084] Typically, query result data is presented in JSON format. The query result data's JSON structure is first parsed, and then filtered based on the field permission whitelist. The field permission whitelist explicitly lists the fields that a user or role has access to. Each field in the JSON data is iterated over, and fields not in the whitelist are considered invalid and filtered.
[0085] There are two ways to handle invalid fields that are filtered out. One is to set the field value to blank, deleting the corresponding information; the other is to replace the field value with a preset desensitizing marker, such as "*" or "confidential information." This ensures the integrity of the data structure while preventing the leakage of sensitive information.
[0086] After invalidating unauthorized fields, the processed query result data is integrated and packaged to generate final response data that complies with the user's field permissions. This data is returned to the user, ensuring that they can only obtain information they are authorized to access, effectively avoiding the risk of data leakage and unauthorized access.
[0087] It can be seen from the above technical solution that the embodiment of the present application provides a data permission control method and related equipment across service links. First, global data permission rules including organizational structure permissions and field permissions are configured through the permission management platform and stored in the global cache; then, user data access requests are received, and the HTTP request interceptor is used to parse relevant information, and matching permission rules are loaded from the global cache and bound to the thread local variables of the current service node; when calling across services, permission rules are passed through the Feign interceptor; in the database query stage, filtering and restriction conditions are generated through the MyBatis interceptor and SQL query statements are injected; finally, the query result data is invalidated according to the field permissions.
[0088] This application achieves many beneficial effects: First, by uniformly configuring global data permission rules and storing them in the global cache, centralized management and unified recursive transmission of permission information are achieved, the problem of redundant and inconsistent permission allocation is solved, and the consistency of permission management is ensured; Second, in cross-service links, by utilizing components such as HTTP request interceptors, Feign interceptors, and MyBatis interceptors, efficient transmission and precise control of permission rules between service nodes are achieved, the problem of difficulty in cross-domain transmission and sharing of permission information is avoided, and full-link and full-domain permission control is achieved; Third, by generating row-level filtering conditions and column-level display restriction conditions, and invalidating unauthorized fields, fine-grained data permission control is achieved, and data security is improved; Fourth, the global cache loads and updates permission configurations at one time, reducing the time overhead of permission queries and updates, and improving the efficiency and scalability of permission management.
[0089] In some embodiments of the present application, the process of the HTTP request interceptor parsing the resource locator and data permission identifier in the request in step S2, loading the matching permission rules from the global cache, and binding the permission rules to the thread local variables of the current service node is introduced, which may specifically include:
[0090] Step S21: Parse the resource locator in the request, and match the resource locator with a preset permission identifier mapping table to obtain the corresponding data permission identifier;
[0091] Step S22: Locate the matching permission rule from the global cache using a hash algorithm;
[0092] Step S23: Bind the matched permission rules to the thread local variables of the current service node in the form of key-value pairs, where the key is the data list identifier and the value is the role code and permission range.
[0093] Specifically, the HTTP request interceptor first parses the resource locator (URL) in the request. The resource locator specifies the specific resource that the user requests to access. The interceptor matches the parsed resource locator in a preset permission identifier mapping table. The permission identifier mapping table pre-sets the permission identifiers corresponding to different resource locators. Through matching, the interceptor can obtain the data permission identifier corresponding to the resource locator. For example, if the resource locator requested by the user corresponds to a page that can only view partial information, the matched data permission identifier will reflect this permission restriction.
[0094] After obtaining the data permission identifier, the system uses a hash algorithm to locate the matching permission rule from the global cache. The hash algorithm takes the data permission identifier as input and calculates a hash value using a specific hash function. This hash value can be used to quickly find the corresponding permission rule in the global cache. The global cache stores the various permission rules configured in step S1. Using the hash algorithm can significantly improve the efficiency of permission rule retrieval, ensuring that the required permission rules can be quickly obtained when the user requests them.
[0095] After successfully locating the matching permission rules, these permission rules are bound to the thread-local variables of the current service node in the form of key-value pairs. Among them, the key is set to the data list identifier, which uniquely identifies a group of related data permission information, facilitating subsequent rapid indexing; the value contains the role code and permission range, which defines in detail the permissions the user has under the current request. For example, the role code can distinguish whether the user is an ordinary employee, administrator, or other specific role, while the permission range clarifies the role's access rights to different data. Binding the permission rules to the thread-local variables allows the permission rules to be quickly retrieved from the thread-local variables at any time during the subsequent processing of the current service node, regardless of the operation performed, providing important data support for achieving precise permission control.
[0096] In some embodiments of the present application, the process of the MyBatis interceptor in step S5 obtaining permission rules from the thread local variables, generating row-level filtering conditions or column-level display restriction conditions, and injecting SQL query statements is introduced, which may specifically include:
[0097] Step S51: Obtain permission rules from the thread local variables;
[0098] Step S52: Generate a row-level filtering condition based on the organizational structure permission in the permission rule, wherein the row-level filtering condition is used to limit the scope of the query result;
[0099] Step S53: Generate a column-level display restriction condition based on the field permission in the permission rule, wherein the column-level display restriction condition is used to restrict visibility or display content of the field in the query result;
[0100] Step S54: Dynamically inject the row-level filtering conditions and the column-level display restriction conditions into the SQL query statement to implement data authority control.
[0101] Specifically, the MyBatis interceptor first retrieves permission rules from the thread-local variables of the current service node. In step S2, the permission rules are bound to the thread-local variables, allowing for quick and easy access to the latest permission information when database queries are needed. These permission rules, configured in step S1 and stored in the global cache, include key information such as organizational structure permissions and field permissions.
[0102] Based on the organizational permissions in the obtained permission rules, the MyBatis interceptor generates row-level filtering conditions. Organizational permissions define the data access scope of different users or roles within the organizational structure. For example, in an enterprise system, employees in different departments can only access data within their own department. Based on these rules, the MyBatis interceptor generates SQL conditions such as "WHERE department_id=[current user's department ID]" to limit the scope of query results and ensure that users only retrieve data rows they have permission to access.
[0103] Based on the field permissions in the permission rules, the MyBatis interceptor generates column-level display restrictions. Field permissions specify the data fields that a user can view. For example, regular employees may only be able to view a subset of non-sensitive fields, while administrators can view all fields. Based on these rules, the MyBatis interceptor filters fields in SQL queries, generating statements like "SELECT field1, field2 FROM table..." to select only the fields that the user has permission to view, thereby limiting the visibility or display of fields in the query results.
[0104] Finally, the MyBatis interceptor dynamically injects the generated row-level filters and column-level display restrictions into the SQL query. Based on the existing query, the row-level filters are added to the WHERE clause, and the column-level display restrictions are applied to the SELECT clause. This allows for data filtering based on permission rules when the database executes the query, fundamentally implementing data permission control and ensuring that query results strictly comply with the user's permission range.
[0105] The following describes a data permission control device across service links provided in an embodiment of the present application. The data permission control device across service links described below and the data permission control method across service links described above can refer to each other.
[0106] See also Figure 2 , Figure 2 This is a schematic diagram of a data permission control device across service links disclosed in an embodiment of the present application.
[0107] like Figure 2 As shown, the data permission control device across service links may include:
[0108] The permission configuration module 110 is used to configure global data permission rules through the permission management platform. The global data permission rules include organizational structure permissions and field permissions, and are stored in the global cache;
[0109] The request parsing module 120 is used to receive a data access request initiated by a user through the front end, parse the resource locator and data permission identifier in the request through the HTTP request interceptor, load the matching permission rules from the global cache, and bind the permission rules to the thread local variables of the current service node;
[0110] The permission transfer module 130 is used to extract the permission rules in the thread local variables of the current service node through the Feign interceptor when any service node in the cross-service chain calls the next service node, attach them to the HTTP request header and pass them to the next service node. The next service node parses the permission rules in the HTTP request header through the Feign interceptor and saves the parsed permission rules in its thread local variables;
[0111] The permission control module 140 is used to obtain permission rules from the thread local variables through the MyBatis interceptor during the database query phase of any service node in the cross-service chain, generate row-level filtering conditions or column-level display restriction conditions, and inject SQL query statements;
[0112] The data processing module 150 is configured to determine query result data based on the SQL query statement, and invalidate unauthorized fields in the query result data according to the field permissions to generate final response data.
[0113] It can be seen from the above technical solution that the embodiment of the present application provides a data permission control method and related equipment across service links. First, global data permission rules including organizational structure permissions and field permissions are configured through the permission management platform and stored in the global cache; then, user data access requests are received, and the HTTP request interceptor is used to parse relevant information, and matching permission rules are loaded from the global cache and bound to the thread local variables of the current service node; when calling across services, permission rules are passed through the Feign interceptor; in the database query stage, filtering and restriction conditions are generated through the MyBatis interceptor and SQL query statements are injected; finally, the query result data is invalidated according to the field permissions.
[0114] This application achieves many beneficial effects: First, by uniformly configuring global data permission rules and storing them in the global cache, centralized management and unified recursive transmission of permission information are achieved, the problem of redundant and inconsistent permission allocation is solved, and the consistency of permission management is ensured; Second, in cross-service links, by utilizing components such as HTTP request interceptors, Feign interceptors, and MyBatis interceptors, efficient transmission and precise control of permission rules between service nodes are achieved, the problem of difficulty in cross-domain transmission and sharing of permission information is avoided, and full-link and full-domain permission control is achieved; Third, by generating row-level filtering conditions and column-level display restriction conditions, and invalidating unauthorized fields, fine-grained data permission control is achieved, and data security is improved; Fourth, the global cache loads and updates permission configurations at one time, reducing the time overhead of permission queries and updates, and improving the efficiency and scalability of permission management.
[0115] Optionally, the process of the HTTP request interceptor parsing the resource locator and data permission identifier in the request, loading the matching permission rules from the global cache, and binding the permission rules to the thread-local variables of the current service node includes:
[0116] Parse the resource locator in the request, and match the resource locator with a preset permission identifier mapping table to obtain the corresponding data permission identifier;
[0117] Locating matching permission rules from the global cache using a hash algorithm;
[0118] The matching permission rules are bound to the thread-local variables of the current service node in the form of key-value pairs, where the key is the data list identifier and the value is the role code and permission range.
[0119] Optionally, the process of the Feign interceptor appending the permission rule to the HTTP request header includes:
[0120] The permission rules are encapsulated as a preset HTTP request header field, wherein the HTTP request header field includes a permission identifier, a role code, and a data list identifier, and the naming of the HTTP request header field follows the naming rules agreed upon between service nodes.
[0121] Optionally, the MyBatis interceptor obtains permission rules from the thread local variables, generates row-level filtering conditions or column-level display restriction conditions, and injects SQL query statements, including:
[0122] Obtaining permission rules from the thread local variable;
[0123] Generate a row-level filtering condition based on the organizational structure permission in the permission rule, wherein the row-level filtering condition is used to limit the scope of the query result;
[0124] generating a column-level display restriction condition based on the field permission in the permission rule, wherein the column-level display restriction condition is used to restrict visibility or display content of the field in the query result;
[0125] The row-level filtering conditions and the column-level display restriction conditions are dynamically injected into the SQL query statement to implement data permission control.
[0126] Optionally, the process of invalidating the unauthorized fields in the query result data includes:
[0127] Parse the JSON structure of the query result data and filter out invalid fields according to the field permission whitelist;
[0128] The invalid field is left blank or replaced with a preset desensitizing mark.
[0129] Optionally, the configuration method of the global data permission rule includes:
[0130] The tree-shaped permission inheritance relationship of the multi-level organizational structure is configured through the visual interface, where child nodes inherit the permissions of the parent node by default, and manual setting of exception rules is supported;
[0131] Defining fine-grained combination control rules for field permissions in the visual interface, including whitelists and blacklists for field permissions;
[0132] The permission rules are updated in real time through the visual interface, and the synchronization refresh mechanism of the global cache is triggered after the update to ensure the consistency of the permission rules across all nodes in the service link.
[0133] The data permission control apparatus across service links provided in the embodiments of the present application can be applied to data permission control devices across service links. Figure 3The hardware structure diagram of the data permission control device across the service link is shown. Figure 3 ,The hardware structure of the data permission control device across service links may include: at least one processor 1, at least one communication interface 2, at least one memory 3 and at least one communication bus 4;
[0134] In the embodiment of the present application, the number of the processor 1, the communication interface 2, the memory 3, and the communication bus 4 is at least one, and the processor 1, the communication interface 2, and the memory 3 communicate with each other through the communication bus 4;
[0135] The processor 1 may be a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present invention;
[0136] The memory 3 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory;
[0137] The memory stores a program, and the processor can call the program stored in the memory, wherein the program is used to:
[0138] Configure global data permission rules through the permission management platform. The global data permission rules include organizational structure permissions and field permissions, and store them in the global cache.
[0139] Receive a data access request initiated by a user through the front-end, parse the resource locator and data permission identifier in the request through the HTTP request interceptor, load the matching permission rules from the global cache, and bind the permission rules to the thread-local variables of the current service node;
[0140] When any service node in the cross-service chain calls the next service node, the Feign interceptor extracts the permission rules in the thread local variables of the current service node, attaches them to the HTTP request header and passes them to the next service node;
[0141] The next service node parses the permission rules in the HTTP request header through the Feign interceptor and saves the parsed permission rules into its thread local variables;
[0142] During the database query phase of any service node in the cross-service chain, the MyBatis interceptor is used to obtain permission rules from the thread-local variables, generate row-level filtering conditions or column-level display restriction conditions, and inject SQL query statements;
[0143] Query result data is determined based on the SQL query statement, and unauthorized fields in the query result data are invalidated according to the field permissions to generate final response data.
[0144] Optionally, the refined functions and extended functions of the program may refer to the above description.
[0145] The present application also provides a readable storage medium, which may store a program suitable for execution by a processor, wherein the program is used to:
[0146] Configure global data permission rules through the permission management platform. The global data permission rules include organizational structure permissions and field permissions, and store them in the global cache.
[0147] Receive a data access request initiated by a user through the front-end, parse the resource locator and data permission identifier in the request through the HTTP request interceptor, load the matching permission rules from the global cache, and bind the permission rules to the thread-local variables of the current service node;
[0148] When any service node in the cross-service chain calls the next service node, the Feign interceptor extracts the permission rules in the thread local variables of the current service node, attaches them to the HTTP request header and passes them to the next service node;
[0149] The next service node parses the permission rules in the HTTP request header through the Feign interceptor and saves the parsed permission rules into its thread local variables;
[0150] During the database query phase of any service node in the cross-service chain, the MyBatis interceptor is used to obtain permission rules from the thread-local variables, generate row-level filtering conditions or column-level display restriction conditions, and inject SQL query statements;
[0151] Query result data is determined based on the SQL query statement, and unauthorized fields in the query result data are invalidated according to the field permissions to generate final response data.
[0152] Optionally, the refined functions and extended functions of the program may refer to the above description.
[0153] The present application also provides a computer program product, including a computer program. When the computer program is executed by a processor, the execution method is as follows:
[0154] Configure global data permission rules through the permission management platform. The global data permission rules include organizational structure permissions and field permissions, and store them in the global cache.
[0155] Receive a data access request initiated by a user through the front-end, parse the resource locator and data permission identifier in the request through the HTTP request interceptor, load the matching permission rules from the global cache, and bind the permission rules to the thread-local variables of the current service node;
[0156] When any service node in the cross-service chain calls the next service node, the Feign interceptor extracts the permission rules in the thread local variables of the current service node, attaches them to the HTTP request header and passes them to the next service node;
[0157] The next service node parses the permission rules in the HTTP request header through the Feign interceptor and saves the parsed permission rules into its thread local variables;
[0158] During the database query phase of any service node in the cross-service chain, the MyBatis interceptor is used to obtain permission rules from the thread-local variables, generate row-level filtering conditions or column-level display restriction conditions, and inject SQL query statements;
[0159] Query result data is determined based on the SQL query statement, and unauthorized fields in the query result data are invalidated according to the field permissions to generate final response data.
[0160] Optionally, the refined functions and extended functions of the program may refer to the above description.
[0161] Finally, it should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or device comprising the element.
[0162] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.
[0163] The above description of the disclosed embodiments is intended to enable one skilled in the art to implement or use the present application. Various modifications to these embodiments will be readily apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application is not limited to the embodiments shown herein, but is intended to conform to the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. A data permission control method across service links, characterized in that: include: Configure global data permission rules through the permission management platform. The global data permission rules include organizational structure permissions and field permissions, and store them in the global cache. Receive a data access request initiated by a user through the front-end, parse the resource locator and data permission identifier in the request through the HTTP request interceptor, load the matching permission rules from the global cache, and bind the permission rules to the thread-local variables of the current service node; When any service node in the cross-service chain calls the next service node, the Feign interceptor extracts the permission rules in the thread local variables of the current service node, attaches them to the HTTP request header and passes them to the next service node; The next service node parses the permission rules in the HTTP request header through the Feign interceptor and saves the parsed permission rules into its thread local variables; During the database query phase of any service node in the cross-service chain, the MyBatis interceptor is used to obtain permission rules from the thread-local variables, generate row-level filtering conditions or column-level display restriction conditions, and inject SQL query statements; Query result data is determined based on the SQL query statement, and unauthorized fields in the query result data are invalidated according to the field permissions to generate final response data.
2. The method according to claim 1, characterized in that The process of the HTTP request interceptor parsing the resource locator and data permission identifier in the request, loading the matching permission rules from the global cache, and binding the permission rules to the thread local variables of the current service node includes: Parse the resource locator in the request, and match the resource locator with a preset permission identifier mapping table to obtain the corresponding data permission identifier; Locating matching permission rules from the global cache using a hash algorithm; The matching permission rules are bound to the thread-local variables of the current service node in the form of key-value pairs, where the key is the data list identifier and the value is the role code and permission range.
3. The method according to claim 1, characterized in that The process of the Feign interceptor appending the permission rules to the HTTP request header includes: The permission rules are encapsulated as a preset HTTP request header field, wherein the HTTP request header field includes a permission identifier, a role code, and a data list identifier, and the naming of the HTTP request header field follows the naming rules agreed upon between service nodes.
4. The method according to claim 1, wherein The MyBatis interceptor obtains permission rules from the thread local variables, generates row-level filtering conditions or column-level display restriction conditions, and injects SQL query statements, including: Obtaining permission rules from the thread local variable; Generate a row-level filtering condition based on the organizational structure permission in the permission rule, wherein the row-level filtering condition is used to limit the scope of the query result; generating a column-level display restriction condition based on the field permission in the permission rule, wherein the column-level display restriction condition is used to restrict visibility or display content of the field in the query result; The row-level filtering conditions and the column-level display restriction conditions are dynamically injected into the SQL query statement to implement data permission control.
5. The method according to claim 1, wherein The process of invalidating the unauthorized fields in the query result data includes: Parse the JSON structure of the query result data and filter out invalid fields according to the field permission whitelist; The invalid field is left blank or replaced with a preset desensitizing mark.
6. The method according to claim 1, characterized in that The configuration method of the global data permission rule includes: The tree-shaped permission inheritance relationship of the multi-level organizational structure is configured through the visual interface, where child nodes inherit the permissions of the parent node by default, and manual setting of exception rules is supported; Defining fine-grained combination control rules for field permissions in the visual interface, including whitelists and blacklists for field permissions; The permission rules are updated in real time through the visual interface, and the synchronization refresh mechanism of the global cache is triggered after the update to ensure the consistency of the permission rules across all nodes in the service link.
7. A data permission control device across service links, characterized in that: include: A permission configuration module is used to configure global data permission rules through the permission management platform. The global data permission rules include organizational structure permissions and field permissions, and are stored in the global cache; The request parsing module is used to receive data access requests initiated by users through the front end, parse the resource locator and data permission identifier in the request through the HTTP request interceptor, load matching permission rules from the global cache, and bind the permission rules to the thread local variables of the current service node; The permission transfer module is used to extract the permission rules in the thread local variables of the current service node through the Feign interceptor when any service node calls the next service node in the cross-service chain, attach them to the HTTP request header and pass them to the next service node. The next service node parses the permission rules in the HTTP request header through the Feign interceptor and saves the parsed permission rules to its thread local variables; The permission control module is used to obtain permission rules from the thread local variables through the MyBatis interceptor during the database query phase of any service node in the cross-service chain, generate row-level filtering conditions or column-level display restriction conditions, and inject SQL query statements; The data processing module is used to determine the query result data based on the SQL query statement, and invalidate the unauthorized fields in the query result data according to the field permissions to generate final response data.
8. A data permission control device across service links, characterized in that: including memory and processor; The memory is used to store programs; The processor is used to execute the program to implement each step of the cross-service link data permission control method according to any one of claims 1 to 6.
9. A readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, each step of the cross-service link data permission control method according to any one of claims 1 to 6 is implemented.
10. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, each step of the cross-service link data permission control method according to any one of claims 1 to 6 is executed.