A row-column level data authority management and access query method and system

Abstract

The present invention proposes a row-column level data permission management and access query method and system, which relate to the technical field of data permission management, refines the management and control of data resources to row-column granularity data permission control, and realizes precise access management after granularity refinement, thereby reducing the data permission management workload of customer operation configuration personnel, taking into account the purposes of flexible permissions and simple configuration, and at the same time, in the scenario of access query of large data volumes, in which there are redundant data requests for different data access behaviors, the original query conditions of the user for business data access query are confirmed, the permission processing object and the original query conditions are merged for authorization processing, the access query is optimized, the redundant consumption of secondary query of data after the existing data is acquired and combined with the user's access requirements is reduced, and the query efficiency of massive data resources is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of data authority management, and more specifically, to a method and system for row-column level data authority management and access query. Background Art

[0002] With the rapid development of technologies such as the Internet, Internet of Things, big data, and cloud computing, as well as the popularization and construction of information bodies such as smart terminals, network society, and digital earth, previously isolated information systems have also been concentrated in large numbers, the amount of data has exploded, and a big data environment has been formed.

[0003] At present, the management of data permissions on the market includes the data granularity of tables, columns, and rows and the operation permission dimensions of viewing, adding, modifying, deleting, authorizing, and downloading. Among them, the practices for big data permission support libraries and tables are already very mature. For example, the prior art discloses a method and system for controlling data access permissions, which pre-establishes a data resource type table for a database table, and sets filtering conditions for specified fields in the data resource type table; according to the data resource type table, data records that meet the field filtering conditions are screened out, an association relationship between the data records and the user is established, and the association relationship is saved to the user's access permission table; finally, a user's access request to the data table is received, the user's access permission table is queried, and the user's access permission is obtained based on the association relationship, and the database table is filtered based on the access permission, so as to display records that meet the filtering conditions under the specified field for the user. However, for data permission management at the row and column levels, especially for complex permission management in big data analysis scenarios, there is a lack of implementation solutions that take into account both flexible permissions and simple configuration.

[0004] A common implementation scheme is to expand the fields of the original table. This scheme is mainly based on the enumeration value control of the corresponding row permissions of the records. Although this method requires relatively small changes, subsequent user operations will be more troublesome. An enumeration value under each field will enter an information, and it is easy to make mistakes. Therefore, it adds a lot of configuration complexity to complex data permission management. Summary of the invention

[0005] In order to solve the current complex permission management in big data analysis scenarios, there is a lack of data management methods with row and column level granularity, which leads to a large workload of data permission management for customer operation and configuration personnel and low data access query efficiency. The present invention proposes a row and column level data permission management and access query method and system, which refines the control of big data resources to the row and column granularity, reduces the data permission management workload and configuration complexity of customer operation and configuration personnel, and improves the access query efficiency of massive data resources.

[0006] In order to achieve the above technical effects, the technical solution of the present invention is as follows:

[0007] A method for row-column level data authority management and access query, the method comprising the following steps:

[0008] S1. The user initiates business data access and obtains the data permission configuration based on the user attributes;

[0009] S2. Encode the row and column level data permissions in the data permission configuration into a permission string, and decode the encoded permission string into a permission expression;

[0010] S3. Perform secondary parsing on the permission expression to obtain the final row and column permissions and encapsulate them into a permission processing object;

[0011] S4. Confirm the original query conditions of the user for business data access query, merge the permission processing object and the original query conditions for authorization processing, and the user queries the business data.

[0012] In this technical solution, row permissions refer to whether a user has the permission to access a row of data; column permissions refer to whether a user has the permission to access a column of data. In a specific big data ecosystem, because the data is stored in rows or columns, there will be corresponding permissions. This solution refines the management and control of data resources to row and column granularity data permission control. After the granularity is refined, precise access management is achieved, which reduces the workload of data permission management for customer operation configuration personnel, and takes into account the purpose of flexible permissions and simple configuration. At the same time, in the scenario of large-scale access queries, there are redundant data requests for different data access behaviors. The original query conditions of the user's business data access query are confirmed, and the permission processing object and the original query conditions are merged for authorization processing. The access query is optimized, reducing the redundant consumption of secondary query data after the existing data is obtained and combined with the user's access requirements, thereby improving the query efficiency of massive data resources.

[0013] Preferably, in step S1, the user's attributes are divided into top-level users and general users. The top-level users have full permissions and do not need to configure additional row permissions or column permissions. The data permissions of general users are configured as the same row permissions or the same column permissions to adapt to the differentiated access requirements of different customers for business data resources.

[0014] Preferably, the row and column level data permissions described in step S2 include row permissions and column permissions. The specific process of encoding the row and column level data permissions in the data permission configuration into a permission string is as follows:

[0015] S21. With the database as the root directory and the table as the secondary directory, the database ID and the table ID are concatenated in the form of a directory hierarchy, and the concatenated form is a string with the same separator;

[0016] S22. Encapsulate the row permissions and column permissions into a JSON object, use the JSON object to specify the fields that need permission control, determine them through an array, support the specification of one or more columns, and specify the method and parameters used to determine the row permissions;

[0017] S23. Convert the JSON object into a string containing only numbers and uppercase and lowercase letters through Base64 encoding;

[0018] S24. Concatenate the string with the same separator represented by the database ID and table ID directory level concatenation in step S21 with the string in S23 to obtain the final permission string, specifying a unique database ID, table ID, field and permission control condition.

[0019] Here, through the splicing form of the hierarchical structure, the combination of different databases and different databases / tables can be well supported, the uniqueness of the library-table combination can be ensured, and the resource registration using the directory hierarchy expression based on the library table does not depend on the type of the resource itself, but can support strategies for multiple data types such as cloud platform data, relational database types, big data engines, and graph databases. In this process, the JSON object is converted into a string containing only numbers and uppercase and lowercase letters through Base64 encoding, which can simplify the storage difficulty and provide cross-platform and cross-language storage capabilities.

[0020] Preferably, in step S22, a Boolean expression is used to specify a method and parameters for determining row permissions, and the parameters correspond to a coding format of a query condition: a lilei expression. The lilei expression encodes the Boolean expression of the query condition separately from the actual content of the query condition, and can perform AND, OR, and NOT operations on several conditions. In the lilei expression, the query condition is a specific value or range or regular expression, which can take into account various types of permission control requirements.

[0021] Here, lilei expression can decouple Boolean expressions from specific conditions, which is more readable and flexible, and easy to implement scenarios where multiple permissions are controlled simultaneously.

[0022] Preferably, the specific process of decoding the encoded permission string into a permission expression in step S2 is:

[0023] S25. Split the permission string to obtain a database ID, table ID directory hierarchical structure, and a Base64-encoded JSON object of row permissions and column permissions;

[0024] S26. Perform Base64 decoding on the JSON object in S25 to obtain a JSON object containing fields for permission control, that is, a lilei expression of column permission and row permission;

[0025] S27. The database ID, table ID directory hierarchical concatenation structure and the JSON objects of row permissions and column permissions decoded in S26 together constitute a permission expression.

[0026] Preferably, the specific process of performing secondary parsing on the permission expression in step S3 is:

[0027] S31. Compare the database ID and table ID in the database ID and table ID directory hierarchical structure with the database ID and table ID accessed by the actual business data, retain the same database ID and table ID, and filter out the different ones to obtain the permission expression configured for the database table that the business data needs to access;

[0028] S32. If no permission expression is obtained after filtering, an "empty" permission processing object is returned, indicating that there is no data permission; if multiple permission expressions are obtained after filtering, the row permission and column permission are merged to obtain the row and column permissions, and are encapsulated as a permission processing object.

[0029] Preferably, in step S32, the operation of merging row permissions and column permissions is performed using a lilei expression to achieve simultaneous control of multiple permissions. When merging row permissions, it includes:

[0030] Combine the boolExpression in lilei expression through AND operation;

[0031] Merge the paramJson in the lilei expression and add all items of one Map to another Map;

[0032] When merging column permissions, each fields field is a list. The fields fields are merged to merge the lists, and then the same fields are deduplicated. For fields that appear more than once, only one is retained.

[0033] Preferably, in step S4, the original query condition for the user to perform a business data access query is defined by a specific business interface, representing the data query operation that the business interface needs to perform.

[0034] Preferably, the specific process of merging the permission processing object with the original query condition for authorization processing is as follows:

[0035] According to the column permissions in the permission processing object, filter the fields in the original query conditions, that is, remove the fields in the original query conditions that are different from the column permissions;

[0036] According to the row permissions in the permission processing object, the original query conditions are merged, that is, the query range in the original query conditions is merged with the range in the column permissions.

[0037] This application also proposes a row-column level data authority management and access query system, including:

[0038] The permission encoding and decoding module is used to encode the row and column-level data permissions in the user's data permission configuration into a permission string when the user initiates business data access, and decode the encoded permission string into a permission expression;

[0039] The permission parsing module is used to perform secondary parsing on the permission expression to obtain the final row and column permissions and encapsulate them into permission processing objects;

[0040] The permission execution module is used to confirm the original query conditions of the user's business data access query and merge the permission processing object with the original query conditions for authorization processing.

[0041] Compared with the prior art, the technical solution of the present invention has the following beneficial effects:

[0042] The present invention proposes a row-column level data permission management and access query method and system, which refines the management and control of data resources to row-column granularity data permission control, and realizes precise access management after granularity refinement, reducing the data permission management workload of customer operation configuration personnel, and taking into account the purposes of flexible permissions and simple configuration. At the same time, in the scenario of access query of large data volumes, there are redundant data requests for different data access behaviors, and the original query conditions of the user for business data access query are confirmed, and the permission processing object and the original query conditions are merged for authorization processing, so as to optimize the access query, reduce the redundant consumption of secondary query data after obtaining the existing data and combining the user's access requirements, and improve the query efficiency of massive data resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Figure 1 A schematic diagram showing a flow chart of a row-column level data authority management and access query method proposed in Embodiment 1 of the present invention;

[0044] Figure 2 A schematic diagram showing a flow chart of encoding row and column-level data permissions in data permission configuration into permission character strings proposed in Embodiment 1 of the present invention;

[0045] Figure 3 A schematic diagram showing a flow chart of decoding an encoded permission character string into a permission expression proposed in Embodiment 1 of the present invention;

[0046] Figure 4A schematic diagram showing a flow chart of performing secondary parsing of a permission expression according to Embodiment 1 of the present invention;

[0047] Figure 5 A structural diagram showing the row and column level data authority management and access query system proposed in Example 3 of the present invention. DETAILED DESCRIPTION

[0048] The drawings are for illustrative purposes only and should not be construed as limiting the present patent;

[0049] In order to better illustrate the present embodiment, some parts of the drawings may be omitted, enlarged or reduced, and do not represent the actual size;

[0050] It is understandable to those skilled in the art that descriptions of certain well-known contents in the drawings may be omitted.

[0051] The technical solution of the present invention is further described below in conjunction with the accompanying drawings and embodiments.

[0052] The positional relationships described in the drawings are only for illustrative purposes and should not be construed as limiting the present patent;

[0053] Example 1

[0054] In this embodiment, if Figure 1 As shown in the figure, a row-column level data permission management and access query method is proposed. Figure 1 , the method comprises the following steps:

[0055] S1. The user initiates business data access and obtains the data permission configuration based on the user attributes;

[0056] S2. Encode the row and column level data permissions in the data permission configuration into a permission string, and decode the encoded permission string into a permission expression;

[0057] S3. Perform secondary parsing on the permission expression to obtain the final row and column permissions and encapsulate them into a permission processing object;

[0058] S4. Confirm the original query conditions of the user for business data access query, merge the permission processing object and the original query conditions for authorization processing, and the user queries the business data.

[0059] The above process proposed in this embodiment does not rely on the data resources themselves, and can support the registration and management of multiple data types such as cloud platform data, relational database types, big data engines and graph databases, and finally form a precise authorization control function for data items, which is convenient for flexible combination of data resource access management according to different scenarios and customer needs, fully adapts to the ever-expanding database storage types, decouples the logic of resource registration and data permission control, and supports the expansion of new data storage types on demand; after the resource is registered, the data items in the resource management are classified and managed, and under the resource control function, support configuration and assembly according to the row and column granularity of the data resources, or a flexible combination of the two, adapting to the differentiated access control requirements of different customers for data resources, and can flexibly perform free combination of access control based on the original classification, and reuse the original configuration logic; finally, when the user initiates a data resource access request, the system will parse the authorization behavior of the corresponding data resource based on the access permission policy of the data resource owned by the user, and finally merge the data authorization behavior, and then parse it into the corresponding precise data query action to obtain data, reducing the redundant consumption of the original acquisition of data first and then performing secondary query of data in combination with user access requirements.

[0060] In step S1, the user's attributes are divided into the highest-level users and general users. The highest-level users have full permissions and do not need to configure additional row permissions or column permissions. The data permissions of general users are configured as the same row permissions or the same column permissions to adapt to the differentiated access requirements of different customers for business data resources, which can be actually specified in specific actual application scenarios.

[0061] In this embodiment, the row and column level data permissions described in step S2 include row permissions and column permissions. For the specific process of encoding the row and column level data permissions in the data permission configuration into permission strings, see Figure 2 ,include:

[0062] S21. With the database as the root directory and the table as the secondary directory, the database ID and table ID are concatenated in the form of a directory hierarchy, and the concatenated form is a string with the same separator; in actual implementation, the database and table are divided by " / ", for example: in the form of / database ID / table ID, the database is the root directory, the table is the secondary directory, and the data is the file under the directory. The hierarchical structure concatenation form can well support the combination of different databases and different data sources / tables, and can ensure the uniqueness of the library-table combination.

[0063] S22. Encapsulate the row permissions and column permissions into a JSON object, use the JSON object to specify the fields that need permission control, determine them through an array, support the specification of one or more columns, and specify the method and parameters used to determine the row permissions;

[0064] S23. Convert the JSON object into a string containing only numbers and uppercase and lowercase letters through Base64 encoding. This can simplify storage and provide cross-platform and cross-language storage capabilities.

[0065] S24. Concatenate the string with the same delimiter represented by the database ID and table ID directory level concatenation in step S21 with the string in S23 to obtain the final permission string, specifying the unique database ID, table ID, field, and permission control conditions. Here, because this permission string contains the library ID, table ID, the list of fields that need permission control, and the row permission lilei expression, we use this string to specify the unique database, table, field, and permission control conditions

[0066] In addition, in step S22, a Boolean expression is used to specify a method and parameters for determining row permissions. The parameters correspond to a coding format of a query condition: a lilei expression. The lilei expression encodes the Boolean expression of the query condition separately from the actual content of the query condition, and can perform AND, OR, and NOT operations on several conditions. In the lilei expression, the query condition is a specific value or range or regular expression, which can take into account various types of permission control requirements.

[0067] For the lilei expression, it is the encoding format of a query condition. By encoding the Boolean expression of the condition separately from the actual content of the condition, the complexity of condition merging is simplified. For example, assuming the original query condition: year = 2022 AND month IN (1, 2, 3), the lilei expression is:

[0068]

[0069]

[0070] Now we need to combine the two expressions through an AND operation, which requires the following three steps:

[0071] A. Renumbering of conditional fields:

[0072] Because the boolExpression and paramJson of the lilei expression are connected by data numbers, and each lilei expression is numbered from 1, the same number will exist when merged. So we need to renumber one of the lilei expressions, for example, renumber expression 2 here.

[0073] B. Merge boolExpression: Since an AND operation is required here, use AND to merge the two boolExpressions to get: (1AND 2)AND 3

[0074] C. Merge paramJson: Just merge the two paramJson.

[0075] Lilei expression encodes conditional expressions through certain rules, making it convenient for us to perform AND, OR, and NOT operations on multiple conditions. It can decouple Boolean expressions from specific conditions, making it more readable and flexible, and easy to implement scenarios where multiple permissions are controlled simultaneously.

[0076] See also Figure 3 The specific process of decoding the encoded permission string into a permission expression in step S2 is as follows:

[0077] S25. Split the permission string to obtain a database ID, table ID directory hierarchical structure, and a Base64-encoded JSON object of row permissions and column permissions;

[0078] S26. Perform Base64 decoding on the JSON object in S25 to obtain a JSON object containing the permission control fields (i.e., column permissions) and the lilei expression of the row permissions;

[0079] S27. The database ID, table ID directory hierarchical concatenation structure and the JSON objects of row permissions and column permissions decoded in S26 together constitute a permission expression.

[0080] See also Figure 4 The specific process of performing secondary analysis on the permission expression in step S3 is as follows:

[0081] S31. Compare the database ID and table ID in the database ID and table ID directory hierarchical structure with the database ID and table ID accessed by the actual business data, retain the same database ID and table ID, and filter out the different ones to obtain the permission expression configured for the database table that the business data needs to access;

[0082] S32. If no permission expression is obtained after filtering, an "empty" permission processing object is returned, indicating that there is no data permission; if multiple permission expressions are obtained after filtering, the row permission and column permission are merged to obtain row and column permissions, and are encapsulated as a permission processing object. In step S32, the row permission and column permission are merged using the lilei expression to achieve simultaneous control of multiple permissions. When merging row permissions, the lilei expression is selected for processing. The process includes:

[0083] Combine the boolExpression in lilei expression through AND operation;

[0084] Merge the paramJson in the lilei expression and add all items of one Map to another Map;

[0085] When merging column permissions, each fields field is a list. The fields fields are merged to merge the lists, and then the same fields are deduplicated. For fields that appear more than once, only one is retained. In this embodiment, the Java class library is directly used to perform deduplication operations. After deduplication, the merged column permissions are obtained.

[0086] In step S4, the original query condition for the user to access the business data is defined by a specific business interface, which represents the data query operation that the business interface needs to perform. For example, in an interface for querying turnover, the original query condition may be that the time is within a certain range.

[0087] In this embodiment, the specific process of merging the permission processing object with the original query condition for authorization processing is as follows:

[0088] According to the column permissions in the permission processing object, filter the fields in the original query conditions, that is, remove the fields in the original query conditions that are different from the column permissions; for example, the original query conditions include the name and age fields, but the column permissions in the permission processing object only include the name field, then modify it to query only the name field.

[0089] According to the row permissions in the permission processing object, the original query conditions are merged, that is, the query range in the original query conditions is merged with the range in the column permissions. For example, in the original query condition, the data with age greater than 18 is queried, and the row permission in the permission processing object is age less than 30, then the query is modified to query the data with age greater than 18 and less than 30.

[0090] Example 2

[0091] This embodiment is explained in combination with specific practice. Assume that there is a sales statistics table of a certain product in 2022 as shown in Table 1, and data permission management at the row and column levels is required:

[0092] Table 1

[0093]

[0094]

[0095] Table 1 records the turnover according to cities and months. Now it is necessary to count the total sales of each city in the first quarter, but it is required that dealers in each province can only see the data of their own province. By using the method proposed by the present invention, only one interface can be provided, and then combined with data permissions, each dealer can only see the data of his own province.

[0096] For the original interface: query the entire table, aggregate the cities, and obtain the turnover of each city. The corresponding SQL is: SELECT SUM(turnover) FROM t_turnover WHERE year=2022AND month IN(1,2,3) GROUP BY city ORDER BY SUM(turnover) DESC

[0097] The head office is set as the highest level user, which can view all data, so there is no need to configure row permissions. The dealers in each province configure row permissions: the province is equal to the province attribute of the account. Although each dealer is configured with the same row permission, the row permission control is different due to the different province attributes of the account:

[0098] Guangdong dealer configuration: Province equals Guangdong;

[0099] Guangxi dealer configuration: Province equals Guangxi;

[0100] Hunan dealer configuration: Province equals Hunan.

[0101] When there are new dealers in the future, you only need to assign this row permission to this dealer, without having to create it again. When the Guangdong dealer calls the interface in step 1, since the row permission is configured: Province equals Guangdong, the interface will merge the original condition with the row permission, and the actual query SQL is:

[0102] SELECT SUM(turnover)FROM t_turnover WHERE year=2022AND month IN(1,2,3)AND province='Guangdong'GROUP BY city ORDER BY SUM(turnover)DESC

[0103] Then when querying, it is equivalent to only aggregating the data in Table 2:

[0104] Table 2

[0105]

[0106]

[0107] Therefore, by using the method proposed in this application, it is ensured that dealers in Guangdong can only query the turnover data of Guangdong, and the same is true for dealers in Guangxi and Hunan.

[0108] If you use the extended field method to achieve the same permission control effect, you need to do the following:

[0109] Add the account_id field to table 1 to limit which account can query the record. If multiple accounts can be queried, you also need to add an intermediate table (account_turnover) to implement a many-to-many relationship;

[0110] The logic of the query interface needs to be modified as follows:

[0111] SELECT SUM(turnover)FROM t_turnover WHERE year=2022AND month IN(1,2,3)AND account_id=? GROUP BY city ORDER BY SUM(turnover)DESC

[0112] Among them, account_id is obtained from the current login account.

[0113] If the administrator needs to query all the data, this interface cannot be used directly. Either a new interface is provided, or the administrator's account_id is associated with all the data. However, either method is very difficult to maintain.

[0114] It can be seen that by extending fields, permission control is coupled with business logic. Each business data table needs to have a corresponding account association table, which is difficult to maintain and prone to errors. The data permission management method described in this patent not only decouples permission control from business logic, but also makes the configuration simple and easy to understand. Interface developers can only focus on business logic, and data permissions are uniformly configured by account managers.

[0115] The above describes how to control the row-level data returned by the query through row permissions. We can also control the return of column-level data through column permissions. Similarly, based on the turnover statistics table 1 of a certain product in 2022, only the administrator accounts of each province can query the turnover, and ordinary accounts are not allowed to query. We can give ordinary accounts the column permissions of the turnover field without configuring them. When ordinary accounts call the interface for querying turnover, the permission execution module will merge the column permissions and the original query fields. If it is found that the aggregated field turnover has no permissions, the aggregate calculation will not be performed, and the response "no data permissions" will be given to the front end to ensure data security.

[0116] Example 3

[0117] This embodiment proposes a row-column level data authority management and access query system. Figure 3 ,include:

[0118] The permission encoding and decoding module is used to encode the row and column-level data permissions in the user's data permission configuration into a permission string when the user initiates business data access, and decode the encoded permission string into a permission expression;

[0119] The permission parsing module is used to perform secondary parsing on the permission expression to obtain the final row and column permissions and encapsulate them into permission processing objects;

[0120] The permission execution module is used to confirm the original query conditions of the user's business data access query and merge the permission processing object with the original query conditions for authorization processing.

[0121] Obviously, the above embodiments of the present invention are only examples for clearly illustrating the present invention, and are not intended to limit the embodiments of the present invention. For those skilled in the art, other different forms of changes or modifications can be made based on the above description. It is not necessary and impossible to list all the embodiments here. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the protection scope of the claims of the present invention.

Claims

1. A row-column level data authority management and access query method, characterized in that: The method comprises the following steps: S1. The user initiates business data access and obtains the data permission configuration based on the user attributes; S2. Encode the row and column level data permissions in the data permission configuration into a permission string, and decode the encoded permission string into a permission expression; S3. Perform secondary parsing on the permission expression to obtain the final row and column permissions and encapsulate them into a permission processing object; S4. Confirm the original query conditions for the user to query the business data, merge the permission processing object with the original query conditions for authorization processing, and the user queries the business data; The row and column level data permissions described in step S2 include row permissions and column permissions. The specific process of encoding the row and column level data permissions in the data permission configuration into permission strings is as follows: S21. With the database as the root directory and the table as the secondary directory, the database ID and the table ID are concatenated in the form of a directory hierarchy, and the concatenated form is a string with the same separator; S22. Encapsulate the row permissions and column permissions into a JSON object, use the JSON object to specify the fields that need permission control, determine them through an array, support the specification of one or more columns, and specify the method and parameters used to determine the row permissions; S23. Convert the JSON object into a string containing only numbers and uppercase and lowercase letters through Base64 encoding; S24. Concatenate the string with the same separator represented by the database ID and table ID directory level concatenation in step S21 with the string in S23 to obtain the final permission string, specifying a unique database ID, table ID, field and permission control condition.

2. The row-column level data authority management and access query method according to claim 1 is characterized in that: In step S1, the user's attributes are divided into top-level users and general users. The top-level users have full permissions and do not need to configure additional row permissions or column permissions. The data permissions of general users are configured as the same row permissions or the same column permissions.

3. The row-column level data authority management and access query method according to claim 1 is characterized in that: In step S22, a Boolean expression is used to specify a method and parameters for determining row permissions. The parameters correspond to a coding format of a query condition: a lilei expression. The lilei expression encodes the Boolean expression of the query condition separately from the actual content of the query condition, and can perform AND, OR, or NOT operations on several conditions. In the lilei expression, the query condition is a specific value or range or regular expression, which can take into account various types of permission control requirements.

4. The row-column level data authority management and access query method according to claim 3 is characterized in that: The specific process of decoding the encoded permission string into a permission expression in step S2 is as follows: S25. Split the permission string to obtain a database ID, table ID directory hierarchical structure, and a Base64-encoded JSON object of row permissions and column permissions; S26. Perform Base64 decoding on the JSON object in S25 to obtain a JSON object containing fields for permission control, namely, a lilei expression of column permission and row permission; S27. The database ID, table ID directory hierarchical concatenation structure and the JSON objects of row permissions and column permissions decoded in S26 together constitute a permission expression.

5. The row-column level data authority management and access query method according to claim 4 is characterized in that: The specific process of performing secondary analysis on the permission expression in step S3 is as follows: S31. Compare the database ID and table ID in the database ID and table ID directory hierarchical structure with the database ID and table ID accessed by the actual business data, retain the same database ID and table ID, and filter out the different ones to obtain the permission expression configured for the database table that the business data needs to access; S32. If no permission expression is obtained after filtering, an "empty" permission processing object is returned, indicating that there is no data permission; If multiple permission expressions are obtained after filtering, the row permission and column permission are merged to obtain the row and column permissions, and are encapsulated as a permission processing object.

6. The row-column level data authority management and access query method according to claim 5 is characterized in that: In step S32, the row permissions and column permissions are merged using the lilei expression to achieve simultaneous control of multiple permissions. When merging row permissions, it includes: Combine the boolExpression in lilei expression through AND operation; Merge the paramJson in the lilei expression and add all items of one Map to another Map; When merging column permissions, each fields field is a list. The fields fields are merged to merge the lists, and then the same fields are deduplicated. For fields that appear more than once, only one is retained.

7. The row-column level data authority management and access query method according to claim 6 is characterized in that: In step S4, the original query conditions for the user to perform a business data access query are defined by a specific business interface, representing the data query operation that the business interface needs to perform.

8. The row-column level data authority management and access query method according to claim 7, characterized in that: The specific process of merging the permission processing object with the original query condition for authorization processing is as follows: According to the column permissions in the permission processing object, filter the fields in the original query conditions, that is, remove the fields in the original query conditions that are different from the column permissions; According to the row permissions in the permission processing object, the original query conditions are merged, that is, the query range in the original query conditions is merged with the range in the column permissions.

9. A row-column level data authority management and access query system, characterized in that: include: The permission encoding and decoding module is used to encode the row and column-level data permissions in the user's data permission configuration into a permission string when the user initiates business data access, and decode the encoded permission string into a permission expression; The permission parsing module is used to perform secondary parsing on the permission expression to obtain the final row and column permissions and encapsulate them into permission processing objects; The permission execution module is used to confirm the original query conditions of the user for business data access query, and merge the permission processing object with the original query conditions for authorization processing; The row and column level data permissions described in the permission encoding and decoding module include row permissions and column permissions. The specific process of encoding the row and column level data permissions in the data permission configuration into permission strings is as follows: S21. With the database as the root directory and the table as the secondary directory, the database ID and the table ID are concatenated in the form of a directory hierarchy, and the concatenated form is a string with the same separator; S22. Encapsulate the row permissions and column permissions into a JSON object, use the JSON object to specify the fields that need permission control, determine them through an array, support the specification of one or more columns, and specify the method and parameters used to determine the row permissions; S23. Convert the JSON object into a string containing only numbers and uppercase and lowercase letters through Base64 encoding; S24. Concatenate the string with the same separator represented by the database ID and table ID directory level concatenation in step S21 with the string in S23 to obtain the final permission string, specifying a unique database ID, table ID, field and permission control condition.

Images