Universal API (Application Program Interface) data access control method and device, equipment and storage medium

Abstract

The invention discloses a universal API data access control method and device, equipment and a storage medium, and the method comprises the steps: obtaining a data model and a database table corresponding to the data model, and creating an associated universal API function according to the data model and the database table; configuring a table-level permission, a row-level permission and a column-level permission for the combination of the role and the data model; dynamically analyzing and applying a table-level permission, a row-level permission and a column-level permission through a universal API function of the universal API module; the system can be seamlessly integrated with a general API and a low-code platform, complete decoupling of authority management and business logic is realized, table-level, row-level and column-level refined data access control can be provided at the same time, the security, flexibility and development efficiency of data access are improved, increasingly complicated business requirements are met, and the system is suitable for popularization and application. According to the invention, refined, dynamic and code-free authority control of the universal API is realized, and the speed and efficiency of the universal API data access control method are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer data security, and in particular to a general API data access control method, device, equipment and storage medium. BACKGROUND

[0002] The prior art widely adopts a Role-Based Access Control (RBAC) model to implement table-level, row-level and column-level data access control for specific module functions; each role can be assigned to multiple users, and the data access control of the function module is configured under the role, and a data access control method is introduced in the function module, so that the corresponding user can apply the configured data access permission after logging in the system; this technology effectively solves the data isolation problem between different roles, but in the scene of low-code Application Programming Interface (API), due to the lack of fixed function scene, it cannot be well applied.

[0003] The prior art usually makes an assumption that the module is fixed, and requires to configure data access permission for each specific function module separately; however, in modern application development, the module is often dynamic and variable, for example, in a low-code platform, the function module can be added, removed or adjusted at any time according to business needs, which makes the traditional permission configuration method unable to adapt to such flexibility, resulting in that the permission cannot be dynamically applied, thereby causing security risks, management complexity and function limitations.

[0004] Specifically, when the module is not fixed, the system cannot automatically identify and configure the permission, and needs to rely on manual intervention or hard coding, which not only increases the development and maintenance cost, but also reduces the response speed and adaptability of the system, and cannot support joint query of multiple tables. SUMMARY

[0005] The main purpose of the present application is to provide a general API data access control method, device, equipment and storage medium, which aims to solve the technical problems in the prior art that in the low-code platform dynamic data model environment, due to the dependence on the fixed function module assumption, the fine-grained permission control of table level, row level and column level cannot be realized, and there is a lack of support for multi-table joint query, resulting in serious limitation of data security and business flexibility.

[0006] In a first aspect, the present application provides a general API data access control method, which comprises the following steps: obtaining a data model and a database table corresponding to the data model, and creating an associated general API function according to the data model and the database table; configure table-level permissions, row-level permissions and column-level permissions for a combination of a role and the data model; dynamically analyze and apply the table-level permissions, the row-level permissions and the column-level permissions through the common API function of the common API module.

[0007] Optionally, the obtaining the data model and the database table corresponding to the data model, and creating an associated common API function according to the data model and the database table, comprises: obtaining a defined data model and a corresponding database table through user interaction; obtaining a unique code of the data model from the database table, and generating a standardized common API function according to the unique code.

[0008] Optionally, the configuring table-level permissions, row-level permissions and column-level permissions for a combination of a role and the data model, comprises: configuring table-level permissions, row-level permissions and column-level permissions for a combination of a role of a specific user and the data model through a visual interface.

[0009] Optionally, the configuring table-level permissions, row-level permissions and column-level permissions for a combination of a role of a specific user and the data model through a visual interface, comprises: determining a combination of a role of a specific user and the data model; configuring, through a visual interface, table-level permissions corresponding to operation permissions of the role on the data model for the combination; configuring, for the combination, row-level permissions corresponding to dynamic filtering of data according to a preset condition expression; configuring, for the combination, column-level permissions corresponding to readability and writeability of each field in the data model.

[0010] Optionally, the dynamically analyzing and applying the table-level permissions, the row-level permissions and the column-level permissions through the common API function of the common API module, comprises: when an API request is received, dynamically analyzing, through the common API function of the common API module, legality of a target table-level permission, and returning access exception information when there is no permission; when the target table-level permission passes the verification, analyzing a target row-level permission, generating a SQL row-level filtering condition, analyzing a target column-level permission, determining readable fields, and analyzing joint query configuration in a target model to generate an association condition; assembling a SQL statement according to the access exception information, the SQL row-level filtering condition, the readable fields and the association condition, executing the SQL statement, and returning a database query statement filtered by permissions.

[0011] Optionally, the legality of the table-level permission is dynamically resolved by the general API function of the general API module upon receiving the API request, and access exception information is returned when there is no permission, comprising: Upon receiving the API request, the target user, target role, target model and operation type are dynamically resolved by the general API function of the general API module; Based on the target user, the target role and the target model, the permission rule library is queried to obtain the target table-level permission, the target row-level permission and the target column-level permission; The target model is subjected to the target table-level permission check, and access exception information is returned when the target table-level permission check fails.

[0012] Optionally, when the target table-level permission check passes, the target row-level permission is resolved, the SQL row-level filtering condition is generated, the target column-level permission is resolved, the readable field is determined, and the joint query configuration in the target model is resolved to generate the association condition, comprising: When the target table-level permission check passes, the target row-level permission is dynamically resolved, and the SQL row-level filtering condition for converting the condition expression into the SQL WHERE clause is generated in real time; The target column-level permission rule is resolved at the same time, the readable field of the target role is determined, the readable field list is generated according to the readable field, and the readable field list is applied to the SELECT part of the SQL query; The preconfigured joint query association in the target model is resolved at the same time to generate the association condition corresponding to the JOIN clause.

[0013] In the second aspect, in order to achieve the above object, the application further provides a general API data access control device, which comprises: An API function creation module is configured to obtain a data model and a database table corresponding to the data model, and create an associated general API function according to the data model and the database table; A permission configuration module is configured to configure table-level permissions, row-level permissions and column-level permissions for a combination of a role and the data model; A resolution and application module is configured to dynamically resolve and apply the table-level permissions, the row-level permissions and the column-level permissions through the general API function of the general API module.

[0014] In a third aspect, to achieve the above object, the present application further provides a general API data access control device, which comprises a memory, a processor, and a general API data access control program stored in the memory and executable on the processor, and the general API data access control program is configured to implement the steps of the general API data access control method as described above.

[0015] In a fourth aspect, to achieve the above object, the present application further provides a storage medium, which stores a general API data access control program, and the general API data access control program, when executed by a processor, implements the steps of the general API data access control method as described above.

[0016] The general API data access control method provided by the present application can be seamlessly integrated with general API and low-code platform, realizes complete decoupling of permission management and business logic, can provide fine-grained data access control at the table level, row level and column level, improves the security, flexibility and development efficiency of data access, meets the increasingly complex business requirements, realizes fine-grained, dynamic and no-code permission control of general API, greatly improves the data security, management efficiency and system adaptability under the low-code platform and general API scenario, and improves the speed and efficiency of the general API data access control method. BRIEF DESCRIPTION OF DRAWINGS

[0017] Figure 1 The device structure schematic diagram of the hardware running environment involved in the embodiment scheme of the present application; Figure 2 The flowchart of the first embodiment of the general API data access control method of the present application; Figure 3 The flowchart of the second embodiment of the general API data access control method of the present application; Figure 4 The flowchart of the third embodiment of the general API data access control method of the present application; Figure 5 The flowchart of the fourth embodiment of the general API data access control method of the present application; Figure 6 The data access processing flowchart in the general API data access control method of the present application; Figure 7The function module diagram of the first embodiment of the general API data access control device of the present application.

[0018] The implementation, functional features and advantages of the present application will be further described with reference to the embodiments and the accompanying drawings. DETAILED DESCRIPTION

[0019] It should be understood that the specific embodiments described herein are merely intended to explain the present application and are not intended to limit the present application.

[0020] The solution of the embodiment of the present application is mainly: by acquiring a data model and a database table corresponding to the data model, creating an associated general API function according to the data model and the database table; configuring table-level permissions, row-level permissions and column-level permissions for a combination of a role and the data model; dynamically parsing and applying the table-level permissions, the row-level permissions and the column-level permissions through the general API function of the general API module; being able to be seamlessly integrated with the general API and the low-code platform, realizing complete decoupling of permission management and business logic, being able to provide fine-grained data access control at the table level, the row level and the column level at the same time, improving the security, flexibility and development efficiency of data access, meeting increasingly complex business requirements, realizing fine-grained, dynamic and no-code permission control of the general API, greatly improving the data security, management efficiency and system adaptability under the low-code platform and the general API scenario, improving the speed and efficiency of the general API data access control method, and solving the technical problems that in the prior art, in the low-code platform dynamic data model environment, due to the dependence on fixed function modules assumptions, the fine-grained permission control at the table level, the row level and the column level cannot be realized, and there is a lack of support for multi-table joint query, resulting in serious limitations of data security and business flexibility.

[0021] Referring to Figure 1 , Figure 1 The device structure schematic diagram of the hardware running environment involved in the embodiment of the present application.

[0022] As Figure 1As shown in the figure, the device can include: a processor 1001, such as a CPU, a communication bus 1002, a user interface 1003, a network interface 1004, a memory 1005. Among them, the communication bus 1002 is used to realize the connection communication between these components. The user interface 1003 can include a display screen (Display), an input unit such as a keyboard (Keyboard), and the optional user interface 1003 can also include a standard wired interface, a wireless interface. The network interface 1004 can optionally include a standard wired interface, a wireless interface (such as a Wi-Fi interface). The memory 1005 can be a high-speed RAM memory, or a stable memory (Non-Volatile Memory), such as a disk memory. The memory 1005 can also be an optional storage device independent of the aforementioned processor 1001.

[0023] Those skilled in the art can understand that, Figure 1 The device structure shown in the figure does not constitute a limitation on the device, and can include more or fewer components than the figure, or combine certain components, or different component arrangements.

[0024] As Figure 1 As shown, the memory 1005 as a storage medium can include an operating device, a network communication module, a user interface module, and a general API data access control program.

[0025] The device of the present application calls the general API data access control program stored in the memory 1005 through the processor 1001, and performs the following operations: Obtain the data model and the database table corresponding to the data model, and create the associated general API function according to the data model and the database table; Configure table-level permissions, row-level permissions and column-level permissions for the combination of roles and the data model; Dynamically parse and apply the table-level permissions, the row-level permissions and the column-level permissions through the general API function of the general API module.

[0026] The device of the present application calls the general API data access control program stored in the memory 1005 through the processor 1001, and also performs the following operations: Obtain the defined data model and its corresponding database table through user interaction; Obtain the unique code of the data model from the database table, and generate a standardized general API function according to the unique code.

[0027] The device of the present application calls the general API data access control program stored in the memory 1005 through the processor 1001, and also performs the following operations: Configure table-level permissions, row-level permissions and column-level permissions for a combination of a specific user's role and the data model through a visual interface.

[0028] The device of the application further performs the following operations by calling the general API data access control program stored in the memory 1005 through the processor 1001: Determine the combination of a specific user's role and the data model; Configure the table-level permissions corresponding to the read, write, update and delete operation permissions of the role on the data model for the combination through the visual interface; Configure the row-level permissions corresponding to the dynamic data filtering according to the preset condition expression for the combination; Configure the column-level permissions corresponding to the readability and writability of each field in the data model for the combination.

[0029] The device of the application further performs the following operations by calling the general API data access control program stored in the memory 1005 through the processor 1001: When receiving an API request, dynamically analyze the legality of the target table-level permission through the general API function of the general API module, and return access exception information when there is no permission; When the target table-level permission is verified, parse the target row-level permission, generate the SQL row-level filtering condition, parse the target column-level permission, determine the readable field, and parse the joint query configuration in the target model to generate the association condition; Assemble the SQL statement according to the access exception information, the SQL row-level filtering condition, the readable field and the association condition, execute the SQL statement, and return the database query statement filtered by the permission.

[0030] The device of the application further performs the following operations by calling the general API data access control program stored in the memory 1005 through the processor 1001: When receiving an API request, dynamically analyze the target user, target role, target model and operation type through the general API function of the general API module; Query the permission rule library based on the target user, the target role and the target model to obtain the target table-level permission, the target row-level permission and the target column-level permission; Perform the target table-level permission verification on the target model, and return access exception information when the target table-level permission verification fails.

[0031] The device of the application further performs the following operations by calling the general API data access control program stored in the memory 1005 through the processor 1001: When the target table-level permission check passes, dynamically analyze the target row-level permission, and generate a SQL row-level filtering condition that converts the conditional expression into a SQL WHERE clause in real time; Meanwhile, analyze the target column-level permission rule, determine the readable fields of the target role, generate a readable field list according to the readable fields, and apply the readable field list to the SELECT part of the SQL query; Meanwhile, analyze the preconfigured joint query association in the target model, and generate an association condition corresponding to the JOIN clause.

[0032] The above scheme, by obtaining a data model and a database table corresponding to the data model, creating an associated general API function according to the data model and the database table, configuring table-level permissions, row-level permissions, and column-level permissions for a combination of a role and the data model, dynamically analyzing and applying the table-level permissions, the row-level permissions, and the column-level permissions through the general API function of the general API module, can be seamlessly integrated with general API and low-code platform, completely decouples permission management and business logic, provides fine-grained data access control at the table level, row level, and column level, improves the security, flexibility, and development efficiency of data access, meets increasingly complex business requirements, realizes fine-grained, dynamic, and codeless permission control of general API, greatly improves the data security, management efficiency, and system adaptability in the low-code platform and general API scenarios, and improves the speed and efficiency of the general API data access control method.

[0033] Based on the above hardware structure, the present application proposes a general API data access control method embodiment.

[0034] Reference Figure 2 , Figure 2 The flowchart of the first embodiment of the general API data access control method of the present application.

[0035] In the first embodiment, the general API data access control method comprises the following steps: Step S10, obtaining a data model and a database table corresponding to the data model, and creating an associated general API function according to the data model and the database table.

[0036] It should be noted that the data model and its corresponding database table are obtained, and an associated general API function is created according to the data model and the database table, realizing dynamic binding of the data model, the database table, and the API function.

[0037] Step S20, configuring table-level permissions, row-level permissions, and column-level permissions for a combination of a role and the data model.

[0038] It should be understood that fine-grained configuration can be performed for the combination of a specific user role (such as "ordinary employee") and a data model, and table-level permission, row-level permission and column-level permission can be configured.

[0039] Step S30, dynamically resolving and applying the table-level permission, the row-level permission and the column-level permission through the general API function of the general API module.

[0040] It can be understood that the general API module can dynamically resolve the table-level permission, the row-level permission and the column-level permission configured in the permission rule library in real time when processing an API request, and seamlessly apply them to the SQL query construction process, ensuring that fine-grained control of data access is automatically completed in a single request without the need for hard coding or system restart.

[0041] The embodiment can seamlessly integrate with the general API and the low-code platform, realize complete decoupling of permission management and business logic, provide fine-grained data access control at the table level, row level and column level, improve the security, flexibility and development efficiency of data access, meet increasingly complex business requirements, realize fine-grained, dynamic and no-code permission control of the general API, greatly improve the data security, management efficiency and system adaptability in the low-code platform and general API scenarios, and improve the speed and efficiency of the general API data access control method.

[0042] Further, Figure 3 The flowchart of the second embodiment of the general API data access control method of the present application is shown in FIG. 2. Figure 3 As shown in FIG. 2, the second embodiment of the general API data access control method of the present application is based on the first embodiment, and in this embodiment, the step S10 specifically includes the following steps: Step S11, obtaining the defined data model and its corresponding database table through user interaction.

[0043] It should be noted that in the model management interface provided by the system, the defined data model (such as the "order" model) and its associated database table (such as the "order" table) can be specified through intuitive user interaction operations (such as selecting a drop-down menu, clicking an import button or filling out a form), and the system can obtain and store these associations in real time, support direct import from existing database tables or new data model creation and synchronization to the database, and provide dynamic binding of basic data for subsequent permission configuration and API generation.

[0044] Step S12, obtain the unique code of the data model from the database table, and generate a standardized general API function according to the unique code.

[0045] It can be understood that by querying the metadata of the database table (such as the model identification field or the table name), the unique code of the data model (for example, "order") can be extracted, and a standardized general API function can be automatically constructed based on the code, and the access path strictly follows the specification of / sys / [model code] / [list, add, update, delete] (such as / sys / order / list), which realizes the dynamic binding of the data model and the API function without manual intervention.

[0046] The above scheme, through user interaction, obtains the defined data model and its corresponding database table; obtains the unique code of the data model from the database table, and generates a standardized general API function according to the unique code, which can significantly improve the development efficiency of the low-code platform, eliminate manual coding errors, ensure the uniformity of API paths, provide a directly callable standardized entrance for subsequent table-level, row-level and column-level permission control, and support seamless integration of fine-grained data security management.

[0047] Further, Figure 4 The flowchart of the third embodiment of the general API data access control method of the present application is shown in Figure 4 The third embodiment of the general API data access control method of the present application is proposed based on the first embodiment, and in this embodiment, the step S20 specifically includes the following steps: Step S21, configuring table-level permissions, row-level permissions and column-level permissions for the combination of a specific user role and the data model through a visual interface.

[0048] It should be noted that through the intuitive visual permission configuration interface, the combination of a specific user role (such as "ordinary employee") and a data model (such as "order table") can be fine-grained configured with table-level permissions, row-level permissions and column-level permissions.

[0049] Further, the step S21 specifically includes the following steps: determining the combination of a specific user role and the data model; configuring the table-level permissions corresponding to the role's add, delete, modify and query operation permissions on the data model for the combination through a visual interface; configuring the row-level permissions corresponding to the dynamic data filtering according to the preset condition expression for the combination; The column-level permissions corresponding to the readability and the writeability of each field in the data model are configured for the combination.

[0050] It can be understood that in the permission rule configuration module, the combination of a specific user role (such as "administrator" or "ordinary employee") and a data model (such as "user table" or "order table") can be finely configured through a visual interface: the table-level permission explicitly specifies the permission of the role to the model for the operations of adding, deleting, modifying and querying (for example, "query" is allowed but "delete" is prohibited); the row-level permission realizes dynamic filtering of data rows by defining a conditional expression (such as user_id = current user ID or status = 'audited'); and the column-level permission sets the readability (such as hiding the "password" field) and the writeability (such as prohibiting modification of the "creation time" field) of each field in the model separately, so as to ensure that the permission rule is accurately matched with the business requirement without code intervention.

[0051] Through the above scheme, the table-level permission, the row-level permission and the column-level permission are configured for the combination of a specific user role and the data model through a visual interface, which can significantly improve the flexibility, security and management efficiency of data access control, provides a dynamic and non-intrusive permission management capability for a low-code platform, and ensures that sensitive data is protected in all aspects in the operations of querying, editing and deleting.

[0052] Further, Figure 5 As shown in a flowchart of a fourth embodiment of the universal API data access control method of the present application, Figure 5 Based on the first embodiment, the fourth embodiment of the universal API data access control method of the present application is proposed, and in the present embodiment, the step S30 specifically includes the following steps: In step S31, when the API request is received, the legality of the target table-level permission is dynamically analyzed through the universal API function of the universal API module, and access exception information is returned when there is no permission.

[0053] It should be noted that when the API request is received, the universal API module will immediately call its standardized function to dynamically verify the table-level permission (i.e. the permission status of the operations of adding, deleting, modifying and querying) of the current user role to the target data model (such as the "order" model in / sys / order / list), so as to block unauthorized access at the first time of request processing, and ensure the security and compliance of data operation.

[0054] Further, the step S31 specifically includes the following steps: When the API request is received, the target user, the target role, the target model and the operation type are dynamically analyzed through the universal API function of the universal API module; query a permission rule library based on the target user, the target role, and the target model to obtain target table-level permission, target row-level permission, and target column-level permission; perform the target table-level permission check on the target model, and return access exception information when the target table-level permission check fails.

[0055] It should be understood that after receiving an API request, the general API module dynamically parses the target user, role, data model, and operation type (such as the "order" model and "query" operation in / sys / order / list) in real time; the system queries the permission rule library based on these information to obtain the table-level permission (control add, delete, modify, and query operations), row-level permission (row-level filter conditions), and column-level permission (field readability) of the combination of the role and the data model; subsequently, the table-level permission check (for example, verifying whether the role is allowed to perform the "query" operation) is performed on the target model, and if the check fails (for example, no access to the model), a standardized access exception information (for example, "403 Forbidden: no permission to access the data model") is returned immediately, thereby blocking unauthorized access in the initial stage of request processing and ensuring data security.

[0056] Step S32, when the target table-level permission check passes, parse the target row-level permission, generate a SQL row-level filter condition, parse the target column-level permission, determine readable fields, and parse the joint query configuration in the target model to generate a correlation condition.

[0057] It can be understood that after the target table-level permission check passes, the row-level permission rule (such as user_id = current user ID) can be dynamically parsed to generate a SQL row-level filter condition, the target column-level permission can be parsed to determine readable fields, and the joint query configuration in the target model can be parsed to generate a correlation condition.

[0058] Further, the step S32 specifically includes the following steps: when the target table-level permission check passes, dynamically parse the target row-level permission, and generate a SQL row-level filter condition that converts a condition expression into a SQL WHERE clause in real time; simultaneously parse the target column-level permission rule, determine readable fields of the target role, generate a readable field list according to the readable fields, and apply the readable field list to the SELECT part of the SQL query; simultaneously parse the preconfigured joint query correlation in the target model to generate a correlation condition corresponding to a JOIN clause.

[0059] It should be noted that after the target table-level permission verification passes, the system dynamically parses the row-level permission rules (such as user_id=current user ID), and converts the conditional expressions into SQL WHERE clauses in real time to achieve row-level data filtering. At the same time, it parses the column-level permission rules, accurately determines the readable fields of the target role and generates a field list (such as hiding the "password" field), and directly applies it to the SELECT part of the SQL query to automatically filter sensitive fields. In addition, the system parses the pre-configured join query relationships in the target model (such as order.user_id=user.id), generates the corresponding JOIN clause relationship conditions, and finally seamlessly integrates the row-level filtering conditions, column-level field control and multi-table join logic to assemble a secure and complete SQL statement, ensuring granular and automated data access.

[0060] Step S33: Assemble an SQL statement based on the access exception information, the SQL row-level filtering conditions, the readable fields, and the association conditions; execute the SQL statement; and return a database query statement that has been filtered by permissions.

[0061] It should be understood that after the target table-level permission verification passes, the SQL row-level filtering conditions, readable fields, and join query conditions are dynamically integrated and automatically assembled into a safe and complete SQL query statement. After execution, the permission-filtered query results are returned to the user to ensure the accuracy and security of data access. Meanwhile, access exception information is only triggered when permission verification fails and does not participate in this assembly process.

[0062] In the specific implementation, see Figure 6 , Figure 6 This is a schematic diagram of the data access processing flow in the general API data access control method of the present invention, as shown below. Figure 6 As shown, through Figure 6 The data access control method's processing flow can ensure that every API call undergoes strict dynamic permission filtering.

[0063] 1. After receiving an API request, the system first parses out the key information (user, role, target model, operation type) and retrieves the corresponding permission configuration from the permission rule base based on this information.

[0064] 2. Perform first-level table-level permission verification. Check if the current role has permission to perform the requested operation (such as query) on this model; if not, the process will directly jump to return a permission exception and deny access.

[0065] 3. If table-level permissions are granted, the system continues to parse row-level permission rules and dynamically converts them into the "WHERE" clause of an SQL query to filter data rows.

[0066] 4. Then, the system parses the column-level permission rules, determines the fields readable or writable by the current role, and generates the `SELECT` part of the SQL query accordingly, achieving the hiding of sensitive fields.

[0067] 5. The system checks and parses the federated query relationships configured in the model, generating the corresponding `JOIN` clauses.

[0068] Assemble the previously generated SELECT, FROM, JOIN, WHERE, and other clauses into a complete and secure SQL query statement and submit it to the database for execution.

[0069] 6. When the table-level permission check fails, the system returns a permission exception response to the user.

[0070] 7. After the database execution is successful, the query result filtered by permissions is returned to the user.

[0071] This process realizes three-level fine-grained permission control from tables, rows to columns, and seamlessly integrates federated query capabilities. The entire process is automated and dynamic, without the need for hard coding.

[0072] This embodiment realizes fine-grained, dynamic, and codeless permission management and control of general APIs by modeling and configuring permission rules, dynamically parsing and applying them to the data query process. The implementation of this embodiment includes the following core modules and steps: Model management module: used to define data models, each model corresponding to a table in the database; the module defines the field (column) information of the model, such as field name, data type, etc., and implements the general API function associated with the model.

[0073] Role management module: used to create and manage user roles (such as "administrator", "manager", "ordinary employee") and associate users with roles.

[0074] Permission rule configuration module: the core of this embodiment; in this module, the administrator can configure three-level permissions for the combination of "role" and "data model" through a graphical interface.

[0075] Table-level permission configuration: for a specified role and model, configure permissions or deny for the four basic operations of addition, deletion, modification, and query.

[0076] Row-level permission configuration: when reading is allowed, further configure row-level filtering rules; rules are defined in the form of conditional expressions, for example, for the "order" model and "ordinary employee" role, the rule can be configured as [order. creator] == [current user. ID]. These rules can be a combination of one or more conditions, using or relationship or and relationship.

[0077] Column-level permission configuration: For all fields (columns) in the model, the "readable" and "writable" permissions can be configured for the specified role; for example, for the "employee" model and the "ordinary employee" role, the "salary" column can be set as not readable and not writable.

[0078] Implementation steps: Step 1: Create a model management module that contains general API functions associated with the model.

[0079] In this embodiment, the model management module realizes a one-to-one correspondence between the data table and the model, supports synchronizing a newly created model to the database, and can also select a table in the database to create a model; based on the basic information of the model, general API functions are created, and users can call the add, delete, update, and query interfaces of the relevant model by accessing paths such as / sys / [model code] / [list, add, update, delete].

[0080] Step 2: Create a role management module.

[0081] In this embodiment, the role management module is responsible for the creation, editing, deletion, and query operations of the role, and can associate users with the role.

[0082] Step 3: Create a permission rule configuration module.

[0083] In this embodiment, the permission rule module is used to configure the relationship between the model and the role. The specific process is as follows: first, select the model and configure the associated role under it; then select the role and set its add, delete, update, and query operation permissions; if the query permission is enabled, the row-level permission configuration is triggered, and fixed rules (such as [order. creator] == [current user. ID]) or SQL rules and other flexible options can be set; finally, the readability or writability of the fields in the model for the role is selected. The above configuration is completed to realize the function of this step.

[0084] Step 4: The general API module is based on the permission rules of step 3.

[0085] In this embodiment, step 3 has established the association between the model, role, and permission point, and this step aims to integrate these associations into the general API. The table-level permission corresponds to the add, delete, update, and query operations of the API, and when there is no permission, the access exception is returned directly; the row-level permission adjusts the general query interface, parses the configuration rules to generate SQL statements, and is attached to the query, edit, and delete operations; the column-level permission determines the returned field set as the output field of the SQL query.

[0086] Step 5: Support joint query.

[0087] In this embodiment, based on the model management module created in step 1, a joint query association configuration can be added to the model to associate other models and set the association field; in step 4, the SQL of the joint query is parsed and integrated into the processing flow of step 4 to finally generate a database query statement.

[0088] It should be noted that the present embodiment aims to completely solve the limitations of the prior art, in which the permission configuration is subject to the "module fixed" assumption, and the core problem that permissions cannot be dynamically applied in the low-code general API scenario; through the present solution, the "model management module" decouples the granularity of permission control from specific functions to a more stable "data model" (i.e., a database table), and each data model encapsulates general API operations; instead of configuring permissions one by one for changing business function modules, the administrator dynamically configures fine-grained permission rules in three dimensions of table level, row level, and column level for the combination of "roles" and "data models" through the visual interface of the "permission rule configuration module"; this design ensures that whether the function modules are added, removed, or adjusted, the underlying data access control can always be based on the data model to be stable and effective, thereby solving the pain point that the traditional method cannot adapt to the flexibility of the low-code platform.

[0089] Dynamic parsing and application of permissions is the key innovation of the present embodiment. When a user accesses data through a general API, the system quickly parses the role of the current user and its associated permission rules at runtime, rather than relying on pre-set hardcoding; for example, the conditional expression of row-level permissions (such as [order. creator] == [current user. ID]) can be instantly converted into a WHERE clause of a SQL query and automatically attached to the query, edit, delete, and other operations; column-level permissions dynamically determine the returned field set; this flexible and real-time mechanism ensures that permissions can be dynamically adjusted in line with business logic without code changes or system restarts, greatly improving the security of the system, reducing the complexity of management, and eliminating the limitations of traditional permission management on function expansion, effectively avoiding security risks and the disadvantages of manual intervention.

[0090] In addition, the present embodiment innovatively solves the problem of insufficient support for multi-table joint queries in the prior art; the "model management module" allows joint query associations to be configured in the model, opening up the path for cross-table data queries; when the general API module processes permission rules, this capability is fully utilized, and the system can simultaneously parse the SQL logic of the joint query and integrate it with the permission filtering conditions to finally generate a database query statement that combines complex queries and detailed permission control, thereby meeting the urgent need for data integration and analysis in complex business scenarios.

[0091] In summary, the embodiment takes high flexibility, refinement and development efficiency as core advantages, realizes codeless, dynamic configuration and real-time application of data access control by completely decoupling permission management and business logic, provides super-fine permission granularity of three levels of table, row and column, and can support complex joint queries, greatly improves data security, management efficiency and system adaptability in low-code platform and general API scenarios, and becomes a comprehensive and forward-looking data access control solution.

[0092] Through the above scheme, when the API request is received, the legality of the target table-level permission is dynamically analyzed by the general API function of the general API module, and access exception information is returned when there is no permission; when the target table-level permission verification is passed, the target row-level permission is analyzed, the SQL row-level filtering condition is generated, the target column-level permission is analyzed, the readable field is determined, and the joint query configuration in the target model is analyzed to generate the association condition; the SQL statement is assembled according to the access exception information, the SQL row-level filtering condition, the readable field and the association condition, the SQL statement is executed, and the database query statement filtered by the permission is returned; the general API and the low-code platform can be seamlessly integrated, the complete decoupling of permission management and business logic is realized, the fine data access control of table level, row level and column level can be provided at the same time, the security, flexibility and development efficiency of data access are improved, the increasingly complex business requirements are met, the fine, dynamic and codeless permission control of the general API is realized, the data security, management efficiency and system adaptability in the low-code platform and the general API scene are greatly improved, and the speed and efficiency of the general API data access control method are improved.

[0093] Correspondingly, the application further provides a general API data access control device.

[0094] Reference Figure 7 , Figure 7 The function module diagram of the first embodiment of the general API data access control device of the application is shown in the figure.

[0095] In the first embodiment of the general API data access control device of the application, the general API data access control device comprises: The API function creation module 10 is used for acquiring a data model and a database table corresponding to the data model, and creating an associated general API function according to the data model and the database table.

[0096] The permission configuration module 20 is used for configuring table-level permission, row-level permission and column-level permission for a combination of a role and the data model.

[0097] The parsing and applying module 30 is configured to dynamically parse and apply the table-level permission, the row-level permission and the column-level permission through the general API function of the general API module.

[0098] The API function creating module 10 is further configured to obtain a defined data model and a corresponding database table through user interaction, obtain a unique code of the data model from the database table, and generate a standardized general API function according to the unique code.

[0099] The permission configuring module 20 is further configured to configure the table-level permission, the row-level permission and the column-level permission for a combination of a role of a specific user and the data model through a visual interface.

[0100] The permission configuring module 20 is further configured to determine the combination of the role of the specific user and the data model, configure, through the visual interface, a table-level permission corresponding to an add-delete-modify-inquire operation permission of the role on the data model for the combination, configure, for the combination, a row-level permission for dynamically filtering data according to a preset condition expression, and configure, for the combination, a column-level permission corresponding to readability and writeability of each field in the data model.

[0101] The parsing and applying module 30 is further configured to, when receiving an API request, dynamically parse legality of a target table-level permission through the general API function of the general API module, and return access exception information when there is no permission; when the target table-level permission passes the verification, parse a target row-level permission, generate a SQL row-level filtering condition, parse a target column-level permission, determine readable fields, and parse joint query configuration in a target model to generate a correlation condition; assemble a SQL statement according to the access exception information, the SQL row-level filtering condition, the readable fields and the correlation condition, execute the SQL statement, and return a database query statement filtered by permission.

[0102] The parsing and applying module 30 is further configured to, when receiving an API request, dynamically parse a target user, a target role, a target model and an operation type through the general API function of the general API module; query a permission rule library based on the target user, the target role and the target model to obtain a target table-level permission, a target row-level permission and a target column-level permission; perform the target table-level permission verification on the target model, and return access exception information when the target table-level permission verification fails.

[0103] The parsing application module 30 is further configured to, when the target table-level permission verification passes, dynamically parse a target row-level permission, generate a SQL row-level filtering condition of converting a conditional expression into a SQL WHERE sub-clause in real time, parse a target column-level permission rule at the same time, determine readable fields of the target role, generate a readable field list according to the readable fields, apply the readable field list to a SELECT part of a SQL query, and generate an association condition of a corresponding JOIN sub-clause at the same time.

[0104] The steps implemented by the various functional modules of the universal API data access control device can refer to the various embodiments of the universal API data access control method, and will not be described here again.

[0105] In addition, the embodiment of the present application further provides a storage medium, and the storage medium stores a universal API data access control program. obtain a data model and a database table corresponding to the data model, and create an associated universal API function according to the data model and the database table; configure table-level permissions, row-level permissions and column-level permissions for a combination of a role and the data model; dynamically parse and apply the table-level permissions, the row-level permissions and the column-level permissions through the universal API function of the universal API module.

[0106] Further, the universal API data access control program executed by the processor further implements the following operations: obtain a defined data model and a corresponding database table through user interaction; obtain a unique code of the data model from the database table, and generate a standardized universal API function according to the unique code.

[0107] Further, the universal API data access control program executed by the processor further implements the following operations: configure table-level permissions, row-level permissions and column-level permissions for a combination of a role of a specific user and the data model through a visual interface.

[0108] Further, the universal API data access control program executed by the processor further implements the following operations: determine a combination of a role of a specific user and the data model; configure table-level permissions corresponding to operation permissions of the role on the data model through a visual interface for the combination; The combination is configured with corresponding row-level permissions for data dynamic filtering according to preset condition expressions; The combination is configured with column-level permissions corresponding to the readability and writeability of each field in the data model.

[0109] Further, the general API data access control program is executed by the processor to further implement the following operations: Upon receiving an API request, the legality of the target table-level permission is dynamically analyzed by the general API function of the general API module, and access exception information is returned when there is no permission; When the target table-level permission verification passes, the target row-level permission is parsed, the SQL row-level filtering condition is generated, the target column-level permission is parsed, the readable field is determined, and the joint query configuration in the target model is parsed to generate the association condition; According to the access exception information, the SQL row-level filtering condition, the readable field, and the association condition, a SQL statement is assembled, the SQL statement is executed, and a database query statement filtered by permission is returned.

[0110] Further, the general API data access control program is executed by the processor to further implement the following operations: Upon receiving an API request, the target user, target role, target model, and operation type are dynamically parsed by the general API function of the general API module; Based on the target user, the target role, and the target model, the permission rule library is queried to obtain the target table-level permission, the target row-level permission, and the target column-level permission; The target table-level permission is checked for the target model, and access exception information is returned when the target table-level permission verification fails.

[0111] Further, the general API data access control program is executed by the processor to further implement the following operations: When the target table-level permission verification passes, the target row-level permission is dynamically parsed, and the SQL row-level filtering condition that converts the condition expression into a SQL WHERE clause is generated in real time; Meanwhile, the target column-level permission rule is parsed to determine the readable field of the target role, and a readable field list is generated according to the readable field, and the readable field list is applied to the SELECT part of the SQL query; Meanwhile, the joint query association preconfigured in the target model is parsed to generate the association condition corresponding to the JOIN clause.

[0112] Those skilled in the art can understand that all or part of the steps of the methods in the above embodiments can be completed by instructing the relevant hardware through a program stored in a storage medium, and the program includes a plurality of instructions for causing an apparatus (which can be a single-chip microcomputer, a chip, etc.) or a processor to execute all or part of the steps of the methods described in various embodiments of the present application. The aforementioned storage medium is a computer readable storage medium, including: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various media capable of storing program codes.

[0113] It should be noted that in this document, the terms "comprising", "including", or any other variant thereof are intended to cover non-exclusive inclusions, so that a process, method, article or apparatus including a series of elements not only includes those elements, but also includes other elements not explicitly listed, or further includes elements inherent to such a process, method, article or apparatus. Without more limitations, the element defined by the statement "including a" does not exclude the presence of other identical elements in the process, method, article or apparatus including the element.

[0114] The above-mentioned serial numbers of the embodiments of the present application are only for description, and do not represent the advantages and disadvantages of the embodiments.

[0115] The above is only the preferred embodiment of the present application, and does not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation, or direct or indirect application in other related technical fields, which is made by using the content of the specification and drawings of the present application, is also included in the patent protection scope of the present application.

Claims

1. A general API data access control method, characterized in that, The general API data access control method includes: Obtain the data model and the corresponding database table, and create associated general API functions based on the data model and the database table; Configure table-level permissions, row-level permissions, and column-level permissions for the combination of roles and the data model; The table-level permissions, row-level permissions, and column-level permissions are dynamically parsed and applied through the general API functions of the general API module.

2. The general API data access control method as described in claim 1, characterized in that, The process of acquiring the data model and the corresponding database table, and creating a general API function based on the data model and the database table, includes: Obtain the defined data model and its corresponding database tables through user interaction; Obtain the unique code of the data model from the database table, and generate standardized general API functions based on the unique code.

3. The general API data access control method as described in claim 1, characterized in that, The configuration of table-level permissions, row-level permissions, and column-level permissions for the combination of roles and the data model includes: The user interface allows configuration of table-level, row-level, and column-level permissions for specific user roles and combinations of data models.

4. The general API data access control method as described in claim 3, characterized in that, The configuration of table-level, row-level, and column-level permissions for a specific user's role and the data model through a visual interface includes: Determine the combination of a specific user's role and the data model; Configure the table-level permissions corresponding to the role's permission to perform CRUD operations on the data model through a visual interface; Configure the row-level permissions corresponding to the dynamic filtering of data rows based on preset condition expressions for the combination; Configure column-level permissions for the readability and writability of each field in the data model for the combination.

5. The general API data access control method as described in claim 1, characterized in that, The dynamic parsing and application of the table-level permissions, row-level permissions, and column-level permissions through the general API function of the general API module includes: Upon receiving an API request, the validity of the target table-level permissions is dynamically resolved through the general API function of the general API module, and an access exception message is returned if there are no permissions. When the target table-level permission verification passes, the target row-level permissions are parsed to generate SQL row-level filtering conditions, the target column-level permissions are parsed to determine readable fields, and the join query configuration in the target model is parsed to generate association conditions. The SQL statement is assembled based on the access exception information, the SQL row-level filtering conditions, the readable fields, and the association conditions. The SQL statement is then executed, and a database query statement filtered by permissions is returned.

6. The general API data access control method as described in claim 5, characterized in that, Upon receiving an API request, the method dynamically parses the validity of the table-level permissions using the general API function of the general API module, and returns access exception information if no permissions are granted, including: Upon receiving an API request, the target user, target role, target model, and operation type are dynamically parsed using the general API function of the general API module. Based on the target user, the target role, and the target model, query the permission rule base to obtain the target table-level permissions, target row-level permissions, and target column-level permissions; The target model is subjected to target table-level permission verification. If the target table-level permission verification fails, an access exception message is returned.

7. The general API data access control method as described in claim 5, characterized in that, When the target table-level permission verification passes, the target row-level permissions are parsed to generate SQL row-level filter conditions, the target column-level permissions are parsed to determine readable fields, and the join query configuration in the target model is parsed to generate association conditions, including: When the target table-level permission verification passes, the target row-level permissions are dynamically parsed, and SQL row-level filtering conditions that convert the conditional expression into an SQL WHERE clause are generated in real time. Simultaneously, the target column-level permission rules are parsed to determine the readable fields of the target role, a readable field list is generated based on the readable fields, and the readable field list is applied to the SELECT part of the SQL query; Simultaneously, the pre-configured join query relationships in the target model are parsed to generate the corresponding join clause relationship conditions.

8. A universal API data access control device, characterized in that, The general API data access control device includes: The API function creation module is used to obtain the data model and the database table corresponding to the data model, and to create associated general API functions based on the data model and the database table. The permission configuration module is used to configure table-level permissions, row-level permissions, and column-level permissions for the combination of roles and the data model. The parsing application module is used to dynamically parse and apply the table-level permissions, row-level permissions, and column-level permissions through the general API functions of the general API module.

9. A universal API data access control device, characterized in that, The general API data access control device includes: a memory, a processor, and a general API data access control program stored in the memory and executable on the processor, the general API data access control program being configured to implement the steps of the general API data access control method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium stores a general API data access control program, which, when executed by a processor, implements the steps of the general API data access control method as described in any one of claims 1 to 7.

Images