A method and system for restricted secure execution of low-code platform hook code

Abstract

The application relates to the technical field of computer program security execution, and discloses a restricted safe execution method and system of low-code platform hook code, the method acquires online hook code and a hook point type bound thereto, determines a pre-execution safety check strategy, a runtime access control strategy, an execution result check strategy and an exception fault tolerance processing strategy according to the hook point type, restricts the interaction between the online hook code and a low-code platform business environment after the check passes, checks the execution result, and determines the processing mode of the main business process of the low-code platform according to result check information, exception information or timeout information; the application can form a continuous safety control mode for a restricted execution environment, and reduce the risk that the hook code breaks through the boundary of the runtime access control and causes the main business process to adopt an unsafe execution result.

Description

Technical Field

[0001] This application relates to the field of computer program secure execution technology, specifically to a restricted secure execution method and system for hook code on a low-code platform. Background Technology

[0002] Low-code platforms typically allow users to submit hook code through online editing pages, code upload interfaces, or hook code registration interfaces, binding the hook code to business processing nodes such as data storage, data querying, interface requests, and workflow transitions. When the main business process of the low-code platform reaches the corresponding node, the platform triggers the execution of the hook code to achieve field processing, business validation, message notification, external interface calls, or query condition expansion. This mechanism improves the scalability of business systems, but it also allows externally submitted or online-maintained executable code to enter the platform's execution chain. Therefore, the execution security of hook code is gradually becoming a significant issue in low-code platforms.

[0003] Existing low-code platforms typically manage hook code through manual review, basic syntax validation, permission configuration, or unified exception handling. While these methods can reduce the likelihood of obviously erroneous code entering the runtime phase to some extent, they still fall short in terms of security controls during program execution. Specifically, some platforms only check syntax or sensitive keywords during the code saving phase, failing to differentiate the execution risks of different business nodes based on hook point types; although some platforms restrict user role permissions, once hook code enters the execution phase, it may still directly access business service instances, data access instances, system configuration instances, or database access objects, making it difficult to establish clear execution environment isolation boundaries.

[0004] In scenarios involving executable software security, mechanisms such as restricted execution environments, sandboxes, secure virtual machines, and runtime access control are typically used to reduce the impact on platform integrity during program execution. However, in low-code platform hook code execution scenarios, hook code is not an independent application but rather an intermediate processing segment embedded in the main business process of the low-code platform. The execution location of the hook code, the data objects allowed to be accessed, the return result requirements, and the business processing methods after exceptions are all related to the specific hook point type. If only a unified sandbox or unified permission isolation method is used, it is easy to cause the problem of different hook point types applying the same security rules, resulting in a lack of differentiated constraints on interface calls, data table access, execution result verification, and failure handling for hook code before data saving, query enhancement hook code, and interface interception hook code.

[0005] Furthermore, existing methods typically focus more on whether hook code can execute successfully, while neglecting the coordination between pre-execution validation, access control during execution, execution result validation, and exception handling. For example, hook code may hide high-risk calls using encoded escape characters before execution; during execution, it may bypass platform interface boundaries to access data tables or open external connection resources; after execution, it may return results that do not meet the requirements of business nodes, or modify fields that should not be modified by hook code; after an exception or timeout occurs, the platform's main business process may continue to use erroneous results, or fail to distinguish between retryable failures and security failures, thus affecting business data changes, access control boundaries, and the integrity of platform operation.

[0006] Therefore, the existing low-code platform hook code execution management still has the following technical problems: In the scenario where hook code is embedded in the execution of the main business process of the low-code platform, the existing technology is difficult to form consistent restricted execution and security control constraints around the hook point type, before, during, and after the execution of hook code and the exception handling stage. This may cause the hook code to break through the runtime access control boundary, affect the platform business environment, or cause the main business process of the low-code platform to adopt insecure execution results. Summary of the Invention

[0007] To address the shortcomings of existing technologies, this application aims to provide a restricted secure execution method and system for hook code in low-code platforms. By acquiring online hook code and the hook point types bound to it, the method determines pre-execution security verification strategies, runtime access control strategies, execution result verification strategies, and exception handling strategies based on the hook point types. These pre-execution verification, runtime access control, execution result verification, and exception handling are then continuously applied to the execution process of the online hook code. This solves the technical problem of existing low-code platforms struggling to establish consistent security control constraints around hook point types in restricted execution environments, sandboxes, secure virtual machines, and runtime access control scenarios when hook code is embedded in the main business process. This achieves the effect of limiting online hook code from breaching the boundaries of the low-code platform's business environment and reducing the adoption of insecure execution results in the main business process of the low-code platform.

[0008] To achieve the above objectives, this application adopts the following technical solution:

[0009] Firstly, this application provides a restricted and secure execution method for low-code platform hook code, including:

[0010] Retrieve the online hook code and the hook point type bound to the online hook code;

[0011] The security policy for online hook code is determined based on the hook point type. The security policy includes pre-execution security verification policy, runtime access control policy, execution result verification policy, and exception handling policy.

[0012] The online hook code is validated before execution according to the pre-execution security verification strategy;

[0013] After the pre-execution verification is passed, the interaction between the online hook code and the low-code platform business environment is restricted according to the runtime access control policy, and the online hook code is executed.

[0014] After the online hook code finishes execution, the execution result is verified according to the execution result verification strategy to obtain the result verification information;

[0015] Based on the result verification information, exception information or timeout information during the execution of online hook code, invoke the exception tolerance handling strategy to determine the processing method of the main business process of the low-code platform.

[0016] Preferably, the method for determining the security policy of online hook code includes:

[0017] Establish a security policy mapping table between hook point types and security policies. The policy mapping records in the security policy mapping table include hook point type field, pre-execution security verification policy field, runtime access control policy field, execution result verification policy field, and exception fault tolerance handling policy field.

[0018] Match the hook point type bound to the online hook code with the hook point type field;

[0019] The security policy is obtained by reading the pre-execution security verification policy field, runtime access control policy field, execution result verification policy field, and exception handling policy field from the matched policy mapping record.

[0020] Preferably, the pre-execution security verification strategy includes a static code security detection rule set, an import statement allowable list, and preset risk thresholds. The static code security detection rule set includes detection modes and risk weights.

[0021] Methods for performing pre-execution verification based on a pre-execution security verification strategy include:

[0022] Convert online hook code into an abstract syntax tree;

[0023] Match the abstract syntax tree with the detection pattern;

[0024] The risk score is obtained by summing the risk weights corresponding to the successfully matched detection patterns.

[0025] Extract the import statements from the online hook code and compare them with the list of allowed import statements;

[0026] When the risk score is less than the preset risk threshold and all imported statements are in the list of allowed imported statements, the pre-execution verification is confirmed to be successful.

[0027] If the risk score is not less than the preset risk threshold, or if there is an import statement that does not belong to the list of allowed import statements, the pre-execution validation will fail.

[0028] Preferably, the method for pre-verification further includes:

[0029] The encoded escape characters in the online hook code are restored to their original characters to obtain the restored code;

[0030] Convert the restored code into a restored abstract syntax tree;

[0031] The abstract syntax tree is restored and matched with the detection patterns, and the risk weights corresponding to the successfully matched detection patterns are accumulated to obtain the restoration risk score.

[0032] Extract the restore import statements from the restore code and compare the restore import statements with the list of allowed import statements;

[0033] When the risk score is less than the preset risk threshold, the restored risk score is less than the preset risk threshold, and all imported statements are in the allowed list of imported statements and all restored imported statements are in the allowed list of imported statements, the pre-execution verification is confirmed to be successful.

[0034] If the restoration risk score is not less than the preset risk threshold, or if there is an import statement that does not belong to the allowed list of import statements, or if there is a restoration import statement that does not belong to the allowed list of import statements, then the pre-execution verification is deemed to have failed.

[0035] Preferably, the runtime access control policy includes a list of restricted interfaces;

[0036] Methods to limit the interaction between online hook code and low-code platform business environments include:

[0037] Read the list of restricted interfaces based on the hook point type;

[0038] Generate a restricted interface proxy object that contains only the interfaces in the restricted interface list;

[0039] Generate the execution context for online hook code;

[0040] Inject restricted interface proxy objects into the execution context, but do not inject business service instances, data access instances, and system configuration instances from the low-code platform business environment into the execution context;

[0041] The restricted interface proxy object is used as the sole object for interaction between the online hook code and the low-code platform business environment;

[0042] Reject interaction requests from entities other than the restricted interface proxy object.

[0043] Preferably, the runtime access control policy further includes a data table access control matrix, which includes a list of data tables that are allowed to be read, a list of data tables that are prohibited from being written to, and a list of data tables that are prohibited from being accessed.

[0044] When executing online hook code, the SQL statement triggered through the restricted interface proxy object is parsed to obtain the operation type and data table identifier. The operation type includes read and write.

[0045] When the operation type is read and the table identifier is not in the list of allowed read tables, or the operation type is write and the table identifier is in the list of prohibited write tables, or the table identifier is in the list of prohibited access tables, the execution of the SQL statement is blocked and an exception message is generated.

[0046] Preferably, the runtime access control policy also includes a timeout threshold;

[0047] Methods for executing online hook code also include:

[0048] Assign execution instance identifiers to online hook code;

[0049] Associate and register the external connection resources opened by the online hook code through the restricted interface proxy object with the execution instance identifier;

[0050] Monitor the execution time of online hook code based on timeout thresholds;

[0051] When the execution time exceeds the timeout threshold, stop the current execution instance of the online hook code and generate timeout information; when an exception is caught during execution, generate exception information.

[0052] Preferably, the execution result verification strategy includes execution result verification rules;

[0053] Methods for validating the execution results of online hook code include:

[0054] Establish a verification mapping relationship between hook point types and execution result verification rules;

[0055] Match the hook point type bound to the online hook code with the validation mapping relationship;

[0056] Read the matching execution result verification rules;

[0057] The execution result is verified according to the execution result verification rules to obtain the result verification information.

[0058] Preferably, the hook point type includes the hook point type before data saving, and the execution result verification rules include return value type rules and unmodifiable field identifiers;

[0059] When the hook point type bound to the online hook code is the hook point type before data saving, the methods for verifying the execution result include:

[0060] Determine if the execution result conforms to the return value type rules;

[0061] Based on the field values ​​of the fields corresponding to the unmodifiable field identifiers, generate summaries of the unmodifiable field values ​​before and after the execution of the online hook code.

[0062] If the execution result does not conform to the return value type rules, or if the summary of the unmodifiable field value before execution is different from the summary of the unmodifiable field value after execution, a verification result of failure will be generated.

[0063] Preferably, the method for verifying the execution result according to the execution result verification rules includes:

[0064] When the execution result verification rule indicates that it is necessary to verify whether the external connection resources have been released, the registered external connection resources are queried based on the execution instance identifier, and it is determined whether the external connection resources have been released.

[0065] If there are unreleased external connection resources, generate verification information indicating that the resources have not been released.

[0066] When the execution result verification rule indicates that the fields in the execution result need to be verified, the restricted field identifier recorded in the execution result verification rule is read, and it is determined whether the execution result contains the field corresponding to the restricted field identifier;

[0067] When the execution result contains a field corresponding to a restricted field identifier, a field validation result is generated indicating that the field validation failed.

[0068] Preferably, the method for invoking the exception handling strategy includes:

[0069] Establish a fault tolerance mapping relationship between hook point type, result verification information type, exception information type, timeout information type and exception fault tolerance handling strategy;

[0070] Determine the result verification information type corresponding to the generated result verification information, the exception information type corresponding to the generated exception information, and the timeout information type corresponding to the generated timeout information;

[0071] The existing result verification information types, exception information types, and timeout information types are summarized into a failure type set;

[0072] Match the hook point type and failure type set with the fault tolerance mapping relationship;

[0073] Read the matching exception handling strategy to determine how to handle the main business process of the low-code platform.

[0074] Preferably, the fault tolerance handling strategy includes a blocking rollback strategy and a continue execution strategy;

[0075] When the matched exception handling strategy is a blocking rollback strategy, stop the main business process of the low-code platform and roll back the business data changes that have been generated by the main business process of the low-code platform.

[0076] When the matched exception handling strategy is to continue execution, record the result verification information, exception information or timeout information, and keep the main business process of the low-code platform running.

[0077] Preferably, the exception handling strategy includes a degraded execution strategy and an asynchronous retry strategy, and the fault tolerance mapping relationship also records a set of safe failure types that are not applicable to asynchronous retries;

[0078] When the matched exception handling strategy is a degraded execution strategy, the execution result of the online hook code is not adopted, and the main business process of the low-code platform continues to be executed.

[0079] When the matched exception handling strategy is an asynchronous retry strategy, read the set of safe failure types that are not applicable to asynchronous retries recorded in the fault tolerance mapping relationship;

[0080] When the set of failure types does not intersect with the set of safe failure types that are not applicable to asynchronous retries, the online hook code, hook point type, execution context data used when executing the online hook code, result verification information, exception information or timeout information are written into the asynchronous retry task, and the online hook code is executed again according to the asynchronous retry task;

[0081] When the set of failure types intersects with the set of safe failure types that are not applicable to asynchronous retries, no asynchronous retry task is written, and the blocking rollback strategy, continuing execution strategy, or degraded execution strategy that matches the set of failure types in the fault tolerance mapping relationship is read.

[0082] Secondly, this application provides a restricted secure execution system for low-code platform hook code, comprising:

[0083] The hook code retrieval module is used to retrieve online hook codes and the hook point types bound to those online hook codes.

[0084] The security policy determination module is used to determine the security policy of online hook code based on the hook point type. The security policy includes pre-execution security verification policy, runtime access control policy, execution result verification policy, and exception handling policy.

[0085] The pre-execution verification module is used to perform pre-execution verification on online hook code according to the pre-execution security verification strategy;

[0086] The runtime access control module is used to restrict the interaction between the online hook code and the low-code platform business environment according to the runtime access control policy after the pre-execution verification is passed, and then execute the online hook code.

[0087] The execution result verification module is used to verify the execution result of the online hook code after the online hook code has been executed, according to the execution result verification strategy, and obtain the result verification information.

[0088] The exception handling module is used to determine the processing method of the main business process of the low-code platform by invoking exception handling strategies based on result verification information, exception information or timeout information during the execution of online hook code.

[0089] Compared with the prior art, the beneficial effects achieved by this application are as follows:

[0090] This application obtains online hook code and the hook point types bound to it, and determines pre-execution security verification strategies, runtime access control strategies, execution result verification strategies, and exception handling strategies based on the hook point types. This enables online hook code to be processed according to the security policies corresponding to the same hook point type before, during, and after execution, as well as in the exception handling stage. This organizes the previously scattered code review, runtime access control, result verification, and exception handling in existing low-code platforms into a continuous, restricted secure execution method. This improves the difficulty of adapting unified sandboxes, unified permission isolation, or single exception handling methods to different hook point types, and enhances the consistency of low-code platform hook code processing in restricted execution environments, secure virtual machines, and runtime access control scenarios.

[0091] By performing pre-execution verification on online hook code according to the pre-execution security verification strategy, risks in the code, import statements, and hidden risks of encoded escape characters can be identified before the online hook code enters the main business process of the low-code platform. This can reduce the situation where high-risk calls, unauthorized import statements, or hidden code content directly enter the subsequent execution stage, and ensure that restricted execution environments or sandbox execution environments have clear verification inputs before the code starts, reducing the risk of insecure code entering the runtime access control stage.

[0092] By restricting the interaction between online hook code and the low-code platform's business environment according to runtime access control policies, and using the restricted interface proxy object as the sole object for interaction between online hook code and the low-code platform's business environment, it is possible to prevent online hook code from directly accessing business service instances, data access instances, and system configuration instances. This limits the interface call boundaries of online hook code during runtime, reduces the risk of online hook code bypassing platform interface boundaries to access the low-code platform's business environment, and improves the clarity of the restricted execution boundaries of executable software in the low-code platform.

[0093] Configuring a data table access control matrix in the runtime access control policy, and parsing and blocking SQL statements directly submitted by online hook code and SQL statements triggered through restricted interface proxy objects, extends runtime access control from the interface call layer to the data access layer. This allows for restrictions on allowing reading, writing, and accessing data tables based on different hook point types, reducing the risk of online hook code unauthorized reading, writing, or accessing sensitive data tables in the main business process of the low-code platform.

[0094] By assigning execution instance identifiers to online hook code and associating external connection resources, exception information, timeout information, and result verification information with execution instance identifiers, a traceable processing record can be formed for each execution process of online hook code. This provides a clear basis for external connection resource release verification, exception fault tolerance handling strategy matching, and asynchronous retry task generation, reducing the problems of exception propagation, resource legacy, and processing link breakage caused by scattered execution records.

[0095] By validating the execution results of online hook code according to the execution result verification strategy, it is possible to determine whether the execution result conforms to the return value type rules, unmodifiable field requirements, external connection resource release requirements, and restricted field output requirements corresponding to the hook point type after the online hook code execution is completed. This can prevent the main business process of the low-code platform from directly adopting execution results that do not meet the requirements of the business node or contain security risks, thereby improving the reliability of the execution result before it enters the main business process of the low-code platform.

[0096] Based on the result verification information, exception information, or timeout information, the exception handling strategy is invoked, and the processing method of the main business process of the low-code platform is determined based on the hook point type and failure type set. This allows for the adaptation of blocking rollback, continuing execution, degraded execution, and asynchronous retry to different failure scenarios. This avoids the simple retrying of safe failure types and also avoids the unnecessary blocking of exceptions that can continue to be processed, giving the main business process of the low-code platform a clearer basis for handling when hook code execution fails, results are non-compliant, or execution times out.

[0097] In summary, this application does not merely add a single sandbox or a single access control mechanism to the low-code platform. Instead, it constructs a restricted secure execution method around the hook point type, which includes pre-execution security verification, runtime access control, execution result verification, and continuous transmission of exception handling. This reduces the risk that online hook code will breach runtime access control boundaries, affect the low-code platform's business environment, or cause the low-code platform's main business processes to adopt insecure execution results. It also improves the coherence, consistency, and controllability of the secure execution process of hook code programs on the low-code platform. Attached Figure Description

[0098] Figure 1 A flowchart illustrating the restricted secure execution method for low-code platform hook code provided in Embodiment 1 of this application;

[0099] Figure 2 This is a schematic diagram of the pre-execution security verification logic provided in Embodiments 3 and 4 of this application;

[0100] Figure 3 This is a schematic diagram of the runtime access control logic provided in Embodiments 5 to 7 of this application;

[0101] Figure 4 This is a schematic diagram of the execution result verification and exception handling logic provided in Embodiments 8 to 13 of this application;

[0102] Figure 5 This is a logical diagram illustrating the application scenario of the hook point type before data saving provided in Embodiment 14 of this application;

[0103] Figure 6 This is a schematic diagram of the data flow logic of the restricted secure execution system for low-code platform hook code provided in Embodiment 15 of this application. Detailed Implementation

[0104] The technical solution of this application will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the embodiments and specific features in the embodiments are detailed descriptions of the technical solution of this application, rather than limitations thereof.

[0105] To facilitate understanding of the embodiments of this application, the execution subject, data object, and strategy object involved in the embodiments of this application will be explained first.

[0106] First, the low-code platform in this application embodiment refers to a computer software platform used to receive, manage, and execute online hook code, and to run the main business process of the low-code platform. The low-code platform can be deployed on a server or as a functional module in an application platform. The low-code platform can also be implemented by a security execution module, a code execution engine, a hook code security execution module, or a software module capable of realizing the secure execution function of online hook code. The low-code platform has at least the functions of online hook code reading, hook point type reading, security policy determination, online hook code execution, and low-code platform main business process processing.

[0107] Second, the online hook code in this application embodiment refers to a code snippet submitted to the low-code platform through an online editing page, code upload interface, or hook code registration interface, and bound to a hook point in the main business process of the low-code platform; the online hook code can be triggered and executed when the main business process of the low-code platform runs to the corresponding hook point; the online hook code is used to perform data verification, field processing, message notification, interface call, or query condition processing in the main business process of the low-code platform; when the low-code platform saves the online hook code, it simultaneously saves the code identifier, version identifier, activation status, and binding relationship.

[0108] Third, the hook point type in this application embodiment refers to the type information used to characterize the location and business semantics of online hook code embedded in the main business process of the low-code platform; the hook point type may include hook point type before data saving, hook point type after data saving, query enhancement hook point type, and interface interception hook point type; the low-code platform determines the triggering position of online hook code in the main business process of the low-code platform, the range of interfaces allowed to be called, the range of data tables allowed to be accessed, the execution result verification requirements, and the exception fault tolerance handling method based on the hook point type; subsequent security strategies are all determined around the hook point type.

[0109] Fourth, the main business process of the low-code platform in this application embodiment refers to the business processing process executed by the low-code platform according to the page configuration, data model configuration, interface configuration, or process configuration; the main business process of the low-code platform includes data addition, data modification, data deletion, data query, interface request processing, approval flow, or message processing; online hook code is triggered and executed at the preset hook point of the main business process of the low-code platform, and the execution result, result verification information, exception information, or timeout information of the online hook code can affect the subsequent processing method of the main business process of the low-code platform.

[0110] Fifth, the low-code platform business environment in this application embodiment refers to the set of runtime resources that the low-code platform can provide to or be indirectly invoked by online hook code when executing the main business process of the low-code platform; the low-code platform business environment includes business service instances, data access instances, system configuration instances, message sending interfaces, asynchronous task interfaces, and database access interfaces; business service instances are used to execute business processing in the main business process of the low-code platform; data access instances are used to read or write business data; system configuration instances are used to read the low-code platform's runtime configuration; message sending interfaces are used to send business messages; asynchronous task interfaces are used to submit asynchronous processing tasks; and database access interfaces are used to execute database read or write operations.

[0111] Sixth, the security strategies in this application embodiment include a pre-execution security verification strategy, a runtime access control strategy, an execution result verification strategy, and an exception handling strategy. The pre-execution security verification strategy is used to identify code risks, import statement risks, and encoded escape character risks before the online hook code is executed. The runtime access control strategy is used to restrict interface calls, data table access, execution time, and external connection resources during the execution of the online hook code. The execution result verification strategy is used to verify the execution result, unmodifiable fields, external connection resources, and restricted fields after the online hook code is executed. The exception handling strategy is used to determine the processing method of the main business process of the low-code platform after the result verification information, exception information, or timeout information is generated.

[0112] Each security policy can be pre-configured by the low-code platform, or it can be configured by the tenant, the administrator, or the platform version. The low-code platform can store each security policy through a security policy mapping table, or it can store each security policy through a configuration file, a database table, or a policy management service. As long as the low-code platform can read the pre-execution security verification policy, the runtime access control policy, the execution result verification policy, and the exception fault tolerance handling policy according to the hook point type, and use the read security policy for the secure execution of online hook code, it belongs to the security policy determination method in the embodiments of this application.

[0113] Example 1:

[0114] This embodiment provides a restricted secure execution method for hook code on a low-code platform. This method can be applied to a low-code platform, or to a hook code secure execution module, hook code execution engine, security verification engine, or processing module with the same function in a low-code platform.

[0115] The core of this embodiment lies in the following: the low-code platform uses hook point types as the main line of security control for online hook code; before the execution of online hook code, the low-code platform determines a pre-execution security verification strategy based on the hook point type, and identifies code risks in the online hook code through the pre-execution security verification strategy; during the execution of online hook code, the low-code platform determines a runtime access control strategy based on the hook point type, and limits the interaction scope between the online hook code and the low-code platform's business environment through the runtime access control strategy; after the execution of online hook code, the low-code platform determines an execution result verification strategy and an exception handling strategy based on the hook point type, verifies the execution result of the online hook code through the execution result verification strategy, and determines the processing method of the low-code platform's main business process through the exception handling strategy; thus, the pre-execution verification, runtime restrictions, execution result verification, and exception handling of online hook code are all executed according to the security strategy corresponding to the hook point type.

[0116] like Figure 1 As shown, the restricted secure execution method for low-code platform hook code in this embodiment may include steps S101 to S106.

[0117] S101, retrieve the online hook code and the hook point type bound to the online hook code.

[0118] In this step, the low-code platform receives online hook code through an online editing page, a code upload interface, or a hook code registration interface. Upon receiving the online hook code, the low-code platform simultaneously generates a code identifier and a version identifier, and writes the online hook code, code identifier, version identifier, activation status, and binding relationship into the hook code record. The binding relationship records the correspondence between the online hook code and hook points in the low-code platform's main business process. When the low-code platform's main business process reaches the target hook point, it reads the hook code record in the activation status according to the hook point identifier of the target hook point, and reads the online hook code from the hook code record. The low-code platform then reads the hook point type field from the binding relationship and determines the field value in the hook point type field as the hook point type bound to the online hook code.

[0119] The hook point type can be determined according to the hook point type table pre-configured by the low-code platform. The hook point type table stores the hook point type field and the hook point trigger position field. The hook point trigger position field is used to record the trigger position of the online hook code in the main business process of the low-code platform. The hook point type can include hook point type before data saving, hook point type after data saving, query enhancement hook point type, and interface interception hook point type. When the online hook code is bound to multiple hook point types, the low-code platform reads the corresponding hook point type according to the actual trigger position of the main business process of the low-code platform and executes the subsequent steps accordingly.

[0120] S102, determine the security policy of online hook code based on hook point type.

[0121] In this step, the low-code platform pre-stores a security policy mapping table. The policy mapping records in the security policy mapping table include hook point type fields, pre-execution security verification policy fields, runtime access control policy fields, execution result verification policy fields, and exception handling policy fields. The low-code platform matches the hook point type bound to the online hook code with the hook point type fields in the security policy mapping table. When the hook point type field matches the hook point type bound to the online hook code, the low-code platform reads the pre-execution security verification policy fields, runtime access control policy fields, execution result verification policy fields, and exception handling policy fields from the matched policy mapping record, and uses the read results as the security policy for the online hook code.

[0122] The pre-execution security verification strategy is used to determine the verification rules that online hook code needs to accept before execution; the runtime access control strategy is used to determine the range of interfaces that online hook code can call, the range of data tables that can be accessed, the allowed execution time, and the external connection resources that need to be registered during execution; the execution result verification strategy is used to determine the return value, field changes, and resource release status that need to be verified after the online hook code execution is completed; the exception fault tolerance handling strategy is used to determine the handling method when the main business process of the low-code platform fails the result verification, generates exception information, or generates timeout information.

[0123] The reason why the same hook point type simultaneously determines the pre-execution security verification strategy, runtime access control strategy, execution result verification strategy, and exception handling strategy is that the triggering position and business semantics of online hook code in the main business process of the low-code platform will simultaneously affect the security control requirements before, during, and after execution. When the hook point type is the pre-data-saving hook point type, the online hook code executes before the business data is written to the database. The low-code platform needs to identify code risks through the pre-execution security verification strategy, restrict write operations and data table access through the runtime access control strategy, verify whether the fields corresponding to the immutable field identifier have changed through the execution result verification strategy, and block the main business process of the low-code platform or roll back the business data changes through the exception handling strategy when the verification fails, an exception occurs, or a timeout occurs.

[0124] When the hook point type is a query enhancement hook point type, the online hook code is used to affect query conditions or query results. The low-code platform needs to identify query-related code risks through pre-execution security verification strategies, limit the list of allowed and prohibited data tables through runtime access control strategies, verify whether the execution result contains the corresponding field of the restricted field identifier through execution result verification strategies, and determine whether the low-code platform's main business process continues execution, degrades execution, or is blocked through exception handling strategies when field verification fails, SQL statements are blocked, or query processing is abnormal. Therefore, the low-code platform determines four types of security policies based on the hook point type, which ensures that the security control requirements of the online hook code correspond to the triggering position and business semantics in the low-code platform's main business process.

[0125] S103, Perform pre-execution verification on the online hook code according to the pre-execution security verification strategy.

[0126] In this step, the low-code platform reads the static code security detection rule set, the list of allowed import statements, and the preset risk threshold from the pre-execution security verification strategy. The low-code platform first performs syntax parsing on the online hook code, converting it into an abstract syntax tree. Then, the platform matches the node content in the abstract syntax tree with the detection patterns in the static code security detection rule set, and generates a risk score according to the risk weight corresponding to the successfully matched detection pattern. The platform then extracts the import statements from the online hook code and compares them with the list of allowed import statements. When the risk score is less than the preset risk threshold and all import statements belong to the list of allowed import statements, the low-code platform generates pre-execution verification information indicating that the verification has passed. When the risk score is not less than the preset risk threshold, or at least one import statement does not belong to the list of allowed import statements, the low-code platform generates pre-execution verification information indicating that the verification has failed.

[0127] The low-code platform can also restore the encoded escape characters in the online hook code according to the pre-execution security verification strategy. After restoring the encoded escape characters to their original characters, the low-code platform obtains the restored code. The low-code platform converts the restored code into a restored abstract syntax tree and matches the restored abstract syntax tree with the detection patterns in the static code security detection rule set to obtain a restored risk score. When the risk score is less than the preset risk threshold, the restored risk score is less than the preset risk threshold, and all import statements belong to the allowed list of import statements and all restored import statements belong to the allowed list of import statements, the low-code platform determines that the pre-execution verification has passed. When any of the risk score, restored risk score, import statement comparison result, or restored import statement comparison result does not meet the corresponding conditions, the low-code platform determines that the pre-execution verification has failed and stops executing the online hook code.

[0128] S104: After the pre-execution verification passes, the interaction between the online hook code and the low-code platform business environment is restricted according to the runtime access control policy, and the online hook code is executed.

[0129] In this step, the low-code platform reads the runtime access control policy after passing the pre-execution verification. Based on the list of restricted interfaces in the runtime access control policy, the low-code platform generates a restricted interface proxy object, which is then used as the sole object for interaction between the online hook code and the low-code platform's business environment. When the online hook code initiates an interface call, the low-code platform determines whether the call belongs to an interface provided by the restricted interface proxy object. If the call belongs to an interface provided by the restricted interface proxy object, the low-code platform allows the call to proceed to the corresponding business processing. If the call does not belong to an interface provided by the restricted interface proxy object, the low-code platform rejects the call and records the reason for rejection.

[0130] The low-code platform also restricts the SQL statements generated by online hook code based on the data table access control matrix in the runtime access control policy; the low-code platform parses the SQL statements generated by online hook code to obtain the operation type and data table identifier; when the operation type is write and the data table identifier belongs to the list of prohibited write data tables, the low-code platform blocks the execution of the SQL statement; when the data table identifier belongs to the list of prohibited access data tables, the low-code platform blocks the execution of the SQL statement; the low-code platform also assigns an execution instance identifier to the online hook code and registers the external connection resources opened by the online hook code through the restricted interface proxy object with the execution instance identifier; the low-code platform monitors the execution duration of the online hook code according to the timeout threshold in the runtime access control policy; when the execution duration exceeds the timeout threshold, the low-code platform generates timeout information; when an exception is caught during the execution of the online hook code, the low-code platform generates exception information.

[0131] S105 After the online hook code finishes execution, the execution result of the online hook code is verified according to the execution result verification strategy to obtain the result verification information.

[0132] In this step, the low-code platform reads the execution result verification strategy after the online hook code execution is completed. The low-code platform then verifies the execution result of the online hook code according to the execution result verification rules in the strategy. When the execution result verification rules include return value type rules, the low-code platform determines whether the execution result of the online hook code conforms to the return value type rules. When the execution result verification rules include unmodifiable field identifiers, the low-code platform generates a summary of the unmodifiable field values ​​before and after the execution of the online hook code, based on the field values ​​corresponding to the unmodifiable field identifiers, and compares whether the summaries of the unmodifiable field values ​​before and after execution are consistent.

[0133] When the execution result verification rule indicates that external connection resources need to be verified as released, the low-code platform queries the registered external connection resources based on the execution instance identifier and determines whether the external connection resources have been released. If there are unreleased external connection resources, the low-code platform generates result verification information indicating that the resources have not been released. When the execution result verification rule indicates that fields in the execution result need to be verified, the low-code platform reads the restricted field identifier in the execution result verification rule and determines whether the execution result contains the field corresponding to the restricted field identifier. If the execution result contains the field corresponding to the restricted field identifier, the low-code platform generates result verification information indicating that the field verification failed. When all execution result verification rules pass, the low-code platform generates result verification information indicating that the verification passed.

[0134] S106. Based on the result verification information, exception information or timeout information during the execution of online hook code, invoke the exception fault tolerance handling strategy to determine the processing method of the main business process of the low-code platform.

[0135] In this step, the low-code platform reads the exception handling strategy and establishes a fault-tolerance mapping relationship between hook point type, result verification information type, exception information type, timeout information type, and exception handling strategy. The low-code platform determines the result verification information type based on the result verification information, the exception information type based on the exception information, and the timeout information type based on the timeout information. The low-code platform matches the hook point type bound to the online hook code, as well as the result verification information type, exception information type, or timeout information type, with the fault-tolerance mapping relationship. The low-code platform reads the matched exception handling strategy and determines the processing method for the low-code platform's main business process based on the exception handling strategy.

[0136] Before executing the asynchronous retry strategy on the low-code platform, the platform first determines whether the result verification information type, exception information type, or timeout information type belongs to the safe failure type that is not applicable to asynchronous retries. The safe failure types that are not applicable to asynchronous retries are pre-configured by the low-code platform in the exception fault tolerance handling strategy. The safe failure types that are not applicable to asynchronous retries include interface call rejection, SQL statement blocking, return value type validation failure, unmodifiable field validation failure, and field validation failure. Among them, unmodifiable field validation failure means that the field corresponding to the unmodifiable field identifier has been changed by the online hook code, return value type validation failure means that the execution result of the online hook code does not conform to the return value type rules, and field validation failure means that the execution result of the online hook code contains the field corresponding to the restricted field identifier.

[0137] When the result verification information type, exception information type, or timeout information type belongs to the safety failure type that is not suitable for asynchronous retries, the low-code platform does not generate an asynchronous retry task; the low-code platform processes the main business process of the low-code platform according to the blocking rollback strategy, the continuing execution strategy, or the degraded execution strategy in the exception fault tolerance handling strategy; when the result verification information type, exception information type, or timeout information type does not belong to the safety failure type that is not suitable for asynchronous retries, the low-code platform allows the asynchronous retry task to be written.

[0138] When the matched exception handling strategy is a blocking rollback strategy, the low-code platform stops the main business process and rolls back the business data changes already generated by the main business process. When the matched exception handling strategy is a continue execution strategy, the low-code platform records the result verification information, exception information, or timeout information, and keeps the main business process running. When the matched exception handling strategy is a degraded execution strategy, the low-code platform does not use the execution result of the online hook code and continues to execute the main business process. When the matched exception handling strategy is an asynchronous retry strategy, the low-code platform writes the online hook code, hook point type, execution context data used when executing the online hook code, result verification information, exception information, or timeout information into the asynchronous retry task, and executes the online hook code again according to the asynchronous retry task.

[0139] Through the above steps, the low-code platform can determine the pre-execution security verification strategy, runtime access control strategy, execution result verification strategy, and exception handling strategy under the same hook point type. The low-code platform can complete code risk and import statement risk verification before online hook code execution, complete interface calls, data table access, execution duration, and external connection resource restrictions during online hook code execution, and complete execution result and external connection resource release verification after online hook code execution. Furthermore, when result verification fails, exception information is generated, or timeout information is generated, the platform determines the handling method of the main business process according to the exception handling strategy. This establishes a hook point type-based correspondence between the secure execution process of online hook code and the handling method of the main business process of the low-code platform.

[0140] Example 2:

[0141] In some embodiments, the low-code platform determines the security policy of online hook code through a security policy mapping table.

[0142] Specifically, the low-code platform pre-establishes a security policy mapping table between hook point types and security policies. The policy mapping records in the security policy mapping table include hook point type fields, pre-execution security verification policy fields, runtime access control policy fields, execution result verification policy fields, and exception handling policy fields. The hook point type field is used to record the hook point types to which the policy mapping record applies; the pre-execution security verification policy field is used to record the pre-execution security verification policy; the runtime access control policy field is used to record the runtime access control policy; the execution result verification policy field is used to record the execution result verification policy; and the exception handling policy field is used to record the exception handling policy.

[0143] After obtaining the hook point type bound to the online hook code on the low-code platform, the low-code platform reads the hook point type field from the security policy mapping table and compares the hook point type bound to the online hook code with the hook point type field item by item. When the field value in the hook point type field matches the hook point type bound to the online hook code, the low-code platform determines the corresponding policy mapping record as a matching policy mapping record. When no matching hook point type field exists, the low-code platform stops executing the online hook code and generates pre-execution verification information for unmatched security policies.

[0144] When a matching policy mapping record is found, the low-code platform reads the pre-execution security verification policy field, runtime access control policy field, execution result verification policy field, and exception handling policy field from the matched policy mapping record. The low-code platform uses the field values ​​in the pre-execution security verification policy field as the pre-execution security verification policy, the field values ​​in the runtime access control policy field as the runtime access control policy, the field values ​​in the execution result verification policy field as the execution result verification policy, and the field values ​​in the exception handling policy field as the exception handling policy. The low-code platform then uses the pre-execution security verification policy, runtime access control policy, execution result verification policy, and exception handling policy together to determine the security policy of the online hook code.

[0145] In one optional implementation, the security policy mapping table stores policy mapping records at the platform level, tenant level, application level, and business entity level respectively. The platform-level policy mapping record is applicable to online hook code within the low-code platform; the tenant-level policy mapping record is applicable to online hook code under the same tenant; the application-level policy mapping record is applicable to online hook code under the same application; and the business entity-level policy mapping record is applicable to online hook code under the same business entity. The low-code platform reads the tenant identifier, application identifier, and business entity identifier from the hook code record and uses the hook point type, tenant identifier, application identifier, and business entity identifier together to match the security policy mapping table.

[0146] In one optional implementation, when multiple policy mapping records are matched simultaneously, the low-code platform selects the policy mapping record in the order of business entity level, application level, tenant level, and platform level. The low-code platform prioritizes using the pre-execution security verification policy field, runtime access control policy field, execution result verification policy field, and exception handling policy field in the business entity level policy mapping record. When any field in the business entity level policy mapping record has no value, the low-code platform reads the field value of the same name in the order of application level, tenant level, and platform level until a complete security policy is formed.

[0147] In another optional implementation, when multiple policy mapping records are matched simultaneously and the low-code platform is configured for merge processing, the low-code platform merges the policy mapping records in the order of business entity level, application level, tenant level, and platform level. During merging, the low-code platform overwrites the field values ​​with the same name in the policy mapping records with the first-ordered field value with the field values ​​with the same name in the policy mapping records with the same name. If the field value with the same name in the policy mapping record with the first-ordered field value has no value, the low-code platform retains the field value with the same name in the policy mapping record with the same name in the policy mapping record with the second-ordered field value. After merging, the low-code platform determines the field values ​​corresponding to the merged pre-execution security verification policy field, runtime access control policy field, execution result verification policy field, and exception fault tolerance handling policy field as the security policy.

[0148] Through this embodiment, the low-code platform can establish a fixed correspondence between hook point types and pre-execution security verification policies, runtime access control policies, execution result verification policies, and exception handling policies through a security policy mapping table. After obtaining the hook point types bound to online hook code, the low-code platform can obtain security policies by field matching, hierarchical selection, or hierarchical merging. This makes the process of determining the security policy of online hook code have a recordable, reviewable, and repeatable processing basis.

[0149] Example 3:

[0150] like Figure 2 As shown, in some embodiments, the pre-execution security verification strategy includes a static code security detection rule set, an import statement allowable list, and a preset risk threshold. The static code security detection rule set includes multiple security detection rules. Each security detection rule includes a detection mode and a risk weight. The detection mode is used to match the abstract syntax tree obtained by converting the online hook code. The risk weight is used to represent the value of the corresponding detection mode in the risk score. The import statement allowable list is used to limit the packages or classes that the online hook code is allowed to import. The preset risk threshold is used to determine whether the risk score meets the pre-execution verification pass condition.

[0151] Specifically, the low-code platform first reads the online hook code and performs syntax parsing on it. The syntax parsing is completed by the low-code platform's preset code parser. The code parser breaks down the online hook code into syntax nodes and generates an abstract syntax tree according to the parent-child relationship and sequence relationship between the syntax nodes. When the syntax parsing fails, the low-code platform generates pre-execution verification information indicating that the verification failed, and records the reason for the syntax parsing failure in the pre-execution verification information. When the syntax parsing succeeds, the low-code platform continues to perform matching between the abstract syntax tree and the detection pattern.

[0152] Subsequently, the low-code platform reads the detection patterns from the static code security detection rule set and traverses the syntax nodes in the abstract syntax tree. The low-code platform compares the node type, method call name, import path, variable assignment relationship, or string content condition in the detection pattern with the corresponding syntax node in the abstract syntax tree. When there is a syntax node in the abstract syntax tree that satisfies the detection pattern, the low-code platform marks the detection pattern as a successful match; when there is no syntax node in the abstract syntax tree that satisfies the detection pattern, the low-code platform marks the detection pattern as unmatched.

[0153] During the matching process, the low-code platform generates a risk score according to the risk weight corresponding to the successfully matched detection mode; in one optional implementation, the risk score is determined according to the following formula: In the formula, represents the risk score; n represents the total number of detection modes in the static code security detection rule set, which is obtained by the low-code platform after reading the static code security detection rule set. This represents the matching flag for the i-th detection pattern. When the i-th detection pattern matches successfully... When the i-th detection pattern does not match, ; This represents the risk weight corresponding to the i-th detection mode. Read from the set of static code security inspection rules.

[0154] Risk weights are non-negative; risk weights within the same static code security detection rule set use the same scoring unit; preset risk thresholds and risk scores use the same scoring unit; when reading the static code security detection rule set, the low-code platform verifies whether the risk weights are non-negative; when any risk weight is negative, the low-code platform stops using the corresponding static code security detection rule set and generates pre-execution verification information for static code security detection rule set configuration errors.

[0155] formula middle, For matching markers, dimensionless; Risk weights are non-negative numbers; risk weights within the same static code security detection rule set use the same scoring unit; risk scoring. This is the result of accumulating risk weights; the preset risk threshold and risk score use the same scoring unit, and the two can be directly compared; the formula only accumulates the corresponding risk weight when the detection pattern is successfully matched, and the risk weight does not produce negative cancellation, which can reflect the processing logic that the risk score is jointly determined by the matching result and the risk weight.

[0156] The low-code platform also extracts import statements from the abstract syntax tree and compares them with the list of allowed import statements. If the package or class corresponding to the import statement exists in the list of allowed import statements, the low-code platform marks the import statement as allowed. If the package or class corresponding to the import statement does not exist in the list of allowed import statements, the low-code platform marks the import statement as disallowed. When the online hook code does not contain an import statement, the low-code platform determines the import statement comparison result as passed.

[0157] When the risk score is less than the preset risk threshold and the import statement comparison result is passed, the low-code platform generates pre-execution verification information that has passed the verification. The pre-execution verification information includes code identifier, version identifier, hook point type, risk score, preset risk threshold and import statement comparison result. The low-code platform writes the pre-execution verification information that has passed the verification into the execution record of the online hook code and allows the online hook code to enter the subsequent runtime access control processing.

[0158] When the risk score is not less than the preset risk threshold, or the import statement comparison result is unsuccessful, the low-code platform generates pre-execution verification information indicating that the verification failed. The pre-execution verification information includes code identifier, version identifier, hook point type, risk score, preset risk threshold, successfully matched detection mode, corresponding risk weight, and import statement comparison result. The low-code platform writes the pre-execution verification information indicating that the verification failed into the execution record of the online hook code and stops executing the online hook code.

[0159] Optionally, the preset risk threshold is set according to the hook point type, the importance level of the business entity, the tenant security level, or the platform security level; the low-code platform pre-saves a risk threshold configuration table; the risk threshold configuration table includes a hook point type field, a business entity importance level field, a tenant security level field, a platform security level field, and a preset risk threshold field; the low-code platform matches the risk threshold configuration table according to the hook point type bound to the online hook code, as well as the business entity importance level, tenant security level, and platform security level in the hook code record, and uses the field value of the preset risk threshold field in the matched record as the preset risk threshold.

[0160] The preset risk threshold is set according to the scoring unit of the risk weights in the static code security detection rule set; the low-code platform uses the risk score between the pre-execution verification being allowed and the pre-execution verification failing as the preset risk threshold field value; when the low-code platform uses a risk score less than the preset risk threshold as the verification passing condition, the preset risk threshold field value is set to the upper boundary value corresponding to the highest allowed risk score; under the same hook point type, the preset risk threshold is not greater than the sum of all risk weights in the static code security detection rule set.

[0161] Through this embodiment, the low-code platform can convert online hook code into an abstract syntax tree and perform node matching on the abstract syntax tree using the detection patterns in the static code security detection rule set. The low-code platform can generate a risk score based on the risk weight corresponding to the successfully matched detection pattern, and obtain pre-execution verification information by combining a preset risk threshold and an import statement allowable list. This makes the pre-execution security verification strategy have clear inputs, processing procedures, and output results.

[0162] Example 4:

[0163] like Figure 2 As shown, in some embodiments, pre-execution verification also includes encoding escape character restoration and import statement verification; encoding escape character restoration is used to restore characters represented in encoded form in the online hook code to their original characters; import statement verification is used to determine whether the package or class imported by the online hook code belongs to the import statement allowed list; encoding escape character restoration and import statement verification are both completed before the online hook code enters the runtime access control processing.

[0164] Specifically, the low-code platform reads the online hook code and identifies the encoded escape characters in the online hook code according to the preset encoding restoration rules. The preset encoding restoration rules are determined by the programming languages ​​and character encoding formats supported by the low-code platform. The low-code platform converts the identified encoded escape characters into the original characters to obtain the restored code. When there are no encoded escape characters in the online hook code, the low-code platform directly uses the online hook code as the restored code for subsequent processing.

[0165] Subsequently, the low-code platform performs syntax parsing on the restored code, breaking it down into syntax nodes, and generating a restored abstract syntax tree according to the parent-child and sequential relationships between these nodes. When syntax parsing fails, the low-code platform generates pre-execution verification information indicating that the verification failed, and records the reason for the syntax parsing failure in this information. When syntax parsing succeeds, the low-code platform matches the restored abstract syntax tree with the detection patterns in the static code security detection rule set, and generates a restored risk score based on the risk weight corresponding to the successfully matched detection pattern.

[0166] After obtaining the restoration risk score, the low-code platform extracts import statements from the abstract syntax tree corresponding to the online hook code and restore import statements from the restore abstract syntax tree corresponding to the restoration code. The low-code platform compares the import statements and restore import statements with the allowed list of import statements. When the packages or classes corresponding to both the import statements and restore import statements exist in the allowed list of import statements, the low-code platform determines that the import statement validation is successful. When the packages or classes corresponding to at least one import statement or at least one restore import statement do not exist in the allowed list of import statements, the low-code platform determines that the import statement validation is unsuccessful.

[0167] When the risk score is less than the preset risk threshold, the restoration risk score is less than the preset risk threshold, and the import statement verification passes, the low-code platform determines that the pre-execution verification has passed. The low-code platform generates the verified pre-execution verification information and writes the code identifier, version identifier, hook point type, risk score, restoration risk score, preset risk threshold, and import statement verification result into the pre-execution verification information. The low-code platform writes the verified pre-execution verification information into the execution record of the online hook code and allows the online hook code to enter runtime access control processing.

[0168] When any of the following conditions are met: the risk score is not less than the preset risk threshold, the restored risk score is not less than the preset risk threshold, or the import statement verification fails, the low-code platform determines that the pre-execution verification has failed. The low-code platform generates pre-execution verification information for the failed verification and records the reason for failure in the pre-execution verification information. The reasons for failure include the risk score not meeting the threshold condition, the restored risk score not meeting the threshold condition, the import statement not belonging to the allowed import statement list, or the restored import statement not belonging to the allowed import statement list. The low-code platform stops executing the online hook code.

[0169] In one optional implementation, the restoration risk score is generated using the same calculation method as the risk score; the low-code platform uses the restoration abstract syntax tree as the matching object, the detection patterns in the static code security detection rule set as the matching rules, and accumulates the risk weights corresponding to the successfully matched detection patterns to obtain the restoration risk score; the generation process of the restoration risk score can be represented as: In the formula, This represents the restoration risk score; n represents the total number of detection modes in the static code security detection rule set; This indicates the matching flag of the i-th detection pattern in the reconstructed abstract syntax tree. When a match is successful... When not matched ; This represents the risk weight corresponding to the i-th detection mode. Read from the set of static code security inspection rules.

[0170] Risk weights are non-negative; risk weights within the same static code security detection rule set use the same scoring unit; preset risk thresholds and restored risk scores use the same scoring unit; when reading the static code security detection rule set, the low-code platform verifies whether the risk weights are non-negative; when any risk weight is negative, the low-code platform stops using the corresponding static code security detection rule set and generates pre-execution verification information for static code security detection rule set configuration errors.

[0171] formula middle, For matching markers, dimensionless; Risk weights are non-negative numbers; risk weights within the same static code security testing rule set use the same scoring unit. This is the result of accumulating risk weights; restoring the risk score. The same scoring unit is used as the preset risk threshold, and the two can be directly compared; the formula logic is consistent with the risk scoring logic in Example 3, only the matching object is replaced by the abstract syntax tree and the restored abstract syntax tree, and the risk weight does not produce negative cancellation, and the calculation process is reasonable.

[0172] Through this embodiment, the low-code platform can perform risk scoring in the original character state of online hook code, and perform restoration risk scoring again after the encoded escape characters are restored; the low-code platform can also perform allow list comparison for import statements and restored import statements respectively; thereby enabling pre-execution verification to identify code content hidden by encoded escape characters, and restrict online hook code from importing packages or classes outside the allowed list of import statements.

[0173] Example 5:

[0174] like Figure 3 As shown, in some embodiments, the runtime access control policy includes a restricted interface list; the restricted interface list is used to limit the low-code platform business environment interfaces that the online hook code is allowed to call during execution; the low-code platform business environment interfaces include user information reading interfaces, business data reading interfaces, business verification interfaces, message sending interfaces, asynchronous task submission interfaces, or configuration reading interfaces; the low-code platform reads the corresponding restricted interface list from the runtime access control policy according to the hook point type, and uses the restricted interface list as the interface call boundary during the execution of the online hook code.

[0175] It should be noted that the restricted interface list in this application refers to the list of interfaces that online hook code is allowed to call in a restricted execution environment; interfaces not recorded in the restricted interface list are not exposed to online hook code, nor may they be called by online hook code through restricted interface proxy objects.

[0176] Specifically, before executing online hook code, the low-code platform first reads the hook point type bound to the online hook code; then, the low-code platform matches the restricted interface list in the runtime access control policy according to the hook point type; when a match is successful, the low-code platform reads the interface identifier, interface name, call parameter type, and return value type from the restricted interface list; when no restricted interface list is matched, the low-code platform stops executing the online hook code and generates an exception message indicating that the runtime access control policy is not matched.

[0177] The low-code platform generates a restricted interface proxy object that contains only the interfaces in the restricted interface list; the restricted interface proxy object provides the interfaces recorded in the restricted interface list to the outside world; the restricted interface proxy object internally connects to the corresponding business services in the low-code platform's business environment; the low-code platform writes the restricted interface proxy object into the execution context data of the online hook code and prohibits the online hook code from directly obtaining the business service instances, data access instances, and system configuration instances in the low-code platform's business environment.

[0178] The restricted interface proxy object can serve as the sole object for interaction between online hook code and the low-code platform's business environment because the low-code platform only injects the restricted interface proxy object into the execution context data when constructing the online hook code's execution context data. The low-code platform does not inject business service instances, data access instances, or system configuration instances into the execution context data. During execution, the online hook code can only read objects that exist in the execution context data. Therefore, the online hook code can only initiate interface calls with the low-code platform's business environment through the restricted interface proxy object.

[0179] When the low-code platform establishes an execution environment for online hook code, it does not expose business service instances, data access instances, system configuration instances, reflection call interfaces, and direct database access objects to the execution environment. These instances are not written into the execution context data of the online hook code. The online hook code cannot obtain these objects from the execution context data during execution. When the online hook code needs to access the low-code platform's business environment, it can only initiate interface calls through the restricted interface proxy object in the execution context data.

[0180] The low-code platform also restricts the scope of runtime objects visible to the online hook code during the online hook code loading phase. When the online hook code requests a business service instance, data access instance, system configuration instance, or direct database access object through reflection, class loading, or context lookup, the runtime access control module rejects the corresponding request. The runtime access control module writes the request method, the name of the requested object, the execution instance identifier, and the reason for rejection into the execution record of the online hook code.

[0181] When loading online hook code, the low-code platform also limits the scope of objects visible to the online hook code; the online hook code cannot obtain business service instances, data access instances, and system configuration instances through execution context data; when the online hook code initiates an interface call, the runtime access control module first determines whether the interface call comes from a restricted interface proxy object; when the interface call does not come from a restricted interface proxy object, the runtime access control module rejects the interface call and writes the rejection reason information into the execution record of the online hook code.

[0182] When online hook code is executed, the low-code platform uses the restricted interface proxy object as the only object for interaction between the online hook code and the low-code platform's business environment. When the online hook code needs to read business data, submit business validation, send messages, or call asynchronous tasks, it can only initiate interface calls through the restricted interface proxy object. After the restricted interface proxy object receives the interface call, the low-code platform first checks whether the interface identifier corresponding to the interface call belongs to the restricted interface list, and then forwards the interface call that belongs to the restricted interface list to the low-code platform's business environment.

[0183] When online hook code initiates an interaction request outside of the restricted interface proxy object, the low-code platform rejects the interaction request. The interaction request includes directly calling business service instances in the low-code platform's business environment, directly calling data access instances, directly reading system configuration instances, or calling interfaces not included in the restricted interface list. The low-code platform records the rejection reason information. The rejection reason information includes code identifier, version identifier, hook point type, execution instance identifier, rejected interface identifier, rejected interface name, and rejection time. The low-code platform writes the rejection reason information into the execution record of the online hook code.

[0184] As an optional implementation, the restricted interface proxy object is generated through dynamic proxy; the low-code platform generates a set of proxy interfaces based on the restricted interface list and creates a proxy instance before the online hook code is executed; the proxy instance receives the interface call initiated by the online hook code and performs interface identifier verification before the interface call enters the low-code platform business environment; when the interface identifier belongs to the restricted interface list, the proxy instance forwards the interface call; when the interface identifier does not belong to the restricted interface list, the proxy instance rejects the interface call.

[0185] As an alternative implementation, the restricted interface proxy object is generated through interface encapsulation; the low-code platform pre-configures encapsulated interface classes for different hook point types; the encapsulated interface class only exposes the interfaces recorded in the restricted interface list; the low-code platform selects the corresponding encapsulated interface class according to the hook point type bound to the online hook code, and writes the instance of the encapsulated interface class as the restricted interface proxy object into the execution context data; the online hook code can only call the low-code platform business environment through the instance of the encapsulated interface class.

[0186] As an alternative implementation, the restricted interface proxy object is generated through a service facade; the low-code platform creates a service facade object for the same hook point type; the service facade object encapsulates multiple low-code platform business environment interfaces into interfaces allowed to be called in the restricted interface list; before executing the online hook code, the low-code platform selects a service facade object according to the hook point type and uses the service facade object as the restricted interface proxy object; the service facade object performs interface identifier verification and writes call records for each interface call.

[0187] Through this embodiment, the low-code platform can read the list of restricted interfaces according to the hook point type and generate a restricted interface proxy object based on the list; online hook code can only interact with the low-code platform business environment through the restricted interface proxy object; the low-code platform can reject interaction requests other than the restricted interface proxy object and record the reason for rejection; thus, the runtime access control policy is implemented at the interface call boundary between the online hook code and the low-code platform business environment.

[0188] Example 6:

[0189] like Figure 3 As shown, in some embodiments, the runtime access control policy further includes a data table access control matrix; the data table access control matrix includes a list of allowed-to-read data tables, a list of prohibited-to-write data tables, and a list of prohibited-to-access data tables; the list of allowed-to-read data tables records the identifiers of data tables that the online hook code is allowed to read during execution; the list of prohibited-to-write data tables records the identifiers of data tables that the online hook code is prohibited from performing write operations during execution; the list of prohibited-to-access data tables records the identifiers of data tables that the online hook code is prohibited from reading or writing during execution; when the low-code platform executes the online hook code, it performs data table access control on the SQL statements generated by the online hook code according to the data table access control matrix.

[0190] The SQL statement interception targets include SQL statements directly generated by online hook code, and SQL statements triggered by the call chain after online hook code calls the low-code platform business environment through a restricted interface proxy object. SQL statements directly generated by online hook code refer to SQL statements submitted by online hook code through the database access interface during execution. SQL statements triggered by the call chain refer to SQL statements generated and submitted by the business service instance, data access instance, or database access interface in the low-code platform business environment after the restricted interface proxy object receives the interface call from the online hook code. The low-code platform sets up SQL interception processing at the database access interface entry point, so that both types of SQL statements enter the judgment process of the data table access control matrix.

[0191] Specifically, the low-code platform intercepts SQL statements generated by online hook code during execution; the low-code platform parses the SQL statements, extracting the corresponding operation type and data table identifier; the operation type includes read and write; when the SQL statement contains multiple data table identifiers, the low-code platform extracts each data table identifier separately and compares each data table identifier with the list of allowed read data tables, the list of prohibited write data tables, and the list of prohibited access data tables; when the SQL statement cannot be parsed to obtain the operation type or data table identifier, the low-code platform blocks the execution of the SQL statement and generates an exception message indicating that the SQL statement parsing failed.

[0192] When an SQL statement contains aliases, the low-code platform parses the correspondence between the aliases and the original table identifiers, and uses the original table identifiers as the comparison objects in the table access control matrix. When an SQL statement contains subqueries, the low-code platform parses the table identifiers in the main query and subqueries respectively, and compares them with the lists of tables allowed to read, tables prohibited to write, and tables prohibited to access. If any table identifier does not meet the corresponding access control conditions, the low-code platform blocks the execution of the SQL statement.

[0193] When an SQL statement contains a view identifier, the low-code platform converts the view identifier into a base table identifier based on the view configuration table. The view configuration table is pre-generated by the low-code platform based on the database view definition. When the view identifier can be converted into a base table identifier, the low-code platform uses the base table identifier as the comparison object in the data table access control matrix. When the view identifier cannot be converted into a base table identifier, the low-code platform blocks the execution of the SQL statement and generates an exception message indicating that the view identifier conversion failed.

[0194] When an SQL statement is formed by dynamic concatenation, the low-code platform uses the complete SQL statement formed before submission to the database access interface as the parsing object. When the dynamically concatenated SQL statement can form a complete SQL statement, the low-code platform parses the operation type and table identifier according to the complete SQL statement. When the dynamically concatenated SQL statement cannot form a complete SQL statement before submission to the database access interface, or when the complete SQL statement cannot parse the operation type or table identifier, the low-code platform blocks the execution of the SQL statement and generates an exception message indicating that the dynamic SQL statement parsing failed.

[0195] When the operation type is read and the data table identifier is not in the list of allowed read data tables, the low-code platform blocks the execution of the SQL statement; the low-code platform does not submit the SQL statement to the database execution process; the low-code platform generates an exception message indicating that read access is blocked; the exception message indicating that read access is blocked includes the code identifier, version identifier, hook point type, execution instance identifier, operation type, data table identifier, and reason for blocking; the low-code platform writes the exception message indicating that read access is blocked into the execution record of the online hook code for subsequent invocation of the exception handling strategy.

[0196] When the operation type is write and the data table identifier belongs to the list of prohibited write tables, the low-code platform blocks the execution of the SQL statement; the low-code platform does not submit the SQL statement to the database execution process; the low-code platform generates an exception message indicating that write access has been blocked; the exception message indicating that write access has been blocked includes the code identifier, version identifier, hook point type, execution instance identifier, operation type, data table identifier, and reason for blocking; the low-code platform writes the exception message indicating that write access has been blocked into the execution record of the online hook code for subsequent invocation of the exception handling strategy.

[0197] When a data table is identified as being on the list of prohibited data tables, the low-code platform blocks the execution of SQL statements. Regardless of whether the operation type is read or write, the low-code platform does not submit the SQL statement to the database execution process. The low-code platform generates exception information indicating that data table access has been blocked. This exception information includes the code identifier, version identifier, hook point type, execution instance identifier, operation type, data table identifier, and reason for blocking. The low-code platform writes this exception information to the execution record of the online hook code for subsequent invocation of exception handling strategies.

[0198] When the operation type is read and the data table identifier belongs to the list of allowed read data tables and is not in the list of prohibited access data tables, the low-code platform allows the SQL statement to enter the database execution process. When the operation type is write and the data table identifier does not belong to the list of prohibited write data tables and is not in the list of prohibited access data tables, the low-code platform allows the SQL statement to enter the database execution process. The low-code platform writes the operation type, data table identifier, and execution instance identifier corresponding to the allowed SQL statement into the execution record of the online hook code for subsequent correlation verification of the execution result.

[0199] In one optional implementation, the data table access control matrix is ​​configured according to hook point type, business entity, tenant, user role, or business process node; the low-code platform pre-stores the data table access control matrix; the matrix records in the data table access control matrix include hook point type field, business entity field, tenant field, user role field, business process node field, allowed read data table list field, prohibited write data table list field, and prohibited access data table list field; the low-code platform matches the data table access control matrix according to the hook point type bound to the online hook code, and the business entity, tenant, user role, and business process node in the execution context data, and reads the corresponding allowed read data table list, prohibited write data table list, and prohibited access data table list.

[0200] In one optional implementation, when the hook point type is a query enhancement hook point type, the low-code platform generates a list of data tables that can be read based on the user role, business entity, and data permission configuration. The list of data tables that can be read only contains the identifiers of the data tables that the current user is authorized to query under the current business entity. When the online hook code corresponding to the query enhancement hook point type generates a read operation, the low-code platform only allows SQL statements whose data table identifiers belong to the list of data tables that can be read to enter the database execution process.

[0201] In another optional implementation, when the low-code platform matches multiple matrix records simultaneously, the low-code platform reads the matrix records in the order of business process node, user role, business entity, tenant, and hook point type. The low-code platform prioritizes the list of prohibited data tables to be written to and the list of prohibited data tables to be accessed in the matrix records that are sorted first. When any list in the matrix records that are sorted first is empty, the low-code platform continues to read the list of the same name in the matrix records that are sorted second, until the list of prohibited data tables to be written to and the list of prohibited data tables to be accessed for the current execution process are formed.

[0202] Through this embodiment, the low-code platform can parse SQL statements during online hook code execution to obtain the operation type and data table identifier. The low-code platform can allow or block read access, write access, and block access respectively based on the list of allowed read data tables, prohibited write data tables, and prohibited access data tables in the data table access control matrix. This extends the runtime access control policy from the interface call boundary to the data access layer, and makes different hook point types correspond to different data table access ranges.

[0203] Example 7:

[0204] like Figure 3 As shown, in some embodiments, the runtime access control policy further includes a timeout threshold; the timeout threshold is used to limit the maximum execution time allowed for the online hook code from the start to the end of execution; before the online hook code enters the runtime access control process, the low-code platform reads the timeout threshold in the runtime access control policy and writes the timeout threshold into the execution context data of the online hook code; the low-code platform monitors the execution process of the online hook code according to the timeout threshold.

[0205] Specifically, the low-code platform assigns an execution instance identifier to the online hook code; the execution instance identifier is used to distinguish the execution records of the same online hook code in different triggering processes; after generating the execution instance identifier, the low-code platform writes the execution instance identifier, code identifier, version identifier, hook point type and execution start time into the execution record of the online hook code; the low-code platform then starts the online hook code and passes the execution instance identifier to the restricted interface proxy object.

[0206] The low-code platform associates and registers external connection resources opened by online hook code through the restricted interface proxy object with execution instance identifiers. External connection resources include database connection resources, file access resources, network connection resources, or message sending connection resources. When the restricted interface proxy object creates an external connection resource, the low-code platform writes the external connection resource identifier, resource type, creation time, and execution instance identifier into the resource registration record. When the external connection resource is released, the low-code platform writes the release time and release result into the resource registration record.

[0207] During the execution of online hook code, the low-code platform monitors the execution duration of the online hook code based on a timeout threshold; in one optional implementation, the execution duration is determined according to the following formula: In the formula, Indicates the execution time; Indicates the start time of execution. Logs are logged when online hook code is launched from a low-code platform; Indicates the monitoring time. The low-code platform reads the execution status of online hook code while monitoring it; the low-code platform will record the execution time. Compare with the timeout threshold.

[0208] The execution start time, monitoring time, and timeout threshold are recorded using the same clock source and the same time unit. The same clock source is provided by the runtime timing component of the low-code platform. The same time unit is determined by the time unit field in the runtime access control policy. When no time unit field is configured in the runtime access control policy, the low-code platform uses milliseconds as the time unit. Both the execution duration and the timeout threshold are in milliseconds or seconds, and the execution duration and the timeout threshold are converted to the same time unit before comparison.

[0209] The execution start time, monitoring time, and timeout threshold are recorded using the same clock source and the same time unit, and the execution duration is... Both the timeout threshold and the timeout threshold are time lengths; they are converted to the same time unit before comparison. When the timeout exceeds the timeout threshold, a timeout message is generated. The judgment logic is consistent with the purpose of the timeout threshold.

[0210] When the execution duration exceeds the timeout threshold, the low-code platform generates timeout information. The timeout information includes the execution instance identifier, code identifier, version identifier, hook point type, execution start time, monitoring time, execution duration, timeout threshold, and timeout reason. The low-code platform writes the timeout information into the execution record of the online hook code. The low-code platform stops the online hook code from continuing to execute according to the runtime access control policy and uses the timeout information as input for subsequent exception handling strategies.

[0211] When an exception is caught during execution, the low-code platform generates exception information. The exception information includes the execution instance identifier, code identifier, version identifier, hook point type, exception occurrence time, exception type, exception location, and exception cause. The low-code platform writes the exception information into the execution record of the online hook code. When the online hook code has already opened external connection resources when the exception occurs, the low-code platform queries the resource registration record based on the execution instance identifier and uses the queried external connection resources as input for the subsequent execution result verification strategy.

[0212] Optionally, the timeout threshold can be read from the security policy mapping table; the low-code platform matches the security policy mapping table according to the hook point type bound to the online hook code, and reads the runtime access control policy field from the matched policy mapping record; when the runtime access control policy field includes a timeout threshold, the low-code platform uses the timeout threshold in the runtime access control policy field as the timeout threshold of the online hook code; when the runtime access control policy field does not include a timeout threshold, the low-code platform reads the platform default timeout threshold and uses the platform default timeout threshold as the timeout threshold of the online hook code.

[0213] Optionally, the timeout threshold can be determined by the hook point type, online hook code version, business process importance level, or platform load status. The low-code platform pre-stores a timeout threshold configuration table. The timeout threshold configuration table includes fields for hook point type, online hook code version, business process importance level, platform load status, and timeout threshold. The platform load status is determined by the low-code platform by reading the runtime monitoring records before executing the online hook code. The low-code platform matches the hook point type, online hook code version, business process importance level, and platform load status with the timeout threshold configuration table and uses the field value of the timeout threshold field in the matched record as the timeout threshold.

[0214] Through this embodiment, the low-code platform can assign execution instance identifiers to online hook code and associate these identifiers with execution records, external connection resources, and runtime monitoring processes. The low-code platform can also generate timeout information based on timeout thresholds and generate exception information when exceptions are captured. Furthermore, the low-code platform can query the registration status of external connection resources using the execution instance identifier. This provides input for subsequent execution result verification strategies to determine whether external connection resources have been released, and for exception handling strategies to determine the processing method of the low-code platform's main business process.

[0215] Example 8:

[0216] like Figure 4 As shown, in some embodiments, the execution result verification strategy includes execution result verification rules; the execution result verification rules are used to limit the objects to be verified after the online hook code execution is completed, the verification conditions, and the type of result verification information generated when the verification fails; the low-code platform reads the execution result verification strategy after the online hook code execution is completed, and verifies the execution result of the online hook code according to the execution result verification rules in the execution result verification strategy.

[0217] Specifically, the low-code platform establishes a verification mapping relationship between hook point types and execution result verification rules. The verification mapping relationship includes a hook point type field and an execution result verification rule field. The hook point type field is used to record the hook point types to which the execution result verification rules apply. The execution result verification rule field is used to record the execution result verification rules corresponding to the hook point types. The low-code platform matches the hook point types bound to the online hook code with the hook point type field and reads the execution result verification rule field from the matching record to obtain the execution result verification rules.

[0218] After reading the execution result verification rules, the low-code platform uses the execution result of the online hook code as the verification object. The low-code platform verifies the execution result of the online hook code item by item according to the verification conditions recorded in the execution result verification rules. When the execution result of the online hook code meets all the verification conditions in the execution result verification rules, the low-code platform generates a verification result message indicating that the verification has passed. When the execution result of the online hook code does not meet any verification condition, the low-code platform generates a verification result message indicating that the verification has failed.

[0219] As an optional implementation, the execution result verification rules include return value type rules; the return value type rules are used to limit the data type that the execution result of the online hook code should have; the low-code platform reads the data type corresponding to the execution result of the online hook code and compares the data type corresponding to the execution result with the return value type rules; when the data type corresponding to the execution result does not belong to the data type limited by the return value type rules, the low-code platform generates result verification information indicating that the return value type verification has failed.

[0220] As an optional implementation, the execution result verification rules include unmodifiable field identifiers; unmodifiable field identifiers are used to limit the business fields that cannot be changed during the execution of online hook code; the low-code platform reads the field value of the field corresponding to the unmodifiable field identifier before executing the online hook code, and reads the field value of the field corresponding to the unmodifiable field identifier again after executing the online hook code; when the field values ​​read before and after execution are inconsistent, the low-code platform generates a result verification message indicating that the unmodifiable field verification has failed.

[0221] The unmodifiable field identifier is pre-generated by the low-code platform based on the business entity field attributes, field permission configuration, or data security level configuration. When the business entity field attributes mark a field as a field that cannot be changed after saving, the low-code platform writes the corresponding field identifier into the unmodifiable field identifier. When the field permission configuration prohibits online hook code from modifying the field, the low-code platform writes the corresponding field identifier into the unmodifiable field identifier. When the data security level configuration requires the field to remain consistent before and after the online hook code execution, the low-code platform writes the corresponding field identifier into the unmodifiable field identifier.

[0222] As an optional implementation, the execution result verification rules include external connection resource release rules. The external connection resource release rules are used to verify whether the external connection resources opened by the online hook code through the restricted interface proxy object have been released. The low-code platform queries the resource registration record based on the execution instance identifier and reads the release result in the resource registration record. When at least one external connection resource has not recorded a release result, the low-code platform generates result verification information for unreleased resources.

[0223] As an optional implementation, the execution result verification rules include restricted field identifiers; the restricted field identifiers are used to limit the fields that must not be included in the execution result of the online hook code; the low-code platform reads the field identifiers in the execution result of the online hook code and compares the field identifiers in the execution result with the restricted field identifiers; when the field identifiers in the execution result contain the restricted field identifiers, the low-code platform generates result verification information indicating that the field verification has failed.

[0224] Restricted field identifiers are pre-generated by the low-code platform based on business entity field attributes, field permission configurations, or data security level configurations. When a business entity field attribute marks a field as a field that cannot be output by online hook code, the low-code platform writes the corresponding field identifier into the restricted field identifier. When the field permission configuration prohibits online hook code from returning a field, the low-code platform writes the corresponding field identifier into the restricted field identifier. When the data security level configuration requires that a field must not appear in the execution result, the low-code platform writes the corresponding field identifier into the restricted field identifier.

[0225] After the low-code platform generates result verification information, it writes the code identifier, version identifier, hook point type, execution instance identifier, execution result verification rule, verification object, verification result, and result verification information type into the execution record of the online hook code. When the result verification information is a result verification information that fails verification, a result verification information that resources are not released, or a result verification information that fails field verification, the low-code platform uses the result verification information as input for the exception fault tolerance handling strategy.

[0226] Through this embodiment, the low-code platform can read the corresponding execution result verification rules according to the hook point type, and verify the execution result, unmodifiable fields, external connection resources and restricted fields of the online hook code after the online hook code is executed; thereby extending the security judgment of the online hook code from the execution process to the execution result, and providing result verification information for the exception fault tolerance handling strategy.

[0227] Example 9:

[0228] like Figure 4 As shown, in some embodiments, the hook point type includes a hook point type before data saving, and the execution result verification rules include return value type rules and unmodifiable field identifiers; the hook point type before data saving is used to indicate that the online hook code is triggered before the business data is saved to the database; the return value type rules are used to limit the data types that the execution result of the online hook code is allowed to use; the unmodifiable field identifier is used to mark the business fields that the online hook code must not change during execution.

[0229] The unmodifiable field identifier is pre-generated by the low-code platform based on the business entity field attributes, field permission configuration, or data security level configuration. Before executing the online hook code corresponding to the hook point type before saving the data, the low-code platform reads the business entity field attributes, field permission configuration, and data security level configuration corresponding to the current business entity, and writes the field identifiers that cannot be changed after saving, are prohibited from being modified by the online hook code, or need to remain consistent before and after execution into the unmodifiable field identifier.

[0230] When the hook point type bound to the online hook code is the pre-data-saving hook point type, the low-code platform first reads the return value type rule in the execution result verification rules; then, the low-code platform reads the execution result of the online hook code and identifies the data type of the execution result; the low-code platform compares the data type of the execution result with the allowed data types recorded in the return value type rule; when the data type of the execution result belongs to the allowed data type recorded in the return value type rule, the low-code platform determines that the return value type rule verification has passed; when the data type of the execution result does not belong to the allowed data type recorded in the return value type rule, the low-code platform determines that the return value type rule verification has failed.

[0231] The low-code platform also reads the unmodifiable field identifiers from the execution result verification rules. Before executing the online hook code, the low-code platform reads the field values ​​corresponding to the unmodifiable field identifiers from the business data to be saved, and concatenates the field identifiers and field values ​​according to the sorting order of the field identifiers to generate a string of field values ​​before execution. The low-code platform performs digest processing on the string of field values ​​before execution to obtain a digest of the unmodifiable field values ​​before the online hook code is executed. The digest processing uses a preset digest algorithm of the low-code platform, which is specified in advance by the low-code platform in the security policy configuration.

[0232] After the online hook code execution is complete, the low-code platform reads the field value corresponding to the unmodifiable field identifier from the business data to be saved again, and concatenates the field identifier and field value according to the same field identifier sorting order to generate the post-execution field value string. The low-code platform performs the same digest processing on the post-execution field value string to obtain the post-execution unmodifiable field value digest. The low-code platform compares the post-execution unmodifiable field value digest with the post-execution unmodifiable field value digest to determine whether the field value corresponding to the unmodifiable field identifier has changed.

[0233] When the execution result does not conform to the return value type rules, the low-code platform generates a result verification message indicating that the verification failed. The result verification message includes the code identifier, version identifier, hook point type, execution instance identifier, return value type rules, data type of the execution result, and reason for verification failure. The reason for verification failure is recorded as the data type of the execution result not belonging to the allowed data type recorded in the return value type rules. The low-code platform writes the result verification message into the execution record of the online hook code and uses the result verification message as input to the exception handling strategy.

[0234] When the summary of unmodifiable field values ​​before execution differs from the summary of unmodifiable field values ​​after execution, the low-code platform generates verification information indicating that the verification failed. The verification information includes code identifier, version identifier, hook point type, execution instance identifier, unmodifiable field identifier, summary of unmodifiable field values ​​before execution, summary of unmodifiable field values ​​after execution, and reason for verification failure. The reason for verification failure is recorded as a change in the field value corresponding to the unmodifiable field identifier. The low-code platform writes the verification information into the execution record of the online hook code and uses the verification information as input for the exception handling strategy.

[0235] When the execution result conforms to the return value type rules, and the summary of the unmodifiable field value before execution is the same as the summary of the unmodifiable field value after execution, the low-code platform generates the result verification information that has passed the verification. The result verification information includes code identifier, version identifier, hook point type, execution instance identifier, return value type rule verification result, and unmodifiable field value summary verification result. The low-code platform writes the result verification information that has passed the verification into the execution record of the online hook code and allows the low-code platform's main business process to proceed to subsequent saving processing.

[0236] Through this embodiment, the low-code platform can perform return value type rule verification on the execution result of online hook code under the hook point type before data saving, and determine whether the field value of the field corresponding to the unmodifiable field identifier has changed by comparing the unmodifiable field value summary before execution and the unmodifiable field value summary after execution; thereby, it can identify the situation where the data type of the execution result does not conform to the return value type rule, and the situation where the field corresponding to the unmodifiable field identifier has been changed by the online hook code.

[0237] Example 10:

[0238] like Figure 4As shown, in some embodiments, the execution result verification rules also indicate whether external connection resources need to be verified, or whether fields in the execution result need to be verified; the verification of whether external connection resources are released is used to determine whether the external connection resources opened by the online hook code through the restricted interface proxy object have been closed; the field verification in the execution result is used to determine whether the execution result of the online hook code contains the field corresponding to the restricted field identifier.

[0239] When the execution result verification rule indicates that it is necessary to verify whether the external connection resource has been released, the low-code platform reads the execution instance identifier corresponding to the online hook code; the low-code platform queries the resource registration record based on the execution instance identifier to obtain the external connection resource registered with the execution instance identifier; the resource registration record includes the external connection resource identifier, resource type, creation time, release time, and release result; the low-code platform reads the release time and release result corresponding to the external connection resource item by item, and determines whether the external connection resource has been released based on whether the release time exists and whether the release result is complete.

[0240] When there are unreleased external connection resources, the low-code platform generates verification information for unreleased resources. This verification information includes code identifier, version identifier, hook point type, execution instance identifier, external connection resource identifier, resource type, creation time, release status, and reason for verification failure. The reason for verification failure is recorded as "external connection resource not fully released". The low-code platform writes the verification information for unreleased resources into the execution record of the online hook code and uses this information as input for the exception handling strategy.

[0241] When all external connection resources associated with the execution instance identifier have a release time and the release result is complete, the low-code platform generates resource release verification result information. The resource release verification result information includes code identifier, version identifier, hook point type, execution instance identifier, external connection resource identifier, and release result. The low-code platform writes the resource release verification result information into the execution record of the online hook code.

[0242] When the execution result verification rule indicates that fields in the execution result need to be verified, the low-code platform reads the restricted field identifiers in the execution result verification rule; the low-code platform parses the execution result of the online hook code and extracts the field identifiers in the execution result; when the execution result is a structured object, the low-code platform reads the field names in the structured object; when the execution result is a key-value set, the low-code platform reads the key names in the key-value set; when the execution result is text data, the low-code platform extracts the field identifiers according to the field parsing method specified in the execution result verification rule.

[0243] Restricted field identifiers are pre-generated by the low-code platform based on business entity field attributes, field permission configurations, or data security level configurations. Before verifying the fields in the execution result, the low-code platform reads the business entity field attributes, field permission configurations, and data security level configurations corresponding to the current business entity, and writes the field identifiers that must not be output by online hook code, must not be returned by online hook code, or must not appear in the execution result into the restricted field identifiers.

[0244] The low-code platform compares the field identifiers in the execution result with the restricted field identifiers item by item. When a field identifier in the execution result contains a field corresponding to a restricted field identifier, the low-code platform generates a field validation failure result. The field validation failure result includes the code identifier, version identifier, hook point type, execution instance identifier, restricted field identifier, field identifier in the execution result, and the reason for validation failure. The reason for validation failure is recorded as the execution result containing a field corresponding to a restricted field identifier. The low-code platform writes the field validation failure result to the execution record of the online hook code and uses the field validation failure result as input for the exception handling strategy.

[0245] When the field identifier in the execution result does not contain the field corresponding to the restricted field identifier, the low-code platform generates field validation result verification information. The field validation result verification information includes code identifier, version identifier, hook point type, execution instance identifier, restricted field identifier, and field identifier in the execution result. The low-code platform writes the field validation result verification information into the execution record of the online hook code and allows the low-code platform to continue subsequent processing according to the execution result verification strategy.

[0246] Through this embodiment, the low-code platform can query external connection resources based on the execution instance identifier and determine whether the external connection resources have been released based on the resource registration record; the low-code platform can also verify whether the execution result of the online hook code contains the field corresponding to the restricted field identifier based on the restricted field identifier; thereby enabling the execution result verification rules to handle the risks of external connection resources and execution result content after the execution of the online hook code.

[0247] Example 11:

[0248] like Figure 4As shown, in some embodiments, when the low-code platform invokes the exception tolerance handling strategy, it establishes a tolerance mapping relationship between the hook point type, result verification information type, exception information type, timeout information type, and exception tolerance handling strategy. The tolerance mapping relationship is used to record the exception tolerance handling strategy adopted by different hook point types under different result verification information types, exception information types, or timeout information types. The tolerance mapping record in the tolerance mapping relationship includes a hook point type field, a result verification information type field, an exception information type field, a timeout information type field, and an exception tolerance handling strategy field.

[0249] Specifically, the low-code platform reads the execution instance identifier corresponding to the online hook code and queries the execution record of the online hook code based on the execution instance identifier; when there is result verification information in the execution record, the low-code platform reads the result verification information type in the result verification information; when there is exception information in the execution record, the low-code platform reads the exception information type in the exception information; when there is timeout information in the execution record, the low-code platform reads the timeout information type in the timeout information; the result verification information type, exception information type, and timeout information type are all written by the low-code platform when generating the corresponding information.

[0250] Subsequently, the low-code platform reads the hook point type bound to the online hook code and matches the hook point type, result verification information type, exception information type, or timeout information type with the fault tolerance mapping record in the fault tolerance mapping relationship. When the hook point type field in the fault tolerance mapping record is consistent with the hook point type bound to the online hook code, and the result verification information type field, exception information type field, or timeout information type field in the fault tolerance mapping record is consistent with the corresponding information type in the current execution record, the low-code platform determines the fault tolerance mapping record as a matching fault tolerance mapping record.

[0251] When a corresponding exception handling strategy is matched, the low-code platform reads the exception handling strategy field from the matched exception handling mapping record and determines the field value in the exception handling strategy field as the exception handling strategy corresponding to the current execution instance identifier. The low-code platform determines the processing method of the low-code platform's main business process based on the exception handling strategy. The processing methods of the low-code platform's main business process include stopping the low-code platform's main business process and rolling back business data changes, recording result verification information, exception information or timeout information and keeping the low-code platform's main business process running, not using the execution result of the online hook code and continuing to execute the low-code platform's main business process, and writing an asynchronous retry task and re-executing the online hook code according to the asynchronous retry task.

[0252] When at least two types of information (result verification information, exception information, and timeout information) exist under the same execution instance identifier, the low-code platform first determines the target information type for fault tolerance mapping relationship matching; the low-code platform reads the fault tolerance processing priority order in the exception fault tolerance processing strategy, and determines the target information type from the result verification information type, exception information type, and timeout information type according to the fault tolerance processing priority order; when the exception fault tolerance processing strategy does not configure the fault tolerance processing priority order, the low-code platform determines the target information type in the order of timeout information type, exception information type, and result verification information type; the low-code platform matches the hook point type and target information type with the fault tolerance mapping relationship, and uses the successfully matched fault tolerance mapping record as the fault tolerance mapping record corresponding to the current execution instance identifier.

[0253] When multiple result verification information types exist under the same execution instance identifier, the low-code platform determines the target result verification information type in the following order: field verification failed, immutable field verification failed, return value type verification failed, and resources not released. When multiple exception information types exist under the same execution instance identifier, the low-code platform determines the target exception information type in the following order: interface call rejected, SQL statement blocked, security policy not matched, and runtime exception. After determining the target result verification information type or the target exception information type, the low-code platform then determines the final target information type used for fault tolerance mapping relationship matching according to the aforementioned fault tolerance processing priority order.

[0254] Optionally, when no matching exception handling strategy is found, the low-code platform adopts the default exception handling strategy. The default exception handling strategy is pre-configured by the low-code platform administrator in the security policy configuration. The default exception handling strategy includes a default processing method and a default recording content. The default processing method is used to determine whether the main business process of the low-code platform should be stopped, whether business data changes should be rolled back, whether execution should continue, or whether an asynchronous retry task should be written. The default recording content is used to determine the scope of information that needs to be written to the execution record. When no default exception handling strategy is configured in the security policy configuration, the low-code platform stops the main business process of the low-code platform and records the reason for the failure to match the exception handling strategy.

[0255] After determining the exception handling strategy, the low-code platform writes the execution instance identifier, hook point type, result verification information type, exception information type, timeout information type, matching fault tolerance mapping record, and exception handling strategy into the execution record of the online hook code. The low-code platform then executes the processing method of the low-code platform's main business process according to the exception handling strategy. After processing, the low-code platform writes the processing result into the execution record so that the execution process of the online hook code and the processing process of the low-code platform's main business process can be queried later.

[0256] In this embodiment, when the low-code platform invokes the exception tolerance handling strategy, it not only judges whether there is exception information, but also matches the tolerance mapping relationship by combining the hook point type, result verification information type, exception information type and timeout information type. This enables different hook point types in the same low-code platform main business process to adopt the corresponding low-code platform main business process processing method under different result verification information, exception information or timeout information.

[0257] Example 12:

[0258] like Figure 4 As shown, in some embodiments, the exception handling strategy includes a blocking rollback strategy and a continuing execution strategy. The blocking rollback strategy is used to stop the main business process of the low-code platform and undo the business data changes already generated by the main business process when the result verification information, exception information, or timeout information of the online hook code affects the processing result of the main business process of the low-code platform. The continuing execution strategy is used to record the corresponding information and keep the main business process of the low-code platform running when the result verification information, exception information, or timeout information of the online hook code does not need to interrupt the main business process of the low-code platform.

[0259] When the matched exception handling strategy is a blocking rollback strategy, the low-code platform first stops the subsequent processing of the main business process of the low-code platform; then the low-code platform reads the transaction record corresponding to the main business process of the low-code platform and determines the business data changes that have been generated based on the transaction record; the low-code platform then calls the transaction rollback interface to restore the business data changes generated by the main business process of the low-code platform to the state before the online hook code was executed; the low-code platform writes the execution instance identifier, hook point type, result verification information, exception information or timeout information, rollback object and rollback result into the execution record.

[0260] The rollback target of the blocking rollback strategy is the transactional business data change in the main business process of the low-code platform; the transactional business data change includes the addition, modification and deletion of business data generated in the same transaction record of the main business process of the low-code platform; the transaction rollback interface undoes the transactional business data change according to the transaction record; the transaction rollback interface is not used to undo external system calls, message sending or non-transactional resource changes that have been triggered by online hook code or restricted interface proxy objects.

[0261] When online hook code or restricted interface proxy objects have triggered external system calls, message sending, or non-transactional resource changes, the low-code platform determines whether the external system call, message sending, or non-transactional resource change has been completed based on the execution record. When the external system call, message sending, or non-transactional resource change has been completed, the low-code platform writes the external system call, message sending, or non-transactional resource change into the execution record and sends a processing notification according to the exception notification method in the exception fault tolerance handling strategy, or writes a compensation task according to the compensation task configuration in the exception fault tolerance handling strategy. The compensation task is used for subsequent execution of the correction processing corresponding to the external system call, message sending, or non-transactional resource change.

[0262] When the matched exception handling strategy is a blocking rollback strategy, and the main business process of the low-code platform has not yet undergone business data changes, the low-code platform stops the subsequent processing of the main business process and records the processing result that no business data changes require rollback; when the main business process of the low-code platform has undergone business data changes but the transaction rollback interface returns a rollback failure result, the low-code platform records the reason for the rollback failure and writes the reason for the rollback failure into the execution record; the low-code platform then sends a processing notification to the low-code platform administrator according to the low-code platform's preset exception notification method.

[0263] When the matched exception handling strategy is to continue execution, the low-code platform does not stop the main business process of the low-code platform; the low-code platform reads the result verification information, exception information or timeout information, and writes the result verification information, exception information or timeout information into the execution record; the low-code platform marks the execution result of the online hook code as not blocking the main business process of the low-code platform; the low-code platform then continues to execute subsequent business processing according to the original processing order of the main business process of the low-code platform.

[0264] When the matched exception handling strategy is to continue execution, and the online hook code has already generated an execution result, the low-code platform determines whether the execution result of the online hook code is allowed to be used by the low-code platform's main business process based on the execution result verification strategy. When the execution result verification strategy does not allow the use of the online hook code's execution result, the low-code platform does not use the online hook code's execution result and keeps the low-code platform's main business process running. When the execution result verification strategy allows the use of the online hook code's execution result, the low-code platform writes the online hook code's execution result into the subsequent processing input of the low-code platform's main business process.

[0265] As an optional implementation, the blocking rollback strategy is used for hook point types before data saving, hook point types before data deletion, or interface interception hook point types. The online hook code corresponding to the aforementioned hook point types is triggered before the main business process of the low-code platform completes the critical business action. When the result verification information, exception information, or timeout information indicates that the online hook code does not meet the corresponding security control requirements, the low-code platform stops the main business process of the low-code platform and reverts the business data changes that have been generated through the blocking rollback strategy.

[0266] As another optional implementation, the continue execution strategy is used for hook point types after data saving, hook point types after process completion, or message notification hook point types. The online hook code corresponding to the aforementioned hook point types is triggered after the main business process of the low-code platform completes the key business action, or the execution result of the online hook code is not used as a necessary input for the continued processing of the main business process of the low-code platform. When result verification information, exception information, or timeout information is generated, the low-code platform records the corresponding information through the continue execution strategy and keeps the main business process of the low-code platform running.

[0267] Through this embodiment, when the fault tolerance handling strategy matching result is a blocking rollback strategy, the low-code platform can stop the main business process of the low-code platform and roll back the business data changes generated by the main business process of the low-code platform; the low-code platform can also record result verification information, exception information or timeout information when the fault tolerance handling strategy matching result is a continue execution strategy, and keep the main business process of the low-code platform continuing to execute; thus enabling the low-code platform to distinguish between interruption handling and continuation handling of the main business process of the low-code platform based on the hook point type and information type.

[0268] Example 13:

[0269] like Figure 4 As shown, in some embodiments, the exception handling strategy further includes a degraded execution strategy and an asynchronous retry strategy. The degraded execution strategy is used to exclude the execution result of the online hook code and maintain the execution of the main business process of the low-code platform when the execution result of the online hook code is not a necessary input for the main business process of the low-code platform. The asynchronous retry strategy is used to write the online hook code and execution context data into the asynchronous retry task when the reason for the failure of the online hook code allows re-execution, and then execute the online hook code again through the asynchronous retry task.

[0270] When the matched exception handling strategy is a degradation execution strategy, the low-code platform reads the execution instance identifier corresponding to the online hook code, and queries the execution result, result verification information, exception information, or timeout information of the online hook code based on the execution instance identifier; the low-code platform marks the execution result of the online hook code as not adopted, and deletes the execution result of the online hook code from the processing input of the low-code platform's main business process; the low-code platform then reads the original processing input of the low-code platform's main business process, and continues to execute the low-code platform's main business process according to the original processing input.

[0271] When the matched exception handling strategy is a degraded execution strategy, and there are alternative processing inputs in the main business process of the low-code platform, the low-code platform reads the alternative processing inputs and uses them as the processing inputs for the main business process. The alternative processing inputs are pre-saved by the low-code platform in the business process configuration. When there are no alternative processing inputs in the main business process of the low-code platform, the low-code platform continues to execute the main business process using the processing inputs before the online hook code execution. The low-code platform writes the degraded execution strategy, the excluded execution results, and the processing inputs used by the main business process of the low-code platform into the execution record.

[0272] Before executing the asynchronous retry strategy on the low-code platform, the platform first determines whether the result verification information type, exception information type, or timeout information type belongs to the safe failure type that is not suitable for asynchronous retries. The safe failure types that are not suitable for asynchronous retries are pre-configured by the low-code platform in the exception fault tolerance handling strategy. The safe failure types that are not suitable for asynchronous retries include interface call rejection, SQL statement blocking, return value type validation failure, non-modifiable field validation failure, and field validation failure. When the result verification information type, exception information type, or timeout information type belongs to the safe failure type that is not suitable for asynchronous retries, the low-code platform does not generate an asynchronous retry task and processes the low-code platform's main business process according to the blocking rollback strategy, continuing execution strategy, or degraded execution strategy in the exception fault tolerance handling strategy.

[0273] When the matched exception handling strategy is an asynchronous retry strategy, and the result verification information type, exception information type, or timeout information type does not belong to the safe failure types that are not suitable for asynchronous retries, and there are no unrecoverable external side effects in the execution record, the low-code platform reads the online hook code, hook point type, execution context data used when executing the online hook code, result verification information, exception information, or timeout information; the low-code platform generates an idempotent identifier based on the code identifier, version identifier, hook point type, business primary key in the execution context data, and original execution instance identifier; the low-code platform writes the online hook code, hook point type, execution context data, result verification information, exception information or timeout information, original execution instance identifier, and idempotent identifier into the asynchronous retry task.

[0274] Subsequently, the low-code platform re-executes the online hook code according to the asynchronous retry task. When the asynchronous retry task meets the execution conditions, the low-code platform reads the online hook code, hook point type, and execution context data from the asynchronous retry task. The low-code platform assigns a new execution instance identifier to the online hook code to be executed again, and processes the online hook code again according to the pre-execution security verification policy, runtime access control policy, execution result verification policy, and exception fault tolerance handling policy. The low-code platform writes the new execution instance identifier and the original execution instance identifier together into the retry record of the asynchronous retry task.

[0275] Optionally, the asynchronous retry task includes the number of retries, the retry interval, the retry status, the failure reason, and the execution instance identifier; the number of retries is determined by the maximum number of retries in the asynchronous retry strategy and the number of retries already executed; the retry interval is determined by the retry interval field in the asynchronous retry strategy; the retry status includes pending retry, retrying, retry successful, and retry failed; the failure reason is read from the result verification information, exception information, or timeout information; the execution instance identifier includes the original execution instance identifier and the new execution instance identifier assigned when the online hook code is executed again.

[0276] The asynchronous retry task also includes an idempotent identifier; the idempotent identifier is used to identify the same retry object before the online hook code is executed again in the asynchronous retry task; the idempotent identifier is generated by combining the code identifier, version identifier, hook point type, business primary key in the execution context data, and original execution instance identifier; before writing the asynchronous retry task, the low-code platform queries the existing asynchronous retry task based on the idempotent identifier; when the same idempotent identifier already exists and the retry status is pending retry or retrying, the low-code platform does not write the asynchronous retry task again.

[0277] Before re-executing the online hook code, the low-code platform performs deduplication verification based on the idempotency flag. If the asynchronous retry task corresponding to the same idempotency flag has already retried successfully, the low-code platform will not execute the current asynchronous retry task and will update the retry status of the current asynchronous retry task to retry cancelled. If the asynchronous retry task corresponding to the same idempotency flag has not retried successfully, the low-code platform will execute the online hook code again according to the asynchronous retry task and write the new execution instance flag into the retry record.

[0278] The asynchronous retry strategy also includes a non-rollbackable external side effect exclusion rule. This rule is used to determine whether the online hook code has triggered an external message, network request, or non-transactional write during its original execution. The low-code platform determines whether there is an external message sending completion record, a network request completion record, or a non-transactional write completion record based on the execution record, the restricted interface proxy object call record, and the resource registration record. When there is an external message sending completion record, a network request completion record, or a non-transactional write completion record, the low-code platform does not generate an asynchronous retry task and writes the processing reason to the execution record.

[0279] When generating asynchronous retry tasks, the low-code platform reads the maximum retry count field from the exception handling strategy. The maximum retry count field is pre-configured by the low-code platform based on the hook point type, failure reason, and asynchronous retry strategy. The low-code platform matches the hook point type and failure reason with the asynchronous retry strategy configuration record, reads the maximum retry count field from the matching record, and uses the value of the maximum retry count field as the maximum retry count for the asynchronous retry task. The failure reason is read from the result verification information, exception information, or timeout information.

[0280] When the low-code platform does not read the maximum number of retries field in the asynchronous retry strategy configuration record, it sets the maximum number of retries to 1; when the result verification information type, exception information type, or timeout information type belongs to the safety failure type that is not applicable to asynchronous retries, it sets the maximum number of retries to 0; the maximum number of retries is a non-negative integer; when the maximum number of retries is 0, the low-code platform does not generate an asynchronous retry task or updates the retry status of the asynchronous retry task to retry failure.

[0281] When writing asynchronous retry tasks, the low-code platform writes the maximum number of retries, the number of retries already executed, the retry interval, the retry status, the failure reason, and the execution instance identifier into the asynchronous retry task; the initial value of the number of retries already executed is 0; after each time the online hook code is executed again, the number of retries already executed is incremented by one; the low-code platform determines whether the asynchronous retry task should enter the next pending retry state by comparing the number of retries already executed with the maximum number of retries.

[0282] When the asynchronous retry task successfully executes the online hook code again, the low-code platform updates the retry status of the asynchronous retry task to "retry successful" and writes a new execution instance identifier and execution completion time. When the asynchronous retry task fails to execute the online hook code again, the low-code platform increments the number of retries already executed and checks whether the number of retries already executed has reached the maximum number of retries. If the number of retries already executed has not reached the maximum number of retries, the low-code platform updates the retry status of the asynchronous retry task to "pending retry". If the number of retries already executed has reached the maximum number of retries, the low-code platform updates the retry status of the asynchronous retry task to "retry failed" and writes the reason for the failure.

[0283] Through this embodiment, the low-code platform can exclude the execution results of online hook code when matching the degradation execution strategy, and continue to execute the main business process of the low-code platform according to the original processing input or the alternative processing input. The low-code platform can also exclude security failure types that are not applicable to asynchronous retries when matching the asynchronous retry strategy, and then write the online hook code, hook point type, execution context data, result verification information, exception information or timeout information into the asynchronous retry task, and execute the online hook code again according to the asynchronous retry task. This can prevent online hook code that fails security verification, is rejected by interface call, is blocked by SQL statement, or has non-compliant execution results from re-entering the execution process through asynchronous retries.

[0284] Example 14:

[0285] like Figure 5 As shown, for ease of understanding, the following uses the pre-save hook point type as an example to fully explain the processing procedures in Examples 1 to 13; the pre-save hook point type indicates that the online hook code is triggered before the business data to be saved is written to the database; the low-code platform uses the pre-save hook point type to connect the pre-execution security verification strategy, runtime access control strategy, execution result verification strategy, and exception fault tolerance handling strategy into the same online hook code execution process.

[0286] The low-code platform first obtains online hook codes through the hook code registration interface; the online hook codes are used to perform business validation before the business data to be saved is written to the database; the low-code platform generates code identifiers and version identifiers for the online hook codes, and writes the online hook code, code identifier, version identifier, activation status and binding relationship into the hook code record; the binding relationship record records the hook point type bound to the online hook code before data saving.

[0287] Subsequently, the low-code platform matches the security policy mapping table with the hook point type before saving the data; the low-code platform reads the pre-execution security verification policy field, runtime access control policy field, execution result verification policy field, and exception tolerance handling policy field from the matched policy mapping record; the low-code platform uses the read pre-execution security verification policy, runtime access control policy, execution result verification policy, and exception tolerance handling policy to determine the security policy of this online hook code.

[0288] Next, the low-code platform processes the online hook code according to the pre-execution security verification strategy; the low-code platform converts the online hook code into an abstract syntax tree and matches the abstract syntax tree with the detection patterns in the static code security detection rule set; the low-code platform generates a risk score according to the risk weight corresponding to the successfully matched detection pattern; the low-code platform also restores the encoded escape characters in the online hook code to their original characters to obtain the restored code, converts the restored code into a restored abstract syntax tree, and then generates a restored risk score according to the same static code security detection rule set.

[0289] The low-code platform extracts import statements and restores import statements from the abstract syntax tree and the restored abstract syntax tree, respectively. The low-code platform compares the import statements and restore import statements with the allowed list of import statements. When the risk score is less than the preset risk threshold, the restore risk score is less than the preset risk threshold, and both the import statement and the restore import statement belong to the allowed list of import statements, the low-code platform generates pre-execution verification information that has passed the verification. When any condition is not met, the low-code platform generates pre-execution verification information that has failed the verification and stops executing the online hook code.

[0290] After the pre-execution verification is passed, the low-code platform generates a restricted interface proxy object according to the runtime access control policy. The low-code platform writes the restricted interface proxy object into the execution context data of the online hook code and prohibits the online hook code from directly obtaining the business service instance, data access instance and system configuration instance in the low-code platform's business environment. When the online hook code needs to read the business data to be saved or submit the business verification result, it can only initiate an interface call through the restricted interface proxy object.

[0291] The low-code platform intercepts the SQL statements generated by the online hook code during execution and parses the SQL statements to obtain the operation type and data table identifier. When the operation type is write and the data table identifier belongs to the list of data tables prohibited from being written to, the low-code platform blocks the execution of the SQL statement. When the data table identifier belongs to the list of data tables prohibited from being accessed, the low-code platform blocks the execution of the SQL statement. The low-code platform also assigns an execution instance identifier to the online hook code and registers the external connection resources opened by the online hook code through the restricted interface proxy object with the execution instance identifier.

[0292] The low-code platform monitors the execution duration of online hook code based on the timeout threshold in the runtime access control policy. When the execution duration exceeds the timeout threshold, the low-code platform generates timeout information and writes it to the execution record. When an exception is caught during the execution of the online hook code, the low-code platform generates exception information and writes it to the execution record. The low-code platform uses the timeout information or exception information as input to the exception tolerance handling strategy.

[0293] After the online hook code execution is completed, the low-code platform reads the return value type rules and unmodifiable field identifiers according to the execution result verification strategy; the low-code platform reads the execution result of the online hook code and determines whether the data type of the execution result belongs to the allowed data type recorded in the return value type rules; the low-code platform also reads the field values ​​of the corresponding fields of the unmodifiable field identifiers before and after the online hook code execution, and generates a summary of the unmodifiable field values ​​before execution and a summary of the unmodifiable field values ​​after execution, respectively.

[0294] When the data type of the execution result is not one of the allowed data types recorded in the return value type rules, the low-code platform generates a result verification message indicating that the return value type validation has failed. When the summary of the unmodifiable field value before execution is different from the summary of the unmodifiable field value after execution, the low-code platform generates a result verification message indicating that the unmodifiable field validation has failed. When the data type of the execution result is one of the allowed data types recorded in the return value type rules, and the summary of the unmodifiable field value before execution is the same as the summary of the unmodifiable field value after execution, the low-code platform generates a result verification message indicating that the validation has passed.

[0295] When the result verification information is a result verification information that fails the return value type verification or the result verification information that fails the verification of the unmodifiable field, the low-code platform matches the hook point type and result verification information type with the fault tolerance mapping relationship before saving the data; when an exception or timeout information is generated during the execution of the online hook code, the low-code platform matches the hook point type, exception information type or timeout information type with the fault tolerance mapping relationship before saving the data; the low-code platform reads the matched exception fault tolerance handling strategy.

[0296] When the matched exception handling strategy is a blocking rollback strategy, the low-code platform stops the subsequent saving process of the main business process and reads the transaction record corresponding to the main business process. The low-code platform determines the business data changes that have been generated based on the transaction record and calls the transaction rollback interface to undo the business data changes. The low-code platform writes the execution instance identifier, the hook point type before data saving, the result verification information, the exception information or timeout information, the rollback object, and the rollback result into the execution record.

[0297] Through this embodiment, the low-code platform can incorporate the pre-execution security verification strategy, runtime access control strategy, execution result verification strategy, and exception handling strategy of online hook code into the same execution process under the hook point type before data saving; the low-code platform can complete code risk verification, interface call restriction, data table access restriction, execution result verification, and rollback blocking before the business data to be saved is written to the database; thus, the online hook code corresponding to the hook point type before data saving is controlled by the same security policy before, during, and after execution.

[0298] Example 15:

[0299] Based on the same inventive concept, this application also provides a restricted secure execution system for low-code platform hook code; the restricted secure execution system for low-code platform hook code is used to execute the restricted secure execution method for low-code platform hook code in embodiments 1 to 14; the restricted secure execution system for low-code platform hook code is deployed in a low-code platform or deployed in a secure execution server that is communicatively connected to the low-code platform.

[0300] like Figure 6 As shown, the restricted secure execution system for hook code on a low-code platform includes a hook code acquisition module, a security policy determination module, a pre-execution verification module, a runtime access control module, an execution result verification module, and an exception handling module. The hook code acquisition module is connected to the security policy determination module. The security policy determination module is connected to the pre-execution verification module, the runtime access control module, the execution result verification module, and the exception handling module, respectively. The pre-execution verification module, the runtime access control module, the execution result verification module, and the exception handling module transmit data according to the execution order of the online hook code.

[0301] The hook code acquisition module is used to obtain online hook codes and the hook point types bound to them. It receives online hook codes through an online editing page, a code upload interface, or a hook code registration interface. The module generates a code identifier and a version identifier for each online hook code and writes the online hook code, code identifier, version identifier, activation status, and binding relationship into the hook code record. Finally, the module reads the hook point type field from the binding relationship and determines the value of this field as the hook point type bound to the online hook code.

[0302] The security policy determination module is used to determine the security policy of online hook code based on hook point type. The security policy determination module reads the security policy mapping table and matches the hook point type bound to the online hook code with the hook point type field in the security policy mapping table. The security policy determination module reads the pre-execution security verification policy field, runtime access control policy field, execution result verification policy field, and exception fault tolerance handling policy field from the matched policy mapping record. The security policy determination module determines the reading result as the security policy of the online hook code.

[0303] The pre-execution verification module performs pre-execution verification on online hook code according to the pre-execution security verification strategy. It converts the online hook code into an abstract syntax tree (AST) and matches the AST with detection patterns in the static code security detection rule set. The module generates a risk score based on the risk weight corresponding to the successfully matched detection pattern. It also restores the encoded escape characters in the online hook code to their original characters, obtaining the restored code, and generates a restoration risk score based on the restored code. Finally, the module compares import statements and restored import statements with the list of allowed import statements and generates pre-execution verification information.

[0304] The runtime access control module restricts the interaction between online hook code and the low-code platform business environment according to runtime access control policies, and executes the online hook code. The runtime access control module generates restricted interface proxy objects based on the restricted interface list and writes these objects into the execution context data of the online hook code. The runtime access control module intercepts SQL statements generated by the online hook code and determines whether the SQL statements are allowed to execute based on the data table access control matrix. The runtime access control module assigns execution instance identifiers to the online hook code and registers the external connection resources opened by the online hook code through the restricted interface proxy objects with the execution instance identifiers. The runtime access control module monitors the execution duration of the online hook code based on timeout thresholds and generates exception or timeout information.

[0305] The execution result verification module verifies the execution results of online hook code according to the execution result verification strategy and obtains result verification information. The module reads the execution result verification rules based on the hook point type. It then determines whether the execution results of the online hook code conform to the return value type rules. The module generates a summary of unmodifiable field values ​​before and after execution based on the unmodifiable field identifier, and compares these summaries. Finally, the module verifies whether external connection resources are released based on the execution instance identifier and verifies fields in the execution result based on the restricted field identifier.

[0306] The exception handling module is used to determine the processing method of the main business process of the low-code platform by invoking exception handling strategies based on result verification information, exception information or timeout information during the execution of online hook code; the exception handling module reads the fault tolerance mapping relationship and matches the hook point type, result verification information type, exception information type or timeout information type with the fault tolerance mapping relationship; the exception handling module executes the blocking rollback strategy, the continuing execution strategy, the degraded execution strategy or the asynchronous retry strategy according to the matched exception handling strategy; the exception handling module writes the processing result into the execution record of the online hook code.

[0307] In some embodiments, the hook code acquisition module, security policy determination module, pre-execution verification module, runtime access control module, execution result verification module, and exception handling module are implemented by software programs; the software programs are stored in the memory of the low-code platform server and are executed by the processor of the low-code platform server; in other embodiments, the hook code acquisition module, security policy determination module, pre-execution verification module, runtime access control module, execution result verification module, and exception handling module are implemented by hardware circuits; in still other embodiments, the hook code acquisition module, security policy determination module, pre-execution verification module, runtime access control module, execution result verification module, and exception handling module are implemented by a combination of software programs and hardware circuits.

[0308] The modules in the restricted secure execution system for low-code platform hook code correspond to the steps in the restricted secure execution method for low-code platform hook code. The hook code acquisition module corresponds to step S101, used to acquire online hook code and the hook point type bound to the online hook code. The security policy determination module corresponds to step S102, used to determine the security policy of the online hook code based on the hook point type. The pre-execution verification module corresponds to step S103, used to perform pre-execution verification on the online hook code according to the pre-execution security verification policy. The runtime access control module corresponds to step S104, used for... After the pre-execution verification is passed, the interaction between the online hook code and the low-code platform business environment is restricted according to the runtime access control policy, and the online hook code is executed; the execution result verification module corresponds to step S105, which is used to verify the execution result of the online hook code after the execution is completed, according to the execution result verification policy, and obtain the result verification information; the exception fault tolerance processing module corresponds to step S106, which is used to call the exception fault tolerance processing policy based on the result verification information, exception information or timeout information during the execution of the online hook code, and determine the processing method of the main business process of the low-code platform.

[0309] Through this embodiment, the restricted secure execution system for low-code platform hook code can acquire online hook code and hook point types through the hook code acquisition module, determine the security policy through the security policy determination module, complete pre-execution verification through the pre-execution verification module, restrict the interaction between online hook code and the low-code platform business environment through the runtime access control module, obtain result verification information through the execution result verification module, and determine the processing method of the low-code platform's main business process through the exception fault tolerance handling module. Thus, the restricted secure execution method for low-code platform hook code can be implemented through a modular system.

[0310] It should be noted that the above embodiments can be combined with each other; Embodiment 1 provides the overall flow of the restricted secure execution method of hook code on a low-code platform; Embodiment 2 provides a method for determining the security policy; Embodiments 3 and 4 provide different implementations of the pre-execution security verification policy; Embodiments 5 to 7 provide different implementations of the runtime access control policy; Embodiments 8 to 10 provide different implementations of the execution result verification policy; Embodiments 11 to 13 provide different implementations of the exception fault tolerance handling policy; Embodiment 14 provides a continuous execution example under a specific hook point type; Embodiment 15 provides a restricted secure execution system for hook code on a low-code platform.

[0311] The above description is merely a preferred embodiment of this application, and the scope of protection of this application shall be determined by the scope defined in the claims. Any improvements and modifications made by those skilled in the art without departing from the essence of the technical solution of this application shall fall within the scope of protection of this application. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of this application shall also be considered within the scope of protection of this application.

Claims

1. A method for restricted secure execution of hook code in a low-code platform, characterized in that, include: Retrieve the online hook code and the hook point type bound to the online hook code; The security policy for online hook code is determined based on the hook point type. The security policy includes pre-execution security verification policy, runtime access control policy, execution result verification policy, and exception handling policy. Methods for determining the security policy of online hook code include: Establish a security policy mapping table between hook point types and security policies. The policy mapping records in the security policy mapping table include hook point type field, pre-execution security verification policy field, runtime access control policy field, execution result verification policy field, and exception fault tolerance handling policy field. Match the hook point type bound to the online hook code with the hook point type field; Read the pre-execution security verification policy field, runtime access control policy field, execution result verification policy field, and exception handling policy field from the matched policy mapping record to obtain the security policy; The online hook code is validated before execution according to the pre-execution security verification strategy; After the pre-execution verification passes, the interaction between the online hook code and the low-code platform business environment is restricted according to the runtime access control policy, and the online hook code is executed. After the online hook code finishes execution, the execution result is verified according to the execution result verification strategy to obtain the result verification information; Based on the result verification information, exception information or timeout information during the execution of online hook code, invoke the exception tolerance handling strategy to determine the processing method of the main business process of the low-code platform.

2. The restricted secure execution method for low-code platform hook code according to claim 1, characterized in that, The pre-execution security verification strategy includes a static code security detection rule set, an import statement allowed list, and preset risk thresholds. The static code security detection rule set includes detection modes and risk weights. Methods for performing pre-execution verification based on a pre-execution security verification strategy include: Convert online hook code into an abstract syntax tree; Match the abstract syntax tree with the detection pattern; The risk score is obtained by summing the risk weights corresponding to the successfully matched detection patterns. Extract the import statements from the online hook code and compare them with the list of allowed import statements; When the risk score is less than the preset risk threshold and all imported statements are in the list of allowed imported statements, the pre-execution verification is confirmed to be successful. If the risk score is not less than the preset risk threshold, or if there is an import statement that does not belong to the list of allowed import statements, the pre-execution validation will fail.

3. The restricted secure execution method for low-code platform hook code according to claim 2, characterized in that, Methods for pre-execution verification also include: The encoded escape characters in the online hook code are restored to their original characters to obtain the restored code; Convert the restored code into a restored abstract syntax tree; The abstract syntax tree is restored and matched with the detection patterns, and the risk weights corresponding to the successfully matched detection patterns are accumulated to obtain the restoration risk score. Extract the restore import statements from the restore code and compare the restore import statements with the list of allowed import statements; When the risk score is less than the preset risk threshold, the restored risk score is less than the preset risk threshold, and all imported statements are in the allowed list of imported statements and all restored imported statements are in the allowed list of imported statements, the pre-execution verification is confirmed to be successful. If the restoration risk score is not less than the preset risk threshold, or if there is an import statement that does not belong to the allowed list of import statements, or if there is a restoration import statement that does not belong to the allowed list of import statements, then the pre-execution validation fails.

4. The restricted secure execution method for low-code platform hook code according to claim 1, characterized in that, Runtime access control policies include a list of restricted interfaces; Methods to limit the interaction between online hook code and low-code platform business environments include: Read the list of restricted interfaces based on the hook point type; Generate a restricted interface proxy object that contains only the interfaces in the restricted interface list; Generate the execution context for online hook code; Inject restricted interface proxy objects into the execution context, but do not inject business service instances, data access instances, and system configuration instances from the low-code platform business environment into the execution context; The restricted interface proxy object is used as the sole object for interaction between the online hook code and the low-code platform business environment; Reject interaction requests from entities other than the restricted interface proxy object.

5. A method for restricted secure execution of low-code platform hook code according to claim 4, characterized in that, Runtime access control policies also include a data table access control matrix, which includes a list of data tables that are allowed to be read, a list of data tables that are prohibited from being written to, and a list of data tables that are prohibited from being accessed. When executing online hook code, the SQL statement triggered through the restricted interface proxy object is parsed to obtain the operation type and data table identifier. The operation type includes read and write. When the operation type is read and the table identifier is not in the list of allowed read tables, or when the operation type is write and the table identifier is in the list of prohibited write tables, or when the table identifier is in the list of prohibited access tables, the execution of the SQL statement is blocked and an exception message is generated.

6. A method for restricted secure execution of hook code on a low-code platform according to claim 5, characterized in that, Runtime access control policies also include timeout thresholds; Methods for executing online hook code also include: Assign execution instance identifiers to online hook code; Associate and register the external connection resources opened by the online hook code through the restricted interface proxy object with the execution instance identifier; Monitor the execution time of online hook code based on timeout thresholds; When the execution time exceeds the timeout threshold, stop the current execution instance of the online hook code and generate timeout information; when an exception is caught during execution, generate exception information.

7. A method for restricted secure execution of hook code on a low-code platform according to claim 6, characterized in that, The execution result verification strategy includes execution result verification rules; Methods for validating the execution results of online hook code include: Establish a verification mapping relationship between hook point types and execution result verification rules; Match the hook point type bound to the online hook code with the validation mapping relationship; Read the matching execution result verification rules; The execution result is verified according to the execution result verification rules to obtain the result verification information.

8. A method for restricted secure execution of low-code platform hook code according to claim 7, characterized in that, Hook point types include hook point types before data saving, and execution result verification rules include return value type rules and unmodifiable field identifiers; When the hook point type bound to the online hook code is the hook point type before data saving, the methods for verifying the execution result include: Determine if the execution result conforms to the return value type rules; Based on the field values ​​of the fields corresponding to the unmodifiable field identifiers, generate summaries of the unmodifiable field values ​​before and after the execution of the online hook code. If the execution result does not conform to the return value type rules, or if the summary of the unmodifiable field value before execution is different from the summary of the unmodifiable field value after execution, a verification result of failure will be generated.

9. A method for restricted secure execution of hook code on a low-code platform according to claim 7, characterized in that, Methods for verifying execution results according to execution result verification rules include: When the execution result verification rule indicates that it is necessary to verify whether the external connection resources have been released, the registered external connection resources are queried based on the execution instance identifier, and it is determined whether the external connection resources have been released. If there are unreleased external connection resources, generate verification information indicating that the resources have not been released. When the execution result verification rule indicates that the fields in the execution result need to be verified, the restricted field identifier recorded in the execution result verification rule is read, and it is determined whether the execution result contains the field corresponding to the restricted field identifier; When the execution result contains a field corresponding to a restricted field identifier, a field validation result is generated indicating that the field validation failed.

10. A method for restricted secure execution of hook code on a low-code platform according to claim 7, characterized in that, Methods for invoking exception handling strategies include: Establish a fault tolerance mapping relationship between hook point type, result verification information type, exception information type, timeout information type and exception fault tolerance handling strategy; Determine the result verification information type corresponding to the generated result verification information, the exception information type corresponding to the generated exception information, and the timeout information type corresponding to the generated timeout information; The existing result verification information types, exception information types, and timeout information types are summarized into a failure type set; Match the hook point type and failure type set with the fault tolerance mapping relationship; Read the matching exception handling strategy to determine how to handle the main business process of the low-code platform.

11. A method for restricted secure execution of low-code platform hook code according to claim 10, characterized in that, Fault tolerance strategies include blocking and rollback strategies and continuing execution strategies; When the matched exception handling strategy is a blocking rollback strategy, stop the main business process of the low-code platform and roll back the business data changes that have been generated by the main business process of the low-code platform. When the matched exception handling strategy is to continue execution, record the result verification information, exception information or timeout information, and keep the main business process of the low-code platform running.

12. A method for restricted secure execution of low-code platform hook code according to claim 10, characterized in that, The fault tolerance handling strategy includes the degradation execution strategy and the asynchronous retry strategy. The fault tolerance mapping relationship also records the set of safe failure types that are not applicable to asynchronous retries. When the matched exception handling strategy is a degraded execution strategy, the execution result of the online hook code is not adopted, and the main business process of the low-code platform continues to be executed. When the matched exception handling strategy is an asynchronous retry strategy, read the set of safe failure types that are not applicable to asynchronous retries recorded in the fault tolerance mapping relationship; When the set of failure types does not intersect with the set of safe failure types that are not applicable to asynchronous retries, the online hook code, hook point type, execution context data used when executing the online hook code, result verification information, exception information or timeout information are written into the asynchronous retry task, and the online hook code is executed again according to the asynchronous retry task; When the set of failure types intersects with the set of safe failure types that are not applicable to asynchronous retries, no asynchronous retry task is written, and the blocking rollback strategy, continuing execution strategy, or degraded execution strategy that matches the set of failure types in the fault tolerance mapping relationship is read.

13. A restricted secure execution system for hook code on a low-code platform, characterized in that, A method for implementing restricted secure execution of low-code platform hook code according to any one of claims 1-12, comprising: The hook code retrieval module is used to retrieve online hook codes and the hook point types bound to those online hook codes. The security policy determination module is used to determine the security policy of online hook code based on the hook point type. The security policy includes pre-execution security verification policy, runtime access control policy, execution result verification policy, and exception handling policy. The pre-execution verification module is used to perform pre-execution verification on online hook code according to the pre-execution security verification strategy; The runtime access control module is used to restrict the interaction between the online hook code and the low-code platform business environment according to the runtime access control policy after the pre-execution verification is passed, and then execute the online hook code. The execution result verification module is used to verify the execution result of the online hook code after the online hook code has been executed, according to the execution result verification strategy, and obtain the result verification information. The exception handling module is used to determine the processing method of the main business process of the low-code platform by invoking exception handling strategies based on result verification information, exception information or timeout information during the execution of online hook code.

Images