Context information dynamic generation interface check chain method, system, device and medium

Abstract

The present application relates to the technical field of edge computing security, and more particularly to a context information dynamic generation interface verification chain method, system, device and medium. It includes: intercepting an interface request, identifying whether the target method corresponding to the interface request is configured with a security verification annotation; if the security verification annotation is configured, collecting the context information of the edge computing node; parsing the verification type configuration in the security verification annotation to obtain an initial verification node set; dynamically filtering the initial verification node set according to the context information to generate a dynamic verification chain; executing the verification nodes in the dynamic verification chain in the order of core verification nodes taking priority over extended verification nodes, and terminating the execution when any verification node fails. The three-dimensional context of the edge node resource state, network state and request attribute is integrated, the "context-verification node" mapping rule is established, the adaptive adjustment of the verification chain is realized, and the problem of mismatch between the static verification chain and the edge dynamic scene is solved.

Description

Technical Field

[0001] This invention relates to the field of edge computing security technology, and in particular to a method, system, device, and medium for dynamically generating interface verification chains based on context information. Background Technology

[0002] In existing technologies, interface security verification schemes can be mainly divided into the following three categories: The first category is heavyweight frameworks (such as Spring Security and Shiro), which are feature-rich but have a core package size of over 5MB, complex integration and configuration, and high coupling, making them unsuitable for edge computing resource-constrained scenarios. The second category consists of lightweight tools (such as JWT utility classes and simple AOP interceptors), which only support single-dimensional verification (such as token verification), lack multi-dimensional security protection capabilities, and whose verification rules are fixed as static chains, making them unable to adapt to the dynamic resource status of edge nodes. The third type is edge-specific security solutions, which use a static combination of verification nodes and do not dynamically adjust the verification strategy based on the edge node context (CPU / memory / network status). When resources are scarce, this can easily lead to a decrease in verification performance or blockage of core services.

[0003] The above three types of interface security verification schemes also have the following technical shortcomings: Firstly, the verification chain is static: the order and combination of verification nodes are fixed and cannot be adjusted according to the dynamic resource status such as edge node CPU / memory usage and network latency. When resources are scarce, it can easily lead to excessively long verification time, affecting core business. Secondly, insufficient scalability: There is a lack of standardized extension interfaces, custom verification rules require modification of the core code, and the cost of adapting to national cryptographic algorithms, device authentication and other personalized needs is high. Thirdly, poor lightweight adaptation: heavyweight frameworks consume too many resources, while lightweight tools have limited functionality and cannot balance multi-dimensional security protection with low resource consumption. Fourth, lack of context awareness: It does not combine different verification of attributes such as request sensitivity level and device trust level. Highly sensitive requests and ordinary requests are treated with the same strategy, which may lead to security vulnerabilities or waste of resources. Summary of the Invention

[0004] To address the shortcomings of the existing technologies, this invention proposes a method, system, device, and medium for dynamically generating interface verification chains based on context information. Specifically, it involves the design and implementation of an interface security verification framework, applicable to resource-constrained scenarios such as ARM architecture gateways and embedded edge devices, and solves security requirements such as preventing tampering, unauthorized access, and abuse of edge node interfaces.

[0005] The technical solution of the present invention to solve the above-mentioned technical problems is as follows: In a first aspect, the present invention provides a method for dynamically generating interface verification chains based on context information, including: Intercept API requests and identify whether the target method corresponding to the API request is configured with a security verification annotation; If a security verification annotation is configured, the context information of the edge computing node will be collected. Parse the verification type configuration in the security verification annotation to obtain the initial set of verification nodes; The initial set of verification nodes is dynamically filtered based on context information to generate a dynamic verification chain. The verification nodes in the dynamic verification chain are executed in the order that the core verification node takes precedence over the extended verification nodes, and execution is terminated if any verification node fails.

[0006] Based on the above technical solution, the present invention can be further improved as follows.

[0007] Furthermore, the context information includes: resource status information, network status information, and request attribute information. When collection fails, the relevant parameters in the context information are set to preset default values. The resource status information includes CPU utilization and memory utilization. The network status information includes the requested Internet Protocol address and network latency; The request attribute information includes the interface sensitivity level and the device trust level.

[0008] Furthermore, the dynamic filtering of the initial set of verification nodes based on context information includes: When the CPU usage or memory usage exceeds the preset resource threshold, the parameter encryption / decryption verification node is removed from the initial verification node set; When the interface sensitivity level reaches the preset high sensitivity level, all verification nodes in the initial verification node set are retained; When the device's trust level is lower than the preset trust threshold, a new device authentication verification node is added to the initial verification node set.

[0009] Furthermore, the core verification node includes: a signature verification node and a token validity verification node; The extended verification nodes include request frequency limiting nodes and parameter encryption / decryption verification nodes.

[0010] Furthermore, the execution of the verification nodes in the dynamic verification chain includes: The chain of responsibility pattern is adopted, first traversing and executing the core verification nodes, and then traversing and executing the extended verification nodes. A local caching component is used to cache frequently checked data; The high-frequency verification data includes the token expiration time and the request frequency count constructed based on the requested Internet Protocol address and interface name.

[0011] Furthermore, obtaining the initial set of verification nodes includes: parsing the verification type configuration in the security verification annotation and loading the corresponding built-in verification nodes; The configuration file is read through the service provider's interface loading mechanism to obtain the custom extended verification node; Combine the built-in verification nodes and the custom extended verification nodes into an initial set of verification nodes.

[0012] Furthermore, the step of terminating execution when any verification node fails includes: The security check exception thrown when the check fails is captured by the global exception handler; The security verification exception is converted into an exception response result containing standardized error codes and prompt information and returned.

[0013] Secondly, the present invention provides a dynamic context information generation interface verification chain system, including: an access layer, an aspect interception layer, a context acquisition layer, a core service layer, a verification node layer, a support layer, and a configuration layer.

[0014] Thirdly, the present invention provides a computer device, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions. When the computer-executable instructions are executed by the processor, the steps of the method for dynamically generating interface verification chains based on context information are implemented.

[0015] Fourthly, the present invention provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the method for dynamically generating interface verification chains of context information.

[0016] The advantages of this invention over the prior art are as follows: Context-aware dynamic verification chain generation technology: Integrates three dimensions of context—edge node resource status, network status, and request attributes—to establish a "context-verification node" mapping rule, enabling adaptive adjustment of the verification chain and solving the problem of mismatch between static verification chains and dynamic edge scenarios; Lightweight architecture design: core package size ≤500KB, collection time ≤10ms, cache optimization reduces redundant calculations, adapts to the low computing power and low memory characteristics of edge devices, and breaks through the application limitations of existing heavyweight frameworks; SPI standardized extension mechanism: hot-swappable verification nodes are achieved through interface definition and configuration files, supporting personalized requirements such as national cryptographic algorithms and device authentication, without modifying the core code, thus improving the framework's extensibility; Differentiated verification strategy: Dynamically adjust the verification strength based on the sensitivity level and device trust level to balance security protection and resource consumption, and avoid resource waste or security vulnerabilities caused by "one-size-fits-all" verification. Highly robust acquisition mechanism: When acquisition fails, it automatically degrades to the default value, and the verification node supports fault self-healing (timeout nodes are automatically skipped), ensuring stable operation in harsh edge environments. Attached Figure Description

[0017] Figure 1 A flowchart illustrating the method for dynamically generating interface validation chains based on context information; Figure 2 A schematic diagram of the structure of a system that dynamically generates interface verification chains based on context information; Figure 3 This is a schematic diagram of the electronic device of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be described below with reference to the accompanying drawings. In the description of the present invention, unless otherwise stated, " / " indicates that the objects before and after are in an "or" relationship. For example, A / B can represent A or B. The "or" in the present invention is merely a description of the relationship between the related objects, indicating that three relationships can exist. For example, A or B can represent: A alone, A and B simultaneously, and B alone. A and B can be singular or plural. Furthermore, in the description of the present invention, unless otherwise stated, "multiple" refers to two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items.

[0019] Furthermore, to facilitate a clear description of the technical solutions of the embodiments of the present invention, the terms "first" and "second" are used in the embodiments of the present invention to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that the terms "first" and "second" are not necessarily different.

[0020] In this embodiment of the invention, the terms "exemplary" or "for example" are used to indicate that something is being described as an example, illustration, or illustration. Any embodiment or design described as "exemplary" or "for example" in this embodiment of the invention should not be construed as superior or more advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner for ease of understanding.

[0021] Example 1, such as Figure 1 As shown in the figure, an embodiment of the present invention provides a method for dynamically generating interface verification chains based on context information, including: S1: Intercept API requests and identify whether the target method corresponding to the API request is configured with a security verification annotation; S2: If a security verification annotation is configured, then collect the context information of the edge computing node; S3: Parse the verification type configuration in the security verification annotation to obtain the initial set of verification nodes; S4: Dynamically filter the initial set of verification nodes based on context information to generate a dynamic verification chain; S5: Execute the verification nodes in the dynamic verification chain in the order that the core verification node takes precedence over the extended verification node, and terminate the execution if any verification node fails.

[0022] It should be noted that the dynamic link consisting of S1 to S5 addresses the shortcomings of existing technologies: First, for heavyweight frameworks with high coupling, S1 achieves non-intrusive triggering through annotations and aspect interception, eliminating the need for complicated configuration.

[0023] Secondly, for the lack of context awareness, the S2 collects the sensitivity level of the interface and the trust level of the device, and the S4 dynamically adjusts the verification strength accordingly (such as retaining all nodes for high sensitivity), eliminating the security blind spots and resource waste caused by the one-size-fits-all strategy.

[0024] Furthermore, regarding the static verification chain, S2 collects CPU and memory status in real time, and S4 dynamically trims nodes accordingly (such as removing high-energy-consuming encryption and decryption nodes when resources are scarce), completely solving the performance bottleneck of edge devices caused by the static chain.

[0025] Then, to address the insufficient scalability, S3 obtains the initial node set through configuration parsing and the SPI mechanism, supports hot-plugging of custom nodes such as national cryptographic algorithms, and achieves low-cost expansion without modifying the core code.

[0026] Finally, to address the poor adaptability of lightweight tools, S3 constructs a multi-dimensional node pool to compensate for the limited functionality of lightweight tools; together with S5, it executes in core priority order and fails quickly, ensuring that even on low-computing-power devices, the bottom line of security can be maintained even if only core nodes are executed, perfectly balancing multi-dimensional protection and low resource consumption.

[0027] Example 2, a second embodiment of the present invention, provides a method for dynamically generating interface verification chains based on context information, including: It should be noted that this application embodiment utilizes an interface request access—AOP interception—context collection—annotation parsing—node filtering—verification chain execution—business logic execution / abnormal response. The core logic for dynamically filtering nodes is explained, along with the judgment conditions for each branch (resource utilization threshold, sensitivity level, trust level), covering both normal and abnormal scenarios.

[0028] It should be noted that the specific implementation of S1 in this application embodiment is as follows; In edge computing scenarios, when a device / client initiates an interface request (such as a RESTful API call), the request enters the framework's access layer, which is the starting point of the entire security verification process. It is compatible with lightweight communication protocols (such as HTTP / HTTPS) of edge nodes, requiring no additional protocol adaptation or modification.

[0029] Spring AOP around advice intercepts all API requests, acting as a "trigger switch" for security checks, ensuring decoupling of check logic from business logic (non-intrusive design). It also identifies whether the method corresponding to the request is annotated with `@ApiSecurity`, thus routing the process accordingly.

[0030] The core decision for process diversion is to allow interfaces without annotations to pass directly, avoiding meaningless validation that consumes edge node resources; interfaces with annotations enter the validation process.

[0031] It should be noted that the specific implementation of S2 in this application embodiment is as follows; Furthermore, the core operating status and request attributes of edge nodes are collected to provide decision-making basis for the "dynamic verification chain" and adapt to the characteristics of limited edge computing resources.

[0032] It should be noted that the context information includes: resource status information, network status information, and request attribute information. When the collection fails, the relevant parameters in the context information will be set to preset default values ​​to avoid process interruption. The resource status information includes CPU utilization and memory utilization. The network status information includes the requested Internet Protocol address and network latency; The request attribute information includes the interface sensitivity level and the device trust level.

[0033] It should be noted that in the embodiments of this application, S3 includes steps A1-A3; Furthermore, it parses the custom parameters in the @ApiSecurity annotation (such as verification type, frequency limit threshold, token expiration time, sensitivity level, etc.) to provide execution rules for the verification nodes. It supports personalized configuration at the interface level, and different interfaces can be set with different verification strategies (such as enabling full verification for highly sensitive interfaces and enabling token verification only for ordinary interfaces).

[0034] The parameters parsed from annotations are encapsulated into a unified configuration Map and passed to each verification node, avoiding scattered parameter transmission and improving code readability and maintainability. This includes core parameters required for node execution, such as frequency limits, token expiration time, and parameter encryption / decryption switches.

[0035] A1: Obtaining the initial set of verification nodes includes: parsing the verification type configuration in the security verification annotation and loading the corresponding built-in verification nodes; A2: Read the configuration file through the service provider interface loading mechanism to obtain the custom extended verification node; A3: Combine the built-in check nodes and custom extended check nodes into an initial check node set.

[0036] Furthermore, the VerifyNodeFactory factory class loads annotation-specified verification nodes (such as SIGN / TOKEN / RATE / ENCRYPT), including built-in nodes and SPI extension nodes. The factory pattern decouples node creation and usage, supports dynamic loading of custom extension nodes, and does not require modification of the core process.

[0037] It should be noted that the specific implementation of S4 in this application embodiment is as follows; By combining the context information of the edge nodes, it is determined whether each verification node needs to be executed, and dynamic filtering is performed to achieve a dynamic verification chain with "resource self-adaptation".

[0038] In an alternative embodiment, a lightweight decision tree model (such as the ID3 algorithm) can be introduced to replace rule-based judgment. The filtering rules are learned based on historical context data, which improves the accuracy of dynamic adjustment. Only the node filtering logic of the core service layer needs to be modified.

[0039] In this embodiment, dynamic filtering involves adding or removing verification nodes from the initial verification node set based on resource status information, interface sensitivity level in request attribute information, and device trust level.

[0040] Furthermore, dynamic filtering includes steps B1-B3: B1: When the CPU usage or memory usage exceeds the preset resource threshold, remove the parameter encryption / decryption verification node from the initial verification node set; B2: When the interface sensitivity level reaches the preset high sensitivity level, retain all verification nodes in the initial verification node set; B3: When the device's trust level is lower than the preset trust threshold, add a new device authentication verification node to the initial verification node set.

[0041] Furthermore, the specific implementation methods for B1-B3 are as follows: When resource utilization is >80%, skip non-core nodes (such as parameter encryption and decryption) and only retain signature and token verification; When the device has a low trust level, add a device authentication and verification node; When the interface has a high sensitivity level, full validation should be enforced.

[0042] It should be noted that after dynamic filtering, the process checks if the list of filtered verification nodes is empty. If empty, the process is allowed to proceed directly (e.g., all non-core nodes are skipped when resources are exhausted), reducing unnecessary process overhead. Executing the filtered verification nodes sequentially is the core execution step of security verification. The `execute` method of each node is called sequentially to complete core security actions such as signature verification, token expiration verification, request frequency limiting, and parameter encryption / decryption. The execution result of a single node is evaluated; if it fails, the process is immediately terminated and an exception is thrown; otherwise, the next node is executed, ensuring the strictness of the verification. Errors include signature verification failure, token expiration, request frequency exceeding limits, and parameter decryption failure.

[0043] It should be noted that the specific implementation of S5 in this application embodiment is as follows; Furthermore, the core verification nodes in S5 are the signature verification node and the token validity verification node; The extended verification nodes are the request frequency limit node and the parameter encryption / decryption verification node; The sequence in S5 adopts the chain of responsibility pattern, first traversing and executing the core verification nodes, and then traversing and executing the extended verification nodes. A local caching component is used to cache high-frequency verification data; the high-frequency verification data includes token expiration time and request frequency counts constructed based on the request Internet Protocol address and interface name.

[0044] Furthermore, executing the filtered verification nodes sequentially is the core execution step of security verification. The `execute` method of each node is called one by one to complete core security actions such as signature verification, token validity verification, request frequency limiting, and parameter encryption / decryption.

[0045] Furthermore, the execution result of a single node is judged. If it fails, the process is terminated immediately and an exception is thrown. If it succeeds, the next node is executed to ensure the strictness of the verification.

[0046] Failure scenarios include signature verification failure, token expiration, request frequency exceeding limits, and parameter decryption failure.

[0047] Furthermore, when a verification node fails to execute, a custom SecurityChainException is thrown, carrying the exception code and the specific reason, to facilitate problem localization.

[0048] Furthermore, for requests that pass validation or require no validation, the original API's business logic is executed to ensure the normal execution of the business process. After the business logic is executed, a normal API response is returned, and the process ends.

[0049] The termination of execution when any verification node fails, as described in embodiment S5 of this application, includes steps C1-C2: C1: Capture the security check exception thrown when the check fails using the global exception handler; C2: Convert the security check exception into an exception response result containing standardized error codes and prompt information and return it.

[0050] In the embodiments of this application, The specific implementation methods for steps C1-C2 are as follows: Unified capture of all exceptions thrown during the verification process prevents exceptions from penetrating to the business layer and ensures consistent interface responses. Exceptions are converted into standardized error codes and message messages to adapt to the exception handling logic of edge clients. A standardized response containing error code, error message, and timestamp is returned to facilitate client identification and handling of security verification failure scenarios (such as token expiration prompts and frequency limit exceedance prompts).

[0051] Example 3, the third embodiment of the present invention, provides a simulation experiment of the method for dynamically generating interface verification chains based on context information. This is based on an interface security protection scenario for an edge intelligent gateway device (the gateway uses an ARM architecture and a Kylin system, with limited CPU / memory resources, requiring protection of core interfaces such as device command issuance and status queries), fully covering the entire lifecycle of the framework from integration to operation and maintenance. Step 1, Edge Environment Adaptation Preparation: Confirm the edge gateway environment (JDK1.8, Maven3.6+, ARM architecture); download the framework JAR package and include it as a dependency in the business project; test the gateway resource baseline (CPU≤80%, memory≤64MB).

[0052] The purpose of step one is to: adapt to the hardware and software characteristics of edge nodes to avoid incompatibility that could prevent the framework from running; confirm that resources meet the requirements for lightweight operation of the framework (core package ≤ 500KB); and provide a basis for subsequent resource threshold configuration.

[0053] Step 2, Framework Auto-Integration and Basic Configuration: Enable Spring Boot auto-configuration in the business project startup class; modify application.yml: replace the signing key with the gateway-specific key; set the frequency limit to 30 times / minute (to adapt to low concurrency of the gateway); set the resource threshold to 75% (ARM device resource sensitive); start the project and verify the initialization log of the node factory.

[0054] The purpose of step two is to: reduce manual development through automatic configuration, aligning with the core of "non-intrusive" design; personalize configurations to adapt to the security requirements and resource capabilities of the edge gateway; and verify the effectiveness of loading the core components of the framework to avoid initialization failures.

[0055] Step 3, mark the business interface with security annotations: Device command issuance interface (highly sensitive): @ApiSecurity(verifyTypes="SIGN,TOKEN,RATE,ENCRYPT", sensitiveLevel=3,rateLimit=20); Device status query interface (normal): @ApiSecurity(verifyTypes="TOKEN,RATE",sensitiveLevel=1,rateLimit=60); Confirm that the interface parameters include validation fields such as sign, token, and content.

[0056] Step 3 serves the following purposes: Configure verification rules differently according to the sensitivity level of the interface; enable full verification for highly sensitive interfaces and simplify rules for ordinary interfaces (saving gateway computing power); complete the access by simply marking with annotations, without modifying the business logic, achieving "non-intrusiveness"; provide the necessary input parameters for the verification node to ensure that the verification logic is executable.

[0057] Step 4, Edge Context Rule Customization: Adapt CPU / Memory Acquisition Logic to ARM Architecture; Configure Gateway Trust Level Rules (Internal Gateway Trust Level = 3, Public Gateway = 2); Simulate Gateway CPU = 80%, and automatically skip verified encryption nodes.

[0058] Step four serves to: ensure the accuracy of edge node context collection, providing a reliable basis for decision-making in dynamic verification chains; customize trust level rules to make verification strategies more suitable for actual gateway scenarios; and verify resource degradation logic to ensure that core verification (signature / Token) is prioritized when the gateway is under high load.

[0059] Optional step, step five, SPI extension of the national cryptographic algorithm: implement a custom verification node for SM4 encryption and decryption (implement the VerifyNodeSpi interface); register the custom node in the SPI configuration file; add the SM4_ENCRYPT type in the annotation, and the verification node will be executed.

[0060] Step 5 serves to: extend the framework's capabilities based on the SPI mechanism to adapt to the requirements of domestically developed cryptographic algorithms; ensure the framework's stability without modifying its core code; and verify the feasibility of integrating the extended nodes into the dynamic verification chain.

[0061] Step Six, Full-Scenario Functional Verification: Normal Scenario: Use a valid token and correct signature to call the interface and verify that the business responds normally; Abnormal scenarios: Signature error → returns SIGN_004; Token expired → returns TOKEN_003; Frequency exceeded → returns RATE_001; In a weak network scenario: the simulated latency is 150ms, and the verification frequency node still executes.

[0062] The purpose of step six is ​​to: cover normal / abnormal / edge special scenarios to verify the integrity of the core functions of the framework; verify the standardized response to anomalies to facilitate identification and processing by the gateway client; and verify the robustness of the verification logic in edge weak network scenarios.

[0063] Step 7, Edge Performance Optimization: Adjust Caffeine cache: reduce the maximum tokenCache capacity from 10000 to 5000; adjust the CPU sampling interval from 100ms to 200ms; stress test with 50 QPS requests to verify that the gateway CPU ≤ 70% and memory ≤ 8MB.

[0064] The purpose of step seven is to: reduce the framework's own resource consumption and adapt to the limited computing power of the gateway; perform stress testing to verify performance indicators and ensure that the framework does not affect the response of business interfaces; implement the core "lightweight" feature of the framework and ensure the stable operation of the gateway.

[0065] Step 8, Production Canary Deployment: Package the business JAR (JVM parameter — Xmx64m) and deploy it to 10% of the gateway nodes; after monitoring shows no abnormalities, deploy it to the full deployment; call the gateway interface to verify that the verification process is normal.

[0066] Step eight serves the following purposes: adapting to edge node deployment methods (lightweight JAR packages, low memory configuration); reducing deployment risks through canary releases and avoiding environmental issues associated with full deployment; and verifying the synergy between the framework and business logic in the production environment.

[0067] Step 9, Operation and Maintenance Monitoring and Rule Iteration: Integrate Prometheus to collect metrics: verification pass rate, number of degradation triggers, and node execution frequency; analyze data weekly and adjust resource thresholds for high-frequency degradation nodes; add device fingerprint verification nodes and iteratively expand the framework capabilities.

[0068] The purpose of step nine is to: monitor the framework's operational status in real time and promptly detect anomalies (such as a sharp drop in the verification pass rate); optimize rules based on data to make the dynamic verification chain more closely match the actual operational status of the gateway; and continuously iterate and expand to adapt to changes in security requirements of business and edge scenarios.

[0069] The specific implementation method for edge smart gateway interface verification scenarios is as follows: Scenario Parameters—Edge Device: ARM architecture Kylin system gateway, 64MB memory, 1GHz CPU frequency; Interface Type: Device command issuance interface (sensitivity level 3), device status query interface (sensitivity level 1); Configuration Parameters: Resource threshold 75%, frequency limit 30 times / minute, Token expiration time 30 minutes.

[0070] Execution process: The device initiates a command delivery request, carrying the sign / token / content parameters, and the interface is marked with @ApiSecurity(verifyTypes="SIGN,TOKEN,RATE,ENCRYPT", sensitiveLevel=3); AOP aspect intercepts the request and triggers context collection: CPU utilization 70%, memory utilization 65%, network latency 80ms, device trust level 2; the core service layer parses the annotation, obtains the basic verification nodes (SIGN / TOKEN / RATE / ENCRYPT), and filters them in combination with the context (sufficient resources, high sensitivity level, retain all nodes); execute nodes in sequence: (1) Signature verification: after removing the sign parameter, recalculate the MD5 signature, compare it with the request sign, and pass; (2) Token verification: parse the JWT Token, verify expiration time, cache Token expiration time, pass; (3) Frequency limit: build cache key based on IP and interface name, atomically increment the number of requests (currently 25 times ≤ 30 times), pass; (4) Parameter encryption and decryption: decrypt content parameter (AES algorithm), replace the original request parameter; if the verification is passed, execute the business logic and return the instruction issuance result.

[0071] It should be noted that this application embodiment focuses on the core characteristics of edge computing nodes—"resource-constrained, scenario-differentiated, and lightweight"—and completes the framework implementation through nine steps: Firstly, from environment adaptation to configuration customization, we ensure the compatibility between the framework and the edge gateway; Secondly, from annotation access to SPI extension, non-intrusive integration and personalized extension are achieved; Third, from functional verification to performance optimization, ensure the framework's security and lightweight design in edge computing scenarios; Fourth, from canary deployment to operation and maintenance iteration, ensure the long-term stable operation of the framework and adapt to business changes.

[0072] Example 4, as Figure 2 As shown, this embodiment provides a system for dynamically generating interface verification chains based on context information, including: It should be noted that, Figure 2 The diagram is a hierarchical block diagram, from top to bottom: Access Layer—Aspect-Oriented Interception Layer—Context Collection Layer—Core Service Layer—Validation Node Layer. The Support Layer and Configuration Layer are listed below the Validation Node Layer. Dependencies between layers are indicated by unidirectional arrows. The Access Layer handles API requests, the Aspect-Oriented Interception Layer triggers the validation process, the Context Collection Layer provides decision data, the Core Service Layer generates and executes the validation chain, the Validation Node Layer is responsible for specific validation actions, and the Support Layer and Configuration Layer provide basic capabilities and flexible configuration.

[0073] The access layer (API access) serves as the interaction point between the framework and business systems, handling all business interface requests annotated with @ApiSecurity and acting as the starting point for security verification. This layer requires no additional modification to the business code; it can be included in the verification scope simply by marking the API with annotations, achieving "non-intrusive" access and adapting to various Java Web interfaces (such as Spring MVC / RESTful interfaces) in edge computing scenarios.

[0074] The core function of the AOP (Aspect-Oriented Programming) interception layer is to intercept interface requests from the access layer, acting as a "switch" for security verification: it identifies whether the interface carries the @ApiSecurity annotation, and allows it to pass directly if it does not; if it carries the annotation, it triggers the subsequent context collection and verification chain execution logic; and it controls the execution order of the verification process (by using the @Order annotation, it takes precedence over business logic), ensuring that the verification action is completed before business processing.

[0075] The Context Collector provides decision-making support for the dynamic verification chain, primarily collecting multi-dimensional context information from edge computing nodes. System resource dimension: CPU utilization, memory utilization (adapting to the resource-constrained characteristics of edge nodes); Network dimension: Request IP, network latency (to determine the communication status of nodes); Request attribute dimension: Interface sensitivity level, device trust level (distinguishing request security priorities); Automatically downgrade to the default value when collection fails to avoid blocking the core verification process due to context collection anomalies.

[0076] The core service layer (Security Chain Service) is the "brain" of the framework, responsible for the generation and execution of dynamic verification chains: parsing the verification types configured by the @ApiSecurity annotation, filtering the verification nodes that need to be executed; determining whether each verification node needs to be executed based on context information (e.g., skipping non-core nodes when resource utilization is too high); executing the verification chain in sequence, uniformly managing the transmission of exceptions and the return of results in the verification process; and encapsulating request parameter parsing logic to adapt to various parameter forms such as HTTP requests and method parameters.

[0077] The Verify Node layer is the core execution unit for security verification, and it is divided into two categories: "built-in nodes" and "SPI extension nodes". Built-in nodes cover the core requirements of edge interface security, including signature verification (preventing request tampering), token verification (preventing unauthorized access), frequency limiting (preventing interface abuse), and parameter encryption and decryption (preventing data leakage). SPI extension nodes provide an extensible entry point, supporting business users to customize verification rules (such as national cryptographic algorithm adaptation, device authentication verification, etc.), and can extend verification capabilities without modifying the core framework code.

[0078] The support layer provides basic capabilities for the core verification process and includes three sub-layers: Caching layer (Caffeine): caches high-frequency data such as token expiration time and request frequency count to reduce redundant calculations and improve verification performance (adapting to the low computing power characteristics of edge nodes); Tool layer: encapsulates common tool capabilities, including encryption / decryption (signature / parameter encryption / decryption), system resource collection (CPU / memory), and network information acquisition (IP / latency), and unifies the calling specifications of tool classes; Exception handling layer: globally captures exceptions in the verification process, uniformly returns standardized error codes and prompts, prevents exceptions from penetrating to the business layer, and ensures the consistency of interface responses.

[0079] The configuration layer enables flexible configuration and automated assembly of the framework: Configuration property binding: Binds configuration parameters (such as signing keys, frequency limit thresholds, and resource thresholds) in application.yml to Java classes, supporting dynamic adjustment; Auto-configuration class: Based on the Spring Boot auto-assembly mechanism, it automatically registers the framework's core beans (such as validation node factories, aspects, and caches) without manual configuration; External configuration file: Centrally manages all configurable items of the framework, adapting to parameter adjustments for different edge computing scenarios (such as reducing the frequency limit threshold for low-resource nodes).

[0080] The overall system architecture adopts a layered architecture design, including: access layer, aspect interception layer, context collection layer, core service layer, verification node layer, support layer, and configuration layer. Each layer has unidirectional dependency, high cohesion and low coupling, and the core package size is ≤500KB, which is adapted to the resource-constrained characteristics of edge computing.

[0081] The context collection layer (core module) includes: ContextInfo and ContextCollector, which depend on SystemUtils and NetworkUtils. It collects multi-dimensional context information from edge nodes to provide decision-making basis for dynamic verification chains. Collection dimensions: resource status dimensions: CPU utilization (preserved to two decimal places) and memory utilization, implemented based on the oshi tool and JVM ManagementFactory. When collection fails, it degrades to the default value (50%).

[0082] In an optional embodiment, the context acquisition tool can be Sigar instead of oshi, maintaining consistency in acquisition dimensions and ensuring data format compatibility by adapting the method parameters in SystemUtils.

[0083] Network status dimensions: request IP, network latency (ms), detected by the InetAddress.isReachable method; latency > 100ms is marked as a weak network status. Request attribute dimensions: Interface sensitivity level (1 low / 2 medium / 3 high), device trust level (1 low / 2 medium / 3 high), obtained from the @ApiSecurity annotation and IP whitelist configuration; collection time is controlled within 10ms to avoid affecting interface response speed.

[0084] The core service layer includes SecurityChainService and SecurityChainServiceImpl, which depend on VerifyNodeFactory. It parses annotation configurations, dynamically filters verification nodes, and executes the verification chain. Parse the verification type (such as SIGN / TOKEN / RATE / ENCRYPT) in the @ApiSecurity annotation to obtain the list of basic verification nodes; when resource utilization is >75%, skip non-core nodes (such as parameter encryption / decryption); when the sensitivity level is ≥3, force full verification; when the device trust level is <2, add a device authentication node; The verification is sorted in the order of "core verification (signature / Token) - extended verification (frequency / encryption / decryption)" to form a dynamic verification chain; the execution nodes are traversed using the chain of responsibility pattern, and the process is terminated immediately if a node fails to verify, thus improving efficiency.

[0085] The core interface of the verification node layer is VerifyNode, which includes built-in nodes and SPI extension nodes. Built-in nodes include: SignatureVerifyNode, TokenValidityVerifyNode, RequestFrequencyLimitVerifyNode, and ParameterEncryptionVerificationNode, covering the core security requirements of edge interfaces. The SPI extension mechanism supports custom nodes (such as national cryptographic algorithm verification and device fingerprint verification) through the VerifyNodeSpi interface and the META-INF / services configuration file without modifying the core framework code. Node features: Each node implements the needExecute method to customize execution conditions and adapt to dynamic filtering logic.

[0086] In an alternative embodiment, the extension mechanism can use Spring SPI (META-INF / spring.factories) instead of the native Java SPI, adapting to scenarios with a tighter Spring ecosystem, requiring only adjustments to the node loading logic of VerifyNodeFactory.

[0087] Support Layer and Configuration Layer: The support layer includes Caffeine caching (cache token expiration time, request frequency count, and configurable maximum capacity), a tool layer (encryption / decryption / system / network tools), and global exception handling (standardized error response); the configuration layer binds application.yml configuration through SecurityChainProperties, supports customization of parameters such as signing key, resource threshold, and frequency limit, and adapts to different edge scenarios.

[0088] In an optional embodiment, the caching component can be replaced by Redis (a lightweight version of Redis Edge), which is suitable for distributed edge cluster scenarios. Only the cache instance creation logic in CacheConfig needs to be modified, without affecting the core process.

[0089] Example 5: In some embodiments, the context information dynamic generation interface verification chain system of the present invention can be implemented in a combination of hardware and software. As an example, the context information dynamic generation interface verification chain system of the present invention can be a processor in the form of a hardware decoding processor, which is programmed to execute the context information dynamic generation interface verification chain method of the present invention. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0090] The modules described in the embodiments of this invention can be implemented in software or hardware. The names of the modules are not, in some cases, limiting the scope of the module itself.

[0091] An electronic device according to an embodiment of the present invention includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any of the above-mentioned methods for dynamically generating interface verification chains based on context information. That is, an electronic device according to an embodiment of the present invention may include, but is not limited to: a processor and a memory; the memory is used to store the computer program; the processor is used to execute the method for dynamically generating interface verification chains based on context information as shown in any embodiment of the present invention by calling the computer program.

[0092] In one alternative embodiment, an electronic device is provided, such as Figure 3 As shown, Figure 3 The illustrated electronic device 4000 includes a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, for example, via a bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of the present invention.

[0093] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this invention. Processor 4001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0094] Bus 4002 may include a path for transmitting information between the aforementioned components. Bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 4002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 3 The bus 4002 is represented by only one thick line, but this does not mean that there is only one bus or one type of bus.

[0095] The memory 4003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto.

[0096] The memory 4003 stores application code (computer program) for executing the present invention, and its execution is controlled by the processor 4001. The processor 4001 executes the application code stored in the memory 4003 to implement the content shown in the foregoing method embodiments.

[0097] Among them, electronic devices can also be terminal devices, which can be any device that can install applications, including at least one of smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, smart TVs, and smart in-vehicle devices.

[0098] It should be noted that, Figure 3 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0099] An embodiment of the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-mentioned methods for dynamically generating interface verification chains from context information.

[0100] Alternatively, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, a floppy disk, and an optical data storage device, etc.

[0101] In an exemplary embodiment, a computer program product or computer program is also provided, which includes computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the aforementioned method for dynamically generating interface verification chains based on context information.

[0102] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0103] It should be understood that the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods and computer program products according to various embodiments of the present invention. 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 the 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-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0104] The computer-readable storage medium provided in this invention can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EEPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0105] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the method shown in the above embodiments.

[0106] The above description is merely a preferred embodiment of the present invention and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

[0107] It should be noted that the terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and represent a limitation on a specific order or sequence. Where appropriate, the order of use for similar objects can be interchanged so that the embodiments of this application described herein can be implemented in an order other than that shown or described.

[0108] Those skilled in the art will recognize that this invention can be implemented as a system, method, or computer program product. Therefore, this invention can be specifically implemented in the following forms: it can be entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software, generally referred to herein as a "circuit," "module," or "system." Furthermore, in some embodiments, this invention can also be implemented as a computer program product contained in one or more computer-readable media, which includes computer-readable program code.

[0109] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A method for dynamically generating interface verification chains based on context information, characterized in that, include: Intercept API requests and identify whether the target method corresponding to the API request is configured with a security verification annotation; If a security verification annotation is configured, the context information of the edge computing node will be collected. Parse the verification type configuration in the security verification annotation to obtain the initial set of verification nodes; The initial set of verification nodes is dynamically filtered based on context information to generate a dynamic verification chain. The verification nodes in the dynamic verification chain are executed in the order that the core verification node takes precedence over the extended verification nodes, and execution is terminated if any verification node fails.

2. The method for dynamically generating interface verification chains based on context information according to claim 1, characterized in that, The context information includes: resource status information, network status information, and request attribute information. When collection fails, the relevant parameters in the context information are set to preset default values. The resource status information includes CPU utilization and memory utilization. The network status information includes the requested Internet Protocol address and network latency; The request attribute information includes the interface sensitivity level and the device trust level.

3. The method for dynamically generating interface verification chains based on context information according to claim 2, characterized in that, The dynamic filtering of the initial set of verification nodes based on context information includes: When the CPU usage or memory usage exceeds the preset resource threshold, the parameter encryption / decryption verification node is removed from the initial verification node set; When the interface sensitivity level reaches the preset high sensitivity level, all verification nodes in the initial verification node set are retained; When the device's trust level is lower than the preset trust threshold, a new device authentication verification node is added to the initial verification node set.

4. The method for dynamically generating interface verification chains based on context information according to claim 1, characterized in that, The core verification nodes include: a signature verification node and a token validity verification node; The extended verification nodes include request frequency limiting nodes and parameter encryption / decryption verification nodes.

5. The method for dynamically generating interface verification chains based on context information according to claim 4, characterized in that, The verification nodes in the dynamic verification chain include: The chain of responsibility pattern is adopted, first traversing and executing the core verification nodes, and then traversing and executing the extended verification nodes. A local caching component is used to cache frequently checked data; The high-frequency verification data includes the token expiration time and the request frequency count constructed based on the requested Internet Protocol address and interface name.

6. The method for dynamically generating interface verification chains based on context information according to claim 1, characterized in that, The process of obtaining the initial set of verification nodes includes: parsing the verification type configuration in the security verification annotation and loading the corresponding built-in verification nodes; The configuration file is read through the service provider's interface loading mechanism to obtain the custom extended verification node; Combine the built-in verification nodes and the custom extended verification nodes into an initial set of verification nodes.

7. The method for dynamically generating interface verification chains based on context information according to claim 5, characterized in that, The step of terminating execution when any verification node fails includes: The security check exception thrown when the check fails is captured by the global exception handler; The security verification exception is converted into an exception response result containing standardized error codes and prompt information and returned.

8. A context information dynamic generation interface verification chain system, applied to the method described in any one of claims 1-7, characterized in that, include: Access layer, aspect interception layer, context collection layer, core service layer, verification node layer, support layer, configuration layer.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images