Operation request processing method and device, electronic equipment and medium

Abstract

The application provides an operation request processing method and device, electronic equipment and medium, the method comprises: obtaining a current operation request initiated by a user; determining whether an operation token is carried in the current operation request; if not, generating an operation token corresponding to the current operation request according to at least an operation identifier and a current session identifier corresponding to the current operation request; if the operation token is carried, signing the operation token with a device public key, extracting the operation identifier and the session identifier after the signature verification is passed; querying an operation conflict matrix with the extracted operation identifier to determine whether the current operation request has a mutual exclusion relationship with an operation corresponding to another active operation token; if there is no mutual exclusion relationship, the current operation request is allowed to be executed, and the operation token corresponding to the current operation request is marked as active; if there is a mutual exclusion relationship, the current operation request is rejected, and the session information corresponding to the operation token currently occupying the related resource is returned.

Description

Technical Field

[0001] This application relates to the field of operation request processing technology, and in particular to an operation request processing method, apparatus, electronic device and medium. Background Technology

[0002] In the field of server management, baseboard management controllers (BMCs) are often used to perform out-of-band management operations such as remote power on / off and firmware updates. These operations usually involve modifications to the underlying hardware or core firmware and are highly risky.

[0003] In practical applications, BMC often needs to concurrently process operation requests from multiple management clients. However, operations such as firmware updates and system reboots inherently involve resource contention and mutual exclusion. Without an effective coordination mechanism, when multiple mutually exclusive operations are executed simultaneously, it can easily lead to operational interference, resource read / write conflicts, and even unpredictable and serious consequences such as firmware corruption or server crashes.

[0004] Currently, most existing BMC management systems rely solely on simple locking mechanisms or manual judgment to handle concurrent operations, making it difficult to flexibly and accurately identify complex mutual exclusion relationships between multiple operation requests, thus failing to effectively avoid the risk of system failures caused by operation conflicts. Summary of the Invention

[0005] This application provides an operation request processing method, including: obtaining a current operation request initiated by a user; determining whether the current operation request carries an operation token; if it does not carry an operation token, generating an operation token corresponding to the current operation request based at least on the operation identifier and the current session identifier, wherein the operation token is generated by signing with the device's private key; if it carries an operation token, verifying the operation token using the device's public key, and extracting the operation identifier and session identifier from the operation token after successful verification; querying an operation conflict matrix using the extracted operation identifier to determine whether the current operation request has a mutually exclusive relationship with the operations corresponding to other currently active operation tokens, wherein the operation conflict matrix has preset mutual exclusion relationships between operations; if no mutual exclusion relationship exists, allowing the execution of the current operation request and marking the operation token corresponding to the current operation request as active; if a mutual exclusion relationship exists, refusing to execute the current operation request and returning the session information corresponding to the operation token currently occupying the relevant resources.

[0006] In some embodiments, the above method further includes: obtaining the MAC address of the management port of the baseboard management controller and the chip's built-in hardware random seed; generating a device key pair based on the MAC address of the management port of the baseboard management controller and the chip's built-in hardware random seed using a preset algorithm, wherein the device key pair includes a device private key and a device public key.

[0007] In some embodiments, generating an operation token corresponding to the current operation request based at least on the operation identifier and the current session identifier corresponding to the current operation request includes: concatenating an information string, the information string including at least the operation identifier, the current session identifier, and a dynamic timeout value; digitally signing the information string based on the device private key to generate a signature string; and encoding the signature string and the information string to generate an operation token.

[0008] In some embodiments, after the operation token is verified by the device public key, the method further includes: extracting an operation identifier from the operation token; comparing the extracted operation identifier with the operation type of the current operation request; and rejecting the current operation request if the comparison result is inconsistent.

[0009] In some embodiments, when a mutual exclusion relationship is determined, the method further includes: obtaining the session identifier and remaining time of the operation token currently occupying the relevant resources; and sending a notification message containing the session identifier and remaining time of the operation token to all online users.

[0010] In some embodiments, the method further includes: starting a background scanning thread to traverse all active operation tokens at predetermined time intervals; marking timed-out operation tokens as inactive and releasing the resources they occupy.

[0011] In some embodiments, the method further includes: creating a target operation session in response to a multi-request sequence operation initiated by a user; maintaining the same operation token during the target operation session, wherein the same operation token is applied to all sub-operation requests contained in the target operation session; querying the operation conflict matrix once at the granularity of the target operation session when each sub-operation request is executed; and releasing the resources occupied by the operation token when the target operation session ends or times out.

[0012] This application also provides an operation request processing apparatus, comprising: an acquisition module for acquiring a current operation request initiated by a user; a first determination module for determining whether the current operation request carries an operation token; a token generation module for generating an operation token corresponding to the current operation request based at least on the operation identifier and the current session identifier, wherein the operation token is generated by signing with the device's private key; a signature verification module for verifying the operation token using the device's public key if the operation token is carried, and extracting the operation identifier and session identifier from the operation token after successful verification; a second determination module for querying an operation conflict matrix using the extracted operation identifier to determine whether the current operation request has a mutually exclusive relationship with the operations corresponding to other currently active operation tokens, wherein the operation conflict matrix has preset mutual exclusion relationships between operations; a marking module for allowing the execution of the current operation request if no mutual exclusion relationship exists, and marking the operation token corresponding to the current operation request as active; and a return module for rejecting the execution of the current operation request and returning the session information corresponding to the operation token currently occupying the relevant resources if a mutual exclusion relationship exists.

[0013] This application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described above.

[0014] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0015] The beneficial effects of the operation request processing method in this application are as follows: By using a pre-set operation conflict matrix with mutual exclusion relationships between operations, and combining it with the operation identifier carried in the operation token for query matching, it can accurately identify whether the current operation request competes for resources with other active operations in the system. Compared with the traditional method of relying on simple global locks or manual judgment, this application significantly improves the flexibility and accuracy of judging the mutual exclusion relationships between complex operations, effectively avoiding operation conflicts caused by misjudgment or omission. In addition, this application does not simply and crudely serialize all operations, but allows operations corresponding to operation tokens that do not have mutual exclusion relationships to be executed concurrently through the operation conflict matrix. This allows the system to maximize the concurrent processing capability of BMC for multiple management requests while ensuring operation safety, avoiding unnecessary blocking, and improving the throughput of the management channel and the overall resource utilization. Attached image description: Figure 1 This illustration shows a flowchart of an operation request processing method according to an embodiment of this application; Figure 2 A flowchart illustrating another embodiment of the operation request processing method of this application is shown schematically; Figure 3 The flowchart illustrating step S130 of an embodiment of this application is shown in the schematic diagram. Figure 4 A flowchart illustrating an operation request processing method according to another embodiment of this application is shown schematically; Figure 5 A flowchart illustrating an operation request processing method according to yet another embodiment of this application is shown. Figure 6 A flowchart illustrating an operation request processing method according to yet another embodiment of this application is shown. Figure 7 A flowchart illustrating an operation request processing method according to yet another embodiment of this application is shown. Figure 8 This illustration schematically shows a system framework diagram of the operation request processing method according to an embodiment of this application; Figure 9 A schematic block diagram of an electronic device according to an embodiment of this application is shown. Detailed Implementation

[0016] Hereinafter, exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings to enable those skilled in the art to implement them more readily. Furthermore, for clarity, portions unrelated to the description of exemplary embodiments have been omitted from the drawings. In this disclosure, it should be understood that terms such as "comprising" or "having" are intended to indicate the presence of features, numbers, steps, behaviors, components, portions, or combinations thereof disclosed in this specification, and are not intended to exclude the possibility of the presence or addition of one or more other features, numbers, steps, behaviors, components, portions, or combinations thereof. It should also be noted that, without conflict, embodiments and features in the embodiments of this disclosure can be combined with each other. The present disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0017] The operation request processing method provided in this application is mainly applied to out-of-band server management scenarios, and is especially suitable for concurrent request processing when the Baseboard Management Controller (BMC) performs management operations on the server.

[0018] In large data centers or cloud computing environments, servers are typically equipped with a dedicated Server Management Console (BMC). As a core component for server management, the BMC has its own processor, memory, and network interface, enabling administrators to provide remote management capabilities even when the main system (i.e., the server's operating system) is offline, in hibernation, or even not installed. Administrators can initiate various management operation requests to the BMC through various management clients (such as a web graphical interface, IPMI command-line tool, Redfish API, or a third-party centralized management platform).

[0019] These management operations can be broadly categorized into two types based on their nature and risk level: one type is status query operations, such as obtaining sensor temperature, checking power status, and reading system logs. These operations are usually read-only, do not compete for resources, and can be executed concurrently. The other type is status modification or high-risk operations, such as remote power-on, power-off, restart, firmware upgrades (including BIOS upgrades and BMC firmware upgrades), operating system installation, and network configuration modifications. These operations involve accessing and modifying exclusive resources such as underlying hardware registers, Flash memory, and power management units, and are usually mutually exclusive.

[0020] Because the BMC needs to serve multiple management clients simultaneously, it may receive multiple operation requests at the same time. For example, administrator A might initiate a firmware upgrade operation via the web interface, while administrator B simultaneously initiates a system reboot operation via the IPMI tool. If these two operations are executed concurrently, it is highly likely that the power supply will be cut off during the firmware writing process, resulting in permanent damage to the server motherboard. Similarly, if two administrators attempt to modify network configurations simultaneously, it may lead to configuration data write conflicts, ultimately resulting in configuration loss or network service malfunctions.

[0021] In the BMC implementations of related technologies, the handling of the aforementioned concurrency conflict issues is relatively primitive. Some solutions employ simple global mutex locks, allowing only one management operation to execute at a time, while all other operations are queued. While this approach avoids conflicts, it severely limits the BMC's concurrent processing capabilities, causing a large number of conflict-free query operations to be blocked, thus reducing management efficiency. Other solutions lack effective conflict detection mechanisms, relying entirely on verbal coordination among administrators or manual judgment. When multiple operations are initiated simultaneously, the system cannot proactively identify and intercept conflicts, allowing them to occur and ultimately passively informing administrators through operation failure feedback.

[0022] Based on the aforementioned technical background and shortcomings in application scenarios, this application provides an operation request processing method. This method introduces an operation token mechanism signed by the device's private key, combined with a pre-defined operation conflict matrix, to achieve verification of the legitimacy of operation requests, accurate identification of mutual exclusion relationships, and rational scheduling of operation resources. This application can maximize the BMC's ability to handle concurrent management requests while ensuring the security of high-risk operation execution, and simultaneously provide administrators with clear operation conflict feedback information, facilitating task coordination and troubleshooting.

[0023] The operation request processing method and system of this application are described in detail with reference to the accompanying drawings.

[0024] Figure 1 The flowchart illustrating an embodiment of the operation request processing method of this application is shown. Figure 1 As shown, the operation request processing method includes steps S110 to S170.

[0025] In step S110, the current operation request initiated by the user is obtained.

[0026] For example, the Baseboard Management Controller (BMC), as the core entity for out-of-band server management, provides a standardized management interface for administrators. This management interface can be exposed through various protocols, including but not limited to: a web service interface based on HTTP or HTTPS, a command-line interface conforming to the IPMI (Intelligent Platform Management Interface) protocol, a RESTful API interface conforming to the Redfish standard specification, and an SNMP (Simple Network Management Protocol) interface. When an administrator sends an operation request to the BMC through the above interface using various management clients (such as browsers, IPMI tools, or third-party network management software), the BMC's built-in request receiving module or middleware interceptor executes this step to obtain the operation request.

[0027] In this embodiment, the BMC is jointly managed by multiple administrators, who may belong to different management roles or permission groups. For example, in actual operation and maintenance, to simplify permission management, data centers sometimes configure a shared management account (e.g., a shared "admin" account) for the same operation and maintenance team. Multiple administrators can log in to the BMC and initiate operation requests simultaneously using this shared account from different locations and using different client devices. In this scenario, although these requests belong to the same account at the user identity level, the sessions from which they originate are independent of each other. That is, when each administrator logs into the BMC, the BMC creates an independent session instance for them and assigns a unique session ID. The "current operation request" obtained in step S110 comes from a specific session instance under this shared account.

[0028] Different administrators can also have their own independent BMC management accounts (e.g., "user_a", "user_b", "admin_c", etc.), each with different permission levels (e.g., administrator permissions, operator permissions, read-only permissions). These administrators can simultaneously log in to the BMC using their respective accounts and initiate operation requests from their own independent sessions. In this scenario, the current operation request obtained in step S110 carries a session identifier associated with the initiator's account.

[0029] In complex real-world operation and maintenance environments, both of the above scenarios may coexist. For example, some administrators may initiate operations using shared accounts, while others may initiate operations using personal accounts, or even initiate multiple requests simultaneously from different browser tabs on the same management client (each tab corresponds to an independent session). Step S110 can uniformly obtain the current operation requests from all the above sources and achieve unified management and conflict coordination through the mechanism based on session identifiers and operation tokens in subsequent steps, without distinguishing between the account type or login method of the request source.

[0030] It should be noted that the determination of operation conflicts in this application is based on "operation type" and "session state" rather than "account identity". That is, whether it is different sessions under the same account or different sessions under different accounts, if there is a mutual exclusion relationship between their corresponding operations, it can be identified and intercepted by the conflict detection mechanism of this application.

[0031] In step S120, it is determined whether the current operation request carries an operation token.

[0032] For example, an operation token can be used to represent a credential of an initiated management operation. The token is generated by the BMC when it first receives an operation request for a session and is digitally signed by the device's private key to ensure its authenticity and integrity. After generation, the operation token will be returned to the management client that initiated the operation and carried by the client in subsequent requests. Step S120 can be used to determine whether the current request is a "new operation request" or a "follow-up request for an existing operation".

[0033] In this embodiment, it is checked whether the operation token field extracted from the current operation request is a valid non-empty value. For example, if a non-empty string can be extracted from the specified carrier position of the request, it is determined to be "carrying an operation token"; if the extracted field is an empty string, a null value, or the field itself does not exist, it is determined to be "not carrying an operation token".

[0034] In step S130, if no operation token is carried, an operation token corresponding to the current operation request is generated at least based on the operation identifier and the current session identifier corresponding to the current operation request. The operation token is generated by signing with the device private key.

[0035] For example, when the BMC receives a brand new operation request (i.e., a request for which it does not yet possess a valid token), it creates a unique, verifiable, and tamper-proof digital credential for the request, namely an operation token. This operation token is returned to the management client, which then carries it in all subsequent requests related to that operation for the BMC to verify signatures and detect conflicts.

[0036] In this embodiment, the operation token is not a simple random string, but a structured data object that carries key operation context information. For example, the operation token contains at least the following fields: operation identifier, session identifier, timestamp, etc.

[0037] Specifically, the "Operation Identifier" field is used to characterize the type of operation to be performed in the current request, and it is consistent with the operation identifier parsed from the request in step S110. This operation identifier can be a predefined enumeration value or a string constant, such as "remote restart," "firmware upgrade," or "acquire sensor information." These character fields can be edited to specific characters corresponding to the actual scenario as needed. After being embedded in the token, this field is used in subsequent steps to query the operation conflict matrix to determine the mutual exclusion relationship between the current operation and other active operations.

[0038] The "Session Identifier" field is used to identify the management session that initiated the operation and must be consistent with the session identifier parsed from the request in step S110. This session identifier is assigned by the BMC's session management module when the administrator successfully logs into the BMC and can be a globally unique session credential generated internally by the BMC. Once embedded in the token, this field is used in subsequent steps to trace and return information about the session occupying the relevant resources in the event of a conflict, enabling the administrator to identify which specific session is occupying the conflicting resource.

[0039] The operation token also includes a timestamp field indicating when the token was generated (e.g., a Unix timestamp). This field is used for subsequent token expiration management. The BMC can determine whether the token has expired based on the difference between the current time and the token's generation time, thereby preventing expired tokens from being maliciously replayed and exploited.

[0040] In this embodiment, the security of the operation token does not rely on the confidentiality of its content, but rather on the unforgeability of its digital signature. The entire token generation process is as follows: First, the aforementioned operation identifier, session identifier, timestamp, and other fields are serialized and concatenated according to an agreed order and format to form the original data to be signed. After completing the construction of the data to be signed, the BMC device private key is used to perform a digital signature operation on the data, and the signature result is concatenated with the original data to generate the aforementioned operation token.

[0041] In this embodiment, the device private key can be an asymmetric encryption private key pre-stored in the BMC secure storage area, and its corresponding device public key is pre-distributed to each management client or stored in a trusted storage location accessible by the BMC. This private key is a global key at the BMC device level, not a user-level key; that is, all operation tokens on the same BMC device are signed by the same device private key. The device public key can be obtained and cached by the management client when the trust relationship is first established, and used for subsequent verification of received operation tokens. In this embodiment, the operation token is not generated when the user logs into the BMC, but is generated on demand when the user initiates a specific operation request. That is, a session can have multiple operation tokens, each token corresponding to an independent operation request. For example, in the same session, the administrator first initiates a firmware upgrade request, obtaining token A; then initiates a system restart request, obtaining token B; the two tokens are managed independently and do not interfere with each other.

[0042] In step S140, if an operation token is carried, the operation token is verified using the device public key. After successful verification, the operation identifier and session identifier are extracted from the operation token.

[0043] For example, when BMC receives a request carrying an operation token, it first performs cryptographic verification of the token's authenticity and integrity. If the verification passes, the operation identifier and session identifier carried within the token are accepted and used for subsequent conflict detection. If the verification fails, the process is terminated directly, and the request is rejected. This pre-verification mechanism ensures that the entire operation conflict detection system is built on a trusted data foundation.

[0044] In this embodiment, the device public key is pre-stored in the protected storage area of ​​the BMC. The BMC reads it directly from the local storage during signature verification. For example, the device public key can be stored in the BMC in the form of a digital certificate, and the public key can be extracted from the certificate during verification. In a distributed management environment, the BMC can obtain the corresponding device public key in real time from a trusted third-party key management service or public key infrastructure system. For example, using the device public key, a signature verification operation is performed according to an agreed-upon algorithm. After successful verification, the corresponding content, such as the operation identifier and session identifier, is obtained from the parsed operation identifier field and session identifier field.

[0045] Asymmetric signature verification ensures that the operation and session identifiers entering the conflict detection phase are genuinely generated by a legitimate BMC and have not been tampered with, providing reliable data input for subsequent conflict matrix queries. Attackers cannot forge valid tokens without the device's private key, nor can they tamper with the operation or session identifiers after intercepting the token, effectively protecting the BMC management interface from malicious injection. Furthermore, by incorporating lightweight filtering methods such as format validation, field integrity checks, and expiration date pre-checks before signature verification, the high computational cost of asymmetric signature verification is avoided due to a large number of invalid tokens, improving the BMC's processing efficiency under resource-constrained conditions.

[0046] In step S150, the extracted operation identifier is used to query the operation conflict matrix to determine whether the current operation request has a mutual exclusion relationship with the operations corresponding to other currently active operation tokens. The operation conflict matrix has preset mutual exclusion relationships between operations.

[0047] For example, after verifying the authenticity of the operation token, BMC uses the operation type as an index to perform a matching query in the pre-configured conflict rule base (i.e., the operation conflict matrix) to determine whether the currently requested operation is mutually exclusive with any other active operation in the system, thereby deciding whether to allow the operation to execute. This step combines the two dimensions of "operation type" and "real-time active status" to achieve accurate and dynamic conflict detection.

[0048] In this embodiment, the preset content of the operation conflict matrix is ​​configured based on the resource contention relationship and system impact scope of BMC out-of-band management operations. For example, when configuring the operation conflict matrix, a table of conflicting operations can be defined first to clarify all locking operations and their mutual exclusion relationships. Specifically, the table of conflicting operations is as follows:

[0049] Based on the information in the table above, operation matrices in various data formats can be configured according to actual conditions. For example, during the BMC firmware development phase, developers can write the operation matrix into the BMC's file system in JSON, XML, or YAML format configuration files based on hardware characteristics and operational risk assessments.

[0050] Additionally, in step S130, before generating the operation token, the BMC can also query the operation conflict matrix based on the operation identifier of the current operation request to determine whether there is already an active operation mutually exclusive with the operation in the current system. If a mutual exclusion relationship exists, the request is directly rejected and the session information of the occupying party is returned, thereby avoiding wasting the computational resources for token generation and signing for an operation that is destined to be rejected.

[0051] In step S160, if there is no mutual exclusion relationship, the current operation request is allowed to be executed, and the operation token corresponding to the current operation request is marked as active.

[0052] For example, after completing token authenticity verification (step S140) and conflict detection (step S150), BMC confirms that the current operation has the conditions for execution, formally grants the operation execution permission, and includes the token corresponding to the operation in the "active token management system" so that it becomes the reference object for subsequent requests to perform conflict detection. This "allow first, mark later" order ensures that the current operation will be identified and avoided by subsequent mutually exclusive requests during its own execution.

[0053] In this embodiment, "active state" means that the operation corresponding to an operation token has been allowed to be executed by the BMC, and the operation is still in the process of execution (including being executed, waiting in the execution queue, or having been completed but the result has not yet been returned synchronously). Operation tokens in the active state will be included in the reference scope of conflict detection in subsequent steps, that is, the operation corresponding to the active token will act as the "occupier" to prevent the execution of other mutually exclusive operations.

[0054] In step S170, if a mutual exclusion relationship exists, the current operation request is rejected, and the session information corresponding to the operation token currently occupying the relevant resources is returned.

[0055] For example, after detecting an operation conflict, BMC adopts a dual processing strategy of "denial of access + information feedback". On the one hand, by refusing execution, it ensures that high-risk operations are not interfered with by concurrency, thus guaranteeing the security and stability of the system; on the other hand, by returning the session information of the party occupying the conflict, the current administrator can quickly understand the specific reason for the operation being denied, the identity of the party occupying the conflict, and the resource usage, thereby enabling effective task coordination.

[0056] Based on the above embodiments of this application, by using a pre-set operation conflict matrix with mutual exclusion relationships between various operations, and combining it with the operation identifier carried in the operation token for query matching, it is possible to accurately identify whether the current operation request is competing for resources with other active operations in the system. Compared with the methods of relying on simple global locks or manual judgment in related technologies, this application significantly improves the flexibility and accuracy of judging mutual exclusion relationships between complex operations, effectively avoiding operation conflicts caused by misjudgment or omission. When a mutual exclusion relationship is determined to exist, the current operation request is rejected, and the session information corresponding to the operation token currently occupying the relevant resources is returned. This mechanism can forcibly ensure that high-risk operations such as firmware updates are not interrupted or interfered with by any other mutually exclusive operations during execution, ensuring the atomicity and security of critical management task execution at the system level, and reducing the risk of firmware damage or server downtime due to operation interference. When an operation request is rejected due to mutual exclusion, the session information (such as initiator, operation type, etc.) corresponding to the operation token currently occupying the resources is explicitly returned. This allows administrators to immediately know the specific reason for the operation being blocked and the party occupying the resources, thereby quickly coordinating tasks or waiting for resource release, significantly improving the visibility of management operations and the efficiency of problem troubleshooting. In addition, the operation token in this application is generated by signing with the device's private key and verified using the device's public key during signature verification. This mechanism ensures the authenticity and integrity of the token, prevents unauthorized clients from forging or tampering with the operation token to bypass mutual exclusion checks, enhances the security of the entire operation request processing flow, and protects the BMC's management interface from malicious attacks.

[0057] Figure 2 A flowchart illustrating an operation request processing method according to another embodiment of this application is shown.

[0058] like Figure 2 As shown, the operation request processing method further includes steps S210 to S220.

[0059] In step S210, the MAC address of the management network port of the baseboard management controller and the chip's built-in hardware random seed are obtained.

[0060] For example, a MAC address is a globally unique hardware identifier for the management network port of the BMC (Block Controller), uniformly assigned by the IEEE Standards Association and permanently embedded in the BMC chip or onboard network card hardware, and cannot be changed throughout the entire lifecycle of the BMC. Introducing the MAC address into the token generation process enables hardware binding of the operation token to a specific BMC device, ensuring that even if the token is intercepted, it cannot be successfully verified on other BMC devices. Simultaneously, the determinism of the MAC address guarantees that the same device generates a consistent basic identifier each time a token is generated, facilitating device-level key derivation or identifier traceability.

[0061] Unlike software random number generators (such as those based on time seeds) on general-purpose computers, the hardware random seed built into the BMC chip can generate entropy values ​​with true randomness based on the physical noise inside the chip (such as thermal noise, quantum tunneling effect, ring oscillator jitter, etc.).

[0062] In this embodiment, during the firmware initialization phase (or driver loading phase) of the BMC, the operating system kernel obtains the MAC address of the network interface card (such as an Ethernet controller) by reading its hardware registers or configuration information in the EEPROM. The method of obtaining the hardware random seed depends on the specific hardware security features integrated into the BMC chip. For example, the BMC firmware can obtain a random number of a specified length (such as 256 bits) by reading or writing specific memory-mapped I / O (MMIO) registers or by calling the security coprocessor driver interface.

[0063] In step S210, a device key pair is generated based on the MAC address of the management network port of the baseboard management controller and the chip's built-in hardware random seed through a preset algorithm. The device key pair includes the device private key and the device public key.

[0064] For example, the MAC address of the management network port of the baseboard management controller and the chip's built-in hardware random seed are concatenated into a 7-byte core seed, and a key pair is generated using the ECC secp256r1 algorithm. The private key is stored in the TPM and the public key is stored in the repository.

[0065] Through the embodiments described above, the deterministic algorithm based on MAC address and hardware random seed enables device key pairs to be regenerated with the same input after firmware reset. This avoids the irrecoverable problem of lost keys in traditional random key generation methods, improving system maintainability. The device uniqueness of the MAC address ensures that the generated key pair is bound to a specific BMC hardware. Even if an attacker obtains the derived algorithm and software environment, they cannot reproduce the same key pair on another device, effectively preventing cross-device copying and misuse of keys. The chip's built-in hardware random seed, as one of the core entropy sources, provides unpredictable true randomness, ensuring that the derived key pair has sufficient cryptographic strength to resist brute-force and dictionary attacks. After the private key is stored in the TPM, its original content never leaves the TPM chip under any circumstances. All signing operations are completed internally within the TPM, fundamentally defending against software-level key extraction attacks and physical-level probe attacks, meeting the stringent requirements for key storage in high-security environments. The public key is stored in the BMC repository and can be viewed through the management interface, enabling the management client to securely and conveniently obtain the device's public key for token verification. At the same time, the integrity and authenticity of the public key are guaranteed through certificate signing or secure partitioning mechanisms.

[0066] Figure 3 The flowchart illustrating step S130 of an embodiment of this application is shown in the schematic diagram.

[0067] like Figure 3 As shown, step S130 may specifically include steps S310 to S330.

[0068] In step S310, an information string is concatenated, which includes at least an operation identifier, a current session identifier, and a dynamic timeout value.

[0069] For example, dynamic timeout values ​​can be dynamically set based on operation type. Different operations may have different risk levels and expected execution times, and the timeout value matches the operation type. Specifically, as shown below: High-risk, long-duration operations (such as firmware upgrades): Set the timeout value to a longer value, such as 3600 seconds (1 hour). Medium-risk operations (such as system restart): Set the timeout value to medium, such as 600 seconds (10 minutes). For low-risk query operations (such as sensor reads): set the timeout value to a short value, such as 60 seconds (1 minute).

[0070] In a preferred embodiment, the BMC maintains a mapping table between operation types and default timeout values, and retrieves the corresponding timeout value by looking up the table based on the operation identifier when generating a token.

[0071] In this embodiment, the string concatenation can use delimiter concatenation, encoding format, JSON format, or fixed-length format, and the specific choice can be made according to the actual situation.

[0072] The above steps construct a structured information string from key information such as the operation identifier, current session identifier, and dynamic timeout value, serving as the plaintext payload of the operation token. This transforms the operation token from a simple random credential into a structured data carrier containing complete operation context information. After decoding the token, the verification terminal can directly obtain core information such as operation type, associated session, and validity period without querying any external status, providing immediate data support for subsequent timeout checks, conflict detection, and session tracing. Furthermore, the extensible structure of the information string (allowing for flexible addition of optional fields such as random numbers, device fingerprints, and operation parameter summaries) provides ample room for future expansion of the token system to support more security features (such as device binding and parameter tamper-proofing), demonstrating the evolvability and forward-looking nature of this invention.

[0073] In step S320, the information string is digitally signed based on the device private key to generate a signature string.

[0074] For example, the digital signature operation in the token generation process specifically adopts the ECC-SHA256 signature algorithm. That is, firstly, the SHA-256 cryptographic hash value (message digest) is calculated on the information string, and then the device private key (generated based on elliptic curve cryptography ECC) is used to perform a digital signature operation on the hash value, finally generating a 64-byte signature string.

[0075] The above steps employ the standard cryptographic process of "SHA-256 hashing first, then ECDSA signing" in the digital signature stage. SHA-256 hashing compresses an arbitrary-length message string into a fixed 32-byte message digest, ensuring a fixed and extremely short input length for subsequent elliptic curve signature operations. This avoids the complex padding and high computational overhead associated with directly signing variable-length message strings, significantly improving the signing efficiency of BMC in resource-constrained environments. Simultaneously, SHA-256's collision resistance ensures the uniqueness of the message string's "digital fingerprint." Any tampering with the message string will cause a change in the hash value, leading to signature verification failure, thus cryptographically guaranteeing the integrity and authenticity of the operation token.

[0076] In step S330, the signature string and the information string are encoded to generate an operation token.

[0077] For example, the data pair of information string (plaintext, structured, carrying operational context) and signature string (ciphertext, binary, carrying proof of authenticity) is encoded, converted, and formatted into a single, compact, transmittable, and parsable standardized credential string.

[0078] Specifically, the signature string can be converted using Base64 encoding. Base64 encoding converts every 3 bytes (24 bits) of binary data into 4 printable ASCII characters (6 bits per character) through a mapping table. The length of the encoded data is approximately 4 / 3 times the original length. After encoding, the information string and signature string need to be assembled into the final operation token according to the agreed format. After the operation token is generated and encoded, BMC returns it to the management client.

[0079] Using the ECC-SHA256 signature scheme to generate a fixed-length 64-byte signature string brings multiple advantages at the engineering implementation level. The fixed-length signature data allows the token generator to accurately pre-allocate a memory buffer before Base64 encoding, avoiding fragmentation and performance overhead caused by dynamic memory allocation. After decoding the token, the signature verification end can extract the signature component at a fixed offset without relying on complex parsers such as ASN.1, reducing the code complexity of the signature verification module and the risk of potential security vulnerabilities. The fixed-length signature string also has a basically constant length after Base64 encoding, which facilitates the unified management of token format and the accurate evaluation of transmission efficiency, making it particularly suitable for embedded systems with limited storage and computing resources, such as BMC.

[0080] Figure 4 A flowchart illustrating an operation request processing method according to another embodiment of this application is shown.

[0081] like Figure 4 As shown, after the operation token is verified using the device public key, steps S410 and S420 are also included.

[0082] In step S410, the operation identifier is extracted from the operation token.

[0083] For example, the operation identifier in the operation token can be extracted by referring to the method of generating the operation token, such as by using the reverse process of generating the operation token. For instance, although the payload of the operation token is Base64 encoded for transmission, the information string before encoding is itself structured text or binary data. When the information string is generated in step S130, a preset serialization format is used to organize multiple fields such as the operation identifier, session identifier, and dynamic timeout value together. Therefore, when extracting the operation identifier at the signature verification end, the payload needs to be deserialized according to the reverse process that is completely symmetrical to that at the generation end.

[0084] Specifically, if the information string uses a delimiter concatenation format, the operation identifier is usually agreed to be the first field. After the BMC restores the payload to a UTF-8 text string, it splits the string according to the agreed delimiter (such as a vertical bar or a comma) and directly takes the first split unit as the original value of the operation identifier.

[0085] If the information string uses the TLV encoding format, the operation identifier is encapsulated in a specific type of TLV structure. The BMC needs to start from the beginning of the payload and read the type identifier, data length and data value of each TLV entry in sequence. When an entry whose type identifier matches the preset operation identifier type is encountered, its data value is extracted as the operation identifier.

[0086] In step S420, the extracted operation identifier is compared with the operation type of the current operation request. If the comparison result is inconsistent, the current operation request is rejected.

[0087] For example, the operation identifier extracted from the operation token is written into a predefined field of the information string when the token is generated in step S130, and then encapsulated within the token after being signed with the device private key and Base64 encoded. After successful signature verification in step S140, the BMC retrieves the value of this identifier from the token payload using the reverse parsing method corresponding to the generating end. The operation type carried in the current operation request itself originates from the operation type parameter parsed from the original request message sent by the BMC from the management client in step S110.

[0088] In this embodiment, when the extracted operation identifier is inconsistent with the currently requested operation type, the BMC's response processing includes the following aspects: At the response level, BMC terminates further processing of the current request, ceases conflict detection and operation execution, and returns a rejection response to the management client. For HTTP / HTTPS interfaces, it returns an HTTP 400 Bad Request or HTTP 403 Forbidden status code, carrying structured error information in the response body, explicitly stating the reason for rejection as "operation token usage does not match the current request," along with the specific values ​​of the operation identifier in the token and the operation type in the request. For IPMI interfaces, it returns a custom-defined completion code, encoding the inconsistency information in the response data field.

[0089] At the log level, every rejection event triggered due to inconsistent operation identifiers is recorded in the BMC's audit log. The log content includes the timestamp of the rejection, the session identifier and source IP of the current request, the operation identifier extracted from the token, the operation type of the current request, and specific information about the discrepancy between the two, for maintenance personnel to troubleshoot problems and for subsequent security audits.

[0090] At the security monitoring level, BMC tracks the frequency of rejection events triggered by the same session or the same source IP with inconsistent operation identifiers. If multiple such rejections are triggered consecutively from the same source within a preset time window, the system identifies it as suspicious behavior and triggers a security alert, or takes proactive protective measures such as temporary blocking. This mechanism is used to prevent brute-force attacks targeting token systems.

[0091] When the operation identifier comparison results are consistent, this verification step passes. At this point, the BMC has confirmed that the token was signed by a legitimate BMC and has not been tampered with, and that the operation identifier bound to the token matches the operation type of the current request. Based on this, the BMC directly uses the operation identifier and session identifier extracted from the token to proceed to the conflict detection process in step S150. The value extracted from the token is used as the basis for subsequent processes because this value has undergone cryptographic verification and has higher credibility than the value directly parsed from the request. By comparing the operation identifier bound to the token with the operation type of the current request, it is ensured that the token is only used for its authorized operation purpose, effectively preventing the legitimate token from being reused across operations and making up for the blind spot in the defense of simple cryptographic signature verification in this security dimension.

[0092] Figure 5 A flowchart illustrating an operation request processing method according to yet another embodiment of this application is shown.

[0093] like Figure 5 As shown, when a mutually exclusive relationship is determined to exist, the method further includes steps S510 and S520.

[0094] In step S510, the session identifier and remaining time of the operation token currently occupying the relevant resources are obtained.

[0095] For example, the BMC has stored the session identifier corresponding to the token in the active token record. When a conflict detection finds a mutual exclusion relationship, the BMC directly reads the pre-stored session identifier field from the detected conflict token record. This session identifier is bound to the operation identifier when the token is generated and is persisted in the active token list when the token is active, so it can be obtained immediately when a conflict occurs.

[0096] The BMC assigns a dynamic timeout value to each token based on the operation type. This timeout value represents the maximum duration the system allows the operation to execute. During operation execution, the BMC records the elapsed time and subtracts the elapsed time from the dynamic timeout value; the difference is the estimated remaining time. For example, if a firmware upgrade operation has a dynamic timeout of 3600 seconds and has already executed for 1200 seconds since being marked as active, the estimated remaining time is 2400 seconds. This calculation method does not require the operation execution engine to report progress information additionally, making it simple to implement, but its estimation accuracy is relatively limited.

[0097] In step S520, a notification message containing the session identifier and the remaining occupancy time is sent to all online users.

[0098] For example, an online user is defined as a user who has successfully logged into the BMC management interface or established a management session after authentication. BMC maintains an active user session table, which records session information for all currently active users.

[0099] BMC's session management module maintains a data structure for active sessions. Each record contains a user ID, session ID, login time, last activity time, session status (valid or invalid), user role and permissions, and the client IP address and type from which the session originated (e.g., web browser, IPMI command line, RESTful API client). When it is necessary to retrieve all online users, BMC iterates through this data structure to filter out users corresponding to all sessions with a status of "valid".

[0100] Acquiring online users also involves role filtering logic. In data center management scenarios with a large number of users, sending notifications to all logged-in users (including those with read-only permissions) may cause information overload, and read-only users themselves cannot initiate write operations, thus limiting the practical significance of receiving conflict notifications. Therefore, in one implementation, the BMC performs role filtering on online users before sending notifications, sending notifications only to user roles with the authority to initiate operation requests (such as administrator and operator roles), while skipping user sessions with only read-only permissions.

[0101] This application embodiment pushes notification information containing session identifiers and remaining usage time to all online users, enabling the entire operations and maintenance team to share the system resource usage status, effectively avoiding the problem of multiple administrators repeatedly attempting mutually exclusive operations due to information silos.

[0102] Figure 6 A flowchart illustrating an operation request processing method according to yet another embodiment of this application is shown.

[0103] like Figure 6 As shown, the above operation request processing method further includes steps S610 to S620.

[0104] In step S610, a background scanning thread is started to traverse all active operation tokens at predetermined time intervals.

[0105] For example, the background scanning thread is automatically created and started after the BMC firmware boots up and the token management module completes initialization. This thread's operation does not depend on any management operation request triggering and is a system-level resident background service. In another implementation, the thread starts when the first operation token is marked as active to avoid consuming unnecessary system resources when there are no active tokens. In a preferred implementation, the thread starts when the system boots up to ensure real-time token management.

[0106] Specifically, the scanning thread employs a runtime model combining an infinite loop and a timed sleep cycle. At the start of each scan cycle, the thread retrieves the current system time and then iterates through the list of active tokens to perform a timeout check. After iteration, the thread enters a sleep state, awaiting the trigger of the next scan cycle. This model is simple to implement, consumes minimal CPU resources, and is suitable for embedded system environments like BMC.

[0107] In another implementation, the scanning thread employs a timer-based interrupt-driven model. The system timer generates interrupt signals at predetermined intervals, and the scanning thread is awakened upon receiving an interrupt signal and performs a scan. This model offers higher timing accuracy, and the thread can be suspended by the operating system during idle periods, further reducing resource consumption.

[0108] In this embodiment, the selection of this interval needs to strike a balance between scanning timeliness and system overhead. An interval that is too short will frequently wake up the scanning thread and increase CPU load; an interval that is too long may cause timeout tokens to remain in the system for too long. In one implementation, the predetermined time interval is set to 30 seconds by default. For scenarios with limited resources or high timeout accuracy requirements, it can be set to 10 seconds; for scenarios with ample resources or low real-time requirements, it can be set to 60 seconds. In a preferred implementation, this time interval can be dynamically configured through the BMC's management interface to adapt to the needs of different operational scenarios.

[0109] When the BMC generates an operation token, it writes the dynamic timeout value into the information string as an absolute timestamp. This timestamp is also stored in the active token record when the token is marked as active in step S160. When the scanning thread performs timeout determination, it obtains the current system time of the BMC and compares it with the absolute timeout timestamp of the token record. If the current time is greater than the timeout timestamp, the token is determined to have timed out.

[0110] In step S620, the timed-out operation token is marked as inactive and the resources it occupies are released.

[0111] For example, when a token is identified as timed out, the scanning thread checks whether the token's current state is still "active" before starting the marking and releasing operations. In one implementation, this check is achieved through an atomic "compare and swap" operation, so that the token is only updated to "timeout in progress" or "inactive" if its state is still "active," thereby avoiding duplicate reclamation of the same token by two threads simultaneously.

[0112] Specifically, the marking operation not only modifies the status field but also appends the reason for eviction (here, "timeout") and a eviction timestamp to the record. This allows for clarification of the reason and time of the token's lifecycle termination during subsequent auditing. After the status update is complete, the scanning thread physically removes the token record from the active token list. In one implementation, to preserve full auditing capabilities, the scanning thread copies the token's key information (including session identifier, operation identifier, creation time, timeout time, eviction time, etc.) to a separate "evictiond token log" buffer or persistent log file before performing the deletion operation.

[0113] After marking the timeout token as inactive and removing it from the list, the scanning thread needs to perform a resource release operation. This operation is the second step in the timeout token revoke process, and its purpose is to return the various resources occupied by the operation corresponding to the token during system operation to the system.

[0114] The types of resources that the operation corresponding to the token may occupy during its active period include one or more of the following in different implementations: Regarding memory resources, the operation may request dynamic memory buffers for storing operation parameters, intermediate data, or execution context during execution. This memory needs to be returned to the heap manager to avoid memory leaks. Regarding concurrency control resources, the operation may hold mutexes, read-write locks, or semaphores to protect shared data structures. These lock resources need to be actively released to prevent other threads or operations from being permanently blocked due to unreleased locks. Regarding hardware exclusive resources, the operation may occupy access rights to specific hardware modules, such as exclusive access to the programming interface of Flash memory, control of the I2C bus, or state locking of the power management unit. These hardware resources need to be marked as available so that other operations can access them normally. Regarding network and communication resources, the operation may establish network connections or sockets for progress reporting or remote interaction. These connections need to be properly closed to release port numbers and connection table entries. Regarding temporary storage resources, operations may create temporary files or directories in the file system to store intermediate results or logs. These temporary files need to be deleted to free up storage space.

[0115] The specific implementation of resource release varies depending on the resource type. For dynamic memory resources, the scanning thread calls the operating system's memory release function (such as the `free` function in C or the memory pool return interface provided by the operating system) to return the allocated memory block to the heap manager. For lock resources, the scanning thread calls the corresponding unlock function (such as the `unlock` or `release` method) to release the lock holding. For hardware-exclusive resources, the scanning thread calls the resource release interface provided by the hardware abstraction layer or device driver to return control of the hardware module. For network connection resources, the scanning thread calls the connection closing interface provided by the network protocol stack (such as the `close` or `shutdown` function) to normally close the socket connection and release the related resources. For temporary storage resources, the scanning thread calls the file system interface (such as the `unlink` or `rmdir` function) to delete temporarily created files or directories.

[0116] Through the aforementioned implementation of the background scanning thread and timeout token reclamation mechanism, this application prevents resource deadlock caused by token leakage. When a client experiences an abnormal disconnection or an unexpected failure occurs during operation execution, the operation token may remain permanently in the active list. The background scanning thread proactively detects and cleans up timeout tokens at predetermined intervals, ensuring that system resources can be released in a timely manner, avoiding the depletion of available resources and indefinite blocking of subsequent operations due to token leakage; thus achieving system-level fallback security protection. This mechanism does not rely on any external triggering conditions and operates independently of the normal operation request process. As the last line of defense for system stability, even if the main process malfunctions, the background scanning can still perform its reclamation duties; it supports flexible scanning strategy configuration. Through configurable scanning intervals, multi-dimensional judgment criteria based on absolute timeout or last active time, and status checks before resource release, this mechanism can adapt to the differentiated needs of different operation and maintenance scenarios and different operation types.

[0117] Figure 7 A flowchart illustrating an operation request processing method according to yet another embodiment of this application is shown.

[0118] like Figure 7 As shown, the above operation request processing method further includes steps S710 to S740.

[0119] In step S710, a target operation session is created in response to a multi-request sequence operation initiated by the user.

[0120] For example, a logical context for full-process management is established at the beginning of a multi-request sequence operation. The target operation session acts as a "container" for the sequence operation. During the session's lifecycle, it associates and manages all sub-operation requests, status information, and resource usage of the sequence operation, ensuring that each sub-operation shares the same operation token and the same conflict detection result during execution.

[0121] Specifically, after a user-initiated operation request arrives at the BMC, the BMC first parses the request to determine whether it belongs to a multi-request sequence operation that requires the creation of a target operation session. For example, based on the operation type identifier carried in the request, the BMC maintains an operation type attribute table, marking each supported operation type with its execution mode attribute, which includes two values: "single operation" and "sequence operation". When the operation type in the request is marked as "sequence operation", the BMC determines that the current request needs to enter the multi-request sequence operation processing flow. For example, the "firmware upgrade" operation is marked as a sequence operation because it needs to complete multiple sub-stages such as file upload, integrity verification, write execution, and result confirmation in sequence; while "acquire sensor temperature" is marked as a single operation because it can be completed within one request response cycle.

[0122] Once a target operation session is created, the BMC assigns it a unique identifier that identifies the session within the system. This session identifier belongs to a different level than the user login session identifier. The login session identifier is used to identify the user's authentication status, while the target operation session identifier is used to identify the execution context of a multi-request sequence operation. In one implementation, the target operation session identifier is generated using a globally unique identifier (UUID) format to ensure its uniqueness throughout the entire BMC runtime and across restart cycles.

[0123] In this embodiment, during the creation of the target operation session, the BMC performs a conflict pre-detection. The purpose is to confirm whether the system has sufficient resources to support the execution of the sequence of operations during the session creation stage, so as to avoid being forced to terminate the session due to a conflict only after the session is created and during the execution of the sub-operations.

[0124] In step S720, the same operation token is maintained during the target operation session, and the same operation token is applied to all sub-operation requests contained in the target operation session.

[0125] For example, this step establishes a one-to-one binding relationship between the operation token and the session, upgrading the token from a "single request credential" to a "session-level persistent credential," thereby providing a unified identity and context association mechanism for multi-request sequence operations.

[0126] Specifically, after a target operation session is created, the BMC generates an operation token for it. This token is immediately bound to the target operation session upon generation. In one implementation, this binding is achieved through a target operation session identifier embedded in the token's information string. The session identifier field in the token payload stores the identifier of the target operation session, not the user login session identifier. After successful signature verification, the BMC extracts the session identifier from the token and uses it to locate the corresponding target operation session context.

[0127] Throughout the entire lifecycle of the target operation session, the BMC maintains the validity and activity of the token. The token will not be released or invalidated upon completion of a single sub-operation request, nor will it be automatically replaced with a new token over time. In this embodiment, the token may become invalid under the following circumstances: the entire target operation session ends normally, the session times out and is reclaimed by the background scanning thread, the user actively cancels the operation, or a system anomaly requires forced termination of the session.

[0128] In this embodiment, all sub-operation requests included in the target operation session carry the same operation token when initiated. When the client initiates the first sub-operation request, it obtains the token from the response of the BMC; when initiating the second and all subsequent sub-operation requests, the token is included in the request until the entire sequence of operations is completed.

[0129] Upon receiving each sub-operation request, the BMC first extracts the operation token from the request and performs signature verification. After successful verification, the BMC extracts the target operation session identifier from the token and searches for the corresponding target operation session in the session management module. If no corresponding session is found (e.g., the session has been released or timed out), the sub-operation request is rejected. If a corresponding session is found, the BMC confirms that the request belongs to the sub-operation sequence of that session, and then decides how to handle the request based on the current state of the session—if the session status is "in progress," the sub-operation is executed normally; if the session status is "completed" or "timed out," the request is rejected and the corresponding error message is returned.

[0130] In step S730, when each sub-operation request is executed, the operation conflict matrix is ​​queried once at the granularity of the target operation session.

[0131] For example, this step increases the granularity of conflict detection from "a single sub-operation request" to "the entire target operation session". The conclusion of a successful query is valid throughout the entire session, and conflict detection is not repeated for all subsequent sub-operation requests, thereby avoiding repeated judgments and potential inconsistencies during the execution of sequential operations.

[0132] "Target operation session as granularity" means that the operation type targeted by the conflict matrix query is the overall operation type represented by the target operation session, rather than the individual operation types of each sub-operation within the session.

[0133] For example, a firmware upgrade sequence might consist of four sub-operations: "upload firmware file," "verify firmware integrity," "write firmware," and "confirm write result." In a single-operation scenario, if each sub-operation queries the conflict matrix separately, "upload firmware file" might not be mutually exclusive with any other operation, while "write firmware" might be mutually exclusive with a system reboot operation, leading to different conflict detection results for different sub-operations at different times. The "session-level granularity" approach, however, means that the BMC uses the overall operation type "firmware upgrade" as an index to query the conflict matrix all at once, determining whether the overall "firmware upgrade" operation is mutually exclusive with other active operations in the system. This query result remains unchanged throughout the entire firmware upgrade session.

[0134] In one implementation, the BMC maintains a mapping relationship between operation types. For operation types marked as sequence operations, the system additionally records the "overall operation type identifier" corresponding to the sequence operation, which is used for conflict matrix lookup. The type identifier of the sub-operation itself is only used for process routing and parameter validation within the execution engine and is not used for conflict matrix lookup.

[0135] In one implementation, to simplify maintenance logic, the BMC employs a locking mechanism: when a conflict query for a target operation session passes, the session's operation token is marked as active and added to the active token list. That is, from the moment the query passes, the session itself becomes an active operation "occupying resources" in the system. Subsequent operations will see the existence of this session during conflict detection and be blocked. This locking mechanism ensures that no new mutually exclusive operations are allowed to execute during session execution, thus guaranteeing the continued validity of the query results.

[0136] In step S740, when the target operation session ends or times out, the resources occupied by the operation token are released.

[0137] For example, this step is the closing step of the multi-request sequence operation token management scheme, corresponding to the single operation token timeout recovery mechanism described above. However, this step further covers the active release scenario when the session ends normally, and specifically considers the multi-sub-operation cleanup requirements unique to sequence operations.

[0138] Specifically, the end of the target operation session is caused by two different triggering conditions, and BMC executes a differentiated recycling process based on the different triggering conditions.

[0139] Normal termination means that all sub-operations within the sequence of operations have been successfully executed as expected, and the final result of the sequence of operations has been returned to the client. In one implementation, the BMC determines that the session meets the normal termination condition after receiving the successful execution response of the last sub-operation of the sequence of operations. At this time, the session status is updated from "in progress" to "completed," and the resource release process is immediately triggered. Normal termination is the expected session termination method, and its recycling process aims for completeness and thoroughness.

[0140] Timeout termination refers to a session's execution time exceeding a preset timeout threshold, or the interval between the session's last active time and the current time exceeding the maximum idle time. The detection mechanism for triggering timeout reclamation is consistent with the background scanning thread mechanism described earlier. When the background scanning thread traverses the active token list, if it finds that the target operation session corresponding to a certain token has timed out, it triggers the timeout reclamation process. Timeout termination is the system's last resort for abnormal termination, and its reclamation process aims at both security and timely resource release.

[0141] When the session termination condition is triggered, the BMC performs a resource release operation. This release operation is not simply removing the token from the active list, but requires a layer-by-layer cleanup in a specific order. For example, before resource release begins, the BMC first updates the session status to "Release in Progress" or "Terminate" to prevent new sub-operation requests from entering the session. Subsequently, the BMC sends a session termination notification to the operation execution engine, informing it that the session is about to end. Upon receiving this notification, the operation execution engine checks if there are any sub-operations currently being executed in the session. If so, the execution engine attempts to safely terminate the sub-operation (such as stopping firmware writing, closing an ongoing KVM connection, etc.) and returns confirmation to the token management module after termination. This coordinated termination mechanism ensures that the execution entities related to the session in the operation execution engine have been completely cleaned up before resource release; after confirming that the operation execution engine has completed the cleanup, the BMC removes the operation token from the active token list. The removal operation is consistent with the marking method described earlier—updating the token status to "Inactive," deleting the record from the active list, and notifying the background scanning thread that the token has been actively reclaimed and does not need to be scanned again. Simultaneously, the BMC releases the resources held by the token within the token management module, including the token's entry in the token cache, the mapping relationship between the session identifier and the token, and any existing token refresh timers. After the token is released, the BMC cleans up the resources occupied by the target operation session itself. The session data structure may contain sub-operation history, intermediate state cache, and temporary file references. For sub-operation history, the BMC archives it to the audit log or persistent storage (if necessary for later tracing) and then removes it from memory. For intermediate state cache, the BMC calls the corresponding release interface to return the memory. For temporary file references, the BMC confirms that the relevant temporary files have been deleted or cleaned up by the operation execution engine; if any residual temporary files are found, they are proactively deleted. After all resources are released, the BMC performs a confirmation operation to verify that the token has been removed from the active list, the session has been deleted from the session management table, and all related memory and temporary resources have been returned. After successful confirmation, the BMC generates a complete session end audit log, recording the session identifier, operation type, end reason (normal completion, timeout, or user cancellation), session duration, a summary of the execution results of each sub-operation, and the resource release results. This audit log is the basic data source for retrospectively tracing the session execution process and troubleshooting anomalies.

[0142] This application embodiment performs a conflict matrix query only once at the session level. This allows for smooth sequential execution of sub-operations in multi-stage operations such as firmware upgrades after the overall conflict detection passes, eliminating the need for re-judging conflicts at the initiation of each sub-operation and improving the continuity of operation execution. Global conflict detection is completed at the beginning of the sequence operation, preventing the client from being forced to interrupt the operation due to conflict detection failures in subsequent stages after incurring costs such as uploading firmware files, thus improving the user experience. Multi-request sequence operations reuse all underlying mechanisms from single-operation scenarios, including token generation, signature verification, activity marking, and background scanning, extending only the token granularity management, reducing the implementation complexity and maintenance cost of the BMC firmware. From token generation at session creation to token maintenance and dynamic management of validity during session execution, and unified release of tokens and resources upon session termination or timeout, a complete closed-loop management of multi-request sequence operations is formed from start to finish. The dynamic extension mechanism of the session timeout value ensures that the token remains valid during long-running sequence operations, preventing the operation from being incorrectly reclaimed midway due to token timeout. Whether the session completes normally or times out abnormally, the token is promptly reclaimed and the resources are fully released after the session ends, ensuring that system resources are not occupied ineffectively for a long time.

[0143] Figure 8 The diagram illustrates a system framework for the operation request processing method according to an embodiment of this application.

[0144] like Figure 8 As shown, the operation request processing system provided in this application is deployed in a baseboard management controller. This baseboard management controller provides multiple management protocol interfaces such as Redfish, IPMI, and Web through a user interface layer to receive various operation requests initiated by users. An operation lock management module is deployed within the system as the core control unit, responsible for the generation, verification, activity marking, and timeout scanning of operation tokens, and maintaining a dynamic token and session repository to record all active tokens and their associated session context information. When performing conflict detection, the operation lock management module queries the pre-configured operation conflict matrix rule base using the operation identifier as an index to determine the mutual exclusion relationship between the current operation and other active operations in the system, and issues execution instructions or returns rejection information to the power control module, firmware management module, sensor management module, and other functional modules based on the determination result. At the same time, the system records key events in the operation process (including token generation, conflict rejection, timeout recycling, etc.) in the system log and can send notification information to the administrator via email, thereby realizing a complete operation request processing closed loop from request access, token management, conflict detection, execution control, and log notification.

[0145] This application also provides an operation request processing apparatus, comprising: an acquisition module for acquiring a current operation request initiated by a user; a first determination module for determining whether the current operation request carries an operation token; a token generation module for generating an operation token corresponding to the current operation request based at least on the operation identifier and the current session identifier, wherein the operation token is generated by signing with the device's private key; a signature verification module for verifying the operation token using the device's public key if the operation token is carried, and extracting the operation identifier and session identifier from the operation token after successful verification; a second determination module for querying an operation conflict matrix using the extracted operation identifier to determine whether the current operation request has a mutually exclusive relationship with the operations corresponding to other currently active operation tokens, wherein the operation conflict matrix has preset mutual exclusion relationships between operations; a marking module for allowing the execution of the current operation request if no mutual exclusion relationship exists, and marking the operation token corresponding to the current operation request as active; and a return module for rejecting the execution of the current operation request and returning the session information corresponding to the operation token currently occupying the relevant resources if a mutual exclusion relationship exists.

[0146] In this embodiment, the implementation logic of the operation request processing device can be referred to the relevant description of the operation request processing method described above, and will not be repeated here. The operation request processing device in this embodiment can be deployed in the operation request processing system described above to implement the various steps of the operation request processing method.

[0147] Figure 9 A schematic block diagram of an electronic device according to an embodiment of this application is shown.

[0148] like Figure 9 As shown, the electronic device 9 of this embodiment includes: a screen, a processor 901, a memory 902, and a computer program 903 stored in the memory 902 and executable on the processor 901. When the processor 901 executes the computer program 903, it implements the steps in the various method embodiments described above. Alternatively, when the processor 901 executes the computer program 903, it implements the functions of each module in the various device embodiments described above.

[0149] Electronic device 9 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device with a screen. Electronic device 9 may include, but is not limited to, processor 901 and memory 902. Those skilled in the art will understand that... Figure 9 This is merely an example of electronic device 9 and does not constitute a limitation on electronic device 9. It may include more or fewer components than shown, or different components.

[0150] The processor 901 can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0151] The memory 902 can be an internal storage unit of the electronic device 9, such as a hard disk or RAM of the electronic device 9. The memory 902 can also be an external storage device of the electronic device 9, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, Flash Card, etc., equipped on the electronic device 9. The memory 902 can also include both internal and external storage units of the electronic device 9. The memory 902 is used to store computer programs and other programs and data required by the electronic device.

[0152] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0153] This application provides a computer program product that stores a computer program, which, when executed by a processor, implements the steps in the above method embodiments.

[0154] If the integrated module is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program may include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium may include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added to or subtracted according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the computer-readable medium does not include electrical carrier signals and telecommunication signals.

[0155] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains 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, can 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.

[0156] The units or modules described in the embodiments of this disclosure can be implemented in software or programmable hardware. The described units or modules can also be located in a processor, and the names of these units or modules do not necessarily constitute a limitation on the unit or module itself.

[0157] In another aspect, this disclosure also provides a computer-readable storage medium, which may be a computer-readable storage medium included in the electronic device or computer system described above; or it may be a standalone computer-readable storage medium not assembled into a device. The computer-readable storage medium stores one or more programs, which are used by one or more processors to execute the methods of the embodiments of this disclosure.

[0158] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in this disclosure 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 inventive concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

Claims

1. An operation request processing method, comprising: Get the current operation request initiated by the user; Determine whether the current operation request carries an operation token; If the operation token is not carried, then at least the operation token corresponding to the current operation request is generated based on the operation identifier and the current session identifier corresponding to the current operation request. The operation token is generated by signing with the device private key. If the operation token is carried, the operation token is verified using the device public key. After successful verification, the operation identifier and session identifier are extracted from the operation token. The extracted operation identifier is used to query the operation conflict matrix to determine whether the current operation request has a mutual exclusion relationship with the operations corresponding to other currently active operation tokens. The operation conflict matrix has preset mutual exclusion relationships between operations. If no mutual exclusion relationship exists, the current operation request is allowed to be executed, and the operation token corresponding to the current operation request is marked as active. If a mutual exclusion relationship exists, the current operation request will be rejected, and the session information corresponding to the operation token currently occupying the relevant resources will be returned.

2. The method according to claim 1, further comprising: Obtain the MAC address of the management network port of the baseboard management controller and the chip's built-in hardware random seed; The device key pair is generated by using the MAC address of the management port of the baseboard management controller and the chip's built-in hardware random seed through a preset algorithm. The device key pair includes the device private key and the device public key.

3. The method according to claim 1, wherein generating the operation token corresponding to the current operation request based at least on the operation identifier corresponding to the current operation request and the current session identifier includes: Concatenate an information string, the information string including at least the operation identifier, the current session identifier, and the dynamic timeout value; The information string is digitally signed based on the device's private key to generate a signature string; The operation token is generated by encoding the signature string and the information string.

4. The method according to claim 1, further comprising, after verifying the operation token using the device public key, the method includes: Extract the operation identifier from the operation token; The extracted operation identifier is compared with the operation type of the current operation request. If the comparison result is inconsistent, the current operation request is rejected.

5. The method according to claim 1, further comprising, when determining that a mutual exclusion relationship exists: Obtain the session identifier and remaining time of the operation token currently occupying the relevant resources; Send a notification message containing the session identifier and the remaining time to all online users.

6. The method according to claim 1, further comprising: Start a background scanning thread to iterate through all active operation tokens at predetermined time intervals; Mark expired operation tokens as inactive and release the resources they occupy.

7. The method according to claim 1, further comprising: In response to a user-initiated multi-request sequence, create a target operation session; The same operation token is maintained during the target operation session and is applied to all sub-operation requests contained in the target operation session; When each of the sub-operation requests is executed, the operation conflict matrix is ​​queried once at the granularity of the target operation session; When the target operation session ends or times out, the resources occupied by the operation token are released.

8. An operation request processing apparatus, comprising: The acquisition module is used to acquire the current operation request initiated by the user; The first determining module is used to determine whether the current operation request carries an operation token. If the token generation module does not carry the operation token, it generates an operation token corresponding to the current operation request based at least on the operation identifier and the current session identifier corresponding to the current operation request. The operation token is generated by signing with the device private key. If the operation token is carried, the signature verification module verifies the operation token using the device public key. After successful verification, the operation identifier and session identifier are extracted from the operation token. The second determining module queries the operation conflict matrix using the extracted operation identifier to determine whether the current operation request has a mutual exclusion relationship with the operations corresponding to other currently active operation tokens. The operation conflict matrix is ​​preset with mutual exclusion relationships between operations. If no mutual exclusion relationship exists, the marking module allows the execution of the current operation request and marks the operation token corresponding to the current operation request as active. If a mutual exclusion relationship exists, the return module will refuse to execute the current operation request and return the session information corresponding to the operation token currently occupying the relevant resources.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the method of any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program that, when executed by a processor, implements the method of any one of claims 1 to 7.

Images