General API data access control methods, devices, equipment and storage media

Abstract

This invention discloses a general API data access control method, apparatus, device, and storage medium. The method obtains a data model and its corresponding database table, and creates associated general API functions based on the data model and database table. It configures table-level, row-level, and column-level permissions for combinations of roles and data models. The method dynamically parses and applies these permissions through the general API functions of the general API module. It can seamlessly integrate with general APIs and low-code platforms, achieving complete decoupling of permission management from business logic. It simultaneously provides fine-grained data access control at the table, row, and column levels, improving data access security, flexibility, and development efficiency. This meets increasingly complex business needs, achieving fine-grained, dynamic, and no-code permission control for general APIs, and improving the speed and efficiency of general API data access control methods.

Description

Technical Field

[0001] This invention relates to the field of computer data security technology, and in particular to a general API data access control method, apparatus, device and storage medium. Background Technology

[0002] Existing technologies widely adopt the Role-Based Access Control (RBAC) model, which implements table-level, row-level, and column-level data access control for specific module functions. Each role can be assigned to multiple users, and data access control for functional modules can be configured under the role. At the same time, data access control methods are introduced into the functional modules, so that the corresponding users can apply the configured data access permissions after logging into the system. This technology effectively solves the data isolation problem between different roles. However, in the scenario of low-code general application programming interfaces (APIs), the lack of fixed functional scenarios prevents it from being well applied.

[0003] Existing technologies are typically based on the assumption that modules are fixed, requiring separate configuration of data access permissions for each specific functional module. However, in modern application development, modules are often dynamic and variable. For example, in low-code platforms, functional modules can be added, removed, or adjusted at any time according to business needs. This makes traditional permission configuration methods unable to adapt to this flexibility, resulting in permissions not being applied dynamically, which in turn leads to security risks, management complexity, and functional limitations.

[0004] Specifically, when modules are not fixed, the system cannot automatically identify and configure permissions, requiring manual intervention or hard coding. This not only increases development and maintenance costs but also reduces the system's response speed and adaptability, and makes it unable to support joint queries of multiple tables. Summary of the Invention

[0005] The main objective of this invention is to provide a general API data access control method, apparatus, device, and storage medium, which aims to solve the technical problems in the prior art where, in a low-code platform dynamic data model environment, the reliance on fixed functional module assumptions makes it impossible to achieve fine-grained permission control at the table, row, and column levels, and lacks support for multi-table join queries, resulting in severely limited data security and business flexibility.

[0006] In a first aspect, the present invention provides a general API data access control method, the general API data access control method comprising the following steps:

[0007] Obtain the data model and the corresponding database table, and create associated general API functions based on the data model and the database table;

[0008] Configure table-level permissions, row-level permissions, and column-level permissions for the combination of roles and the data model;

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

[0010] Optionally, the step of obtaining the data model and the corresponding database table, and creating a general API function based on the data model and the database table, includes:

[0011] Obtain the defined data model and its corresponding database tables through user interaction;

[0012] Obtain the unique code of the data model from the database table, and generate standardized general API functions based on the unique code.

[0013] Optionally, configuring table-level permissions, row-level permissions, and column-level permissions for the combination of roles and the data model includes:

[0014] The user interface allows configuration of table-level, row-level, and column-level permissions for specific user roles and combinations of data models.

[0015] Optionally, configuring table-level permissions, row-level permissions, and column-level permissions for a specific user's role and the data model through a visual interface includes:

[0016] Determine the combination of a specific user's role and the data model;

[0017] Configure the table-level permissions corresponding to the role's permission to perform CRUD operations on the data model through a visual interface;

[0018] Configure the row-level permissions corresponding to the dynamic filtering of data rows based on preset condition expressions for the combination;

[0019] Configure column-level permissions for the readability and writability of each field in the data model for the combination.

[0020] Optionally, the step of dynamically parsing and applying the table-level permissions, row-level permissions, and column-level permissions through the general API function of the general API module includes:

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

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

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

[0024] Optionally, the step of dynamically resolving the legality of the table-level permissions through the general API function of the general API module when receiving an API request, and returning access exception information when there is no permission, includes:

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

[0026] 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;

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

[0028] Optionally, 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, including:

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

[0030] 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;

[0031] Simultaneously, the pre-configured join query relationships in the target model are parsed to generate the corresponding join clause relationship conditions.

[0032] Secondly, to achieve the above objectives, the present invention also proposes a universal API data access control device, the universal API data access control device comprising:

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

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

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

[0036] Thirdly, to achieve the above objectives, the present invention also proposes a universal API data access control device, the universal API data access control device comprising: a memory, a processor, and a universal API data access control program stored in the memory and executable on the processor, the universal API data access control program being configured to implement the steps of the universal API data access control method as described above.

[0037] Fourthly, to achieve the above objectives, the present invention also proposes a storage medium storing a general API data access control program, wherein 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.

[0038] The general API data access control method proposed in this invention obtains a data model and the corresponding database table, and creates associated general API functions based on the data model and the database table; configures table-level permissions, row-level permissions, and column-level permissions for the combination of roles and the data model; dynamically parses and applies the table-level permissions, row-level permissions, and column-level permissions through the general API functions of the general API module; it can seamlessly integrate with general APIs and low-code platforms, achieving complete decoupling of permission management and business logic, and simultaneously providing fine-grained data access control at the table, row, and column levels, improving the security, flexibility, and development efficiency of data access, meeting increasingly complex business needs, and realizing fine-grained, dynamic, and no-code permission control of general APIs. This greatly improves data security, management efficiency, and system adaptability in low-code platforms and general API scenarios, and increases the speed and efficiency of the general API data access control method. Attached Figure Description

[0039] Figure 1 This is a schematic diagram of the device structure of the hardware operating environment involved in the embodiments of the present invention;

[0040] Figure 2 This is a flowchart illustrating the first embodiment of the general API data access control method of the present invention;

[0041] Figure 3 This is a flowchart illustrating the second embodiment of the general API data access control method of the present invention;

[0042] Figure 4 This is a flowchart illustrating the third embodiment of the general API data access control method of the present invention;

[0043] Figure 5 This is a flowchart illustrating the fourth embodiment of the general API data access control method of the present invention;

[0044] 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;

[0045] Figure 7 This is a functional block diagram of the first embodiment of the general API data access control device of the present invention.

[0046] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0047] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0048] The solution of this invention mainly involves: obtaining a data model and the corresponding database table; creating associated general API functions based on the data model and the database table; configuring table-level, row-level, and column-level permissions for the combination of roles and the data model; dynamically parsing and applying the table-level, row-level, and column-level permissions through the general API functions of the general API module; seamlessly integrating with general APIs and low-code platforms to achieve complete decoupling of permission management and business logic; providing fine-grained data access control at the table, row, and column levels simultaneously; improving the security, flexibility, and development efficiency of data access; meeting increasingly complex business needs; achieving fine-grained, dynamic, and no-code permission control of general APIs; greatly improving data security, management efficiency, and system adaptability in low-code platforms and general API scenarios; increasing the speed and efficiency of general API data access control methods; and solving the technical problems in the prior art where, in the dynamic data model environment of low-code platforms, due to the reliance on fixed functional module assumptions, fine-grained permission control at the table, row, and column levels cannot be achieved, and there is a lack of support for multi-table joint queries, resulting in severely limited data security and business flexibility.

[0049] Reference Figure 1 , Figure 1This is a schematic diagram of the device structure of the hardware operating environment involved in the embodiments of the present invention.

[0050] like Figure 1 As shown, the device may include: a processor 1001, such as a CPU; a communication bus 1002; a user interface 1003; a network interface 1004; and a memory 1005. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen or an input unit such as a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed RAM or non-volatile memory, such as a disk drive. Optionally, the memory 1005 may also be a storage device independent of the aforementioned processor 1001.

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

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

[0053] The device of the present invention calls the general API data access control program stored in the memory 1005 through the processor 1001 and performs the following operations:

[0054] Obtain the data model and the corresponding database table, and create associated general API functions based on the data model and the database table;

[0055] Configure table-level permissions, row-level permissions, and column-level permissions for the combination of roles and the data model;

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

[0057] The device of the present invention, through processor 1001 calling the general API data access control program stored in memory 1005, also performs the following operations:

[0058] Obtain the defined data model and its corresponding database tables through user interaction;

[0059] Obtain the unique code of the data model from the database table, and generate standardized general API functions based on the unique code.

[0060] The device of the present invention, through processor 1001 calling the general API data access control program stored in memory 1005, also performs the following operations:

[0061] The user interface allows configuration of table-level, row-level, and column-level permissions for specific user roles and combinations of data models.

[0062] The device of the present invention, through processor 1001 calling the general API data access control program stored in memory 1005, also performs the following operations:

[0063] Determine the combination of a specific user's role and the data model;

[0064] Configure the table-level permissions corresponding to the role's permission to perform CRUD operations on the data model through a visual interface;

[0065] Configure the row-level permissions corresponding to the dynamic filtering of data rows based on preset condition expressions for the combination;

[0066] Configure column-level permissions for the readability and writability of each field in the data model for the combination.

[0067] The device of the present invention, through processor 1001 calling the general API data access control program stored in memory 1005, also performs the following operations:

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

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

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

[0071] The device of the present invention, through processor 1001 calling the general API data access control program stored in memory 1005, also performs the following operations:

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

[0073] 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;

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

[0075] The device of the present invention, through processor 1001 calling the general API data access control program stored in memory 1005, also performs the following operations:

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

[0077] 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;

[0078] Simultaneously, the pre-configured join query relationships in the target model are parsed to generate the corresponding join clause relationship conditions.

[0079] This embodiment, through the above-described scheme, obtains the data model and the corresponding database table, and creates associated general API functions based on the data model and the database table; configures table-level permissions, row-level permissions, and column-level permissions for the combination of roles and the data model; dynamically parses and applies the table-level permissions, row-level permissions, and column-level permissions through the general API functions of the general API module; it can seamlessly integrate with general APIs and low-code platforms, achieving complete decoupling of permission management and business logic, and simultaneously providing fine-grained data access control at the table, row, and column levels, improving the security, flexibility, and development efficiency of data access, meeting increasingly complex business needs, and realizing fine-grained, dynamic, and no-code permission control of general APIs. This greatly improves data security, management efficiency, and system adaptability in low-code platforms and general API scenarios, and increases the speed and efficiency of general API data access control methods.

[0080] Based on the above hardware structure, an embodiment of the general API data access control method of the present invention is proposed.

[0081] Reference Figure 2 , Figure 2This is a flowchart illustrating the first embodiment of the general API data access control method of the present invention.

[0082] In the first embodiment, the general API data access control method includes the following steps:

[0083] Step S10: Obtain the data model and the database table corresponding to the data model, and create associated general API functions based on the data model and the database table.

[0084] It should be noted that the data model and its corresponding database table are obtained, and a general API function is created based on the data model and the database table to achieve dynamic binding between the data model, the database table and the API function.

[0085] Step S20: Configure table-level permissions, row-level permissions, and column-level permissions for the combination of role and data model.

[0086] It should be understood that fine-grained configuration of specific user roles (such as "ordinary employees") and data models can be performed by configuring table-level permissions, row-level permissions, and column-level permissions.

[0087] Step S30: Dynamically parse and apply the table-level permissions, row-level permissions, and column-level permissions through the general API function of the general API module.

[0088] Understandably, when processing API requests, the general API module can dynamically parse the table-level, row-level, and column-level permissions configured in the permission rule base in real time 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.

[0089] This embodiment, through the above-described scheme, obtains the data model and the corresponding database table, and creates associated general API functions based on the data model and the database table; configures table-level permissions, row-level permissions, and column-level permissions for the combination of roles and the data model; dynamically parses and applies the table-level permissions, row-level permissions, and column-level permissions through the general API functions of the general API module; it can seamlessly integrate with general APIs and low-code platforms, achieving complete decoupling of permission management and business logic, and simultaneously providing fine-grained data access control at the table, row, and column levels, improving the security, flexibility, and development efficiency of data access, meeting increasingly complex business needs, and realizing fine-grained, dynamic, and no-code permission control of general APIs. This greatly improves data security, management efficiency, and system adaptability in low-code platforms and general API scenarios, and increases the speed and efficiency of general API data access control methods.

[0090] Furthermore, Figure 3 This is a flowchart illustrating the second embodiment of the general API data access control method of the present invention, as shown below. Figure 3 As shown, based on the first embodiment, a second embodiment of the general API data access control method of the present invention is proposed. In this embodiment, step S10 specifically includes the following steps:

[0091] Step S11: Obtain the defined data model and its corresponding database table through user interaction.

[0092] It should be noted that in the model management interface provided by the system, users can specify the defined data model (such as the "order" model) and its associated database table (such as the "order" table) through intuitive user interaction operations (such as selecting drop-down menus, clicking the import button, or filling out forms). The system obtains and stores these relationships in real time, supports importing data directly from existing database tables or creating new data models and synchronizing them to the database, and provides the basic data for dynamic binding for subsequent permission configuration and API generation.

[0093] Step S12: Obtain the unique code of the data model from the database table, and generate standardized general API functions based on the unique code.

[0094] Understandably, by querying the metadata of a database table (such as a model identifier field or table name), a unique code for the data model (e.g., "order") can be extracted, and standardized, general-purpose API functions can be automatically built based on this code. The access path strictly follows the specification of / sys / [model code] / [list, add, update, delete] (e.g., / sys / order / list), realizing the dynamic binding between the data model and API functions without manual intervention.

[0095] This embodiment, through the above-described scheme, obtains a defined data model and its corresponding database table through user interaction; obtains a unique code for the data model from the database table; and generates standardized general API functions based on the unique code. This significantly improves the development efficiency of low-code platforms, eliminates manual coding errors, ensures unified and standardized API paths, provides a standardized entry point for subsequent table-level, row-level, and column-level permission control that can be directly invoked, and supports seamless integration of refined data security management.

[0096] Furthermore, Figure 4 This is a flowchart illustrating the third embodiment of the general API data access control method of the present invention, as shown below. Figure 4 As shown, based on the first embodiment, a third embodiment of the general API data access control method of the present invention is proposed. In this embodiment, step S20 specifically includes the following steps:

[0097] Step S21: Configure table-level permissions, row-level permissions, and column-level permissions for a specific user's role and the combination of the data model through a visual interface.

[0098] It should be noted that the intuitive visual permission configuration interface allows for fine-grained configuration of table-level, row-level, and column-level permissions for specific user roles (such as "ordinary employees") and data models (such as "order table").

[0099] Furthermore, step S21 specifically includes the following steps:

[0100] Determine the combination of a specific user's role and the data model;

[0101] Configure the table-level permissions corresponding to the role's permission to perform CRUD operations on the data model through a visual interface;

[0102] Configure the row-level permissions corresponding to the dynamic filtering of data rows based on preset condition expressions for the combination;

[0103] Configure column-level permissions for the readability and writability of each field in the data model for the combination.

[0104] Understandably, the permission rule configuration module allows for fine-grained configuration of specific user roles (such as "administrator" or "regular employee") and data models (such as "user table" or "order table") through a visual interface: table-level permissions explicitly specify the CRUD (Create, Read, Update, Delete) operations permitted for a role on that model (e.g., allow "query" but prohibit "delete"); row-level permissions dynamically filter data rows by defining conditional expressions (e.g., user_id=current user ID or status='approved'); column-level permissions individually set readability (e.g., hide the "password" field) and writability (e.g., prohibit modification of the "creation time" field) for each field in the model, ensuring that permission rules accurately match business needs without code intervention.

[0105] This embodiment, through the above-described scheme, configures table-level, row-level, and column-level permissions for specific user roles and the data model through a visual interface. This significantly improves the flexibility, security, and management efficiency of data access control, providing low-code platforms with dynamic and non-intrusive permission management capabilities, and ensuring comprehensive security protection for sensitive data during query, editing, and deletion operations.

[0106] Furthermore, Figure 5 This is a flowchart illustrating the fourth embodiment of the general API data access control method of the present invention, as shown below. Figure 5As shown, based on the first embodiment, a fourth embodiment of the general API data access control method of the present invention is proposed. In this embodiment, step S30 specifically includes the following steps:

[0107] Step S31: Upon receiving an API request, dynamically parse the legality of the target table-level permissions using the general API function of the general API module, and return access exception information if no permissions are granted.

[0108] It should be noted that upon receiving an API request, the general API module will immediately invoke its standardized functions to dynamically verify the current user role's table-level permissions (i.e., permission status for CRUD operations) on the target data model (such as the "order" model in / sys / order / list). This will block unauthorized access at the very first moment of request processing, ensuring the security and compliance of data operations.

[0109] Furthermore, step S31 specifically includes the following steps:

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

[0111] 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;

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

[0113] It should be understood that upon 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). Based on this information, the system queries the permission rule base to obtain the table-level permissions (controlling CRUD operations), row-level permissions (row-level filtering conditions), and column-level permissions (field read / write permissions) for the combination of the role and the data model. Subsequently, table-level permission verification is performed on the target model (e.g., verifying whether the role is allowed to execute the "query" operation). If the verification fails (e.g., no permission to access the model), a standardized access exception message is immediately returned (e.g., "403 Forbidden: No permission to access this data model"), thereby blocking unauthorized access at the initial stage of request processing and ensuring data security.

[0114] Step S32: When the target table-level permission verification passes, parse the target row-level permissions, generate SQL row-level filtering conditions, parse the target column-level permissions, determine readable fields, and parse the join query configuration in the target model to generate association conditions.

[0115] Understandably, after the target table-level permission verification passes, row-level permission rules (such as user_id=current user ID) can be dynamically parsed to generate SQL row-level filtering conditions. At the same time, target column-level permissions can be parsed to determine readable fields, and the join query configuration in the target model can be parsed to generate join conditions.

[0116] Furthermore, step S32 specifically includes the following steps:

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

[0118] 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;

[0119] Simultaneously, the pre-configured join query relationships in the target model are parsed to generate the corresponding join clause relationship conditions.

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

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

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

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

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

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

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

[0127] 4. Next, the system parses the column-level permission rules, determines the fields that the current role can read or write, and generates the `SELECT` part of the SQL query accordingly to hide sensitive fields.

[0128] 5. The system checks and parses the configured join query relationships in the model and generates the corresponding "JOIN" clauses.

[0129] The previously generated SELECT, FROM, JOIN, WHERE clauses are assembled into a complete and safe SQL query statement and submitted to the database for execution.

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

[0131] 7. After the database execution is successful, the query results filtered by permissions will be returned to the user.

[0132] This process achieves three levels of fine-grained access control from table to row to column, and seamlessly integrates JOIN query capabilities. The entire process is automated and dynamic, requiring no hard coding.

[0133] This embodiment achieves refined, dynamic, and code-free permission 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: Core modules:

[0134] Model Management Module: Used to define data models, with 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 also implements the general API functions associated with the model.

[0135] Role Management Module: Used to create and manage user roles (such as "Administrator", "Manager", "Regular Employee") and associate users with roles.

[0136] Permission rule configuration module: the core of this embodiment; in this module, the administrator can configure three levels of permissions for the combination of "roles" and "data models" through a graphical interface.

[0137] Table-level permission configuration: Configure permission or denial for the four basic operations of adding, deleting, modifying, and querying for specified roles and models.

[0138] Row-level permission configuration: When read access is allowed, row-level filtering rules can be further configured. Rules are defined in the form of conditional expressions. For example, for the "Order" model and the "Regular Employee" role, the rule can be configured as [Order.Creator] == [Current User.ID]. These rules can be combinations of one or more conditions, using OR or AND relationships.

[0139] Column-level permission configuration: For all fields (columns) in the model, you can configure "read" and "write" permissions for a specified role; for example, for the "Employee" model and the "Regular Employee" role, you can set the "Salary" column to be unreadable and unwriteable.

[0140] Implementation steps:

[0141] Step 1: Create a model management module that contains common API functions associated with models.

[0142] In this embodiment, the model management module implements a one-to-one correspondence between data tables and models, supports the synchronization of newly created models to the database, and also allows users to select tables in the database to create models. Based on the basic information of the models, a general API function is created, and users can call the CRUD interfaces of the relevant models by accessing paths such as / sys / [model code] / [list, add, update, delete].

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

[0144] In this embodiment, the role management module is responsible for creating, editing, deleting and querying roles, and can associate users with roles.

[0145] Step 3: Create the permission rule configuration module.

[0146] In this embodiment, the permission rules module is used to configure the relationship between models and roles. The specific process is as follows: First, select a model and configure associated roles under it; then select a role and set its CRUD (Create, Delete, Update, Query) operation permissions; if query permissions are enabled, row-level permission configuration is triggered, which can be set with fixed rules (such as [Order.Creator] == [Current User.ID]) or flexible options such as SQL rules; finally, select the readability or writability of fields in the model for the role. Completing the above configuration achieves the functionality of this step.

[0147] Step 4: The general API module is based on the permission rules in Step 3.

[0148] In this embodiment, step 3 has established the association between models, roles, and permission points. This step aims to integrate these associations into the general API. Table-level permissions correspond to the API's CRUD operations; if permissions are not met, an access exception is returned directly. Row-level permissions are achieved by adjusting the general query interface, parsing configuration rules to generate SQL statements, and attaching them to query, edit, and delete operations. Column-level permissions determine the set of returned fields, which serve as the output fields for the SQL query.

[0149] Step 5: Support join queries.

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

[0151] It should be noted that this embodiment aims to completely solve the limitations of existing technologies, such as the restriction of permission configuration by the assumption of "fixed modules" and the core problem that permissions cannot be dynamically applied in low-code general API scenarios. Through this solution, the "model management module" decouples the granularity of permission control from specific functions to a more stable "data model" (i.e., database table). Each data model encapsulates general API operations. Administrators no longer need to configure permissions for each changing business function module. Instead, they can use the visual interface of the "permission rule configuration module" to dynamically configure fine-grained permission rules at the table, row, and column levels for the combination of "roles" and "data models". This design ensures that regardless of the addition, removal, or adjustment of functional modules, the underlying data access control can always be stably effective based on the data model, thereby solving the pain point that traditional methods cannot adapt to the flexibility of low-code platforms.

[0152] The dynamic parsing and application of permissions is a key innovation of this embodiment. When a user accesses data through a general API, the system quickly parses the current user's role and its associated permission rules at runtime, rather than relying on preset hard-coded rules. For example, conditional expressions for row-level permissions (such as [order.creator] == [current user.ID]) can be instantly converted into the WHERE clause of an SQL query and automatically appended to operations such as querying, editing, and deleting. Column-level permissions dynamically determine the set of fields returned. 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 system security, reducing management complexity, and eliminating the limitations of traditional permission management on functional expansion, effectively avoiding security risks and the drawbacks of manual intervention.

[0153] Furthermore, this embodiment innovatively solves the problem of insufficient support for multi-table join queries in the prior art; the "model management module" allows the configuration of join query associations in the model, opening up the path for cross-table data queries; this capability is fully utilized when the general API module processes permission rules, the system can synchronously parse the SQL logic of the join query and integrate it with permission filtering conditions, and 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.

[0154] In summary, this embodiment boasts high flexibility, granularity, and development efficiency as its core advantages. By completely decoupling permission management from business logic, it achieves no-code, dynamic configuration, and real-time application of data access control. It not only provides ultra-fine-grained permission granularity at the table, row, and column levels but also supports complex join queries, greatly improving data security, management efficiency, and system adaptability in low-code platforms and general API scenarios. It has become a comprehensive and forward-looking data access control solution.

[0155] This embodiment, through the above-described scheme, dynamically parses the legality of the target table-level permissions using the general API function of the general API module when an API request is received, and returns access exception information when permissions are not granted. When the target table-level permissions pass verification, it parses the target row-level permissions, generates SQL row-level filtering conditions, parses the target column-level permissions, determines readable fields, and parses the join query configuration in the target model to generate association conditions. Based on the access exception information, the SQL row-level filtering conditions, the readable fields, and the association conditions, it assembles an SQL statement, executes the SQL statement, and returns a database query statement that has passed permission filtering. It can seamlessly integrate with general APIs and low-code platforms, achieving complete decoupling of permission management and business logic. It can simultaneously provide fine-grained data access control at the table, row, and column levels, improving the security, flexibility, and development efficiency of data access, meeting increasingly complex business needs, and realizing fine-grained, dynamic, and no-code permission control of general APIs. This greatly improves data security, management efficiency, and system adaptability in low-code platforms and general API scenarios, and increases the speed and efficiency of general API data access control methods.

[0156] Accordingly, the present invention further provides a general API data access control device.

[0157] Reference Figure 7 , Figure 7 This is a functional block diagram of the first embodiment of the general API data access control device of the present invention.

[0158] In a first embodiment of the universal API data access control device of the present invention, the universal API data access control device includes:

[0159] API function creation module 10 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.

[0160] The permission configuration module 20 is used to configure table-level permissions, row-level permissions, and column-level permissions for the combination of roles and the data model.

[0161] The parsing application module 30 is used to 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.

[0162] The API function creation module 10 is also used to obtain a defined data model and its corresponding database table through user interaction; obtain a unique code of the data model from the database table; and generate standardized general API functions based on the unique code.

[0163] The permission configuration module 20 is also used to 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.

[0164] The permission configuration module 20 is also used to 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; and configure the column-level permissions corresponding to the readability and writability of each field in the data model.

[0165] The parsing application module 30 is further configured to, upon receiving an API request, dynamically parse the legality of the target table-level permissions using the general API function of the general API module, and return access exception information if no permissions are granted; when the target table-level permissions pass the verification, parse the target row-level permissions to generate SQL row-level filtering conditions, parse the target column-level permissions to determine readable fields, and parse the join query configuration in the target model to generate association conditions; 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 for permissions.

[0166] The parsing application module 30 is further configured to, upon receiving an API request, dynamically parse the target user, target role, target model, and operation type using the general API function of the general API module; query the permission rule base based on the target user, target role, and target model to obtain target table-level permissions, target row-level permissions, and target column-level permissions; perform target table-level permission verification on the target model; and return access exception information if the target table-level permission verification fails.

[0167] The parsing application module 30 is also used to dynamically parse the target row-level permissions when the target table-level permission verification passes, and generate SQL row-level filtering conditions that convert the conditional expression into an SQL WHERE clause in real time; at the same time, it parses the target column-level permission rules, determines the readable fields of the target role, generates a list of readable fields based on the readable fields, and applies the list of readable fields to the SELECT part of the SQL query; at the same time, it parses the pre-configured join query associations in the target model and generates the association conditions of the corresponding JOIN clause.

[0168] The steps for implementing each functional module of the general API data access control device can be referred to in the various embodiments of the general API data access control method of the present invention, and will not be repeated here.

[0169] Furthermore, embodiments of the present invention also propose a storage medium storing a general API data access control program, which, when executed by a processor, performs the following operations:

[0170] Obtain the data model and the corresponding database table, and create associated general API functions based on the data model and the database table;

[0171] Configure table-level permissions, row-level permissions, and column-level permissions for the combination of roles and the data model;

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

[0173] Furthermore, when the general API data access control program is executed by the processor, it also performs the following operations:

[0174] Obtain the defined data model and its corresponding database tables through user interaction;

[0175] Obtain the unique code of the data model from the database table, and generate standardized general API functions based on the unique code.

[0176] Furthermore, when the general API data access control program is executed by the processor, it also performs the following operations:

[0177] The user interface allows configuration of table-level, row-level, and column-level permissions for specific user roles and combinations of data models.

[0178] Furthermore, when the general API data access control program is executed by the processor, it also performs the following operations:

[0179] Determine the combination of a specific user's role and the data model;

[0180] Configure the table-level permissions corresponding to the role's permission to perform CRUD operations on the data model through a visual interface;

[0181] Configure the row-level permissions corresponding to the dynamic filtering of data rows based on preset condition expressions for the combination;

[0182] Configure column-level permissions for the readability and writability of each field in the data model for the combination.

[0183] Furthermore, when the general API data access control program is executed by the processor, it also performs the following operations:

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

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

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

[0187] Furthermore, when the general API data access control program is executed by the processor, it also performs the following operations:

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

[0189] 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;

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

[0191] Furthermore, when the general API data access control program is executed by the processor, it also performs the following operations:

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

[0193] 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;

[0194] Simultaneously, the pre-configured join query relationships in the target model are parsed to generate the corresponding join clause relationship conditions.

[0195] Those skilled in the art will understand that all or part of the steps in the methods described above can be implemented by a program instructing related hardware. The program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium is a computer-readable storage medium, including: USB flash drive, mobile hard drive, read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk, and other media that can store program code.

[0196] It should be noted that, in this document, 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. Unless otherwise specified, 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 that element.

[0197] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0198] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A generic API data access control method, characterized by, The general API data access control method comprises: 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; 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 a general API module; wherein the dynamic parsing and application of the table-level permissions, the row-level permissions and the column-level permissions through the general API function of the general API module comprises: when an API request is received, dynamically parsing the legality of target table-level permissions through the general API function of the general API module, and returning access exception information when there is no permission; when the target table-level permission verification is passed, parsing target row-level permissions, generating SQL row-level filtering conditions, parsing target column-level permissions, determining readable fields, and parsing joint query configurations in the target model to generate association conditions; assembling a SQL statement according to the access exception information, the SQL row-level filtering conditions, the readable fields and the association conditions, executing the SQL statement, and returning a database query statement filtered by permissions; wherein the dynamic parsing of the legality of the table-level permissions through the general API function of the general API module when the API request is received, and the return of access exception information when there is no permission, comprises: when an API request is received, dynamically parsing a target user, a target role, a target model and an operation type through the general API function of the general API module; querying a permission rule library based on the target user, the target role and the target model to obtain target table-level permissions, target row-level permissions and target column-level permissions; performing target table-level permission verification on the target model, and returning access exception information when the target table-level permission verification fails.

2. The universal API data access control method of claim 1, wherein, The obtaining of the data model and the database table corresponding to the data model, and the creation of the associated general API function according to the data model and the database table, comprises: obtaining a defined data model and a database table corresponding thereto through user interaction; obtaining a unique code of the data model from the database table, and generating a standardized general API function according to the unique code.

3. The universal API data access control method of claim 1, wherein, The configuration of 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 and the data model through a visual interface.

4. The universal API data access control method of claim 3, wherein, The configuration of table-level permissions, row-level permissions and column-level permissions for a combination of a role and the data model through a visual interface comprises: determining a combination of a role of a specific user and the data model; configuring table-level permissions corresponding to operation permission of the data model of the role for the combination through a visual interface; configuring row-level permissions corresponding to dynamic filtering of data according to a preset condition expression for the combination; Corresponding column-level permissions of readability and writeability of each field in the data model are configured for the combination.

5. The universal API data access control method of claim 1, wherein, When the target table-level permission check passes, target row-level permissions are parsed, SQL row-level filtering conditions are generated, target column-level permissions are parsed, readable fields are determined, and joint query configurations in the target model are parsed to generate association conditions, including: When the target table-level permission check passes, target row-level permissions are dynamically parsed, and SQL row-level filtering conditions that convert condition expressions into SQL WHERE clauses are generated in real time; Target column-level permission rules are parsed at the same time to determine readable fields of the target role, readable field lists are generated according to the readable fields, and the readable field lists are applied to the SELECT part of SQL queries; Joint query associations preconfigured in the target model are parsed at the same time to generate association conditions corresponding to JOIN clauses.

6. A generic API data access control apparatus, characterized by, The general API data access control device comprises: An API function creation module configured to obtain a data model and a database table corresponding to the data model, and create associated general API functions according to the data model and the database table; A permission configuration module configured to configure table-level permissions, row-level permissions, and column-level permissions for a combination of a role and the data model; A parsing and application module configured to dynamically parse and apply the table-level permissions, the row-level permissions, and the column-level permissions through the general API functions of the general API module; The parsing and application module is further configured to, when an API request is received, dynamically parse the legality of target table-level permissions through the general API functions of the general API module, and return access exception information when there is no permission; when the target table-level permission check passes, parse target row-level permissions, generate SQL row-level filtering conditions, parse target column-level permissions, determine readable fields, and parse joint query configurations in the target model to generate association conditions; assemble a SQL statement according to 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 filtered by permissions; The parsing and application module is further configured to, when an API request is received, dynamically parse a target user, a target role, a target model, and an operation type through the general API functions of the general API module; query a permission rule library based on the target user, the target role, and the target model to obtain target table-level permissions, target row-level permissions, and target column-level permissions; and perform the target table-level permission check on the target model, and return access exception information when the target table-level permission check fails.

7. A generic API data access control device, characterized by The general API data access control device comprises a memory, a processor, and a general API data access control program stored on 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 according to any one of claims 1 to 5.

8. A storage medium, characterized by The storage medium has stored thereon a general API data access control program which, when executed by the processor, implements the steps of the general API data access control method of any one of claims 1 to 5.

Images