Request verification method and coal bidding request verification method

Abstract

The embodiment of the present specification provides a request verification method and a coal bidding request verification method. The request verification method comprises: obtaining a target request sent by a target object for a target activity, wherein the target request carries target request information and a target request token corresponding to the target request information; generating a target request identifier of the target request based on the target request information; extracting an auxiliary request identifier from a verification information library according to the target request token, wherein the verification information library comprises a plurality of candidate request identifiers respectively carrying candidate request tokens, and the auxiliary request token corresponding to the auxiliary request identifier is the same as the target request token; and determining a request verification result of the target request according to the target request identifier and the auxiliary request identifier. Thus, the historical request identifier can be associated with the request token, and the verification result can be determined based on the current request identifier and the historical request identifier, thereby reducing the situation that the request information is tampered with, the request token is reused, and the request is replayed.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of information security technology, and in particular to a request verification method and a coal bidding request verification method. Background Technology

[0002] In internet marketing campaigns, online transactions, and various high-concurrency scenarios, server-side interfaces often face security threats such as malicious order manipulation, forged requests, replay attacks, and data tampering. If client-initiated requests are not strictly verified, it can lead to the illegal seizure of campaign resources and distortion of business data, and may also cause serious financial losses and system risks. Therefore, an effective request verification solution is urgently needed.

[0003] Currently, most request verification schemes use single-dimensional verification, such as relying solely on fixed signatures to verify parameter integrity or solely on token verification. However, these methods have significant drawbacks: on the one hand, static signatures are easily cracked or replayed, and the verification process is coupled with sensitive parameters, increasing the risk of leakage; on the other hand, simple token verification cannot detect content tampering and lacks semantic binding, which means that legitimate tokens may be used for illegal requests. Summary of the Invention

[0004] In view of this, embodiments of this specification provide a request verification method. One or more embodiments of this specification also relate to a coal bidding request verification method, a request verification device, a coal bidding request verification device, a computing device, a computer-readable storage medium, and a computer program product, to address the technical deficiencies existing in the prior art.

[0005] According to a first aspect of the embodiments of this specification, a request verification method is provided, comprising: Obtain the target request sent by the target object for the target activity, wherein the target request carries target request information and the target request token corresponding to the target request information; Based on the target request information, generate the target request identifier for the target request; Based on the target request token, the auxiliary request identifier is extracted from the verification information database. The verification information database includes multiple candidate request identifiers, each carrying a candidate request token. The auxiliary request token corresponding to the auxiliary request identifier is the same as the target request token. The request verification result of the target request is determined based on the target request identifier and the auxiliary request identifier.

[0006] According to a second aspect of the embodiments of this specification, a method for verifying coal bidding requests is provided, comprising: Obtain the coal bidding request sent by the target user for the coal bidding activity, wherein the coal bidding request carries coal bidding request information and the coal bidding request token corresponding to the coal bidding request information; Based on the coal bidding request information, a coal bidding request identifier is generated for the coal bidding request; Based on the coal bidding request token, the coal bidding auxiliary request identifier is extracted from the verification information database. The verification information database includes multiple candidate coal bidding request identifiers, each carrying a candidate coal bidding request token. The coal bidding auxiliary request token corresponding to the coal bidding auxiliary request identifier is the same as the coal bidding request token. The coal bidding request verification result is determined based on the coal bidding request identifier and the coal bidding auxiliary request identifier.

[0007] According to a third aspect of the embodiments of this specification, a request verification apparatus is provided, comprising: The first acquisition module is configured to acquire the target request sent by the target object for the target activity, wherein the target request carries target request information and the target request token corresponding to the target request information; The first generation module is configured to generate a target request identifier for the target request based on the target request information; The first extraction module is configured to extract auxiliary request identifiers from the verification information database based on the target request token. The verification information database includes multiple candidate request identifiers, each carrying a candidate request token. The auxiliary request token corresponding to the auxiliary request identifier is the same as the target request token. The first determining module is configured to determine the request verification result of the target request based on the target request identifier and the auxiliary request identifier.

[0008] According to a fourth aspect of the embodiments of this specification, a coal bidding request verification device is provided, comprising: The second acquisition module is configured to acquire the coal bidding request sent by the target user for the coal bidding activity, wherein the coal bidding request carries coal bidding request information and the coal bidding request token corresponding to the coal bidding request information. The second generation module is configured to generate a coal bidding request identifier based on the coal bidding request information. The second extraction module is configured to extract a coal bidding auxiliary request identifier from the verification information database based on the coal bidding request token. The verification information database includes multiple candidate coal bidding request identifiers that each carry a candidate coal bidding request token. The auxiliary coal bidding request token corresponding to the coal bidding auxiliary request identifier is the same as the coal bidding request token. The second determining module is configured to determine the coal bidding request verification result of the coal bidding request based on the coal bidding request identifier and the coal bidding auxiliary request identifier.

[0009] According to a fifth aspect of the embodiments of this specification, a computing device is provided, comprising: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the first aspect of the method or the second aspect described above.

[0010] According to a sixth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores a computer program / instructions that, when executed by a processor, implement the steps of the method described in the first or second aspect above.

[0011] According to a seventh aspect of the embodiments of this specification, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement the steps of the method described in the first or second aspect above.

[0012] This specification provides a request verification method in one embodiment. It associates a target request token with a historical request identifier and regenerates the target request identifier based on the target request information when the target request is submitted. This allows the request verification process to simultaneously associate the current request information with the historical request information corresponding to the target request token, thereby reducing the likelihood of the target request token being reused after the target request information has been modified. Furthermore, by combining candidate request tokens, object verification results, token status information, and target activity information for verification, the method can reduce instances of obtaining a request token without passing object verification, reuse of the request token, and request replay, thus improving the accuracy and security of request verification. Attached Figure Description

[0013] Figure 1 This is a flowchart of a request verification method provided in one embodiment of this specification; Figure 2 This is a flowchart of a coal bidding request verification method provided in one embodiment of this specification; Figure 3 This is an architecture diagram of a request processing system provided in one embodiment of this specification; Figure 4 This is a schematic diagram of a request verification interface provided in one embodiment of this specification; Figure 5 This is a schematic diagram of the structure of a request verification device provided in one embodiment of this specification; Figure 6 This is a schematic diagram of the structure of a coal bidding request verification device provided in one embodiment of this specification; Figure 7 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0014] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0015] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items. The term “at least one” as used in one or more embodiments of this specification means “one or more,” and “a plurality of” means “two or more.” The term “comprising” is an open-ended description and should be understood as “including but not limiting,” and may include other content in addition to what has been described.

[0016] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0017] Furthermore, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in one or more embodiments of this specification are obtained through open-source datasets or public datasets that comply with their license agreements, or are obtained with full authorization from the relevant parties. Moreover, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0018] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0019] A client is a program, device, or application instance that communicates with a server and is able to send requests to the server and receive results from the server. Clients can run on terminal devices, browsers, applications, or other devices with communication capabilities.

[0020] A server is a computing device, server cluster, or service system that can receive requests sent by clients and process, validate, or respond to those requests. Servers can be used to perform tasks such as request reception, information storage, token generation, request validation, and result return.

[0021] Human-machine verification refers to a verification method used to distinguish whether the request initiator is a genuine user. Human-machine verification can include image verification, swipe verification, behavior trajectory verification, SMS verification, device environment verification, or a combination of multiple verification methods.

[0022] A request token is a token generated and issued by the server to the client. Request tokens can be used to indicate that the client has completed a specific verification process, or to assist the server in identifying whether a request meets preset verification conditions in subsequent requests.

[0023] An identifier is a label used to represent a specific object, information, or data content. Identifiers can be generated based on the information to be processed and used to find, compare, associate, or verify the corresponding information content.

[0024] A replay request refers to a request initiator repeatedly sending a request that has already been sent, or reusing previously obtained request data, token information, or other content to initiate a new request. Replay requests may cause the server to process the same request content repeatedly.

[0025] An API (Application Programming Interface) is a specification of the interface used for data exchange and function calls between different programs, systems, services, or modules. An API typically includes an interface address, request method, request parameters, return parameters, authentication rules, or calling protocol. Through APIs, clients, servers, or other system modules can send requests, receive responses, or invoke corresponding functions according to preset rules.

[0026] This specification provides a request verification method, and also relates to a coal bidding request verification method, a request verification device, a coal bidding request verification device, a computing device, a computer-readable storage medium, and a computer program product, which will be described in detail in the following embodiments.

[0027] See Figure 1 , Figure 1This specification shows a flowchart of a request verification method according to an embodiment, which specifically includes the following steps: Step 102: Obtain the target request sent by the target object for the target activity, wherein the target request carries target request information and the target request token corresponding to the target request information.

[0028] It should be noted that the target object refers to the participating object that initiates the target request or corresponds to the target request. Target objects typically include users, clients, terminal devices, application instances, virtual roles, business entities, or other objects that can directly or indirectly send requests to the server. Target objects can be used to characterize the source of the target request, enabling the server to determine the association between the target request and the corresponding participating object during the request verification process, thereby facilitating subsequent identification and verification of the target request. For example, a target object can be a user participating in an online registration activity through a client, an object initiating a data submission request through a terminal device, or a virtual role or application instance performing resource acquisition, permission unlocking, task confirmation, or sensitive operations in an interactive application. In any scenario involving object participation, request submission, resource acquisition, permission confirmation, or sensitive operation verification, the request initiator or request associated party can be considered the target object in the embodiments of this specification.

[0029] A target activity refers to the activity, task, process, or matter targeted by the target request. A target activity typically includes information such as an activity identifier, activity type, activity status, or activity time range. Target activities can be used to define the processing scenario corresponding to the target request, enabling the server to determine the activity object associated with the target request. For example, a target activity can be an online registration activity, a data submission activity, a reservation activity, a qualification confirmation activity, or a task processing flow. Target activities can be various online marketing or interactive activities, and can also cover emerging digital consumption forms such as in-game resource allocation, virtual asset trading, and paid knowledge unlocking. Any online activity involving user participation, resource allocation, or sensitive operations that needs to be protected against forgery and abuse can be considered a target activity in the embodiments of this specification.

[0030] Target request information refers to the information in a target request used to describe the content of the request. Target request information typically includes request parameters, request content, request type, request time, request object, operation type, or request fields related to the target activity. Target request information can be used to generate a target request identifier, enabling the identifier to characterize the specific content of the target request, so that subsequent determination of whether the target request corresponds to the corresponding request token can be made based on the target request identifier. For example, target request information may include form content, data summary, operation type, target activity identifier, request time, resource acquisition information, permission confirmation information, or task processing information submitted by the target object in the target activity. Any information that can describe the content, scope, object, or purpose of a request initiated by the target object for the target activity can be used as target request information in the embodiments of this specification.

[0031] A target request token is a token information carried in a target request that corresponds to the target request information. Target request tokens can typically be strings, encoded fields, token identifiers, encrypted fields, or other token data that can be recognized by the server. Target request tokens can be used to look up corresponding auxiliary request identifiers in a verification database, thus providing a basis for subsequent judgments on whether the target request information corresponds to historical request information. For example, target request tokens can be carried in the target request's request parameters, request fields, request message, or other request data. Target request tokens can be used in scenarios such as data submission, appointment confirmation, permission unlocking, resource retrieval, task confirmation, or sensitive operation verification to assist the server in identifying whether the target request meets preset verification conditions.

[0032] In practical applications, there are various ways to obtain target requests sent by a target object for a target activity. The specific method is chosen based on the actual situation, and this specification does not impose any limitations on these methods. In one possible implementation, the server can receive the target request sent by the target object through a preset request interface. Specifically, the target object can send a target request to the server through a client. After receiving the target request, the server parses the request parameters, request message, request fields, or other request data in the target request to obtain the target request information and target request token carried by the target request. In another possible implementation, the server can obtain the target request sent by the target object through a gateway, message queue, or intermediate service. Specifically, the target request sent by the target object can first be received and forwarded by the gateway, message queue, or intermediate service. The server then obtains the target request from the forwarded request data and parses it to obtain the target request information and target request token carried by the target request.

[0033] Step 104: Generate the target request identifier based on the target request information.

[0034] It should be noted that the target request identifier refers to the identification information generated based on the target request information, used to characterize the target request. The target request identifier typically includes strings, encoded values, digest values, index values, hash values, or other data that can characterize the target request information. The target request identifier can be used in subsequent steps to compare with auxiliary request identifiers to determine whether the target request matches the historical request information corresponding to the target request token. For example, if the target request information includes target activity identifiers, operation types, request parameters, data digests, resource acquisition information, or permission confirmation information, a corresponding target request identifier can be generated based on the above content.

[0035] It should be noted that the target request identifier can be used to reflect the content characteristics of the target request information. When the key content in the target request information changes, the target request identifier generated based on the target request information may also change accordingly. Therefore, after the target object obtains the target request token, if the target request information is modified, the target request identifier generated by the server based on the modified target request information may be inconsistent with the auxiliary request identifier corresponding to the target request token. This facilitates the server's identification of whether the target request information and the target request token still correspond.

[0036] In practical applications, there are various ways to generate a target request identifier based on target request information. The specific method chosen depends on the actual situation, and this specification does not limit this approach. One possible implementation involves standardizing the target request information to obtain standardized target request information, and then generating a target request identifier based on the standardized target request information. The standardization process may include at least one of the following: field sorting, format conversion, null value handling, character encoding unification, or redundant field filtering. Another possible implementation involves extracting key information representing the target request from the target request information according to a preset identifier generation rule, and generating a target request identifier based on this key information. The preset identifier generation rule may include a digest algorithm, an encoding algorithm, a mapping rule, or a combination thereof.

[0037] In some embodiments, when generating a candidate request identifier, random information generated by the server can also be obtained, and a candidate request identifier can be generated based on the candidate request information and the random information. The random information can be stored in association with the candidate request identifier or the candidate request token. Subsequently, when generating the target request identifier, the corresponding random information can be obtained based on the target request token, and the target request identifier can be generated based on the target request information and the random information. This reduces the possibility of different request information generating the same request identifier under specific circumstances.

[0038] In one optional embodiment of this specification, the process of generating a target request identifier based on target request information may further include the following steps: Obtain the request attribute information of the target request, wherein the request attribute information includes at least one of the target object information of the target object and the target activity information of the target activity; Based on the target request information and request attribute information, generate the target request identifier.

[0039] It should be noted that request attribute information refers to information associated with the target request and capable of helping to characterize the request context in which the target request occurs. Request attribute information typically includes at least one of target object information and target activity information. Through request attribute information, the target request identifier can be associated not only with the target request information but also with the object or activity corresponding to the target request. For example, request attribute information can be information such as target object identifier, client identifier, device identifier, session identifier, target activity identifier, activity status, or activity time range.

[0040] Target object information refers to information used to characterize a target object. Target object information typically includes target object identifiers, user identifiers, client identifiers, device identifiers, or session identifiers. Through target object information, a target request identifier can be associated with the target object sending the target request, which helps reduce the reuse of request tokens between different target objects. For example, target object information can be the user identifier of the target object, or it can be the device identifier of the terminal device used by the target object.

[0041] Target activity information refers to information used to characterize a target activity. Target activity information typically includes information such as the target activity identifier, activity status, activity time range, or activity processing rules. Through target activity information, a target request identifier can be associated with the target activity targeted by the target request, which helps reduce the reuse of the same request token across different target activities. For example, target activity information can be the target activity identifier or information about whether the target activity is currently in a processable state.

[0042] In practical applications, there are various ways to obtain the request attribute information of a target request, and the specific method chosen depends on the actual situation. This specification does not impose any limitations on these methods in its embodiments. In one possible implementation, the request attribute information can be obtained by parsing the target request. For example, the target request may carry target request information and a target request token, which can be located in the target request's request parameters, request message, request fields, or other request data. In another possible implementation, the request attribute information can be obtained by querying based on the target request information. For example, the server can query target activity information based on the target activity identifier in the target request information, or determine the target object information based on the session information corresponding to the target request.

[0043] In practical applications, there are various ways to generate a target request identifier based on target request information and request attribute information. The specific method chosen depends on the actual situation, and this specification does not impose any limitations on this method. In one possible implementation, the target request information and request attribute information can be concatenated, sorted, or formatted to obtain information to be processed, and a target request identifier can be generated based on this information. In another possible implementation, key information representing the target request can be extracted from both the target request information and request attribute information, and then a target request identifier can be generated based on the extracted key information. For example, if the target request information includes request content and operation type, the target request identifier can be further generated by combining the target object identifier and the target activity identifier; if the target request information includes request parameters, the target request identifier can also be further generated by combining the target activity status.

[0044] By applying the scheme of the embodiments of this specification, a target request identifier is generated by combining target request information and request attribute information. This allows the target request identifier to simultaneously represent the request content and the object or activity associated with the request, which helps to improve the accuracy of the correspondence between the target request identifier and the target request, thereby providing a basis for subsequent request verification.

[0045] Step 106: Extract the auxiliary request identifier from the verification information database based on the target request token. The verification information database includes multiple candidate request identifiers that each carry a candidate request token. The auxiliary request token corresponding to the auxiliary request identifier is the same as the target request token.

[0046] It's important to note that a verification information database refers to a data set used to store the correspondence between candidate request identifiers and candidate request tokens. A verification information database typically includes databases, tables, cache spaces, distributed storage systems, or other data structures capable of storing and retrieving verification information. Through the verification information database, a candidate request token can be found based on a target request token, and the corresponding candidate request identifier can be further determined, thus providing auxiliary information for subsequent request verification. For example, the verification information database can be a token verification table maintained by the server, or a data set in a distributed cache used to store the correspondence between request identifiers and request tokens. Verification information databases can be applied to online document submission, appointment confirmation, permission unlocking, resource retrieval, task confirmation, or other scenarios requiring the association and verification of request tokens and request information.

[0047] A candidate request identifier is a request identifier pre-generated and stored in a verification information database. Candidate request identifiers typically include strings, encoded values, digest values, hash values, index values, or other data that can characterize candidate request information. Using candidate request identifiers, historical request identifiers can be provided during the target request verification stage for comparison with the target request identifier to determine whether the target request information corresponds to the request information generated during the candidate request stage. For example, a candidate request identifier can be a digest value generated based on candidate request information, or an encoded value generated according to preset identifier generation rules. In a data submission scenario, candidate request identifiers can be generated based on information such as data type, data digest, submission operation type, and activity identifier; in an appointment confirmation scenario, candidate request identifiers can be generated based on information such as appointment item, appointment time period, confirmation operation type, and activity identifier.

[0048] A candidate request token is a token information corresponding to a candidate request identifier. Candidate request tokens typically include strings, token numbers, encoded fields, encrypted fields, or other token data that can be recognized by the server. Through candidate request tokens, a lookup relationship can be established between target request tokens and candidate request identifiers, enabling the server to reverse-engineer the corresponding historical request identifier based on the target request token during the target request stage. For example, a candidate request token can be a token string generated by the server after a candidate object passes object verification and associated with a candidate request identifier. Candidate request tokens can be used in subsequent requests such as formal data submission, appointment confirmation, permission unlocking, resource retrieval, or task confirmation to help the server confirm whether subsequent requests correspond to the information from the candidate request stage.

[0049] Auxiliary request identifiers are candidate request identifiers extracted from the verification information database based on the target request token. These identifiers typically originate from candidate request tokens in the verification information database that match the target request token. Using auxiliary request identifiers, they can be compared with the target request identifier in subsequent steps to determine if the target request information matches the historical request information corresponding to the target request token. For example, when the target request token is identical to a candidate request token in the verification information database, the candidate request identifier corresponding to that token can be identified as the auxiliary request identifier. Therefore, even if the target object resends the request during the target request phase, the server can still find the historical request identifier corresponding to the candidate request phase based on the target request token.

[0050] A secondary request token is a request token corresponding to a secondary request identifier. Secondary request tokens are typically candidate request tokens in the verification information database that correspond to the secondary request identifier. Through secondary request tokens, it can be shown that the secondary request identifier was determined from the verification information database based on token information identical to the target request token. For example, if a candidate request token in the verification information database is identical to the target request token, then that candidate request token can be used as the secondary request token corresponding to the secondary request identifier, and the candidate request identifier corresponding to that candidate request token can be used as the secondary request identifier. This establishes a correspondence between the target request token, secondary request tokens, and secondary request identifiers, providing a basis for subsequently determining the request verification result.

[0051] In practical applications, there are multiple ways to extract auxiliary request identifiers from the verification information database based on the target request token. The specific method chosen depends on the actual situation, and this specification does not impose any limitations on this approach. In one possible implementation, the target request token can be used as a query condition to search the verification information database for candidate request tokens identical to the target request token, and the candidate request identifier corresponding to that candidate request token can be identified as the auxiliary request identifier. In another possible implementation, the target request token can be parsed first to obtain the token index or token identifier within the target request token. Then, a matching query can be performed in the verification information database based on the token index or token identifier to determine the candidate request tokens corresponding to the target request token, and the corresponding candidate request identifier can be extracted as the auxiliary request identifier.

[0052] For example, in a data submission activity, when a target submits a target request, it carries a target request token. The server can use this target request token to query the verification information database for the corresponding candidate request token and extract the candidate request identifier corresponding to the candidate request token as an auxiliary request identifier. As another example, in a reservation activity, when a target submits a confirmation request, it carries a target request token. The server can use this target request token to determine the matching candidate request token in the verification information database and obtain the corresponding auxiliary request identifier.

[0053] In one optional embodiment of this specification, before retrieving the auxiliary request identifier from the verification information database based on the target request token, the following steps may be included: Retrieve candidate requests sent by candidate objects for candidate activities, wherein the candidate requests carry candidate request information; Based on the candidate request information, a candidate request identifier is generated for each candidate request. Generate a candidate request token that identifies the candidate request; The candidate request identifier and candidate request token are associated and stored in the verification information database.

[0054] It should be noted that a candidate object refers to an object that sends a candidate request before the target request is verified. The candidate object typically includes users, clients, terminal devices, application instances, or other objects capable of initiating a request. The source of the candidate request can be determined through the candidate object. For example, the candidate object could be a user who submits a candidate request through a client.

[0055] A candidate activity refers to the activity, task, process, or matter targeted by a candidate request. A candidate activity typically includes information such as a candidate activity identifier, candidate activity status, candidate activity time range, or candidate activity processing rules. Through the candidate activity, the processing scenario corresponding to the candidate request can be determined. For example, the candidate activity could be an online registration activity, a document submission activity, a reservation activity, or a qualification confirmation activity.

[0056] A candidate request is a request sent by a candidate object to a candidate activity to generate a candidate request identifier and a candidate request token. A candidate request typically includes request parameters, request fields, a request message, or a request sending time. Through the candidate request, basic request data to be associated can be provided for the subsequent target request verification stage. For example, the candidate request can be a pre-verification request sent by the candidate object before the target request is submitted.

[0057] Candidate request information refers to the information in a candidate request used to describe its content. This information typically includes request content, request type, request parameters, request time, or request fields related to the candidate activity. Candidate request identifiers can be generated using this information. For example, the candidate request information could be form content submitted by a candidate object for a candidate activity, operation type, candidate activity identifier, or request time.

[0058] A candidate request identifier is an identifier generated based on candidate request information and used to characterize a candidate request. The candidate request identifier typically includes data such as a string, encoded value, digest value, or index value. This candidate request identifier can be used as a historical identifier for comparison with the target request identifier in the subsequent target request verification stage. For example, the candidate request identifier can be a digest value generated based on the candidate request information.

[0059] A candidate request token refers to token information generated corresponding to a candidate request identifier. The candidate request token typically includes a string, token number, encoded field, or other token data that can be recognized by the server. Through the candidate request token, a correspondence can be established between the candidate request identifier and the subsequent target request token. For example, the candidate request token can be a token string generated by the server and returned to the candidate object.

[0060] In practical applications, there are various ways to obtain candidate requests sent by candidate objects for candidate activities, and the specific method should be selected according to the actual situation. This specification does not impose any limitations on these methods in the embodiments. In one possible implementation, the candidate request sent by the candidate object is received through a preset request interface on the server side, and the candidate request is parsed to obtain the candidate request information carried in the request. In another possible implementation, the candidate request sent by the candidate object can be obtained through a gateway, message queue, or intermediate service, and the candidate request information can be determined from the received request data.

[0061] In practical applications, there are various ways to generate candidate request identifiers based on candidate request information. The specific method chosen depends on the actual situation, and this specification does not impose any limitations on this method. In one possible implementation, the candidate request information can be standardized, and a candidate request identifier can be generated based on the standardized information. In another possible implementation, key information representing the candidate request can be extracted from the candidate request information according to preset identifier generation rules, and a candidate request identifier can be generated based on the extracted key information.

[0062] In practical applications, there are various ways to generate candidate request tokens that identify candidate request identifiers. The specific method chosen depends on the actual situation, and this specification does not impose any limitations on this method. In one possible implementation, candidate request tokens can be generated according to preset token generation rules, and a correspondence between candidate request tokens and candidate request identifiers can be established. In another possible implementation, candidate request tokens can be generated based on at least one of candidate request identifiers, candidate object information, candidate activity information, or token generation time, enabling the candidate request tokens to correspond to candidate request identifiers.

[0063] In practical applications, there are various ways to associate and store candidate request identifiers and candidate request tokens in the verification information database. The specific method chosen depends on the actual situation, and this specification does not impose any limitations on this approach. In one possible implementation, the candidate request identifier and candidate request token can be stored as association fields in a database, data table, or file system. In another possible implementation, the candidate request identifier and candidate request token can be associated and stored in a cache space or distributed storage system, so that the auxiliary request identifier can be retrieved from the verification information database later based on the target request token.

[0064] In some embodiments, after generating the candidate request token, the candidate request token can also be sent to the client corresponding to the candidate object, so that the candidate object carries the candidate request token when sending the target request in the future, as the target request token corresponding to the target request information.

[0065] By applying the scheme of the embodiments of this specification, by generating candidate request identifiers and candidate request tokens respectively and storing them in a verification information database, a data foundation can be provided for extracting auxiliary request identifiers based on target request tokens in the future, which is conducive to establishing the correspondence between target request tokens and candidate request identifiers.

[0066] In one optional embodiment of this specification, before generating the candidate request token that identifies the candidate request, the following steps may be included: Generate object verification information for candidate objects and send the object verification information to the candidate objects; Obtain the object verification results of the candidate objects based on the object verification information; The candidate request token that generates the candidate request identifier includes: If the object verification result indicates that the candidate object has passed the verification, a candidate request token with a candidate request identifier is generated.

[0067] It should be noted that, Object verification information refers to information used to verify candidate objects. This object verification information typically includes at least one of the following: verification content, verification parameters, verification rules, verification page information, or verification control information. By using this object verification information, candidate objects can complete the corresponding verification process before obtaining a candidate request token, which helps reduce the possibility of abnormal objects directly obtaining the candidate request token. For example, the object verification information can be graphic verification information, behavioral verification information, question verification information, or a combination of multiple verification information.

[0068] The object verification result refers to the verification result obtained after the candidate object receives feedback based on the object verification information. The object verification result typically includes a verification pass result or a verification failure result, and may also include verification operation data, verification response data, or verification status data. Through the object verification result, it can be determined whether the candidate object meets the conditions for generating a candidate request token. For example, the object verification result can be a verification pass result determined by the server after the candidate object completes the verification operation.

[0069] In practical applications, there are multiple ways to generate object verification information for candidate objects and send the object verification information to the candidate objects. The specific method is selected based on the actual situation, and this specification does not limit this approach. In one possible implementation, the server can generate object verification information according to preset verification rules and display the object verification information to the candidate object through the client corresponding to the candidate object. In another possible implementation, the server can call a verification service to generate object verification information and send the object verification information to the client corresponding to the candidate object through a preset interface.

[0070] In practical applications, there are multiple ways to obtain the object verification result fed back by the candidate object based on the object verification information. The specific method is selected according to the actual situation, and the embodiments in this specification do not impose any limitations on this. In one possible implementation of this specification, the verification response data submitted by the candidate object based on the object verification information can be received, and the object verification result can be determined based on the verification response data. In another possible implementation of this specification, the object verification result returned by the verification service can be received, wherein the verification service can determine the object verification result based on the verification response data fed back by the candidate object.

[0071] In practical applications, when the object verification result indicates that the candidate object has passed verification, there are multiple ways to generate a candidate request token with a candidate request identifier. The specific method is selected based on the actual situation, and this specification does not limit this approach. In one possible implementation, if the object verification result is successful, a candidate request token can be generated according to a preset token generation rule, and a correspondence between the candidate request token and the candidate request identifier can be established. In another possible implementation, if the object verification result is successful, a candidate request token can be generated based on at least one of the following: candidate request identifier, candidate object information, candidate activity information, or token generation time.

[0072] For example, in a data submission activity, the server can first send object verification information to the candidate object, and generate a candidate request token corresponding to the candidate request identifier when the candidate object returns an object verification result indicating that the verification has passed. As another example, in a reservation activity, the server can generate a candidate request token with the candidate request identifier after the candidate object has completed object verification.

[0073] Specifically, in a data submission activity, the candidate activity can be a data submission process, the candidate object can be a user participating in the data submission process, and the candidate request can be a pre-verification request sent by the user before formally submitting the data. The candidate request information can include the data submission activity identifier, data type, submission operation type, and summary information of the data to be submitted. After receiving the candidate request, the server can generate a candidate request identifier based on the candidate request information.

[0074] Before generating candidate request tokens, the server can generate object verification information for the candidate objects and send this information to the corresponding client. The client can then display the object verification information to the candidate objects and receive feedback actions from them based on that information. The server can then determine the object verification result based on the feedback actions from the candidate objects.

[0075] If the object verification result indicates that the candidate object has passed the verification, the server generates a candidate request token corresponding to the candidate request identifier and stores the candidate request identifier and candidate request token together in the verification information database. When the candidate object is formally submitted later, it can carry the target request token, enabling the server to extract the auxiliary request identifier from the verification information database based on the target request token and verify the formally submitted target request.

[0076] By applying the solution in the embodiments of this specification, and by verifying the candidate object before generating the candidate request token, the generation process of the candidate request token can be associated with the verification result of the candidate object, which helps to improve the security of candidate request token generation.

[0077] In one optional embodiment of this specification, the above-mentioned generation of candidate object verification information may include the following steps: Get the activity end time and candidate request time of the candidate activities; The object verification strength is determined based on the activity end time and the candidate request time. Based on the object verification strength, generate object verification information for candidate objects.

[0078] It should be noted that object validation strength refers to the degree of validation strength used when generating object validation information. Object validation strength is typically reflected by at least one of the following: validation content complexity, validation operation requirements, validation error tolerance range, validation response time requirements, or re-validation interval. By adjusting object validation strength, the validation requirements of the object validation information can be adjusted according to the time stage of the candidate request. For example, if the candidate request time is far from the event end time, the object validation strength can be lower; if the candidate request time is close to the event end time, the object validation strength can be higher.

[0079] In practical applications, there are multiple ways to obtain the activity end time of a candidate activity and the candidate request time of a candidate request. The specific method chosen depends on the actual situation, and this specification does not impose any limitations on these methods. In one possible implementation, the activity end time of a candidate activity can be obtained by querying the activity information database based on the candidate activity identifier, and the time when the server receives the candidate request can be determined as the candidate request time. In another possible implementation, the activity end time can be obtained from the activity configuration information corresponding to the candidate activity, and the candidate request time can be determined from the request time field carried in the candidate request or from the request reception record.

[0080] In practical applications, there are multiple ways to determine object verification strength based on the activity end time and candidate request time. The specific method chosen depends on the actual situation, and this specification does not impose any limitations on this approach. One possible implementation of this specification is to determine the time stage corresponding to the candidate request based on the time difference between the activity end time and the candidate request time, and then determine the object verification strength based on that time stage. Another possible implementation of this specification is to pre-set the correspondence between different remaining duration ranges and object verification strengths, and then query the corresponding object verification strength based on the remaining duration determined by the activity end time and the candidate request time.

[0081] In practical applications, there are various ways to generate object verification information for candidate objects based on object verification strength. The specific method chosen depends on the actual situation, and this specification does not impose any limitations on this approach. In one possible implementation, when the object verification strength is high, the operational precision requirements, response time requirements, or behavioral trajectory verification requirements in the object verification information can be increased. In another possible implementation, when the object verification strength is high, the tolerance range for verification errors can be narrowed, verification operation steps can be increased, or the interval for obtaining object verification information again can be extended.

[0082] The solution implemented in this specification determines the object verification strength based on the activity end time of the candidate activity and the candidate request time of the candidate request, and generates object verification information based on the object verification strength. This allows the object verification information to be adapted to the activity time stage of the candidate request, which is beneficial to improving the security of the object verification process.

[0083] Step 108: Determine the request verification result of the target request based on the target request identifier and the auxiliary request identifier.

[0084] It should be noted that the request verification result refers to the result information used to characterize whether the target request has passed verification. The request verification result typically includes verification pass result, verification failure result, abnormal result, result requiring supplementary verification, or other information that can characterize the verification status. Through the request verification result, it can be determined whether a preset verification relationship is satisfied between the target request identifier and the auxiliary request identifier, thus providing a basis for whether to continue processing the target request, whether to intercept the target request, whether to prompt for re-verification, or whether to update the target request token status. For example, the request verification result can be a status code indicating that the target request has passed verification, a prompt indicating that the target request has failed verification, or a status information indicating that the target request needs to be re-verified. In scenarios such as data submission, appointment confirmation, permission unlocking, resource retrieval, task confirmation, or sensitive operation verification, the server can determine whether to continue executing the subsequent processing corresponding to the target request based on the request verification result.

[0085] The verification relationship between the target request identifier and the auxiliary request identifier refers to the relationship used to determine whether the target request identifier and the auxiliary request identifier match. This verification relationship typically includes a consistency relationship, a correspondence relationship, a mapping relationship, or a relationship that satisfies a preset matching rule. Through this verification relationship, it can be determined whether the target request information corresponding to the current target request corresponds to the historical request information represented by the auxiliary request identifier, thereby determining whether the target request token is still applicable to the current target request. For example, if the target request identifier and the auxiliary request identifier are the same, it can be determined that they satisfy the verification relationship, indicating that the current target request information matches the historical request information corresponding to the target request token; if the target request identifier and the auxiliary request identifier are different, it can be determined that they do not satisfy the verification relationship, indicating that the current target request information does not match the historical request information corresponding to the target request token. Therefore, when the target request information changes, the target request token is reused, or the target request does not correspond to a historical request, it can be promptly determined that the target request has failed verification.

[0086] In practical applications, there are multiple ways to determine the verification result of a target request based on the target request identifier and the auxiliary request identifier. The specific method chosen depends on the actual situation, and this specification does not impose any limitations on this approach. In one possible implementation, the target request identifier and the auxiliary request identifier can be compared for consistency, and the verification result can be determined based on the comparison result. For example, if the target request identifier and the auxiliary request identifier match, the verification result can be determined as successful; if they do not match, the verification result can be determined as unsuccessful. In another possible implementation, the target request identifier and the auxiliary request identifier can be matched according to preset matching rules, and the verification result can be determined based on the matching result. For example, if the target request identifier and the auxiliary request identifier satisfy a preset correspondence, the verification result can be determined as successful; if they do not satisfy the preset correspondence, the verification result can be determined as unsuccessful.

[0087] For example, in a data submission activity, after the target object sends a target request, the server can generate a target request identifier based on the target request information and extract an auxiliary request identifier from the verification information database based on the target request token. If the target request identifier matches the auxiliary request identifier, it means that there is a correspondence between the target request token carried by the target request and the target request information, and it can be determined that the target request verification result is successful; if the two do not match, it can be determined that the target request verification result is unsuccessful.

[0088] The scheme implemented in this specification involves obtaining a target request sent by a target object for a target activity, wherein the target request carries target request information and a target request token corresponding to the target request information; generating a target request identifier based on the target request information; extracting an auxiliary request identifier from a verification information database based on the target request token, wherein the verification information database includes multiple candidate request identifiers, each carrying a candidate request token, and the auxiliary request token corresponding to the auxiliary request identifier is the same as the target request token; determining the request verification result of the target request based on the target request identifier and the auxiliary request identifier. Historical request identifiers can be associated with the target request token, and the target request identifier can be regenerated based on the target request information when the target request is submitted. This allows the request verification process to simultaneously associate the current request information and the historical request information corresponding to the target request token, thereby reducing the reuse of the target request token after the target request information has been modified. Furthermore, by combining candidate request tokens, object verification results, token status information, and target activity information for verification, the occurrence of obtaining a request token without passing object verification, reuse of the request token, and replay of the request can be reduced, improving the accuracy and security of request verification.

[0089] It is worth noting that the request verification method proposed in one or more embodiments of this specification is widely applicable to high-security scenarios such as anti-fraud measures for internet marketing activities, online payment transaction verification, API interface security protection, user login authentication, and sensitive data access control. It can also be extended to verify item bidding requests, prevent auction bid tampering, authenticate service calls between distributed systems, verify communication between IoT devices, verify the authenticity of electronic invoices, detect cheating in games, and any business process that needs to ensure the integrity of requests and the legitimacy of identities. Its verification mechanism based on the dual binding of tokens and dynamic identifiers has good universality and scalability, and is not limited to specific industries or technical architectures.

[0090] In one optional embodiment of this specification, determining the request verification result of the target request based on the target request identifier and the auxiliary request identifier may include the following steps: If the target request identifier and the auxiliary request identifier are the same, the request verification result of the target request is determined to be successful. If the target request identifier and the auxiliary request identifier are inconsistent, the request verification result of the target request is determined to be verification failure.

[0091] It should be noted that consistency between the target request identifier and the auxiliary request identifier means that the target request identifier generated based on the target request information is the same as or meets the preset consistency condition of the auxiliary request identifier extracted from the verification information database based on the target request token. By determining whether the target request identifier and the auxiliary request identifier are consistent, it can be determined whether the target request information corresponds to the candidate request identifier associated with the target request token. For example, if the target request identifier and the auxiliary request identifier are strings, consistency can mean that the string content is the same; if the target request identifier and the auxiliary request identifier are encoded values, consistency can mean that the encoded values ​​are the same.

[0092] A successful verification means that the target request meets the verification requirements. A successful verification typically indicates that the target request identifier and the auxiliary request identifier are consistent, or that they meet a preset consistency condition. The successful verification result confirms a correspondence between the target request information and the target request token. For example, a successful verification can be indicated by a status code, a result field, or a verification flag.

[0093] A verification failure refers to a verification result where the target request does not meet the request verification requirements. Verification failure typically indicates that the target request identifier and the auxiliary request identifier are inconsistent, or that they do not meet a preset consistency condition. Through the verification result of a failed request, it can be determined that there is no corresponding relationship between the target request information and the target request token. For example, verification failure can be indicated by an error code, a failure status field, or a verification failure flag.

[0094] In practical applications, when the target request identifier and the auxiliary request identifier are identical, there are multiple ways to determine that the request verification result of the target request is valid. The specific method chosen depends on the actual situation, and this specification does not impose any limitations on this approach. One possible implementation of this specification is to directly compare the target request identifier and the auxiliary request identifier for consistency. If they are completely identical, the request verification result of the target request is determined to be valid. Another possible implementation of this specification is to match the target request identifier and the auxiliary request identifier according to a preset consistency rule. If they satisfy the preset consistency rule, the request verification result of the target request is determined to be valid.

[0095] In practical applications, there are multiple ways to determine the verification result of the target request as failed when the target request identifier and the auxiliary request identifier are inconsistent. The specific method chosen depends on the actual situation, and this specification does not impose any limitations on this approach. In one possible implementation, the target request verification result can be determined as failed if the contents of the target request identifier and the auxiliary request identifier are different. In another possible implementation, the target request identifier and the auxiliary request identifier can be matched according to a preset consistency rule; if the two do not satisfy the preset consistency rule, the target request verification result can be determined as failed.

[0096] Specifically, during the data submission activity, when the target object formally submits the data, the server can generate a target request identifier based on the target request information and extract an auxiliary request identifier from the verification information database based on the target request token. If the target request identifier and the auxiliary request identifier are consistent, it means that the currently submitted target request information matches the candidate request identifier corresponding to the target request token, and the request verification result can be determined as verification passed; if the target request identifier and the auxiliary request identifier are inconsistent, it means that the currently submitted target request information does not match the candidate request identifier corresponding to the target request token, and the request verification result can be determined as verification failed.

[0097] By applying the scheme of the embodiments of this specification, the verification is determined to be successful when the target request identifier and the auxiliary request identifier are consistent, and the verification is determined to be unsuccessful when they are inconsistent. The request verification can be completed based on the correspondence between the current request information and the historical request identifier, which helps to reduce the situation where the target request token is reused after the target request information is modified.

[0098] In one optional embodiment of this specification, before determining the request verification result of the target request based on the target request identifier and the auxiliary request identifier, the following steps may be included: Obtain verification auxiliary information, wherein the verification auxiliary information includes at least one of the following: the current status information of the target request token, the binding object information of the target request token, and the target activity information of the target activity; Based on the target request identifier and the auxiliary request identifier, determine the request verification result of the target request, including: Based on the verification auxiliary information, the target request identifier, and the auxiliary request identifier, determine the request verification result of the target request.

[0099] It should be noted that verification auxiliary information refers to information used to assist in determining the verification result of the target request. This verification auxiliary information typically includes at least one of the following: the current status information of the target request token, the binding object information of the target request token, and the target activity information. Using this verification auxiliary information, verification can be further performed based on the target request identifier and the auxiliary request identifier, combined with relevant information from the target request token or the target activity. For example, the verification auxiliary information may be information on whether the target request token is currently available, information on the object bound to the target request token, or information on the current status of the target activity.

[0100] The current status information of the target request token refers to the information used to characterize the current state of the target request token. Current status information typically includes an available state, an unavailable state, a valid state, an expired state, an unused state, a used state, or other information that can characterize whether the target request token currently meets the verification requirements. Through this current status information, it can be determined whether the target request token is currently suitable for participating in the verification of the target request. For example, the current status information could be that the target request token is in a valid state.

[0101] The binding object information of the target request token refers to the information used to identify the object associated with the target request token. This binding object information typically includes information such as object identifier, user identifier, client identifier, device identifier, or session identifier. Through this binding object information, it can be determined whether the target request token corresponds to the object sending the target request. For example, the binding object information could be the user identifier bound to the target request token.

[0102] Target activity information refers to information used to characterize a target activity. This target activity information typically includes a target activity identifier, activity status, activity time range, or activity processing rules. Through this target activity information, it can be determined whether the target activity targeted by the target request meets the request verification requirements. For example, the target activity information could be information about whether the target activity is currently in a processable state.

[0103] In practical applications, there are multiple ways to obtain verification auxiliary information, and the specific method should be selected according to the actual situation. This specification does not impose any limitations on these methods in the embodiments. In one possible implementation, the verification information database can be queried based on the target request token to obtain the current status information or bound object information corresponding to the target request token. In another possible implementation, the activity information database can be queried based on the target request information or the target activity identifier to obtain the target activity information.

[0104] In practical applications, there are multiple ways to determine the verification result of a target request based on verification auxiliary information, the target request identifier, and the auxiliary request identifier. The specific method chosen depends on the actual situation, and this specification does not impose any limitations on these methods. In one possible implementation, the target request identifier and the auxiliary request identifier are identical, and the verification auxiliary information meets preset auxiliary verification conditions; in another possible implementation, the target request identifier and the auxiliary request identifier are checked for consistency, and the verification auxiliary information is checked separately. The verification result of the target request is then determined based on the consistency check result and the auxiliary check result.

[0105] Specifically, if the target request identifier and the auxiliary request identifier are consistent, and the current status information of the target request token indicates that the target request token meets the verification requirements, the verification result of the target request can be determined as successful. Here, the verification auxiliary information meeting preset auxiliary verification conditions may include the target request token's bound object information corresponding to the target object, and / or target activity information indicating that the target activity is in a processable state. If the target request identifier and the auxiliary request identifier are inconsistent, or the verification auxiliary information does not meet the preset auxiliary verification conditions, the verification result of the target request can be determined as unsuccessful. For example, in a data submission activity, the server can, based on confirming that the target request identifier and the auxiliary request identifier are consistent, further combine the current status information of the target request token, the bound object information, or the target activity information to determine whether the target request passes verification.

[0106] By applying the scheme of the embodiments in this specification, and combining the target request identifier and the auxiliary request identifier with the verification auxiliary information to determine the request verification result, the request verification process can be further associated with the target request token status, the bound object, or the target activity information, which is beneficial to improving the accuracy of the request verification result.

[0107] In one optional embodiment of this specification, the aforementioned verification assistance information includes the current status information of the target request token; obtaining the verification assistance information may include: Obtain the token lifecycle of the target request token, where the token lifecycle is determined based on the activity end time of the target activity and the target request time of the target request; Based on the token's lifecycle, the current state information of the target request token is determined.

[0108] It should be noted that the token lifecycle refers to a time attribute used to characterize whether the target request token is still available at the target request time. The token lifecycle typically includes information such as validity period, validity expiration time, remaining validity period, or expiration time. Through the token lifecycle, it can be determined whether the target request token still meets the verification requirements at the target request time. For example, the token lifecycle can be the remaining validity period determined based on the activity end time and the target request time.

[0109] The activity end time refers to the end time corresponding to the target activity. The activity end time typically includes information such as the target activity's deadline, closing time, or stop processing time. The activity end time determines whether the target request token is still in a valid phase matching the target activity. For example, the activity end time could be the time when the target activity stops receiving requests.

[0110] The target request time refers to the time when the target object sends the target request or when the server receives the target request. The target request time typically includes information such as the request sending time, request receiving time, or request processing time. By using the target request time, the time status of the target request token in the current request scenario can be determined. For example, the target request time could be the system time at which the server received the target request.

[0111] Current status information refers to information used to characterize whether the target request token currently meets the verification requirements. This current status information typically includes information such as valid, expired, available, unavailable, unused, used, or invalid. Using this current status information, it can be further determined whether the target request token can participate in this request verification when determining the verification result. For example, the current status information could indicate that the target request token is in a valid state, or it could indicate that the target request token is in an expired state.

[0112] In practical applications, there are multiple ways to obtain the token lifecycle of a target request token, and the specific method chosen depends on the actual situation. This specification does not impose any limitations on this method in its embodiments. In one possible implementation, the end time of the target activity and the request time of the target request can be obtained, and the token lifecycle of the target request token can be determined based on the time difference between the end time and the request time. In another possible implementation, different token lifecycles corresponding to different time intervals can be pre-set, and the time interval in which the target request is located can be determined based on the end time of the activity and the request time. The token lifecycle of the target request token can then be determined based on this time interval.

[0113] In practical applications, there are multiple ways to determine the current status information of a target request token based on its lifecycle. The specific method chosen depends on the actual situation, and this specification does not impose any limitations on the embodiments thereof. In one possible implementation, the current status information of the target request token can be determined as valid if the token lifecycle indicates that the target request token is still valid. In another possible implementation, the current status information of the target request token can be determined as expired if the token lifecycle indicates that the target request token has exceeded its validity period.

[0114] Specifically, after receiving a target request, the server can determine the target request time and obtain the end time of the target activity. Then, based on the activity end time and the target request time, it can determine the token lifecycle of the target request token and further determine the current status information of the target request token based on the token lifecycle. If the current status information indicates that the target request token is valid, the request verification result can be determined by combining the target request identifier and the auxiliary request identifier. If the current status information indicates that the target request token is expired, it can be determined that the target request token does not meet the verification requirements.

[0115] By applying the scheme of the embodiments of this specification, the token lifecycle is determined based on the activity end time of the target activity and the target request time of the target request, and the current status information of the target request token is determined based on the token lifecycle. This allows the request verification process to verify the target request token in conjunction with the time status of the target activity, which helps to reduce the situation where the target request token continues to participate in the request verification after it has exceeded the validity period.

[0116] In one optional embodiment of this specification, after determining the request verification result of the target request based on the target request identifier and the auxiliary request identifier, the following steps may be further included: If the verification result is successful, update the current status information of the target request token to expired.

[0117] It's important to note that an expired status refers to a target request token no longer meeting the conditions for continuing to participate in request verification. An expired status typically indicates that the target request token has been used, has exceeded its validity period, or has been set to unavailable. Updating a target request token to an expired status can include changing it from unused to used, or setting it to an unavailable state. By updating the current status information of the target request token to an expired status, the possibility of the same target request token being reused in subsequent requests can be reduced. For example, after the target request verification passes, the server can update the status field corresponding to the target request token to an expired status.

[0118] In practical applications, there are multiple ways to update the current status information of the target request token to an expired state when the request verification result is successful. The specific method chosen depends on the actual situation, and this specification does not impose any limitations on this approach. One possible implementation of this specification involves querying the status field corresponding to the target request token in the verification information database and updating the status field from valid to expired. Another possible implementation involves generating a token status update instruction when the request verification result is successful, and updating the current status information of the target request token to an expired state based on the token status update instruction.

[0119] Specifically, during the data submission process, once the server determines that the verification result of the target request has passed, it can query the corresponding token status information in the verification information database based on the target request token and update the current status information of the target request token to expired. If a request carrying the same target request token is subsequently received again, the server can determine, based on the current status information of the target request token, that the target request token no longer meets the verification requirements.

[0120] By applying the solution in the embodiments of this specification, and updating the current status information of the target request token to an expired state when the request verification result is successful, the target request token can lose the condition to participate in verification again after passing the verification, which helps to reduce the situation where the target request token is reused.

[0121] See Figure 2 , Figure 2 This specification shows a flowchart of a coal bidding request verification method according to an embodiment, which specifically includes the following steps: Step 202: Obtain the coal bidding request sent by the target user for the coal bidding activity, wherein the coal bidding request carries coal bidding request information and the coal bidding request token corresponding to the coal bidding request information.

[0122] It should be noted that "target users" refers to users, clients, terminal devices, corporate entities, or other entities capable of initiating coal bidding requests who participate in coal bidding activities and send such requests. Coal bidding activities refer to online bidding for coal resources, coal lots, coal resource packages, or other coal-related trading resources. A coal bidding request is a verification request sent by a target user in connection with a coal bidding activity. Coal bidding requests can be sent when formally submitting a bid or can be requests for sensitive operations related to the coal bidding activity.

[0123] Coal bidding request information refers to the information in a coal bidding request that describes the content of the current coal bidding request. This information typically includes bidding activity identifier, lot identifier, resource package identifier, bidding user identifier, participating company identifier, bid amount, bidding round, bidding time window, request time, or bidding business message. From this information, a coal bidding request identifier can be generated, allowing the identifier to represent the specific content of the current coal bidding request.

[0124] A coal bidding request token is a token information carried in a coal bidding request that corresponds to the coal bidding request information. The coal bidding request token can typically be a string, an encoded field, a token identifier, an encrypted field, or other token data that can be recognized by the server. The coal bidding request token can be used to find the corresponding coal bidding auxiliary request identifier in the verification information database, thus providing a basis for subsequently determining whether the coal bidding request information has been modified.

[0125] In practical applications, there are various ways to obtain coal bidding requests sent by target users for coal bidding activities. The specific method is selected according to the actual situation, and the embodiments in this specification do not limit this. In one possible implementation, the target user can send a coal bidding request to the server through a client. After receiving the coal bidding request, the server parses the request parameters, request message, request fields, or other request data in the coal bidding request to obtain the coal bidding request information and the coal bidding request token. In another possible implementation, the coal bidding request sent by the target user can be forwarded to the server through a gateway, message queue, or intermediate service. The server obtains the coal bidding request information and the coal bidding request token from the forwarded request data.

[0126] Step 204: Based on the coal bidding request information, generate a coal bidding request identifier for the coal bidding request.

[0127] It should be noted that the coal bidding request identifier refers to the identification information generated based on the coal bidding request information, used to characterize the coal bidding request. The coal bidding request identifier can typically include strings, encoded values, digest values, hash values, index values, or other data that can characterize the coal bidding request information. In a coal bidding scenario, the coal bidding request identifier can serve as the request fingerprint corresponding to the coal bidding request.

[0128] In practical applications, there are various methods for generating coal bidding request identifiers based on coal bidding request information. The specific method chosen depends on the actual situation, and the embodiments in this specification do not impose any limitations on this. One possible implementation of this specification involves standardizing the coal bidding request information to obtain standardized coal bidding request information, and then generating a coal bidding request identifier based on the standardized coal bidding request information. The standardization process may include at least one of the following: field sorting, format conversion, null value handling, character encoding unification, or redundant field filtering.

[0129] In another possible implementation of this specification, key information characterizing the coal bidding request can be extracted from the coal bidding request information according to a preset fingerprint generation rule, and a coal bidding request identifier can be generated based on the extracted key information. For example, the coal bidding request identifier can be generated based on at least one of the following: bidding activity identifier, bid segment identifier or resource package identifier, bidding user identifier, participating enterprise identifier, bid amount, bidding round, bidding time window, and server-side random information. Exemplarily, the coal bidding request identifier can be obtained by hashing the bidding business message, user identity, bidding time window, and server-side random information.

[0130] By generating a coal bidding request identifier based on the coal bidding request information, the coal bidding request identifier can be associated with the specific content of the current coal bidding request. When a target user modifies the bid amount, lot identifier, resource package identifier, bidding round, or bidding time window after obtaining the coal bidding request token, the regenerated coal bidding request identifier may change, thus making it easier for the server to identify whether the coal bidding request information has been modified.

[0131] Step 206: Based on the coal bidding request token, extract the coal bidding auxiliary request identifier from the verification information database. The verification information database includes multiple candidate coal bidding request identifiers, each carrying a candidate coal bidding request token. The auxiliary coal bidding request token corresponding to the coal bidding auxiliary request identifier is the same as the coal bidding request token.

[0132] It should be noted that the verification information database refers to a data set used to store the correspondence between candidate coal bidding request identifiers and candidate coal bidding request tokens. The verification information database typically includes databases, data tables, cache space, distributed storage systems, or other data structures capable of storing and querying verification information. The verification information database can store multiple candidate coal bidding request identifiers, as well as the candidate coal bidding request tokens corresponding to each candidate coal bidding request identifier.

[0133] The candidate coal bidding request identifier is a request identifier pre-generated and stored in the verification information database based on the candidate coal bidding request information before the formal submission of the coal bidding request. The candidate coal bidding request identifier can be used to characterize the proposed bid message during the pre-verification stage. The candidate coal bidding request token is the token information corresponding to the candidate coal bidding request identifier. The candidate coal bidding request token can be generated by the server after the target user completes the human-machine verification and stored in the verification information database in association with the candidate coal bidding request identifier.

[0134] The coal bidding auxiliary request identifier refers to the candidate coal bidding request identifier extracted from the verification information database based on the coal bidding request token. The coal bidding auxiliary request identifier typically originates from the candidate coal bidding request token corresponding to the same candidate coal bidding request token in the verification information database. Using the coal bidding auxiliary request identifier, it can be compared with the coal bidding request identifier in subsequent steps to determine whether the coal bidding request information in the formal submission stage corresponds to the proposed bid business message in the pre-verification stage.

[0135] In practical applications, there are multiple ways to extract the coal bidding auxiliary request identifier from the verification information database based on the coal bidding request token. The specific method should be selected according to the actual situation, and the embodiments in this specification do not impose any limitations on this. In one possible implementation of this specification, the coal bidding request token can be used as a query condition to search for candidate coal bidding request tokens that are the same as the coal bidding request token in the verification information database, and the candidate coal bidding request identifier corresponding to the candidate coal bidding request token can be determined as the coal bidding auxiliary request identifier. In another possible implementation of this specification, the coal bidding request token can be parsed first to obtain the token index or token identifier, and then a matching query can be performed in the verification information database based on the token index or token identifier to determine the corresponding coal bidding auxiliary request identifier.

[0136] Step 208: Determine the coal bidding request verification result based on the coal bidding request identifier and the coal bidding auxiliary request identifier.

[0137] It should be noted that the coal bidding request verification result refers to the information used to indicate whether the coal bidding request has passed the verification. The coal bidding request verification result typically includes verification success, verification failure, abnormal results, or other information that can characterize the verification status. Based on the coal bidding request verification result, it can be determined whether the server should continue processing the coal bidding request, or whether to block the coal bidding request and prompt for re-verification.

[0138] In practical applications, there are multiple ways to determine the verification result of a coal bidding request based on the coal bidding request identifier and the coal bidding auxiliary request identifier. The specific method should be selected according to the actual situation, and the embodiments in this specification do not impose any limitations on this. In one possible implementation of this specification, the coal bidding request identifier and the coal bidding auxiliary request identifier can be compared for consistency. If they match, the coal bidding request verification result is determined to be successful; if they do not match, the coal bidding request verification result is determined to be unsuccessful.

[0139] In another possible implementation of this specification, the coal bidding request verification result can be determined by further combining the current status information of the coal bidding request token, the bound object information, and the activity status information of the coal bidding activity, based on the fact that the coal bidding request identifier and the coal bidding auxiliary request identifier are consistent. For example, if the coal bidding request identifier and the coal bidding auxiliary request identifier are consistent, the coal bidding request token is in a valid or unused state, the bidding user identifier or participating enterprise identifier bound to the coal bidding request token corresponds to the target user, and the coal bidding activity is in a bidding-available state, the coal bidding request verification result can be determined as verification passed. If the coal bidding request identifier and the coal bidding auxiliary request identifier are inconsistent, or the coal bidding request token has expired, been used, the bound object is inconsistent, or the coal bidding activity has ended, the coal bidding request verification result can be determined as verification failed.

[0140] By applying the scheme of the embodiments in this specification, by carrying coal bidding request information and coal bidding request token in the coal bidding request, generating a coal bidding request identifier based on the coal bidding request information, and extracting a coal bidding auxiliary request identifier from the verification information database based on the coal bidding request token, and then determining the coal bidding request verification result based on the coal bidding request identifier and the coal bidding auxiliary request identifier, a correspondence can be formed between the coal bidding request in the formal submission stage and the proposed bid business message in the pre-verification stage. This reduces the possibility of the target user reusing the coal bidding request token after modifying the bid amount, bid segment identifier, resource package identifier, bidding round, or bidding time window, thereby improving the accuracy and security of coal bidding request verification.

[0141] It should be noted that the request verification method provided in the embodiments of this specification can be applied to various activity scenarios that require verification of the correspondence between the target object, the target request information, and the request token. For example, the embodiments of this specification can be applied to online data submission activities, online registration activities, appointment confirmation activities, qualification review activities, resource acquisition activities, permission unlocking activities, task confirmation activities, item bidding activities, digital resource allocation activities, anti-fraud measures for internet marketing activities, online payment transaction verification, API interface security protection, user login authentication, sensitive data access control, or other online activities involving target object participation, request submission, resource allocation, permission confirmation, or sensitive operation verification. Furthermore, the embodiments of this specification are particularly suitable for bidding-type activity scenarios with high concurrency, high timeliness, and sensitive request content, such as coal bidding activities, coal resource package bidding activities, coal bid section bidding activities, bulk commodity bidding activities, material procurement bidding activities, transportation capacity bidding activities, or other online bidding activities that need to prevent bidding requests from being tampered with, request tokens from being reused, and requests from being replayed. For ease of understanding, the request verification method provided in the embodiments of this specification will be explained below using a coal bidding activity as an example.

[0142] In one optional embodiment of this specification, a coal bidding activity is used as an example. This coal bidding activity can be used by a target entity to submit a bid request for a target coal resource, coal lot, or coal resource package within a preset bidding time range. Coal resources can correspond to different coal types, coal resource packages, coal batches, coal lots, delivery locations, or delivery times. Before the target entity formally submits its bid request, the server needs to verify the target entity, the proposed bid message, and the status of the coal bidding activity to reduce the possibility of the bid message being modified, the request token being reused, or the bid request being replayed.

[0143] In this scenario, the candidate activity can be a coal bidding activity, and the candidate objects can be bidding users, participating companies, or their corresponding clients participating in the coal bidding activity. The candidate request can be a pre-verification request sent by the candidate object before formally submitting its bid. The candidate request carries candidate request information, which may include the coal bidding activity identifier, bid segment identifier, coal resource package identifier, bidding user identifier, participating company identifier, bid amount, bidding round, bidding time window, candidate request time, and random information from the server, etc.

[0144] For example, candidate request information may include the following proposed bid message: {"activityId":"A001","lotId":"L01","bidAmount":"685.50"}. Here, activityId can represent the coal bidding activity identifier, lotId can represent the bid segment identifier or coal resource package identifier, and bidAmount can represent the bid amount. In addition to the above fields, candidate request information may also include information such as the bidding user identifier, participating company identifier, bidding round, bidding time window, client identifier, device identifier, or candidate request time. For example, candidate request information may also include the coal resource package name, coal type information, delivery location, delivery cycle, or other information used to characterize the target coal resource.

[0145] After the server obtains the candidate requests sent by the candidate objects for the candidate activities, it can generate candidate request identifiers based on the candidate request information. In coal bidding activities, the candidate request identifier can be the request fingerprint corresponding to the candidate bidding request. The fields used to generate the request fingerprint can include at least one of the following: coal bidding activity identifier, bid segment identifier, coal resource package identifier, bidding user identifier, participating enterprise identifier, bid amount, bidding round, bidding time window, and server-side random information. For example, the request fingerprint can be generated as follows: fingerprint = hash(business message + user identity + bidding time window + server-side random information). The business message can include information such as the coal bidding activity identifier, bid segment identifier or coal resource package identifier, and bid amount; the user identity can include the bidding user identifier or participating enterprise identifier; and the server-side random information can be used to ensure that each verification request is unique, reducing the possibility of different requests generating the same request fingerprint.

[0146] Specifically, upon receiving a candidate request, the server can generate server-side random information and use this random information, along with the candidate request information, to generate a candidate request identifier. The server-side random information can be a random number, a random string, a random combination of timestamps, or other random data generated by the server. By incorporating server-side random information into the candidate request identifier generation process, different candidate request identifiers can still be generated when the same candidate initiates multiple pre-verification requests for the same coal bidding activity, the same coal resource package, and the same bid amount. This improves the uniqueness of the candidate request identifier and reduces the possibility of different bid requests generating the same request fingerprint.

[0147] Before generating the candidate request token, the server can first generate object verification information for the candidate object and send it to the corresponding client. This object verification information can be human-machine verification information used to confirm the authenticity of the candidate object's operation. For example, in coal bidding activities, object verification information can include graphic verification information, sliding verification information, behavioral trajectory verification information, problem verification information, equipment and environment verification information, or a combination of multiple verification information. Therefore, human-machine verification can be performed on the candidate object before it receives the candidate request token, reducing the likelihood of automated programs bypassing front-end interaction to directly obtain the request token.

[0148] When generating object verification information, the server can obtain the activity end time and candidate request time of candidate activities, and determine the object verification strength based on these times. In a coal bidding activity, the activity end time can be the end time of the coal bidding activity, and the candidate request time can be the time when the server receives the pre-verification request. The server can calculate the remaining time between the candidate request time and the end time of the coal bidding activity; for example, the remaining time can be determined based on the time difference between the end time of the coal bidding activity and the candidate request time.

[0149] When there is a long remaining time, the server can determine a lower object validation strength; when there is a short remaining time, the server can determine a higher object validation strength. For example, when the coal bidding activity is far from its end, object validation information can use lower-complexity sliding validation or graphical validation; when the coal bidding activity is close to its end, object validation information can correspond to higher behavioral trajectory validation requirements, a smaller sliding error tolerance range, a longer re-validation interval, higher response time requirements, or more validation steps. Therefore, the object validation strength can be increased during the phase when the coal bidding activity is nearing its end, when bidding request submissions are frequent, or when the risk of abnormal bidding requests is high.

[0150] After a candidate object completes its corresponding operation based on the object verification information, the client can send the object verification result back to the server. The object verification result can include verification pass / fail results, sliding trajectory data, operation time, terminal device identifier, client identifier, verification response data, or device environment information, etc. The server obtains the object verification result sent back by the candidate object based on the object verification information. If the object verification result indicates that the candidate object has passed verification, the server generates a candidate request token with the candidate request identifier and stores the candidate request identifier and candidate request token together in the verification information database.

[0151] In coal bidding activities, the verification information database can store information such as candidate request identifier, candidate request token, coal bidding activity identifier, bid section identifier, coal resource package identifier, bidding user identifier, participating enterprise identifier, bid amount, bidding round, bidding time window, server-side random information, candidate request time, token current status information, and token validity period. The candidate request token can be returned to the client corresponding to the candidate object, so that the candidate object can carry it when subsequently submitting a formal coal bidding request. If the object verification result indicates that the candidate object verification failed, the server may not generate a candidate request token.

[0152] Furthermore, in coal bidding activities, the server can determine the validity period of candidate request tokens based on the activity's end time and the candidate request time. For example, if the candidate request time is far from the end time of the coal bidding activity, a longer token validity period can be determined; if the candidate request time is close to the end time, a shorter token validity period can be determined. This allows for shortening the validity period of candidate request tokens near the end of the coal bidding activity, reducing the risk of candidate request tokens being held, reused, or replayed for extended periods in the final stages.

[0153] Subsequently, the target entity sends a target request for the target activity. The target activity can be the aforementioned coal bidding activity, and the target entity can be a bidding user, participating enterprise, or its corresponding client participating in the coal bidding activity. The target request can be a submission request sent by the target entity when formally submitting its coal bidding bid. The target request carries target request information and a target request token corresponding to the target request information. The target request information may include the coal bidding activity identifier, bid segment identifier, coal resource package identifier, bidding user identifier, participating enterprise identifier, bid amount, bidding round, bidding time window, and target request time, etc.; the target request token can be the token information obtained by the target entity during the pre-verification phase and carried in the target request.

[0154] After the server obtains the target request sent by the target object for the target activity, it generates a target request identifier based on the target request information. In coal bidding activities, the target request identifier can also be the request fingerprint corresponding to the formal bidding request. The server can obtain server-side random information associated with the target request token from the verification information database based on the target request token, and generate the target request identifier based on the target request information, the target object's identity information, the bidding time window, and the server-side random information. For example, the target request identifier can be generated as follows: fingerprint = hash(business message + user identity + bidding time window + server-side random information). The business message in the target request stage may include information such as the coal bidding activity identifier, the bid section identifier or coal resource package identifier, and the bidding amount.

[0155] Optionally, the server can also obtain request attribute information of the target request. This request attribute information includes at least one of the target object information and the target activity information. In coal bidding activities, the target object information may include the bidder identifier, participating enterprise identifier, client identifier, device identifier, or session identifier, etc.; the target activity information may include the coal bidding activity identifier, bid section identifier, coal resource package identifier, bidding round, activity status, bidding time range, or bidding processing rules, etc. The server can generate a target request identifier based on the target request information and request attribute information, enabling the target request identifier to simultaneously represent the request content of the formal bid request and the object or activity associated with the target request.

[0156] After generating the target request identifier, the server extracts the auxiliary request identifier from the verification information database based on the target request token. Specifically, the server can use the target request token as a query condition to search the verification information database for candidate request tokens that are identical to the target request token, and determine the candidate request identifier corresponding to the candidate request token as the auxiliary request identifier. Thus, the auxiliary request token corresponding to the auxiliary request identifier is the same as the target request token, and the auxiliary request identifier can be used as a historical request identifier for comparison with the target request identifier. In coal bidding activities, the auxiliary request identifier can be used to represent the proposed bid message in the pre-verification stage, and the target request identifier can be used to represent the bid message in the formal submission stage. The server can compare the two to determine whether the formally submitted bid message corresponds to the proposed bid message in the pre-verification stage.

[0157] Before determining the verification result, the server can also obtain verification auxiliary information. Verification auxiliary information may include at least one of the following: the current status information of the target request token, the binding object information of the target request token, and the target activity information of the target activity. In coal bidding activities, the current status information of the target request token can be used to indicate whether the target request token is currently valid, unused, used, or expired; the binding object information of the target request token can be used to indicate the bidder identifier, participating enterprise identifier, client identifier, or device identifier bound to the target request token; the target activity information of the target activity can be used to indicate whether the coal bidding activity is currently in a bidding-available state, whether the bidding end time has expired, whether it is in the current bidding round, and whether the target coal resource package allows continued submission of bidding requests.

[0158] In one optional implementation, the verification auxiliary information includes the current status information of the target request token. The server can obtain the token lifecycle of the target request token, which is determined based on the end time of the target activity and the target request time. In a coal bidding activity, the end time can be the end time of the coal bidding activity, and the target request time can be the time when the server receives the formal bid request. The server can determine the remaining validity period of the target request token based on the time difference between the end time of the coal bidding activity and the target request time; or determine the valid expiration time corresponding to the target request token based on the bidding time window in which the target request time is located. The server then determines the current status information of the target request token based on the token lifecycle. For example, when the target request time is within the valid period of the target request token and the target request token has not been used, the current status information can be determined to be valid or unused; when the target request time exceeds the valid period of the target request token, or the target request token has been used, the current status information can be determined to be expired or used.

[0159] Then, the server determines the verification result of the target request based on the verification auxiliary information, the target request identifier, and the auxiliary request identifier. Specifically, if the target request identifier matches the auxiliary request identifier and the verification auxiliary information meets the preset auxiliary verification conditions, the verification result of the target request can be determined as successful. In coal bidding activities, the preset auxiliary verification conditions may include: the target request token is in a valid or unused state; the bidder identifier bound to the target request token corresponds to the target object; the participating enterprise identifier bound to the target request token corresponds to the target object; the target activity is in a bidding-available state; the target request time has not exceeded the end time of the coal bidding activity; the bidding round corresponding to the target request is consistent with the current bidding round of the target activity; and the bid segment identifier or coal resource package identifier corresponding to the target request is consistent with the candidate request stage, etc.

[0160] If the target request identifier and the auxiliary request identifier are inconsistent, or if the auxiliary verification information does not meet the preset auxiliary verification conditions, the target request verification result can be determined as verification failure. For example, if the target object modifies the bid amount, coal bidding activity identifier, bid section identifier, coal resource package identifier, bidder identifier, participating enterprise identifier, bidding round, or bid time window in the business message after obtaining the target request token, the target request identifier regenerated by the server based on the target request information may be inconsistent with the auxiliary request identifier, and in this case, the target request verification can be determined to have failed. As another example, if the target request token has been used, has expired, or the bidder identifier and participating enterprise identifier bound to the target request token do not correspond to the current target object, the target request verification can also be determined to have failed.

[0161] If the request verification result is successful, the server can continue processing the target request. For example, the server can write the target request information into the coal bidding request processing record, or submit the target request information to the coal bidding processing module for subsequent bidding processing. If the request verification result is successful and the target request is successfully processed, the server can also update the current status information of the target request token to expired. For example, the server can query the status field corresponding to the target request token in the verification information database and update the status field from valid to expired, or from unused to used. If a coal bidding request carrying the same target request token is received again subsequently, the server can determine that the target request token no longer meets the verification requirements based on the current status information of the target request token, thereby reducing the reuse of the target request token and the replay of coal bidding requests.

[0162] By applying the solutions in the embodiments of this specification, in coal bidding activities, the proposed bid business message, object identity, bidding time window, and server-side random information in the pre-verification stage can be bound by the candidate request identifier. When the formal bidding request is submitted, the target request identifier is regenerated and compared, thereby reducing the situation where the target object continues to reuse the target request token after modifying the bid amount, bid segment identifier, coal resource package identifier, bidding round, or bidding time window. At the same time, by combining the current status information of the target request token, the bound object information, and the target activity information for verification, and updating the status of the target request token after the verification is passed and the bidding is successfully processed, the reuse of the target request token and the replay of coal bidding requests can be reduced, thereby improving the accuracy and security of bidding request verification in coal bidding activities.

[0163] The above is an illustrative scheme of a coal bidding request verification method according to this embodiment. It should be noted that the technical solution of this coal bidding request verification method belongs to the same concept as the technical solution of the above-described request verification method. For details not described in detail in the coal bidding request verification method, please refer to the description of the technical solution of the above-described request verification method.

[0164] The request verification method proposed in the embodiments of this specification can be applied to, for example, Figure 3 The request processing system shown is not limited to this. See also Figure 3 , Figure 3 This specification illustrates an architecture diagram of a request processing system according to an embodiment of the present specification. The request processing system may include a client 302 and a server 304. Client 302 is used to send a target request sent by the target object to the target activity to server 304; Server 304 is used to receive a target request sent by client 302 for a target activity, wherein the target request carries target request information and a target request token corresponding to the target request information; based on the target request information, a target request identifier is generated for the target request; based on the target request token, an auxiliary request identifier is extracted from the verification information database, wherein the verification information database includes multiple candidate request identifiers, each carrying a candidate request token, and the auxiliary request token corresponding to the auxiliary request identifier is the same as the target request token; based on the target request identifier and the auxiliary request identifier, the request verification result of the target request is determined; and the request verification result of the target request is sent to client 302.

[0165] Optionally, the server-side 304 can also be used to obtain the candidate request sent by the candidate object for the candidate activity, generate a candidate request identifier based on the candidate request information, generate object verification information of the candidate object, obtain the object verification result fed back by the candidate object based on the object verification information, and generate a candidate request token of the candidate request identifier if the object verification result indicates that the candidate object has passed the verification, and associate and store the candidate request identifier and the candidate request token in the verification information database.

[0166] like Figure 3 As shown, server 304 can connect to one or more clients 302 via a local area network (LAN), wide area network (WAN), internet connection, or other types of data network. Client 302 can include, but is not limited to, smartphones, tablets, laptops, PDAs, personal computers, smart home devices, and in-vehicle devices. Client 302 can also interact with the user through a graphical user interface, receiving target activity input or selection, request content, and object verification operations from the target object, and sending candidate requests, object verification results, or target requests to server 304, thereby implementing the request verification method provided in the embodiments of this specification.

[0167] In this setup, client 302 and server 304 establish a connection via a network. The network provides the medium for communication between client 302 and server 304. The network can include various connection types, such as wired or wireless communication links or fiber optic cables. The data transmitted by client 302 may need to undergo encoding, transcoding, compression, or other processing before being published to server 304.

[0168] Client 302 can be a browser, application (APP), or web application such as HyperText Markup Language 5 (H5) application, or a lightweight application (also known as a mini-program), or cloud application, etc. Client 302 can be developed based on the software development kit (SDK) of the corresponding service provided by server 304, such as based on the Real-Time Communication (RTC) SDK. Client 302 can be deployed in electronic devices and depends on the device to run or on certain APPs on the device. Electronic devices may have a display screen and support information browsing, such as personal mobile terminals such as mobile phones, tablets, and personal computers. Various other types of applications can also be configured in electronic devices, such as human-computer interaction applications, model training applications, text processing applications, web browser applications, shopping applications, search applications, instant messaging tools, email clients, social platform software, etc.

[0169] Server-side 304 can include servers providing various services, such as servers providing communication services to multiple clients, servers supporting backend training of models used on clients, and servers processing data sent by clients. It should be noted that server-side 304 can be implemented as a distributed server cluster composed of multiple servers, or as a single server. The server can also be a server in a distributed system, or a server integrated with blockchain. The server can also be a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms, or an intelligent cloud computing server or intelligent cloud host with artificial intelligence technology.

[0170] It is worth noting that the request verification method provided in the embodiments of this specification is generally executed by the server. However, in other embodiments of this specification, the client may also have similar functionality to the server, thereby executing the request verification method provided in the embodiments of this specification. In other embodiments, the request verification method provided in the embodiments of this specification may also be executed jointly by the client and the server.

[0171] See Figure 4 , Figure 4This diagram illustrates a request verification interface according to an embodiment of this specification. The request verification interface may include a request input area, an object verification area, and a result display area. The request input area may include a target activity input box, a request content input box, an "OK" control, and a "Cancel" control; the object verification area may include an object verification information display box and verification operation controls; the result display area may include a result display box.

[0172] For example, such as Figure 4 As shown, the target activity input box can display "Target Activity: [Document Submission Activity A]", which shows the target activity the candidate is currently participating in; the request content input box can display "Request Content: [Document Type Summary]", which shows the request content the candidate is about to submit. Candidates can enter or select a target activity through the target activity input box and enter their request content through the request content input box.

[0173] After the user clicks the "OK" control, the client can send a candidate request to the server, which carries candidate request information. Upon receiving the candidate request, the server can generate a candidate request identifier based on the candidate request information and generate object verification information for the candidate object, which is then sent to the client. The client can display the object verification information and verification operation controls in the object verification area.

[0174] For example, such as Figure 4 As shown, the object validation information display box can show object validation prompts such as "Slide to the right end to complete the validation"; the validation operation control can be a sliding validation control. Users can perform validation operations in the object validation area based on the object validation information. For example, a user can drag the sliding validation control and move it to the right end to complete the object validation operation. The client can generate object validation results based on the user's validation operations and send the object validation results to the server.

[0175] The server obtains the object verification result based on the object verification information of the candidate object. If the object verification result indicates that the candidate object has passed the verification, a candidate request token with a candidate request identifier is generated, and the candidate request identifier and the candidate request token are associated and stored in the verification information database.

[0176] The client can display the generated candidate request tokens in the results display area. For example, such as... Figure 4As shown, the result display box can show prompts such as "Verification passed √" and "Candidate request token generated", indicating that the object verification has passed and the candidate request token has been successfully generated. Optionally, the result display box can also display the identification information, generation time information, or other prompts related to the candidate request token.

[0177] In practical applications, users can interact with controls in various ways, including clicking, double-clicking, touching, hovering, swiping, long-pressing, voice control, or shaking. The specific method chosen depends on the actual situation, and this specification does not impose any limitations on this.

[0178] Corresponding to the above method embodiments, this specification also provides embodiments of a request verification device. Figure 5 A schematic diagram of a request verification device according to one embodiment of this specification is shown. Figure 5 As shown, the device includes: The first acquisition module 502 is configured to acquire the target request sent by the target object for the target activity, wherein the target request carries target request information and the target request token corresponding to the target request information; The first generation module 504 is configured to generate a target request identifier for the target request based on the target request information; The first extraction module 506 is configured to extract an auxiliary request identifier from a verification information database based on the target request token. The verification information database includes multiple candidate request identifiers, each carrying a candidate request token. The auxiliary request token corresponding to the auxiliary request identifier is the same as the target request token. The first determining module 508 is configured to determine the request verification result of the target request based on the target request identifier and the auxiliary request identifier.

[0179] Optionally, the first generation module 504 is further configured to obtain request attribute information of the target request, wherein the request attribute information includes at least one of target object information of the target object and target activity information of the target activity; and generate a target request identifier of the target request based on the target request information and the request attribute information.

[0180] Optionally, the first determining module 508 is further configured to determine that the request verification result of the target request is verified as passed if the target request identifier and the auxiliary request identifier are consistent; and to determine that the request verification result of the target request is verified as failed if the target request identifier and the auxiliary request identifier are inconsistent.

[0181] Optionally, the device further includes: acquiring verification auxiliary information, wherein the verification auxiliary information includes at least one of the current status information of the target request token, the binding object information of the target request token, and the target activity information of the target activity; determining the request verification result of the target request based on the target request identifier and the auxiliary request identifier, including: determining the request verification result of the target request based on the verification auxiliary information, the target request identifier, and the auxiliary request identifier.

[0182] Optionally, the device further includes: obtaining the token lifecycle of the target request token, wherein the token lifecycle is determined based on the activity end time of the target activity and the target request time of the target request; and determining the current state information of the target request token based on the token lifecycle.

[0183] Optionally, the device further includes: acquiring a candidate request sent by a candidate object for a candidate activity, wherein the candidate request carries candidate request information; generating a candidate request identifier for the candidate request based on the candidate request information; generating a candidate request token for the candidate request identifier; and a storage module configured to associate and store the candidate request identifier and the candidate request token in a verification information database.

[0184] Optionally, the device further includes: generating object verification information for a candidate object and sending the object verification information to the candidate object; obtaining the object verification result fed back by the candidate object based on the object verification information; and generating a candidate request token of the candidate request identifier, including: generating a candidate request token of the candidate request identifier when the object verification result indicates that the candidate object has passed the verification.

[0185] Optionally, the device further includes: obtaining the activity end time of the candidate activity and the candidate request time of the candidate request; determining the object verification strength based on the activity end time and the candidate request time; and generating object verification information of the candidate object based on the object verification strength.

[0186] Optionally, the device further includes an update module configured to update the current status information of the target request token to an expired state if the request verification result is successful.

[0187] The scheme implemented in this specification involves an acquisition module obtaining a target request carrying target request information and a target request token, a generation module generating a target request identifier based on the target request information, an extraction module extracting an auxiliary request identifier from a verification information database based on the target request token, and a determination module determining the request verification result based on the target request identifier and the auxiliary request identifier. This allows the request verification process to simultaneously associate the current request information with the historical request information corresponding to the target request token, thereby reducing the reuse of the target request token after the target request information has been modified. Furthermore, by combining verification auxiliary information, object verification results, object verification strength, and token state updates, the reuse of request tokens and request replay can be reduced, improving the accuracy and security of request verification.

[0188] The above is an illustrative scheme of a request verification device according to this embodiment. It should be noted that the technical solution of this request verification device and the technical solution of the above-described request verification method belong to the same concept. For details not described in detail in the technical solution of the request verification device, please refer to the description of the technical solution of the above-described request verification method.

[0189] Corresponding to the above method embodiments, this specification also provides embodiments of a coal bidding request verification device. Figure 6 A schematic diagram of a coal bidding request verification device according to one embodiment of this specification is shown. Figure 6 As shown, the device includes: The second acquisition module 602 is configured to acquire the coal bidding request sent by the target user for the coal bidding activity, wherein the coal bidding request carries coal bidding request information and a coal bidding request token corresponding to the coal bidding information. The second generation module 604 is configured to generate a coal bidding request identifier for the coal bidding request based on the coal bidding request information. The second extraction module 606 is configured to extract a coal bidding auxiliary request identifier from the verification information database based on the coal bidding request token. The verification information database includes multiple candidate coal bidding request identifiers that each carry a candidate coal bidding request token. The auxiliary coal bidding request token corresponding to the auxiliary coal bidding request identifier is the same as the coal bidding request token. The second determining module 608 is configured to determine the coal bidding request verification result of the coal bidding request based on the coal bidding request identifier and the auxiliary coal bidding request identifier.

[0190] The scheme implemented in this specification involves a second acquisition module acquiring a coal bidding request carrying coal bidding request information and a coal bidding request token, a second generation module generating a coal bidding request identifier based on the coal bidding request information, a second extraction module extracting a coal bidding auxiliary request identifier from the verification information database based on the coal bidding request token, and a second determination module determining the coal bidding request verification result based on the coal bidding request identifier and the coal bidding auxiliary request identifier. This approach reduces the reuse of the target request token and the replay of coal bidding bid requests, thereby improving the accuracy and security of bid request verification in coal bidding activities.

[0191] The above is a schematic scheme of a coal bidding request verification device according to this embodiment. It should be noted that the technical solution of this coal bidding request verification device and the technical solution of the coal bidding request verification method described above belong to the same concept. For details not described in detail in the coal bidding request verification device, please refer to the description of the technical solution of the coal bidding request verification method described above.

[0192] Figure 7 A structural block diagram of a computing device according to one embodiment of this specification is shown. The components of the computing device 700 include, but are not limited to, a memory 710 and a processor 720. The processor 720 is connected to the memory 710 via a bus 730, and a database 750 is used to store data.

[0193] The computing device 700 also includes an access device 740, which enables the computing device 700 to communicate via one or more networks 760. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 740 may include one or more of any type of wired or wireless network interface (e.g., Network Interface Card (NIC)), such as an IEEE 802.11 Wireless Local Area Networks (WLAN) interface, a Wi-MAX (World Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.

[0194] In one embodiment of this specification, the above-described components of the computing device 700 and Figure 7 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 7 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0195] The computing device 700 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 700 can also be a mobile or stationary server.

[0196] The processor 720 is used to execute a computer program / instruction, which, when executed by the processor, implements the steps of the above-described request verification method.

[0197] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the above-described request verification method belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the above-described request verification method.

[0198] An embodiment of this specification also provides a computer-readable storage medium storing a computer program / instructions that, when executed by a processor, implement the steps of the above-described request verification method.

[0199] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the above-described request verification method belong to the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the above-described request verification method.

[0200] An embodiment of this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described request verification method.

[0201] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the above-described request verification method belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the above-described request verification method.

[0202] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0203] Computer instructions include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. Computer-readable media can 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 computer-readable media can be appropriately added or removed according to the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0204] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0205] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0206] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A request verification method, characterized in that, include: Obtain the target request sent by the target object for the target activity, wherein the target request carries target request information and a target request token corresponding to the target request information; Based on the target request information, a target request identifier for the target request is generated; Based on the target request token, an auxiliary request identifier is extracted from the verification information database, wherein the verification information database includes multiple candidate request identifiers that each carry a candidate request token, and the auxiliary request token corresponding to the auxiliary request identifier is the same as the target request token; The request verification result of the target request is determined based on the target request identifier and the auxiliary request identifier.

2. The method according to claim 1, characterized in that, The step of generating the target request identifier based on the target request information includes: Obtain the request attribute information of the target request, wherein the request attribute information includes at least one of the target object information of the target object and the target activity information of the target activity; Based on the target request information and the request attribute information, the target request identifier is generated.

3. The method according to claim 1, characterized in that, The step of determining the request verification result of the target request based on the target request identifier and the auxiliary request identifier includes: If the target request identifier matches the auxiliary request identifier, the request verification result of the target request is determined to be verified as passed. If the target request identifier and the auxiliary request identifier are inconsistent, the request verification result of the target request is determined to be a verification failure.

4. The method according to any one of claims 1 to 3, characterized in that, Before determining the request verification result of the target request based on the target request identifier and the auxiliary request identifier, the method further includes: Obtain verification assistance information, wherein the verification assistance information includes at least one of the current status information of the target request token, the binding object information of the target request token, and the target activity information of the target activity; The step of determining the request verification result of the target request based on the target request identifier and the auxiliary request identifier includes: The request verification result of the target request is determined based on the verification assistance information, the target request identifier, and the assistance request identifier.

5. The method according to claim 4, characterized in that, The verification assistance information includes the current status information of the target request token; The acquisition of verification auxiliary information includes: Obtain the token lifecycle of the target request token, wherein the token lifecycle is determined based on the activity end time of the target activity and the target request time of the target request; Based on the token's lifecycle, the current state information of the target request token is determined.

6. The method according to any one of claims 1 to 3, characterized in that, Before retrieving the auxiliary request identifier from the verification information database based on the target request token, the process further includes: Obtain the candidate request sent by the candidate object for the candidate activity, wherein the candidate request carries candidate request information; Based on the candidate request information, a candidate request identifier is generated for the candidate request; Generate a candidate request token for the candidate request identifier; The candidate request identifier and the candidate request token are associated and stored in the verification information database.

7. The method according to claim 6, characterized in that, Before generating the candidate request token that identifies the candidate request, the method further includes: Generate object verification information for the candidate object and send the object verification information to the candidate object; Obtain the object verification result fed back by the candidate object based on the object verification information; The candidate request token that generates the candidate request identifier includes: If the object verification result indicates that the candidate object has passed the verification, the candidate request token of the candidate request identifier is generated.

8. The method according to claim 7, characterized in that, The object verification information for generating the candidate object includes: Obtain the activity end time of the candidate activity and the candidate request time of the candidate request; The object verification strength is determined based on the activity end time and the candidate request time; Based on the object verification strength, the object verification information of the candidate object is generated.

9. The method according to any one of claims 1 to 3, characterized in that, After determining the request verification result of the target request based on the target request identifier and the auxiliary request identifier, the method further includes: If the request verification result is successful, the current status information of the target request token is updated to expired.

10. A method for verifying coal bidding requests, characterized in that, include: Obtain the coal bidding request sent by the target user for the coal bidding activity, wherein the coal bidding request carries coal bidding request information and a coal bidding request token corresponding to the coal bidding request information; Based on the coal bidding request information, a coal bidding request identifier is generated for the coal bidding request. Based on the coal bidding request token, a coal bidding auxiliary request identifier is extracted from the verification information database. The verification information database includes multiple candidate coal bidding request identifiers, each carrying a candidate coal bidding request token. The coal bidding auxiliary request token corresponding to the coal bidding auxiliary request identifier is the same as the coal bidding request token. The coal bidding request verification result is determined based on the coal bidding request identifier and the coal bidding auxiliary request identifier.

11. A computing device, characterized in that, include: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the method according to any one of claims 1 to 10.

12. A computer-readable storage medium, characterized in that, It stores a computer program / instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1 to 10.

13. A computer program product, characterized in that, Includes a computer program / instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1 to 10.

Images