An interpretive script pre-execution verification method, device, medium and program product

Abstract

The application provides an interpreted script pre-execution verification method, device, medium and program product. The method comprises: obtaining an interpreted script to be verified and parsing to generate an abstract syntax tree; before performing traversal interpretation execution on the abstract syntax tree, identifying script access objects based on the abstract syntax tree to form an access object set to be checked, comparing the access object set to be checked with a preset access object white list, and determining abnormal access objects; configuring a verification executor as an interpretation execution subject of the abstract syntax tree, pointing an execution flow of the abstract syntax tree to the verification executor, and then performing traversal interpretation execution on the abstract syntax tree; in the traversal interpretation execution process, using an overlay execution rule for syntax nodes in the abstract syntax tree, so that multiple execution paths are executed, the verification execution of remaining syntax nodes and execution paths is not interrupted when an exception occurs, and a pre-execution verification result of the script is generated. The application improves the automation degree and efficiency of the verification execution process.

Description

An interpreted script pre-execution verification method, device, medium, and program product Technical Field

[0001] This application relates to the field of computer technology, and in particular to an interpreted script pre-execution verification method, device, medium, and program product. Background Technology

[0002] As internet businesses continue to iterate, in scenarios such as target user screening for marketing campaigns and dynamic decision analysis, to adapt to the frequent adjustments of business rules, rule engines combined with dynamic scripts are typically used to describe and execute business logic. As a middleware technology that supports the parsing and execution of business rules, a rule engine can express business rules in a "condition-action" structure. The engine parses and executes the corresponding logic, thereby decoupling business rules from program code and improving the dynamic configuration capability of business logic.

[0003] To enable on-demand configuration and dynamic updates of business rules, existing business systems typically express and execute business logic through scripts. These scripts mostly employ interpreted execution, with the engine parsing and dynamically calling them line by line during runtime, allowing for logic adjustments without compilation. Currently, there are two main methods for generating business rule scripts: first, business personnel select options from preset filter templates or configuration forms to generate logical expressions; second, developers manually write interpreted scripts based on business requirements, which are then verified through testing processes before deployment.

[0004] However, because rule scripts rely on an interpreted execution mechanism, complete branch coverage verification cannot be performed before saving or deploying the script. This is especially true in scripts containing complex conditional statements or multi-branch structures, where the interpreter only executes the branch relevant to the current input condition during a single execution, leaving other branches untriggered. This results in potential runtime anomalies (such as missing methods, mismatched parameter numbers or types, or incorrect identifier references) not being detected in advance. Furthermore, business systems typically have numerous callable variables and methods, and existing script mechanisms often lack fine-grained access control. Business users may reference unauthorized variables or method interfaces when writing scripts, posing security risks.

[0005] Therefore, how to effectively verify script logic and avoid runtime anomalies before script submission, and how to control the access scope of resources that the script can call, have become technical problems that need to be solved by existing technologies. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this application provides an interpreted script pre-execution verification method, device, medium, and program product, which at least solves the problem that interpreted scripts cannot effectively verify all execution paths during the save or submit phase, and cannot identify illegal access behavior and hide runtime anomalies in advance.

[0007] To achieve the above objectives and other advantages, some embodiments of this application provide the following aspects:

[0008] In a first aspect, some embodiments of this application provide an interpreted script pre-execution verification method, including:

[0009] Obtain the interpreted script to be verified, and parse the interpreted script to generate an abstract syntax tree;

[0010] Before performing a traversal interpretation and execution of the abstract syntax tree, script access objects are identified based on the abstract syntax tree to form a set of access objects to be verified, and the set of access objects is compared with a preset access object whitelist to determine abnormal access objects.

[0011] Configure the verification executor as the main body for interpreting and executing the abstract syntax tree, direct the execution flow of the abstract syntax tree to the verification executor, and have the verification executor perform traversal interpretation and execution of the abstract syntax tree;

[0012] During the traversal interpretation and execution process, a coverage execution rule is applied to at least one type of syntax node in the abstract syntax tree so that multiple execution paths corresponding to the syntax node are executed. When an exception occurs during execution, the traversal interpretation and execution is not interrupted by the exception, and the remaining syntax nodes and execution paths are verified and executed to complete the full path execution verification of the interpreted script.

[0013] Based on the comparison results of the access object whitelist and the execution results output during the traversal interpretation execution process, the verification results of the interpreted script in the pre-execution verification stage are generated.

[0014] Secondly, some embodiments of this application also provide an electronic device, the electronic device comprising:

[0015] One or more processors; and a memory storing computer program instructions that, when executed, cause the processors to perform the interpreted script pre-execution verification method as described above.

[0016] Thirdly, some embodiments of this application also provide a computer-readable storage medium having a computer program and / or instructions stored thereon, wherein the computer program and / or instructions, when executed by a processor, implement the interpreted script pre-execution verification method as described above.

[0017] Fourthly, some embodiments of this application also provide a computer program product, including a computer program and / or instructions, which, when executed by a processor, implement the interpreted script pre-execution verification method as described above.

[0018] Compared with existing technologies, the solution provided in this application generates an abstract syntax tree by parsing the script to be verified, enabling a structured expression of script execution semantics. This facilitates access object identification and execution path analysis based on syntax nodes. By comparing the access object with a preset whitelist before traversal interpretation and execution, illegal access behavior can be identified before the script enters the traversal interpretation and execution process, reducing the risk of runtime anomalies due to unauthorized access and preventing scripts with permission issues from entering the subsequent execution verification process, thus improving the security and controllability of the script verification process. By configuring a verification executor to replace the default interpretation and execution process of the script engine and performing traversal interpretation and execution of the abstract syntax tree, each branch path in the script is executed without relying on specific test data. Combined with an execution mechanism that does not interrupt exceptions, deep runtime errors can be exposed in the pre-execution stage, including exceptions such as type mismatches, missing methods, or incorrect parameters. This allows potential script errors to be identified before deployment, thereby improving the security and reliability of script releases. Therefore, compared to relying on manual development and testing processes to deploy scripts or building rule logic through customized pages, this application can complete access behavior verification and deep semantic verification during the script saving or submission stage, reducing dependence on specific test data and operating environment, improving the automation and efficiency of the verification execution process, thereby supporting rapid adjustment of business rules and enabling non-professionals to independently complete script configuration and deployment. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other implementation methods can be obtained based on these drawings without creative effort.

[0020] Figure 1 is a flowchart illustrating one of the methods for interpreting script pre-execution verification provided in this application.

[0021] Figure 2 is a second schematic flowchart of an interpreted script pre-execution verification method provided in an embodiment of this application;

[0022] Figure 3 is a flowchart illustrating the script access object whitelist verification method provided in an embodiment of this application;

[0023] Figure 4 is a schematic diagram of the class relationship and execution replacement between the native execution system of the interpreted script engine and the verification execution rewriting system provided in the embodiments of this application;

[0024] Figure 5 is a schematic diagram of the rewriting of the verification execution logic of key syntax nodes in the abstract syntax tree provided in the embodiments of this application;

[0025] Figure 6 is a schematic diagram of the structure of the electronic device provided in an embodiment of this application. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0027] Some embodiments of this application relate to an interpreted script pre-execution verification method. Referring to Figures 1 and 2, the method may include the following steps:

[0028] Step S1: Obtain the interpreted script to be verified, and parse the interpreted script to generate an abstract syntax tree.

[0029] Specifically, the interpreted script to be verified is obtained from the script configuration module, the rule management system, or an external input interface. Interpreted scripts are a type of script that uses an interpreted execution mechanism. Their content is parsed and executed line by line by the script engine during runtime, without needing to be pre-compiled into an independent executable program. They are typically used to describe business rule logic containing conditional judgments, logical operations, and control structures, and are characterized by flexible syntax, low configuration costs, and ease of dynamic adjustment. Interpreted scripts can be configured and generated by business personnel or dynamically generated by the system according to preset rules; their specific source is not a limitation of this embodiment. In some embodiments, the interpreted script adopts an expression script form based on an expression language. It parses and executes expressions containing logical judgments, arithmetic operations, and variable references or method calls to achieve dynamic calculation of business rules. For example, it can be written based on expression languages ​​such as JEXL, MVEL, and SpEL.

[0030] After obtaining the interpreted script, the script execution middleware (such as the JEXL script engine) in the runtime environment performs syntax parsing. The parsing process includes lexical analysis and syntax analysis of the script content. Lexical analysis breaks down the script text into syntactic units such as variable identifiers, constants, and operators. Syntactic analysis combines these syntactic units according to their logical relationships based on grammatical rules, thereby constructing an abstract syntax tree to represent the script's semantic structure. During the construction of the abstract syntax tree, formatting information unrelated to the script's semantics is stripped away, retaining only the syntactic structure and hierarchical relationships relevant to the script's execution logic, thus expressing the script's logical structure in a structured data format. To avoid impacting the existing parsing process and execution logic of the script parsing engine, this embodiment does not obtain syntactic structure information by modifying the parsing engine's source code or inserting intrusive parsing logic. Instead, it accesses the syntactic data objects generated during the parsing process through reflection after parsing is complete. Starting with the root node in the syntax data object, the lower-level syntax nodes are recursively traversed according to the relationships between nodes. The syntax nodes and their relationships obtained during the traversal are organized into an abstract syntax tree structure. Alternatively, a graph structure or other data structures that represent multi-level semantic relationships can be used to fully represent the syntax hierarchy and composition relationships of the interpreted script.

[0031] In one example, an interpreted script can contain compound conditional expressions formed by combining multiple conditional statements using logical operators. For instance, the script might contain the following logical statement: "user.consume > 1000 && user.vip". After parsing the interpreted script, the resulting abstract syntax tree has a root node representing a logical AND operation, indicating a logical relationship where multiple conditions must be satisfied simultaneously. Under this root node are multiple child nodes: one is a comparison expression node, representing the comparison between the variable "user.consume" and the threshold "1000", and the other is a variable expression node, representing the judgment of the Boolean condition variable "user.vip". In this way, the multiple conditional statements connected by logical operators in the original script text are parsed and mapped into multiple syntax nodes with a clear hierarchical relationship. It should be understood that the above logical statements do not constitute a complete interpreted script, but rather logical sub-expressions within the interpreted script, typically existing as part of conditional statement nodes, branch control nodes, or rule clauses.

[0032] The abstract syntax tree generated in the above manner serves as the core carrier of the semantics of the interpreted script, providing a unified data structure foundation for subsequent traversal interpretation and execution based on the abstract syntax tree, as well as multi-execution path coverage verification.

[0033] Step S2: Before performing traversal interpretation and execution on the abstract syntax tree, identify script access objects based on the abstract syntax tree, form a set of access objects to be verified, and compare the set of access objects with a preset whitelist of access objects to determine abnormal access objects.

[0034] As an optional embodiment, in step S2, identifying script access objects based on the abstract syntax tree to form a set of access objects to be verified specifically includes:

[0035] Step S201: Based on the abstract syntax tree, traverse the set of syntax nodes containing multi-level syntax nodes, and filter out the syntax nodes related to the semantics of script accessing objects. The syntax nodes include: syntax nodes used to represent variable reference semantics, syntax nodes used to represent method call semantics, and syntax nodes used to represent object property access or member access semantics.

[0036] Specifically, referring to Figure 3, a systematic traversal process is performed on the set of syntax nodes containing multi-level syntax nodes based on the abstract syntax tree. The traversal starts with the root node in the abstract syntax tree and visits each lower-level syntax node sequentially according to the hierarchical relationship between nodes. The traversal method can employ depth-first traversal or breadth-first traversal to ensure complete coverage of syntax nodes at each level of the syntax structure. When traversing each syntax node, the node type information is first read to determine its basic semantic role in the syntax structure. Simultaneously, combined with the node's position in the abstract syntax tree and the type information of its parent and child nodes, the functional role of the syntax node in the script syntax structure is determined. When the semantic role of a syntax node indicates that it may carry variable reference semantics or method call semantics, the syntax node is selected as a syntax node related to the semantics of the script access object.

[0037] The syntax nodes related to script access object semantics include, but are not limited to, the following categories: One category is syntax nodes representing variable reference semantics, which describe the access behavior of reading, participating in calculations, or participating in expression evaluation of variable identifiers in the script; another category is syntax nodes representing method call semantics, which describe the calling behavior of business methods or functions in the script, and their node attributes typically include the method name, parameter list, or call expression structure; and a third category is syntax nodes representing object attribute or member access semantics, which describe the access behavior of object attributes, object fields, or object members in the script. Syntax nodes used only to describe flow control, logical combination, or expression organization structure are not considered for this step.

[0038] In one implementation based on the JEXL expression engine, the aforementioned syntax nodes can correspond to the Identifier node, IdentifierAccess node, and Var node in the abstract syntax tree, respectively. The Identifier node represents the referencing semantics of variable identifiers, the IdentifierAccess node represents the method call semantics in the script, and the Var node represents the declaration or referencing semantics of local variables. During traversal, by reading the node attribute information (including identifier name, access path, call structure, etc.) carried by each syntax node and combining it with its contextual relationship in the syntax structure, the nodes are uniformly filtered to obtain a subset of syntax nodes that are directly related to script access behavior at the syntax structure level.

[0039] Step S202: Based on the positional relationship, conditional constraint relationship, and scope association relationship of the syntax nodes in the script control structure, determine whether the syntax nodes have execution reachability during script execution, and thereby determine the valid syntax nodes related to the script execution semantics.

[0040] In this embodiment, based on the subset of access semantically related syntax nodes obtained in step S201, it is further determined whether each syntax node has execution reachability during the actual script execution process, thereby identifying the valid syntax nodes related to script execution semantics. Execution reachability is used to characterize whether the syntax node can be actually executed or triggered under at least one legal script execution path.

[0041] Specifically, the execution path constraints of syntax nodes are first analyzed from the perspective of control structure. The type of control structure in which the syntax node resides is identified, including conditional branching structures, loop structures, or multi-branch selection structures, and the specific branch position of the syntax node within the corresponding control structure is resolved. If the syntax node is in a conditional branching structure, the conditional expression corresponding to that branch is recorded; if the syntax node is in a loop structure, the loop entry condition and the constraints of the loop control variables are recorded to determine whether the syntax node has a path to be scheduled for execution.

[0042] Secondly, the reachability conditions of syntax nodes are analyzed from the perspective of conditional constraints. Based on the conditional expressions that the syntax nodes depend on, semantic abstraction is performed on the conditional expressions to determine whether there is a possibility that the conditional expressions are true at the logical level. For branch paths that are always false, mutually exclusive, or unsatisfiable, the syntax nodes in the corresponding branches are determined to be execution-unreachable nodes; for branch paths that may be true under at least one combination of conditions, the corresponding syntax nodes are determined to be execution-reachable nodes.

[0043] Then, the validity of the syntax node is analyzed from the perspective of scope association. Combining the scope hierarchy information of the syntax node, it is determined whether the variables or methods involved in the syntax node are resolvable within the current scope. If the variables or methods referenced by the syntax node are not visible or are obscured within their respective scopes, the syntax node is determined to be semantically unreachable; otherwise, the syntax node is retained as a candidate execution node.

[0044] After the above multi-dimensional analysis, a syntax node is determined to be a valid syntax node related to script execution semantics only if it simultaneously satisfies control structure constraints, condition constraints, and scope constraints under at least one legal execution path; otherwise, it is excluded from the set of valid syntax nodes. This effectively eliminates access semantic nodes that exist only in the syntax structure but are unlikely to be triggered during actual execution, thus ensuring that the analysis only targets script access behaviors that may actually occur.

[0045] Step S203: Based on the node type and node attribute information corresponding to the valid syntax node, determine the corresponding script access object and form a set of access objects to be verified.

[0046] As an optional embodiment, step S203 specifically includes:

[0047] Step S2031: Based on the node type and node attribute information of the valid syntax nodes, perform semantic mapping processing on the valid syntax nodes and parse them into variable access objects and method call objects.

[0048] Specifically, for valid syntax nodes whose node type represents variable reference semantics or object attribute access / member access semantics, they are mapped to variable access objects; for valid syntax nodes whose node type represents method call semantics, they are mapped to method call objects. During the mapping process, the system combines the node attribute information carried by the syntax node for judgment. The node attribute information includes at least identifier text, access expression structure, or call structure identifier, which is used to determine the access object category corresponding to the syntax node.

[0049] In one implementation, when the valid syntax node is an Identifier node or a Var node, it is parsed into a variable access object, and the variable identification information corresponding to the variable access object is recorded. When the valid syntax node is an IdentifierAccess node, it is parsed into a method call object, and the method identification information corresponding to the method call object is recorded. Through the above semantic mapping process, the node information at the syntax structure level is uniformly converted into an object representation at the script access object level.

[0050] Step S2032: Based on the variable access object and the method call object, extract the corresponding identifier name, access path and call parameter information respectively, and perform aggregation processing on the variable access object and the method call object according to the preset data structure to generate the variable call list and the method call list.

[0051] Specifically, for variable access objects, the variable identifier name and its access path information in the script are extracted from the corresponding valid syntax node; for method call objects, the method name, call path, and parameter structure information related to the call are extracted from the corresponding valid syntax node. Parameter structure information may include the number of parameters, parameter positional relationships, or parameter type descriptions, used to characterize the call features of the method call in the script.

[0052] After extraction, the extracted attribute information is structured and encapsulated, unit by unit for variable access objects and method call objects. Multiple variable access objects are aggregated according to variable identifiers to form a variable call list; multiple method call objects are aggregated according to method identifiers to form a method call list. The variable call list and method call list are used to uniformly represent the variable access behavior and method call behavior involved in the execution semantic constraints of the business script.

[0053] Step S2033: Based on the variable call list and the method call list, form a set of access objects to be verified.

[0054] In one implementation, after generating variable call lists and method call lists respectively, a unified data aggregation process is performed based on the access behaviors recorded in the two lists. Specifically, variable access objects and method call objects are abstracted into unified access object description units. Each access object description unit includes at least fields such as identifier name, access path, call parameter attributes, and semantic type identifier, used to characterize resource access behaviors that may be triggered during the execution of the interpreted script. Further, a key-value mapping can be established between multiple access object description units according to the identifier name and access path, and deduplication processing can be performed to merge the same access behaviors corresponding to different syntax nodes into a single access object.

[0055] After aggregation, the access object description units are written into a unified data set structure to form a set of access objects to be verified. The access object set can be stored using a list, mapping table, or other data structures suitable for fast lookup. In this process, only access behaviors that may be triggered during script execution are modeled; the script execution results are not evaluated or derived, and the process does not rely on input data during runtime. This decouples the construction of the access object set from the runtime environment, providing a unified and complete data foundation for whitelist access permission verification and abnormal call detection.

[0056] Through steps S201-S203, this embodiment establishes an access object identification mechanism for pre-execution verification at the abstract syntax structure level, enabling the systematic and structured extraction and verification of potential access behaviors in the script before entering traversal interpretation and execution. By filtering the access semantics of multi-level syntax nodes in the syntax structure representation, only syntax nodes carrying variable references, object attribute access, or method call semantics are retained, avoiding misidentification of syntax nodes used only for flow control or expression organization as access nodes. Furthermore, the execution reachability of syntax nodes is judged by combining the position of control structure, conditional constraint relationships, and scope association relationships, effectively eliminating access semantic nodes that cannot be triggered under any legal execution path. On this basis, the effective syntax nodes that can be executed are uniformly mapped to variable access objects and method call objects, generating variable call lists and method call lists that reflect the true execution semantics of the business script. Through the above processing, potential access behaviors in the script can be accurately located and expressed in a structured form, reducing the risk of misjudgment caused by static syntax analysis and improving the accuracy and reliability of script access object identification.

[0057] As an optional embodiment, before comparing the set of access objects with a preset access object whitelist to determine abnormal access objects, the method further includes: obtaining the access object whitelist, which includes a set of script access objects allowed in interpreted scripts, specifically including:

[0058] Step A101: Obtain whitelist configuration information that describes script access control rules. The whitelist configuration information includes multiple access control rules. Each access control rule defines the scope of script access objects that are allowed to be accessed under at least one script business type, business scenario, or execution context.

[0059] In one implementation, business variables and methods accessible to business personnel are pre-maintained in a structured configuration to form a whitelist configuration. The whitelist configuration includes multiple access control rules, each defining the scope of script access objects that an interpreted script is allowed to access under at least one script business type, business scenario, or execution context. Each access control rule includes at least: rule application condition information and rule-allowed access object definition information. The rule application condition information describes the prerequisites for the access control rule to take effect, which may include, but is not limited to, script type identifiers, business module identifiers, business scenario identifiers, execution environment identifiers, or other contextual characteristics that can characterize the script's usage scenario. The rule-allowed access object definition information describes that the access control rule takes effect when the script characteristics of the business script meet the corresponding rule application conditions, thereby limiting the set of script access objects that the interpreted script is allowed to access. The set of script access objects may include variable access objects, method call objects, or a combination of both.

[0060] In one alternative implementation, the whitelist configuration information can be maintained in a structured configuration format, such as storing it in the form of a rule table, configuration file, or configuration data object. Each access control rule records its applicable conditions and the corresponding scope of access objects in a structured field, thereby supporting independent configuration, dynamic adjustment, and on-demand loading of access control rules.

[0061] Step A102: Based on the script feature information of the interpreted script, dynamically select access control rules that meet the applicable conditions from multiple access control rules in the whitelist configuration information, and generate an access object whitelist that is compatible with the interpreted script based on the access control rules.

[0062] In this embodiment, the script characteristic information of the interpreted script is first obtained. The script characteristic information is used to characterize the script's usage background and applicable environment, and may include, but is not limited to: the script type identifier to which the interpreted script belongs, the business module identifier, the business scenario identifier, the execution environment identifier, and context parameter information related to script execution. The above-mentioned script characteristic information can be provided by the business system during the script submission, configuration, or invocation stage, or automatically determined by the script management module based on the script's configuration location, invocation entry point, or runtime parameters.

[0063] After obtaining the script characteristic information of the business script, rule matching processing is performed on the whitelist configuration information obtained in step A101. In one implementation, when the script characteristic information of the interpreted script meets the rule application conditions of a certain access control rule, the access control rule is marked as a valid rule; when the rule application conditions are not met, the corresponding access control rule is ignored. Through the above matching process, a set of access control rules that match the applicable scenario of the current business script is selected from multiple access control rules.

[0064] After determining the applicable set of access control rules, the allowed script access objects are summarized and integrated based on the allowed access object information defined in the access control rule set. This involves extracting the corresponding variable access object definition information and method call object definition information from each access control rule, merging access objects with duplicate definitions, and generating an access object whitelist that fits the current interpreted script. The access object whitelist is used to clearly define the scope of script access objects allowed in the current interpreted script execution scenario.

[0065] Through steps A101-A102, during the script verification phase, access control rules matching the current applicable scenario of the interpreted script are dynamically selected from multiple pre-configured access control rules based on the script characteristic information of the interpreted script. A whitelist of access objects adapted to the interpreted script is then generated accordingly. Compared to the static, unified whitelist configuration method used in existing technologies, this embodiment can dynamically generate a whitelist of access objects adapted to the business script based on the actual characteristics and usage scenarios of the interpreted script, without relying on a static, fixed whitelist configuration. This improves the flexibility and scenario adaptability of script access control.

[0066] As an optional embodiment, in step S2, the set of access objects is compared with a preset whitelist of access objects to determine abnormal access objects.

[0067] Specifically, the identified set of access objects can include variable access objects and method call objects. Each script access object contains at least one identifier to uniquely identify the access object, such as identifier name, access path, method name, parameter characteristics, or object type information. The generated access object whitelist contains the range of script access objects that the current interpreted script is allowed to access under the corresponding business scenario or execution context. Each whitelist item also includes at least one identifier describing the allowed access object and may further include rule attributes such as access level, invocation method, parameter constraints, or usage conditions.

[0068] During the comparison process, each script access object in the access object set is matched against a whitelist entry in the access object whitelist. Matching can be based at least on the consistency of object identification information, such as comparing variable names, method names, or whether the access path meets the access rules defined in the access object whitelist. In scenarios with hierarchical access or nested objects, a comprehensive match can be performed by combining access path prefixes, object type relationships, or call context information. Script access objects that exist in the access object set but cannot be matched against a whitelist entry are identified as abnormal access objects. Abnormal access objects indicate that the access behavior is outside the permitted scope of the current business script, potentially corresponding to unauthorized variable access, illegal method calls, or object usage that does not conform to scenario constraints.

[0069] In one implementation, the identified abnormal access objects can be aggregated and a list of abnormal access objects can be generated. This list of abnormal access objects can be used for subsequent script verification result output, problem prompts, risk interception, or audit records.

[0070] In one implementation, after identifying an abnormal access object, the object description information corresponding to the abnormal access object is retrieved from an object description information database based on the object identifier information of the abnormal access object. The object description information database is used to centrally store description information related to script access objects, so as to achieve unified management and mapping between script access object identifiers and their business semantics, functional uses, and usage constraints.

[0071] The object description information repository can be pre-maintained by developers or system maintenance personnel during the system configuration phase and stored in a structured data format. To facilitate the categorization and management of different types of script access objects, corresponding object description information tables can be created within the object description information repository based on the type of the script access object. For example, for variable access objects, a variable object description information table is created in the object description information repository to store descriptive information related to business variables accessible by scripts. As shown in Table 1, in the example of the variable object description information table, each record corresponds to a business variable accessible by scripts, and its fields include at least: variable name field, variable type field, variable business meaning field, and variable usage constraint field. Through this variable object description information table, the data type, business meaning, and allowed usage conditions of each business variable can be clearly described.

[0072] Table 1 Example of variable object description

[0073]

[0074] For method call objects, a method object description information table is established in the object description information repository to store descriptive information related to business methods that can be called by scripts. As shown in Table 2, each record in the method object description information table corresponds to a business method, and its fields include at least: method name field, method function description field, method input parameter definition field, method return value description field, and method call constraints or usage example field, so as to realize the semantic interpretation and usage restriction description of method call behavior in scripts.

[0075] Table 2 Example of method object description

[0076]

[0077] During the business script saving or verification phase, when an abnormal access object is detected in the script, the object description information in the object description information library is further used to generate verification prompt information corresponding to the abnormal access object. The verification prompt information not only indicates the reason for the abnormality that the script access object is not covered by the access object whitelist, but also, in combination with the business semantic description and usage constraints in the object description information, provides business personnel with an understandable explanation of the abnormality and suggestions for correction.

[0078] By combining the object description information database with the script verification process, even if business personnel cause access anomalies in the script due to negligence or insufficient understanding of the business objects during the script writing process, the system can automatically identify the anomaly during the script saving or verification stage, and output clear and understandable prompts to business personnel based on the object description information, thereby helping business personnel to quickly locate the problem and complete the correction.

[0079] Step S3: Configure the verification executor as the main body for interpreting and executing the abstract syntax tree, direct the execution flow of the abstract syntax tree to the verification executor, and let the verification executor perform traversal interpretation and execution of the abstract syntax tree.

[0080] As an optional embodiment, step S3 specifically includes:

[0081] Step S301: Generate a script engine instance for verification execution by rewriting the native builder of the interpreted script engine.

[0082] An interpreted script engine is a software component used to parse and execute interpreted scripts. It typically includes functional units such as a script parsing module, an abstract syntax tree (AST) storage module, and an interpretation and execution control module. During script runtime, it parses and executes each line of the script content in real-time. In actual operation, the interpreted script engine usually creates and initializes its instance through its native builder. The native builder receives engine parameter configurations and generates a default script engine instance. This instance uses a native interpretation and execution mechanism to execute the AST during script execution. In existing technologies, script engine instances created by the native builder typically only support single-path interpretation and execution based on runtime conditions, which is insufficient to meet the requirements of multi-path coverage verification during script verification. Therefore, this embodiment does not directly intervene in the native engine during script execution. Instead, it rewrites the native builder of the interpreted script engine (e.g., the JEXL script engine) from the source of the script engine instance creation.

[0083] Rewriting the native builder refers to adjusting the build logic used to generate script engine instances while maintaining compatibility with the original builder interface and engine configuration parameters. Instead of generating a script engine instance using the native interpreted execution mechanism during the build phase, it generates a script engine instance for verification execution. This script engine instance still structurally possesses the basic capabilities of script parsing and abstract syntax tree generation, but its internal execution scheduling logic is configured to support verification execution mode. This allows the script execution flow to enter a comprehensive, multi-path verification execution mechanism during subsequent script parsing, object creation, and interpreted execution.

[0084] As an optional embodiment, step S301 specifically includes:

[0085] Step S3011: Provide a validation builder that inherits from the native builder of the interpreted script engine;

[0086] Step S3012: In the verification builder, override the build method used to create the script engine instance;

[0087] Step S3013: The construction method generates a script engine instance for verification execution while keeping the original engine configuration parameters valid. The script engine instance is configured to use a different verification execution mechanism than the interpreted script engine when parsing and interpreting the script.

[0088] In this embodiment, the interpreted script engine is implemented using a layered architecture. Its base layer consists of native classes of the script engine, used to perform basic functions such as script parsing and interpretation. For example, in the JEXL engine architecture, as shown in Figure 4, the native classes include the builder class JexlBuilder, the core script engine class JexlEngine, the script interface or abstract definition class JexlScript, the script implementation class Script, and the interpreter class Interpreter. These native classes together constitute the default implementation system of the interpreted script engine, used to generate an abstract syntax tree from the script text and interpret and execute the abstract syntax tree according to the established execution rules of interpreted languages.

[0089] Building upon the aforementioned native implementation framework, this embodiment further introduces core classes for business logic rewriting. These classes enable full-path script execution verification in the verification execution mode without altering the overall architecture of the native engine. Specifically, the core classes for business logic rewriting include KooBossJexlBuilder, KooBossJexlEngine, KooBossJexlScript, and KooBossJexlInterpreter. These classes inherit from their respective native classes and rewrite the key construction and interpretation execution logic.

[0090] The KooBossJexlBuilder class inherits from the JexlBuilder class and is used to replace the native script engine instance with a custom verification execution script engine instance during the script engine instance creation phase. The KooBossJexlEngine class inherits from the JexlEngine class and is used to introduce object generation logic related to verification execution during the creation of script objects and verification executors. The KooBossJexlScript class inherits from the JexlScript class and is used to guide the script execution request to the verification executor when the script is triggered for execution. The KooBossJexlInterpreter class inherits from the Interpreter class and is used to rewrite the default interpretation and execution semantics of various syntax nodes in the abstract syntax tree to support traversal and multi-path verification execution.

[0091] As an example implementation, to introduce a verification execution mechanism without intruding on the internal execution flow of the native script engine, a custom `KooBossJexlBuilder` class inherits from the `JexlBuilder` class, and the underlying `create` method used to create script engine instances in the native builder is overridden. This overriding ensures that when creating an execution engine instance, the builder no longer generates a native `JexlEngine` script engine instance, but instead generates a custom `KooBossJexlEngine` class to create the script engine instance. This ensures that the creation result of the script engine instance consistently points to the custom verification execution script engine, completing the switching of the interpretation and execution entry point during the engine construction phase. This allows the script object generation and interpretation / execution process to be uniformly scheduled by the custom script engine instance.

[0092] Through the processing in steps S3011 to S3013, a verification builder that inherits from the native builder is provided. The construction method for creating script engine instances is overridden in the builder. While keeping the original engine configuration parameters (including syntax rules, custom functions, and execution context) valid, a script engine instance for verification execution is generated. This eliminates the need to introduce intrusive execution control logic during the script execution phase, achieving a smooth switch from business execution to verification execution in the interpreted script execution mode. It has good scalability and compatibility.

[0093] Step S302: During the script parsing and execution object creation phases, the script engine instance generates a script object for storing the abstract syntax tree and a verification executor for verifying execution, respectively, to replace the native script object and native interpreter in the interpreted script engine.

[0094] After generating the script engine instance for verification execution in step S301, the script engine instance enters the script object and verification executor creation phase. In this phase, the script engine instance typically needs to generate a script object based on the parsing results, which carries the abstract syntax tree corresponding to the script and related execution information. At the same time, it generates a verification executor, which is used to interpret and execute the abstract syntax tree when the script is triggered for execution.

[0095] In this embodiment, the script engine instance does not use the native object creation mechanism of the interpreted script engine. Instead, it introduces object generation logic related to verification and execution during the object creation phase. This causes the generated script object and verification executor to no longer use the native execution semantics, but are configured to support the verification execution mode. The script object generated in this way is used to store and manage the abstract syntax tree and establishes an association with the verification executor during the script execution phase. The verification executor is used to undertake the task of interpreting and executing the abstract syntax tree in subsequent execution processes, replacing the native interpreter to complete the script interpretation and execution.

[0096] As an optional embodiment, step S302 specifically includes:

[0097] Step S3021: Rewrite the creation logic of the native script object through the script engine instance, so that the generated script object can retain the original script semantic representation ability while having the execution scheduling ability to transfer the script execution request to the verification executor.

[0098] Step S3022: Rewrite the creation logic of the native interpreter through the script engine instance to generate a verification executor associated with the script object. The verification executor is used to replace the native interpreter during the script execution phase and perform traversal interpretation and execution of the abstract syntax tree.

[0099] Specifically, by redirecting the execution entry point of the script object, the script execution request is handed over to the verification executor associated with the script object for processing, so that the verification executor can perform traversal interpretation and execution of the abstract syntax tree.

[0100] Specifically, in the JEXL engine system, the JexlEngine class, as the core engine class of the native script engine, is used to complete the parsing, compilation, and execution environment management of expressions. It is the core hub connecting the builder configuration and the script execution process.

[0101] It's important to note that the JexlScript class, as a compiled script expression object within the JEXL engine, stores the abstract syntax tree (AST) generated after the interpreted script is parsed, along with core logic information related to script execution. It also supports repeated execution of the script within the same execution environment. In the native implementation, when a JexlScript object is triggered for execution, its execution flow is typically handled by the native Interpreter class, which interprets and executes the AST. The Interpreter class is the interpreter class in the JEXL engine, used to traverse the AST, interpret and execute the script logic node by node, and handle variable resolution, method calls, and output of computation results during execution. Under runtime constraints, the Interpreter class typically selects a single execution path based on conditional judgments to complete a single script execution.

[0102] In this embodiment, in order to introduce a full-path verification execution mechanism during the script execution phase, a custom KooBossJexlEngine class is used to inherit the JexlEngine class, and its key methods related to script execution are overridden, so that the script engine instance no longer uses the native execution system during the object creation phase.

[0103] In one example implementation, the KooBossJexlEngine class overrides the script creation method to generate a custom KooBossJexlScript object instead of a native JexlScript object. This custom object carries the abstract syntax tree and semantic information related to script execution. The KooBossJexlScript class inherits from the JexlScript class to gain the ability to store the abstract syntax tree and script semantic information. Furthermore, it overrides the script execution entry method, so that when the script object is triggered, it no longer calls the native Interpreter class for interpretation and execution, but instead delegates the script execution request to its associated verification executor.

[0104] Meanwhile, the KooBossJexlEngine class also rewrites the creation logic of the native interpreter, generating a custom KooBossJexlInterpreter class instance during the script object creation phase to replace the native Interpreter class. The KooBossJexlInterpreter class instance acts as a verification executor, used in verification execution mode to perform traversal interpretation and execution of the abstract syntax tree, and rewrites the default interpretation and execution semantics of various syntax nodes in the abstract syntax tree, thereby supporting verification execution functions such as multi-branch path coverage, execution without interruption due to exceptions, and execution trajectory recording.

[0105] Through steps S3021-S3022, this embodiment structurally restructures the execution scheduling relationship of the interpreted script during the script object and verification executor generation stage. This creates a stable and associated execution mapping relationship between the script object and the verification executor, allowing the verification executor to directly take over the interpretation and execution process of the abstract syntax tree when the interpreted script is triggered, without going through the execution path selection mechanism of the native interpreter. This avoids interference from the native execution semantics on the verification execution process. This restructured design embeds the verification execution capability cohesively into the execution flow of the script object itself, which helps improve the determinism of execution path control and the stability of the verification execution process.

[0106] Step S303: When the script object is triggered to execute, the interpretation and execution request of the abstract syntax tree is redirected to the verification executor, so that the verification executor can perform traversal interpretation and execution of the abstract syntax tree.

[0107] Specifically, the execution entry method of the script object is overridden so that when the script object receives an execution trigger instruction, it no longer sends the abstract syntax tree (API) interpretation and execution request to the native interpreter. Instead, it forwards the interpretation and execution request to the verification executor associated with the script object. The verification executor, as the main body for interpreting and executing the API, takes over the script's interpretation and execution process.

[0108] After the verification executor takes over the interpretation and execution process, it performs a traversal interpretation and execution of the abstract syntax tree. Unlike the native interpretation executor, which selects a single execution path based on runtime conditions, the verification executor traverses each syntax node in the abstract syntax tree according to preset verification and execution rules, and performs overriding execution on the corresponding execution path based on the syntax node type, thereby realizing the verification and execution of multiple potential execution paths in the script.

[0109] Through the aforementioned execution entry redirection mechanism, the script object can switch the script execution from the native interpreted execution mode to the verification execution mode without changing the original semantic structure of the script. This ensures that when the script is triggered for execution, the verification executor can complete the traversal and multi-path interpretation and execution of the abstract syntax tree, providing the execution foundation for subsequent full-path execution verification.

[0110] Through steps S301-S303, this embodiment, without disrupting the original overall architecture and configuration system of the interpreted script engine, collaboratively reconstructs the construction logic of the script engine instance, the creation logic of script objects and verification executors, and the script execution entry point. This ensures that the interpretation and execution flow of the abstract syntax tree is stably directed to the verification execution system during the engine instance creation stage. By rewriting the engine instance creation method at the builder layer, execution ambiguity caused by the coexistence of native execution paths and verification execution paths is avoided from the source. Furthermore, a stable execution association is established between the script object and the verification executor during the object creation stage. When the script is triggered for execution, the verification executor uniformly takes over the interpretation and execution process through execution entry point redirection. This embeds the verification execution mechanism cohesively into the object lifecycle and execution flow of the script engine, providing a deterministic and controllable execution foundation for multi-path abstract syntax tree traversal execution, which is beneficial for improving the stability and reliability of the full-path verification of interpreted scripts.

[0111] Step S4: During the traversal interpretation and execution process, a coverage execution rule is applied to at least one type of syntax node in the abstract syntax tree so that multiple execution paths corresponding to the syntax node are executed. If an exception occurs during the execution process, the traversal interpretation and execution will not be interrupted by the exception, and the remaining syntax nodes and execution paths will continue to be verified and executed to complete the full path execution verification of the interpreted script.

[0112] To ensure that traversal-style interpreted execution can cover multiple execution paths formed by branch judgments, logical short-circuiting, loop iterations, and exception propagation, this embodiment, before step S4, first rewrites the default interpreted execution semantics of at least one type of key syntax nodes in the abstract syntax tree by the verification executor. This execution semantic rewriting mechanism is not a local adjustment to a single syntax node, but rather a unified adjustment of the interpreted execution rules for key syntax nodes in the abstract syntax tree. This allows the verification executor, during traversal-style interpreted execution, to no longer be limited by the runtime behavior rules inherent in the native interpreted execution semantics, such as "conditional path selection, early return due to logical short-circuiting, and interruption of propagation upon exception triggering." Instead, it implements differentiated execution control for different types of syntax nodes according to a preset coverage verification strategy, thereby completing traversal-style interpreted execution with the goal of execution path coverage and execution trajectory recording. Based on the above execution semantic rewriting mechanism, Figure 3 shows a schematic diagram of the verification execution logic rewriting of key syntax nodes in the abstract syntax tree, illustrating the coverage execution control method adopted for different types of syntax nodes in the verification execution mode.

[0113] Specifically, for branch control syntax nodes (the "if node behavior rewriting" shown in Figure 5), the verification executor performs an overriding rewrite of its interpretation and execution rules: when traversing to a branch control node, it does not select a single branch to execute based on the runtime condition judgment result, but instead triggers the execution of multiple branch logics of that branch control node one by one. In specific implementation, the verification executor can extract the branch set into a sequence of branches to be executed, and execute "the branch with the condition being true, the branch with the condition being false, and the optional else-if chain branch" in a preset order, and write the execution start identifier, branch identifier, execution result, and exception status of each branch in the global execution context respectively; when the condition evaluation itself is abnormal (such as missing variables or type mismatch causing the condition expression to fail to evaluate), the verification executor does not use the exception as the termination condition of the branch node, but records the condition evaluation exception and continues to execute the remaining branch logic to ensure the continuity of branch path coverage. In this way, the effects of "forcing the execution of all branches instead of only executing branches that meet the conditions", "recording the execution process and result of each branch", and "continuing to execute the code block even if the condition judgment is wrong" are achieved.

[0114] For logical operation syntax nodes (“Logical Operator Processing (AND / OR)” shown in Figure 5), the verification executor cancels the short-circuit evaluation rule and performs a complete evaluation and recording of each operand. Taking the logical AND node (e.g., ASTAndNode) as an example, in the native semantics, a short-circuit return will occur when any operand is false; in this embodiment, when the verification executor traverses to the logical AND node, it evaluates both the left and right operands (or multiple operand sequences) in operand order, and writes the evaluation result of each operand, as well as the variable references, method calls, and exception information involved in the evaluation process, into the execution track. For logical OR nodes (such as ASTOrNode), the short-circuit behavior of "returning early if any operand is true" is also canceled. Instead, all operands are evaluated and recorded to avoid certain branches or method call paths not being triggered for a long time due to short-circuiting. When the logical operation node itself has uncertain evaluation or abnormal return value, the verification executor records the abnormal state in the global execution context and returns the preset verification result to maintain the traversal to continue, thereby achieving the purpose of "recording the values ​​and expressions of the left and right operands in detail".

[0115] For loop control syntax nodes (“Loop Statement Processing” shown in Figure 5), the verification executor records loop start and end information and iteration status during the loop execution phase, and continues subsequent iterations even if an exception occurs during partial iteration execution. Taking the for-each loop as an example, when the verification executor enters the loop node, it writes a loop start event in the global execution context and records the summary information of the loop set (e.g., whether the set is empty, the set length, and the set element type identifier). During iteration, it writes the iteration number, iteration variable binding status, and iteration body execution result for each iteration. When an exception occurs during the execution of an iteration body, the verification executor catches the exception and records the exception type and trigger position. Instead of throwing the exception upwards to interrupt the loop node, it continues to execute subsequent iterations and writes a loop end event at the end of the loop, thus achieving the continuity requirement that “partial iteration exceptions do not affect subsequent iteration coverage verification.”

[0116] For method call syntax nodes (“Method Call Processing” shown in Figure 5), the verification executor parses and records the method call object and method information during the interpretation execution phase, and performs catch and degradation processing on preset business exceptions to avoid interrupting the traversal interpretation execution. Specifically, when traversing to a method call node, the verification executor parses the call target (object identifier or class identifier), method identifier, and parameter list information, and writes the above information as a method execution event into the global execution context; then, it performs wrapper exception handling for method call execution: if a general runtime exception occurs, the exception is recorded and marked as “caught”, allowing the traversal to continue; if a preset business exception is triggered (such as EvalRaiseException, an exception type used for business interruption), it is treated as a “business interruption signal” and processed specifically, that is, only the exception information, trigger location, and corresponding business interruption semantic identifier are recorded, without using it as a termination condition for interpretation execution, so as to ensure that the verification execution process continues to advance and covers subsequent syntax nodes and paths.

[0117] For decision-oriented or return-value-sensitive syntax nodes (as shown in Figure 5, "Rewriting the behavior of the empty() function"), the validation executor returns a preset validation result and records the exception information when an exception or uncertain execution result occurs, in order to avoid the undecidable state of such nodes blocking subsequent path coverage. Taking the empty() decision function as an example, the validation executor can rewrite the default behavior of this function node: when its input value parsing fails, context variables are missing, or evaluation is abnormal, the exception is not thrown upwards, but the exception is recorded and a preset validation return value is returned (e.g., returning TRUE or returning a neutral value for continued coverage), while marking the return as a "validation degradation return" in the execution trajectory; and the variable names or access paths related to empty() can be extracted and written to the execution log context, so as to locate potential variable null value risks or type risks in the script later, thereby achieving the trajectory enhancement purpose of "extracting variables and recording them to the execution log context".

[0118] After completing the default interpretation and execution semantic rewriting, the process proceeds to step S4: the verification executor performs traversal interpretation and execution on the abstract syntax tree, and applies covering execution rules to at least one type of syntax node during the traversal to ensure that multiple execution paths corresponding to the syntax node are executed. During the traversal, the verification executor triggers interpretation and execution node by node according to the node access order of the abstract syntax tree. When encountering branch control nodes, logical operation nodes, loop control nodes, method call nodes, and decision nodes, the corresponding covering execution rules are invoked to achieve multi-path coverage. Simultaneously, exceptions generated during script execution are captured and recorded. Exception information is written to the global execution context in the form of node-level events without triggering an interruption to the traversal interpretation and execution process, thus continuing to verify and execute the remaining syntax nodes and execution paths. Through the above mechanism, this embodiment can continuously trigger and record hidden paths caused by condition judgments, logical short circuits, loop iterations, and business interruption exceptions within a single verification execution cycle, enabling the script to complete path verification with higher coverage before being put into business operation.

[0119] As an optional embodiment, the process of performing full-path verification on the interpreted script also includes:

[0120] Construct a global execution state container for aggregating execution state data generated during the traversal interpretation execution process;

[0121] Execution events generated by different syntax nodes during the traversal interpretation execution process will be written into the global execution state container in a unified data structure. The execution events include at least one of the following: syntax node identifier, branch selection identifier, execution order identifier, or exception state identifier.

[0122] By performing correlation analysis on the execution events aggregated in the global execution state container, execution trajectory data is generated to characterize the coverage of each execution path during the verification execution of the interpreted script.

[0123] Specifically, before the verification executor performs traversal interpretation and execution of the abstract syntax tree, a global execution state container is first constructed. The global execution state container is used to continuously and effectively aggregate various execution state data generated during the traversal interpretation and execution process within a single verification execution cycle. It can be implemented in the form of an in-memory data structure, a context object, or a state set, and is used to uniformly carry the execution event information generated by different syntax nodes during the execution process.

[0124] During the traversal-style interpretation and execution process, the verification executor generates corresponding execution events for the execution behavior of each syntax node in the abstract syntax tree when interpreting and executing them. These events are then written into the global execution state container using a unified data structure. Execution events describe the execution status of syntax nodes during the verification and execution process, and include at least one or more of the following information: syntax node identifier, used to uniquely identify the currently executed syntax node and its position in the abstract syntax tree; branch selection identifier, used to indicate the branch path corresponding to the branch control type syntax node during the overlay execution process; execution order identifier, used to reflect the execution sequence of syntax nodes during the traversal-style interpretation and execution process; and exception status identifier, used to indicate whether an exception occurred during the execution of the syntax node and the exception type information. Through this method, execution events generated by different types of syntax nodes during the traversal-style interpretation and execution process are continuously written into the global execution state container, thus forming an execution state set reflecting the entire script execution process.

[0125] After the traversal-style interpreted execution is completed, correlation analysis is performed on the execution events aggregated in the global execution state container. Correlation analysis can perform path-level association and combination of execution events based on syntax node identifiers, branch selection identifiers, and execution order identifiers, thereby generating execution trajectory data that characterizes the coverage of each execution path during the verification execution of the interpreted script. Execution trajectory data reflects whether each logical branch, loop iteration, and exception path in the script has been covered and can be used for subsequent verification result output, exception localization, or coverage integrity assessment.

[0126] By introducing the aforementioned global execution state container and execution trajectory generation mechanism, this embodiment can structurally record and analyze the multi-execution path coverage of interpreted scripts without relying on specific input conditions or manual test cases, providing reliable data support for the full-path execution verification of interpreted scripts.

[0127] It should be noted that the global execution state container can be maintained as a set of states or a state mapping structure in the global execution context, and its specific implementation does not constitute a limitation on the scope of protection of this application.

[0128] Step S5: Based on the comparison results of the access object whitelist and the execution results output during the traversal interpretation execution process, generate the verification results of the interpreted script in the pre-execution verification stage.

[0129] In one implementation, after completing the whitelist comparison of access objects and the traversal interpretation execution, access object comparison results and execution status results are obtained respectively. The access object comparison results are used to indicate whether the script access objects are within the access range allowed by the preset access object whitelist; the execution status results are used to record the execution status of each syntax node during the traversal interpretation execution process and the exceptions that occur during execution, including exception type, exception location, and corresponding execution path information.

[0130] The two types of verification results are aggregated, associating the semantic location and path information of the abnormal access objects and execution exceptions to form structured verification feedback information. If there are access objects in the access object set that are not covered by the whitelist, a prompt indicating unauthorized access is generated; if a runtime exception occurs during traversal interpretation and execution, exception information indicating the cause of the execution exception is generated, and an execution log can be further generated to record path coverage and execution trajectory information. In one example, the verification results may include prompt information, abnormal access object information, runtime exception information, and execution path logs, which are used to guide users to modify the script during the script saving or submission stage.

[0131] In summary, the interpreted script pre-execution verification method provided in this application generates an abstract syntax tree by parsing the script to be verified, enabling a structured expression of script execution semantics. This facilitates access object identification and execution path analysis based on syntax nodes. By comparing access objects with a preset whitelist before traversal interpreted execution, illegal access behaviors can be identified in advance before entering the traversal interpreted execution process, reducing the risk of runtime anomalies due to unauthorized access and preventing scripts with permission issues from entering the subsequent execution verification process, thus improving the security and controllability of the script verification process. By configuring a verification executor to replace the default interpreted execution process of the script engine and performing traversal interpreted execution on the abstract syntax tree, each branch path in the script is executed without relying on specific test data. Combined with an execution mechanism that does not interrupt exceptions, deep runtime errors can be exposed in the pre-execution stage, including exceptions such as type mismatches, non-existent methods, or incorrect parameters. This allows potential script errors to be identified before deployment, thereby improving the security and reliability of script releases. Therefore, compared to relying on manual development and testing processes to deploy scripts or building rule logic through customized pages, this application can complete access behavior verification and deep semantic verification during the script saving or submission stage, reducing dependence on specific test data and operating environment, improving the automation and efficiency of the verification execution process, thereby supporting rapid adjustment of business rules and enabling non-professionals to independently complete script configuration and deployment.

[0132] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this application. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this application.

[0133] Furthermore, some embodiments of this application also provide an electronic device. The electronic device includes: one or more processors; and a memory storing computer program instructions, which, when executed, cause the processor to perform an interpreted script pre-execution verification method as provided in any one or more of the above embodiments. Figure 6 discloses an exemplary structural diagram of the electronic device. The electronic device includes: one or more processors 1101, a memory 1102, and interfaces for connecting the various components, including high-speed interfaces and low-speed interfaces. The various components are interconnected using different buses and can be mounted on a common motherboard or otherwise installed as needed. The processor can process instructions executed within the electronic device, including instructions stored in or on the memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface).

[0134] The electronic device may further include an input device 1103 and an output device 1104. The processor 1101, memory 1102, input device 1103 and output device 1104 may be connected by a bus or other means, as shown in Figure 6, which illustrates a connection via a bus.

[0135] In this embodiment, a computer-readable medium stores a computer program / instruction, which, when executed by a processor, implements an interpreted script pre-execution verification method provided in any one or more of the above embodiments. This computer-readable medium may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more computer-readable instructions.

[0136] The memory 1102 can serve as a non-transitory computer-readable storage medium, used to store non-transitory software programs, non-transitory computer-executable programs, and modules. The processor 1101 executes various functional applications and data processing of the server by running the non-transitory software programs, instructions, and modules stored in the memory 1102, thereby implementing the program instructions / modules corresponding to the methods provided in any one or more of the embodiments described above in this application.

[0137] The computer program product provided in this application includes one or more computer programs / instructions. When executed by a processor, these computer programs / instructions generate, in whole or in part, the processes or functions described in this application. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means.

[0138] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0139] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily made by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims, and the above embodiments should be regarded as exemplary and non-limiting.

Claims

1. A method for pre-execution verification of interpreted scripts, characterized in that, include: Obtain the interpreted script to be verified, and parse the interpreted script to generate an abstract syntax tree; Before performing a traversal interpretation and execution of the abstract syntax tree, script access objects are identified based on the abstract syntax tree to form a set of access objects to be verified, and the set of access objects is compared with a preset access object whitelist to determine abnormal access objects. The configuration verifier acts as the interpreter of the abstract syntax tree, directing the execution flow of the abstract syntax tree to the verifier. The verifier then performs a traversal interpretation and execution of the abstract syntax tree. This includes: the native classes of the interpreted script engine, such as the builder class JexlBuilder, the core script engine class JexlEngine, the script interface or abstract definition class JexlScript, the script implementation class Script, and the interpreter class Interpreter; and core classes that inherit from the corresponding native classes without changing the overall architecture of the native engine and generate business logic rewrites, such as KooBossJexlBuild. The class `der` consists of the classes `KooBossJexlEngine`, `KooBossJexlScript`, and `KooBossJexlInterpreter`. The `KooBossJexlBuilder` class inherits from the `JexlBuilder` class and overrides the construction method used to create the script engine instance in the native builder. This allows the native script engine instance to be replaced with a verification execution script engine instance during the script engine instance creation phase. The `KooBossJexlEngine` class inherits from the `JexlEngine` class and is used by the script engine instance during the script parsing and execution object creation phases. Instead of generating script objects for storing the abstract syntax tree and verification executors for verifying execution, we replace the native script objects and native interpreters in the interpreted script engine. The `KooBossJexlScript` class, inheriting from the `JexlScript` class, directs script execution requests to the verification executor when a script object is triggered. The `KooBossJexlInterpreter` class, inheriting from the `Interpreter` class, rewrites the default interpretation and execution semantics of various syntax nodes in the abstract syntax tree. An instance of the `KooBossJexlInterpreter` class serves as the verification executor, used for verification... In the verification execution mode, the abstract syntax tree is traversed and interpreted. Before the step of the verification executor traversing and interpreting the abstract syntax tree, the method further includes: the verification executor rewriting the default interpretation and execution semantics of at least one type of syntax node in the abstract syntax tree. By uniformly adjusting the interpretation and execution rules of the syntax nodes in the abstract syntax tree, the verification executor is no longer limited by the runtime behavior rules inherent in the original interpretation and execution semantics, such as conditional one-way path execution, logical short-circuit early return, and exception triggering interruption propagation. Instead, it completes the traversal interpretation and execution with the goal of execution path coverage and execution trajectory recording.During the traversal-style interpreted execution process, a coverage-style execution rule is applied to at least one type of syntax node in the abstract syntax tree, ensuring that multiple execution paths corresponding to the syntax node are executed. If an exception occurs during execution, the traversal-style interpreted execution is not interrupted by the exception and continues to verify and execute the remaining syntax nodes and execution paths, thus completing the full-path execution verification of the interpreted script. Based on the comparison results of the access object whitelist and the execution results output during the traversal-style interpreted execution, the verification results of the interpreted script in the pre-execution verification stage are generated.

2. The method for pre-execution verification of interpreted scripts according to claim 1, characterized in that, The step of identifying script access objects based on the abstract syntax tree and forming a set of access objects to be verified includes: traversing a set of syntax nodes containing multi-level syntax nodes based on the abstract syntax tree, filtering out syntax nodes related to the semantics of script access objects, wherein the syntax nodes include: syntax nodes for representing variable reference semantics, syntax nodes for representing method call semantics, and syntax nodes for representing object attribute access or member access semantics; determining whether the syntax nodes have execution reachability during script execution based on their positional relationship, conditional constraint relationship, and scope association relationship in the script control structure, and thereby determining valid syntax nodes related to script execution semantics; and determining the corresponding script access objects based on the node type and node attribute information corresponding to the valid syntax nodes, and forming a set of access objects to be verified.

3. The method for pre-execution verification of interpreted scripts according to claim 2, characterized in that, The step of determining the corresponding script access object based on the node type and node attribute information of the valid syntax node, and forming a set of access objects to be verified, includes: performing semantic mapping processing on the valid syntax node based on the node type and node attribute information of the valid syntax node, parsing it into variable access objects and method call objects; extracting the corresponding identifier name, access path, and call parameter information based on the variable access object and the method call object, and aggregating the variable access object and the method call object according to a preset data structure to generate a variable call list and a method call list; and forming a set of access objects to be verified based on the variable call list and the method call list.

4. The method for pre-execution verification of interpreted scripts according to claim 1, characterized in that, The construction method generates a script engine instance for verification execution while keeping the original engine configuration parameters valid. The script engine instance is configured to use a different verification execution mechanism than the interpreted script engine when parsing and interpreting the script.

5. The method for pre-execution verification of interpreted scripts according to claim 1, characterized in that, The step of generating a script object for storing the abstract syntax tree and a verification executor for verifying execution during the script parsing and execution object creation phases of the script engine instance, replacing the native script object and native interpreter in the interpreted script engine, includes: rewriting the creation logic of the native script object by the script engine instance, so that the generated script object, while maintaining the original script semantic representation capability, has the execution scheduling capability to transfer script execution requests to the verification executor; rewriting the creation logic of the native interpreter by the script engine instance to generate a verification executor associated with the script object, the verification executor being used to replace the native interpreter during the script execution phase to perform traversal interpretation and execution of the abstract syntax tree; wherein, by redirecting the execution entry point of the script object, the script execution request is handed over to the verification executor associated with the script object for processing, so that the verification executor performs traversal interpretation and execution of the abstract syntax tree.

6. The method for pre-execution verification of interpreted scripts according to claim 1, characterized in that, The verification executor rewrites the default interpretation and execution semantics of at least one type of syntax node in the abstract syntax tree. Specifically, this includes: for branch control syntax nodes, adopting a covering branch execution rule to execute multiple branch logics one by one, instead of selecting a single execution path based on runtime conditions; for logical operation syntax nodes, canceling the short-circuit evaluation rule, performing a complete evaluation of each operand and recording the evaluation process; for loop control syntax nodes, recording loop start and end information and iteration status during loop execution, and continuing subsequent iterations when exceptions occur in some iterations; for method call syntax nodes, recording the method calling object and method information, and capturing and downgrading preset business exceptions to avoid interrupting traversal interpretation and execution; and for decision syntax nodes, returning a preset verification result and recording exception information when exceptions or uncertain execution results occur.

7. An electronic device, characterized in that, The electronic device includes: one or more processors; and a memory storing computer program instructions, which, when executed, cause the processor to perform the interpreted script pre-execution verification method as described in any one of claims 1-6.

8. A computer-readable storage medium having a computer program and / or instructions stored thereon, characterized in that, When the computer program and / or instructions are executed by the processor, they implement the interpreted script pre-execution verification method as described in any one of claims 1-6.

9. A computer program product, comprising a computer program and / or instructions, characterized in that, When the computer program and / or instructions are executed by the processor, they implement the interpreted script pre-execution verification method as described in any one of claims 1-6.

Images