Row-level data permission authorization method and device, equipment and medium

Abstract

The invention discloses a row-level data permission authorization method and device, equipment and a medium, and relates to the technical field of computers. Comprising the following steps: registering basic data into a preset database; configuring a corresponding field management user with a field management authority for the preset service field; creating or updating a record in a user data permission table based on the user permission application to determine a permission relationship between the user identifier and the entity data; registering a service data table and a mapping relation between an entity column and an entity type in the service data table in a preset service field based on a user instruction of a field management user; and dynamically generating a permission filtering condition based on the query SQL and the user identifier so as to generate an SQL statement with permission filtering, and querying corresponding service data from the service data table based on the mapping relationship so as to generate a corresponding query result based on the service data. Therefore, the efficiency and flexibility of line-level data permission authorization can be improved on the premise of ensuring data security.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method, apparatus, device, and medium for authorizing row-level data permissions. Background Technology

[0002] As enterprises deepen their digital transformation, the amount of business data managed and stored in the information systems of large organizations is experiencing explosive growth, with the number of data tables often reaching thousands or even tens of thousands. This massive amount of data often contains sensitive business information from different departments and positions. Ensuring the security and compliance of data during sharing and use, and preventing unauthorized access and data leaks, has become a core challenge in system design.

[0003] Traditional access control mechanisms are mostly based on table-level or database-level coarse-grained management, which cannot meet the fine-grained business requirement of "different users can only access data rows within their authorized scope in the same data table". Therefore, row-level data permission technology has emerged. In existing technologies, role-based access control models are the mainstream solution for implementing row-level permissions. However, this centralized architecture based on RBAC has gradually revealed the following significant drawbacks in practice:

[0004] Inefficient access control: In large organizations with numerous data tables and users, configuring row-level permissions for all tables relies entirely on the platform administrator. When a new user is added, the administrator needs to manually filter and authorize them from thousands of business data tables; when a new business data table is added, the administrator needs to filter out a subset of users authorized to access that table from a large pool of users. This "N-to-N" authorization model results in an extremely heavy workload and low efficiency in access control configuration.

[0005] Accuracy of permission configuration is difficult to guarantee: Platform administrators are often unfamiliar with the specific meanings and data relationships of data tables in various business areas. Having personnel unfamiliar with the business configure fine-grained data permissions for massive data tables is highly susceptible to errors due to misunderstandings. This can result in either excessive data access permissions creating security vulnerabilities or insufficient authorization hindering normal business operations.

[0006] Insufficient system scalability and responsiveness: The centralized management model creates bottlenecks in the system's access control capabilities. With the rapid expansion of the organization and its business, every personnel change or addition of a new data table requires centralized processing by the platform administrator, resulting in untimely responses and hindering the system's flexibility and scalability.

[0007] As can be seen from the above, how to improve the efficiency and flexibility of row-level data permission authorization while ensuring data security is an urgent problem to be solved. Summary of the Invention

[0008] In view of this, the purpose of this invention is to provide a row-level data permission authorization method, apparatus, device, and medium, which can improve the efficiency and flexibility of row-level data permission authorization while ensuring data security. The specific solution is as follows:

[0009] Firstly, this application provides a row-level data permission authorization method, including:

[0010] Register basic data into a preset database; the basic data includes entity types and entity data, the entity types include business domain types, and the entity data includes preset business domains corresponding to the business domain types;

[0011] Configure corresponding domain management users with domain management permissions for the preset business domain in the entity data;

[0012] Based on user permission requests, a record is created or updated in the user data permission table, and the permission relationship between the user identifier and the entity data is determined based on the record; the record includes user identifier, entity type, entity identifier, and permission status;

[0013] Based on the user instructions of the domain management user, register a business data table in the preset business domain, and register the mapping relationship between the entity columns contained in the business data table and the entity type;

[0014] Receive the query SQL sent by the current user through a preset application, dynamically generate permission filtering conditions based on the query SQL and the user identifier of the current user, and inject the permission filtering conditions into the query SQL to generate an SQL statement with permission filtering.

[0015] The SQL statement with permission filtering is used to query the corresponding business data from the business data table based on the mapping relationship, so as to generate the corresponding query results based on the business data, and return the query results to the preset application.

[0016] Optionally, configuring a domain management user with domain management permissions for the preset business domain in the entity data includes:

[0017] By creating target records in the user data permission table, corresponding domain management users with domain management permissions are configured for the preset business domains;

[0018] Wherein, the user identifier in the target record is the user identifier of the domain management user; the entity type in the target record is the type representing the domain; the entity identifier in the target record is the identifier of the preset business domain; and the permission status in the target record is authorized.

[0019] Optionally, the creation or update of records in the user data permission table based on user permission requests includes:

[0020] Based on the user's permission request, create a record in the user data permission table with the permission status "in progress";

[0021] The permission status of the recorded information will be updated to authorized based on the approval results of the platform-managed users.

[0022] Among them, records with an authorized permission status indicate that the corresponding user has data access permissions to the corresponding entity data.

[0023] Optionally, the mapping relationship between the entity columns included in the business data table and the entity type is registered, including:

[0024] The name, description, and identifier of the preset business domain of the business data table are recorded in the metadata of the business data table.

[0025] The entity column mapping table records the name of the business data table, the names of the entity columns contained in the business data table, and the entity types corresponding to the entity columns.

[0026] Optionally, the step of dynamically generating permission filtering conditions based on the query SQL and the current user's user identifier includes:

[0027] The query SQL is parsed to determine the target business data table corresponding to the query SQL, and the entity column name and corresponding entity type associated with the target business data table are determined from the entity column mapping table based on the target business data table;

[0028] The system queries the user data permission table based on the current user's user identifier and the entity type to determine the set of entity identifiers that the current user can access, and dynamically generates permission filtering conditions based on the set of entity identifiers and the entity column name.

[0029] Optionally, the step of dynamically generating permission filtering conditions based on the entity identifier set and the entity column name includes:

[0030] If the entity identifier set is empty, then a filtering condition with a logical result of false is generated for the corresponding entity column;

[0031] If the entity identifier set contains a unique entity identifier, then a preset format of equality filtering conditions is generated for the corresponding entity column;

[0032] If the entity identifier set contains multiple entity identifiers, then a preset format set filtering condition is generated for the corresponding entity column;

[0033] If the target business data table is associated with multiple entity columns, the filter conditions generated for each entity column are combined to form the final permission filter conditions.

[0034] Optionally, parsing the query SQL to determine the target business data table corresponding to the query SQL includes:

[0035] The query SQL is parsed using a preset SQL syntax parsing tool to extract the names of one or more business data tables contained in the query SQL as the target business data table corresponding to the query SQL.

[0036] Secondly, this application provides a row-level data permission authorization device, comprising:

[0037] The basic data registration module is used to register basic data into a preset database. The basic data includes entity types and entity data. The entity types include business domain types, and the entity data includes a preset business domain corresponding to the business domain type.

[0038] The first permission configuration module is used to configure corresponding domain management users with domain management permissions for the preset business domain in the entity data;

[0039] The second permission configuration module is used to create or update records in the user data permission table based on user permission requests, and to determine the permission relationship between the user identifier and the entity data based on the records; the records include user identifier, entity type, entity identifier and permission status;

[0040] The business data registration module is used to register a business data table in the preset business domain based on the user instructions of the domain management user, and to register the mapping relationship between the entity columns contained in the business data table and the entity type;

[0041] The permission filtering module is used to receive the query SQL sent by the current user through a preset application, dynamically generate permission filtering conditions based on the query SQL and the user identifier of the current user, and inject the permission filtering conditions into the query SQL to generate an SQL statement with permission filtering.

[0042] The data query module is used to query the corresponding business data from the business data table based on the mapping relationship using the SQL statement with permission filtering, generate the corresponding query results based on the business data, and return the query results to the preset application.

[0043] Thirdly, this application provides an electronic device, comprising:

[0044] Memory, used to store computer programs;

[0045] A processor is used to execute the computer program to implement the aforementioned row-level data permission authorization method.

[0046] Fourthly, this application provides a computer-readable storage medium for storing a computer program, wherein the computer program, when executed by a processor, implements the aforementioned row-level data permission authorization method.

[0047] This application provides a row-level data permission authorization method, which registers basic data into a preset database. The basic data includes entity types and entity data. The entity types include business domain types, and the entity data includes preset business domains corresponding to the business domain types. For each preset business domain in the entity data, a corresponding domain management user with domain management permissions is configured. Records are created or updated in a user data permission table based on user permission requests, and the permission relationship between the user identifier and the entity data is determined based on the records. The records include a user identifier, entity type, entity identifier, and permission status. Based on user instructions from the domain management user, a business data table is registered in the preset business domain, and the mapping relationship between the entity columns contained in the business data table and the entity types is registered. A query SQL statement is received from the current user through a preset application, and permission filtering conditions are dynamically generated based on the query SQL and the current user's user identifier. The permission filtering conditions are injected into the query SQL to generate a permission-filtered SQL statement. The permission-filtered SQL statement is used to query the corresponding business data from the business data table based on the mapping relationship to generate corresponding query results, and the query results are returned to the preset application.

[0048] As can be seen from the above, this application introduces "domains" as special entities, distributing the core function of permission management from a single platform administrator to domain administrators, thus constructing a new authorization architecture that combines "centralization and decentralization." This is achieved by pre-defining entity types and entities, and binding user permissions to entities rather than specific data tables. Based on this, domain administrators register the business data tables they manage and declare the entity columns used for permission filtering and their corresponding entity types. When a user initiates a data query, precise row-level filtering conditions are dynamically generated and injected into the query statement based on the mapping relationship between the user's entity permissions and the entity columns of the target table. This not only significantly reduces the configuration workload and management risks for platform administrators dealing with massive amounts of data tables, but also ensures the accuracy of permission settings and provides excellent scalability for permission management—adding a new user only requires configuring entity permissions, and adding a new data table only requires registration by the domain administrator, automatically achieving row-level permission control across the entire system. This improves the efficiency and flexibility of row-level data permission authorization while ensuring data security. Attached Figure Description

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

[0050] Figure 1 This is a flowchart of a row-level data permission authorization method disclosed in this invention;

[0051] Figure 2 This is a flowchart of a specific row-level data permission authorization method disclosed in this invention;

[0052] Figure 3 This is a schematic diagram of a row-level data permission authorization device disclosed in this invention;

[0053] Figure 4 This is a structural diagram of an electronic device disclosed in this invention. Detailed Implementation

[0054] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0055] Traditional access control mechanisms are mostly based on table-level or database-level coarse-grained management, which cannot meet the fine-grained business requirement of "different users can only access data rows within their authorized scope in the same data table". Therefore, row-level data permission technology has emerged. In existing technologies, role-based access control models are the mainstream solution for implementing row-level permissions. However, this centralized architecture based on RBAC has gradually revealed significant shortcomings in practice, including low permission management efficiency, difficulty in ensuring the accuracy of permission configuration, and insufficient system scalability and responsiveness. Therefore, this application provides a row-level data permission authorization scheme that can improve the efficiency and flexibility of row-level data permission authorization while ensuring data security.

[0056] See Figure 1 As shown in the figure, this application discloses a row-level data permission authorization method, including:

[0057] Step S11: Register the basic data into the preset database.

[0058] In this embodiment, in response to operation commands from platform management users with platform management privileges, basic data is registered in a public preset database by adding corresponding records to the entity type table and the entity data table. The basic data includes entity types and entity data. The entity types include business domain types, and the entity data includes preset business domains corresponding to the business domain types. An entity typically refers to an independently existing and distinguishable thing or object, and a unique ID is generally created for each entity. Common entity types include legal persons (enterprises, government agencies, public institutions, etc.), departments, temporary organizations (such as project teams, committees), personnel, equipment, and systems. It is important to note that a domain is a special type of entity used to group business data tables into multiple domain subsets. Each business data table uniquely belongs to a specific domain, and each domain has a designated domain administrator.

[0059] Step S12: Configure corresponding domain management users with domain management permissions for the preset business domain in the entity data.

[0060] In this embodiment, in response to the operation command of the platform management user, the target user is set as a domain management user for a preset domain by inserting an authorization record into the user data permission table. Specifically, configuring a corresponding domain management user with domain management permissions for the preset business domain in the entity data can include: configuring a corresponding domain management user with domain management permissions for the preset business domain by creating a target record in the user data permission table; wherein, the user identifier in the target record is the user identifier of the domain management user; the entity type in the target record is the type representing the domain; the entity identifier in the target record is the identifier of the preset business domain; and the permission status in the target record is authorized. That is, by setting a corresponding domain management user for the preset domain, when the business data table in the preset domain is added, permission configuration only needs to be performed in response to the command of the corresponding domain management user, without the need for the platform management user to participate in the configuration, thus reducing configuration redundancy and permission management workload.

[0061] Step S13: Create or update a record in the user data permission table based on the user permission request, and determine the permission relationship between the user identifier and the entity data based on the record.

[0062] In this embodiment, upon receiving a permission request from a user, the system responds to the operation instructions of the platform management user by inserting an authorization record into the user data permission table to approve the permission request. Specifically, creating or updating a record in the user data permission table based on the user permission request can include: creating a record with a permission status of "in application" in the user data permission table based on the user permission request; and updating the permission status of the record to "authorized" based on the approval result of the platform management user. A record with an authorized permission status indicates that the corresponding user has data access rights to the corresponding entity data. The record includes a user identifier, entity type, entity identifier, and permission status. That is, when a new user is added, only the platform management user needs to configure permissions, instead of requiring each domain management user to set permissions separately for the new user, reducing configuration redundancy and permission management workload.

[0063] Step S14: Based on the user instructions of the domain management user, register a business data table in the preset business domain, and register the mapping relationship between the entity columns contained in the business data table and the entity type.

[0064] In this embodiment, in response to the user instruction of the domain management user, a business data table is registered by inserting records into a data table. The records in the data table include, but are not limited to, the business data table name, business data table description, and the domain to which the business data table belongs. Further, in response to the user instruction of the domain management user, records are inserted into an entity column mapping table to register the entity column information of the business data table. Specifically, registering the mapping relationship between the entity columns contained in the business data table and the entity types may include: recording the name, description, and identifier of the preset business domain to which the business data table belongs in the metadata of the business data table; and recording the name of the business data table, the names of the entity columns contained in the business data table, and the entity types corresponding to the entity columns in the entity column mapping table. That is, the domain management user can manage business data in a preset domain based on the domain management permissions granted by the platform management user. When a business data table is added to a preset domain, permission configuration only needs to be performed in response to the instruction of the corresponding domain management user, without requiring the platform management user to participate in the configuration, thus reducing configuration redundancy and permission management workload.

[0065] Step S15: Receive the query SQL sent by the current user through a preset application, dynamically generate permission filtering conditions based on the query SQL and the user identifier of the current user, and inject the permission filtering conditions into the query SQL to generate an SQL statement with permission filtering.

[0066] In this embodiment, permission filtering conditions are generated based on the business data and related mapping relationships generated in the preceding steps, so as to filter the query content of the current user based on the permission filtering conditions. Specifically, the dynamic generation of permission filtering conditions based on the query SQL and the user identifier of the current user may include: parsing the query SQL to determine the target business data table corresponding to the query SQL, and determining the entity column name and corresponding entity type associated with the target business data table from the entity column mapping table based on the target business data table; querying the user data permission table based on the user identifier of the current user and the entity type to determine the set of entity identifiers that the current user can access, and dynamically generating permission filtering conditions based on the set of entity identifiers and the entity column name. That is, the business data table name is extracted from the input query SQL, and the business data table name is used as the filtering condition to query the corresponding entity column name and entity type. Further, the queried entity type and the current user's information are used as the filtering condition to query the entities in the entity type that the current user has permission to access in the user data permission table.

[0067] It is worth mentioning that the query SQL can be parsed using a pre-defined SQL syntax parsing tool, improving parsing efficiency. Specifically, parsing the query SQL to determine the target business data table corresponding to the query SQL can include: using a pre-defined SQL syntax parsing tool to parse the query SQL and extract the names of one or more business data tables contained in the query SQL as the target business data table corresponding to the query SQL. The pre-defined SQL syntax parsing tool includes, but is not limited to, open-source SQL parsing tools such as Apache Calcite and JSQLParserdg.

[0068] It is important to note that using the business data table name as a filter condition may result in various entity types being retrieved. Specifically, the dynamic generation of permission filtering conditions based on the entity identifier set and the entity column name can include: if the entity identifier set is empty, generating a filter condition with a logical result of false for the corresponding entity column; if the entity identifier set contains a unique entity identifier, generating an equality filter condition in a preset format for the corresponding entity column; if the entity identifier set contains multiple entity identifiers, generating a set filter condition in a preset format for the corresponding entity column; if the target business data table is associated with multiple entity columns, combining the filter conditions generated for each entity column to form the final permission filtering conditions. The aforementioned preset SQL syntax parsing tool is then used to add the permission filtering conditions to the original SQL. For example, the business data table name is extracted from the input query SQL, and the extracted table names (which may be multiple) are denoted as... , ,… Using the extracted table name as the filter, query the entity column names and entity types from the entity list of the data table. The queried entity column names and entity types (there may be multiple types) are denoted as follows: , ,…, and , ,…, Using the entity type found in the query ( , ,…, Using the currently logged-in user ID as the filter, the system queries the user data permission table for entity IDs. Among n entity types, it checks the user data permission table to find entities of t entity types that the user has permission to access, where 0 ≤ t ≤ n. If t = 0, it means the user does not have permission to access the data table. , ,… Any record. If t > 0, use and (1≤i≤t) represents the name and type of the i-th entity column. Assume that the i-th entity type in the user data permission table corresponds to r entity IDs. Represents the entity ID, where 1 ≤ j ≤ r. Generate permission filtering conditions based on the aforementioned query results.

[0069] If t=0, the permission filtering condition is "1>2". When this filtering condition is appended to the query SQL, the result set returned by the executed SQL will definitely be empty.

[0070] If t=1 and r=1, the permission filtering condition is " ”;

[0071] If t=1 and r>1, the permission filtering condition is " ”;

[0072] If t > 1 and r ≥ 1, the permission filtering condition is " ".

[0073] Step S16: Use the SQL statement with permission filtering to query the corresponding business data from the business data table based on the mapping relationship, generate the corresponding query results based on the business data, and return the query results to the preset application.

[0074] In this embodiment, a user requests to query data in a specific business data table through a pre-defined application. The application calls a pre-defined permission SQL service interface to automatically add permission filtering conditions to the query SQL. The application then queries the business data table using the SQL and returns the result set to the user. Specifically, the application receives user input from the front end, which includes the ID of the business data table the user wants to access. The application generates a query SQL based on the business data table ID and related business logic. The application uses the query SQL to call the pre-defined permission SQL service interface, which automatically adds permission filtering conditions to the query SQL. The application uses the query SQL to access the business database to obtain business data and displays the returned result set to the user.

[0075] As can be seen from the above, this embodiment of the application introduces "domains" as special entities, distributing the core function of permission management from a single platform administrator to domain administrators, thus constructing a new authorization architecture that combines "centralization and decentralization." This is achieved by predefining entity types and entities, and binding user permissions to entities rather than specific data tables. Based on this, domain administrators register the business data tables they manage and declare the entity columns used for permission filtering and their corresponding entity types. When a user initiates a data query, precise row-level filtering conditions are dynamically generated and injected into the query statement based on the mapping relationship between the user's entity permissions and the entity columns of the target table. This not only significantly reduces the configuration workload and management risks for platform administrators dealing with massive amounts of data tables, but also ensures the accuracy of permission settings. Furthermore, it provides excellent scalability for permission management—adding a new user only requires configuring entity permissions, and adding a new data table only requires registration by the domain administrator, automatically achieving row-level permission control across the entire system. This improves the efficiency and flexibility of row-level data permission authorization while ensuring data security.

[0076] See Figure 2 As shown in the embodiments of this application, a specific row-level data permission authorization method is disclosed, including:

[0077] In this embodiment, the system contains multiple entity data tables. Assume table `entity_1` is a department table with the entity type "department," containing department definition data such as Sales Department 1 and Sales Department 2; table `entity_2` is a product table with the entity type "product." The system also contains multiple business data tables. Assume table `table_1` is a monthly sales report containing monthly sales statistics (such as sales volume and revenue) for Sales Department 1 and Sales Department 2; table `table_2` is a monthly inventory report. Platform administrators, domain administrators, and general users have all registered in the user table (`users`) and can log in normally.

[0078] The platform administrator performs system initialization (basic data module). First, basic data is registered in the database. Specific steps include registering entity types, registering entity data, and configuring domain administrators. For example, records ('dpt', 'department', 'entity_1') and ('domain', 'domain', null) are inserted into the `entity_type` table. Here, `dpt` represents the department type, whose data is stored in the `entity_1` table; `domain` represents a specific business domain type. Records are inserted into the `entities` table, such as ('dpt01', 'Sales Department 1', 'dpt') and ('domain01', 'Sales Domain', 'domain'). This creates the department entity "Sales Department 1" and the business domain entity "Sales Domain". Domain administrators are appointed by inserting an authorization record into the `user_data_permit` table. For example, inserting ('domain_admin_D', 'domain', 'domain01', '2') indicates that user `domain_admin_D` is granted administrative permissions to entity `domain01` (sales domain) (status 2 indicates authorized), thus becoming the domain administrator for that domain.

[0079] In this embodiment, user data permissions (user authorization module) are configured. For example, user zhangsan is transferred to Sales Department 1 and requests access to its sales statistics. User zhangsan requests access to the data of "Sales Department 1". The system inserts a record ('zhangsan', 'dpt', 'dpt01', '1') into the user_data_permit table, with status 1 indicating "Requesting". The platform administrator approves the request and updates the record's status to 2 ("Authorized"). At this point, user zhangsan is officially granted permission to access entity dpt01 (Sales Department 1). This permission is global.

[0080] In this embodiment, the registration business data table and entity column mapping (data table management module) are implemented.

[0081] Domain administrator `domain_admin_D` registers business data tables within the "Sales Domain" (domain01) it manages. It inserts a record into the `tables` table ('table_1', 'Sales Monthly Report', 'domain01'), declaring that table_1 belongs to the "Sales Domain". It also inserts a record into the `table_entity_columns` table ('table_1', 'sales_department', 'dpt'). This declares that the column named `sales_department` in table_1 is an "entity column," storing values ​​corresponding to entity identifiers of type `dpt` (department). This is crucial metadata connecting data and permissions.

[0082] In this embodiment, permission filtering conditions are dynamically generated and injected (permission SQL service module).

[0083] When user zhangsan queries data through the application, the "Permission SQL Service" automatically activates. The application issues a query: `SELECT * FROM table_1`. The Permission SQL Service uses an SQL parser (such as Apache Calcite) to parse the target table as `table_1`. Based on the table name `table_1`, it queries the `table_entity_columns` table to obtain the entity column `sales_department` and its corresponding entity type `dpt`. Based on the current user zhangsan and the entity type `dpt`, it queries the `user_data_permit` table to obtain the set of entity identifiers that zhangsan has permission to access: `{'dpt01'}`. Since there is only one entity identifier `dpt01` in the set, an equality filter condition `sales_department = 'dpt01'` is generated. This condition is injected into the original SQL, generating the final executed SQL: `SELECT * FROM table_1 WHERE sales_department = 'dpt01'`.

[0084] In this embodiment, a query is executed and the results are returned (by the application). The application executes the rewritten SQL statement described above. The database returns only the data rows where the sales_department field value is dpt01, which represents the monthly sales report data for "Sales Department 1". The results are returned to the user zhangsan, achieving precise row-level access control.

[0085] As can be seen from the above, this embodiment of the application introduces "domains" as a special entity, distributing the core function of permission management from a single platform administrator to domain administrators who are more familiar with the data tables of their respective business domains, resulting in more accurate permission configuration. With the workload distributed among 1+N administrators, permission management processing capabilities are stronger and responses are more timely. When a new user is added, only the platform administrator needs to configure permissions, without requiring each domain administrator to set permissions individually for the new user; when a new business data table is added, only the domain administrator of the business data table needs to configure permissions, without the platform administrator's involvement. This forward-looking design style reduces configuration redundancy and the workload of permission management.

[0086] See Figure 3 As shown in the figure, this application discloses a row-level data permission authorization device, including:

[0087] The basic data registration module 11 is used to register basic data to a preset database; the basic data includes entity types and entity data, the entity types include business domain types, and the entity data includes a preset business domain corresponding to the business domain type.

[0088] The first permission configuration module 12 is used to configure corresponding domain management users with domain management permissions for the preset business domain in the entity data.

[0089] The second permission configuration module 13 is used to create or update records in the user data permission table based on user permission requests, and to determine the permission relationship between the user identifier and the entity data based on the records; the records include user identifier, entity type, entity identifier and permission status.

[0090] The business data registration module 14 is used to register a business data table in the preset business domain based on the user instructions of the domain management user, and to register the mapping relationship between the entity columns contained in the business data table and the entity type.

[0091] The permission filtering module 15 is used to receive the query SQL issued by the current user through a preset application, dynamically generate permission filtering conditions based on the query SQL and the user identifier of the current user, and inject the permission filtering conditions into the query SQL to generate an SQL statement with permission filtering.

[0092] The data query module 16 is used to query the corresponding business data from the business data table based on the mapping relationship using the SQL statement with permission filtering, generate the corresponding query results based on the business data, and return the query results to the preset application.

[0093] In some specific embodiments, the first permission configuration module 12 may specifically include:

[0094] The domain permission record unit is used to configure corresponding domain management users with domain management permissions for a preset business domain by creating target records in the user data permission table;

[0095] Wherein, the user identifier in the target record is the user identifier of the domain management user; the entity type in the target record is the type representing the domain; the entity identifier in the target record is the identifier of the preset business domain; and the permission status in the target record is authorized.

[0096] In some specific embodiments, the second permission configuration module 13 may specifically include:

[0097] The permission request unit is used to create a record in the user data permission table with a permission status of "in progress" based on the user's permission request.

[0098] The permission approval unit is used to update the permission status of the record to authorized based on the approval results of the platform-managed users;

[0099] Among them, records with an authorized permission status indicate that the corresponding user has data access permissions to the corresponding entity data.

[0100] In some specific embodiments, the business data registration module 14 may specifically include:

[0101] A business data registration unit is used to record the name, description, and identifier of the preset business domain of the business data table in the metadata of the business data table.

[0102] The mapping relationship registration unit is used to record the name of the business data table, the name of the entity column contained in the business data table, and the entity type corresponding to the entity column in the entity column mapping table.

[0103] In some specific embodiments, the permission filtering module 15 may specifically include:

[0104] The query SQL parsing submodule is used to parse the query SQL to determine the target business data table corresponding to the query SQL, and to determine the entity column name and corresponding entity type associated with the target business data table from the entity column mapping table based on the target business data table;

[0105] The permission filtering condition generation submodule is used to query the user data permission table based on the current user's user identifier and the entity type to determine the set of entity identifiers that the current user can access, and dynamically generate permission filtering conditions based on the set of entity identifiers and the entity column name.

[0106] Accordingly, the query SQL parsing submodule may specifically include:

[0107] The query SQL parsing unit is used to parse the query SQL using a preset SQL syntax parsing tool, so as to extract the names of one or more business data tables contained in the query SQL as the target business data table corresponding to the query SQL;

[0108] Accordingly, the permission filtering condition generation submodule may specifically include:

[0109] The first permission filtering condition generation unit is used to generate a filtering condition with a logical result of false for the corresponding entity column if the entity identifier set is empty.

[0110] The second permission filtering condition generation unit is used to generate an equal value filtering condition in a preset format for the corresponding entity column if the entity identifier set contains a unique entity identifier.

[0111] The third permission filtering condition generation unit is used to generate a set filtering condition in a preset format for the corresponding entity column if the entity identifier set contains multiple entity identifiers.

[0112] The fourth permission filtering condition generation unit is used to combine the filtering conditions generated for each entity column to form the final permission filtering conditions if the target business data table is associated with multiple entity columns.

[0113] Furthermore, embodiments of this application also disclose an electronic device, Figure 4 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the row-level data permission authorization method disclosed in any of the foregoing embodiments. Furthermore, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0114] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0115] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0116] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the row-level data permission authorization method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include a computer program capable of performing other specific tasks.

[0117] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned row-level data permission authorization method. The specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0118] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0119] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0120] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0121] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

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

Claims

1. A row-level data permission authorization method, characterized in that, include: Register the basic data into the preset database; The basic data includes entity types and entity data. The entity types include business domain types, and the entity data includes preset business domains corresponding to the business domain types. Configure corresponding domain management users with domain management permissions for the preset business domain in the entity data; Based on user permission requests, a record is created or updated in the user data permission table, and the permission relationship between the user identifier and the entity data is determined based on the record; the record includes user identifier, entity type, entity identifier, and permission status; Based on the user instructions of the domain management user, register a business data table in the preset business domain, and register the mapping relationship between the entity columns contained in the business data table and the entity type; Receive the query SQL sent by the current user through a preset application, dynamically generate permission filtering conditions based on the query SQL and the user identifier of the current user, and inject the permission filtering conditions into the query SQL to generate an SQL statement with permission filtering. The SQL statement with permission filtering is used to query the corresponding business data from the business data table based on the mapping relationship, so as to generate the corresponding query results based on the business data, and return the query results to the preset application.

2. The row-level data permission authorization method according to claim 1, characterized in that, The step of configuring corresponding domain management users with domain management permissions for the preset business domain in the entity data includes: By creating target records in the user data permission table, corresponding domain management users with domain management permissions are configured for the preset business domains; Wherein, the user identifier in the target record is the user identifier of the domain management user; the entity type in the target record is the type representing the domain; the entity identifier in the target record is the identifier of the preset business domain; and the permission status in the target record is authorized.

3. The row-level data permission authorization method according to claim 1, characterized in that, The creation or updating of records in the user data permission table based on user permission requests includes: Based on the user's permission request, create a record in the user data permission table with the permission status "in progress"; The permission status of the recorded information will be updated to authorized based on the approval results of the platform-managed users. Among them, records with an authorized permission status indicate that the corresponding user has data access permissions to the corresponding entity data.

4. The row-level data permission authorization method according to claim 1, characterized in that, The mapping relationship between the entity columns and the entity types contained in the business data table is registered, including: The name, description, and identifier of the preset business domain of the business data table are recorded in the metadata of the business data table. The entity column mapping table records the name of the business data table, the names of the entity columns contained in the business data table, and the entity types corresponding to the entity columns.

5. The row-level data permission authorization method according to claim 4, characterized in that, The dynamic generation of permission filtering conditions based on the query SQL and the current user's identifier includes: The query SQL is parsed to determine the target business data table corresponding to the query SQL, and the entity column name and corresponding entity type associated with the target business data table are determined from the entity column mapping table based on the target business data table; The system queries the user data permission table based on the current user's user identifier and the entity type to determine the set of entity identifiers that the current user can access, and dynamically generates permission filtering conditions based on the set of entity identifiers and the entity column name.

6. The row-level data permission authorization method according to claim 5, characterized in that, The dynamic generation of permission filtering conditions based on the entity identifier set and the entity column name includes: If the entity identifier set is empty, then a filtering condition with a logical result of false is generated for the corresponding entity column; If the entity identifier set contains a unique entity identifier, then a preset format of equality filtering conditions is generated for the corresponding entity column; If the entity identifier set contains multiple entity identifiers, then a preset format set filtering condition is generated for the corresponding entity column; If the target business data table is associated with multiple entity columns, the filter conditions generated for each entity column are combined to form the final permission filter conditions.

7. The row-level data permission authorization method according to claim 5, characterized in that, The step of parsing the query SQL to determine the target business data table corresponding to the query SQL includes: The query SQL is parsed using a preset SQL syntax parsing tool to extract the names of one or more business data tables contained in the query SQL as the target business data table corresponding to the query SQL.

8. A row-level data permission authorization device, characterized in that, include: The basic data registration module is used to register basic data into a preset database; The basic data includes entity types and entity data. The entity types include business domain types, and the entity data includes preset business domains corresponding to the business domain types. The first permission configuration module is used to configure corresponding domain management users with domain management permissions for the preset business domain in the entity data; The second permission configuration module is used to create or update records in the user data permission table based on user permission requests, and to determine the permission relationship between the user identifier and the entity data based on the records; the records include user identifier, entity type, entity identifier and permission status; The business data registration module is used to register a business data table in the preset business domain based on the user instructions of the domain management user, and to register the mapping relationship between the entity columns contained in the business data table and the entity type; The permission filtering module is used to receive the query SQL sent by the current user through a preset application, dynamically generate permission filtering conditions based on the query SQL and the user identifier of the current user, and inject the permission filtering conditions into the query SQL to generate an SQL statement with permission filtering. The data query module is used to query the corresponding business data from the business data table based on the mapping relationship using the SQL statement with permission filtering, generate the corresponding query results based on the business data, and return the query results to the preset application.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the row-level data permission authorization method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Used to store a computer program, wherein the computer program, when executed by a processor, implements the row-level data permission authorization method as described in any one of claims 1 to 7.

Images