Request processing method, request sending method, request processing device, request sending device and electronic equipment

Abstract

The invention provides a request processing method and device, a request sending method and device and electronic equipment, and relates to the technical field of network security and website development, in particular to the technical field of request verification. The method comprises: receiving token generation information sent by a client, the token generation information comprising at least one of device information of a first device logged in by a first account, first behavior information corresponding to the first account, and network environment information of the first device; generating a first token corresponding to the first account based on the token generation information, and sending the first token to the client; receiving a request corresponding to the first account sent by the client, and extracting a second token corresponding to the first account from the request; and based on the first token, verifying the second token.

Description

Technical Field

[0001] The present disclosure relates to the fields of network security and website development technology, and in particular to the field of request verification technology, and in particular to a request processing method, a request sending method, a device, an electronic device, a storage medium, and a computer program product. Background Art

[0002] In the related art, after receiving the request sent by the client, the server will mostly verify the token in the request to verify the request. However, during the transmission and use of the token, there is a problem of token leakage, resulting in low network security. Summary of the invention

[0003] The present disclosure proposes a request processing method, a request sending method, an apparatus, an electronic device, a storage medium and a computer program product.

[0004] According to a first aspect of the present disclosure, a request processing method is proposed, including: receiving token generation information sent by a client, wherein the token generation information includes at least one of device information of a first device logged in by a first account, first behavior information corresponding to the first account, and network environment information of the first device; based on the token generation information, generating a first token corresponding to the first account, and sending the first token to the client; receiving a request corresponding to the first account sent by the client, and extracting a second token corresponding to the first account from the request; and verifying the second token based on the first token.

[0005] According to a second aspect of the present disclosure, a request sending method is proposed, including: obtaining token generation information, and sending the token generation information to a server, wherein the token generation information includes at least one of device information of a first device logged in by a first account, first behavior information corresponding to the first account, and network environment information of the first device; receiving a first token corresponding to the first account sent by the server; obtaining a second token corresponding to the first account; generating a request corresponding to the first account based on the second token, and sending the request to the server.

[0006] According to a third aspect of the present disclosure, a request processing device is proposed, including: a first receiving module, used to receive token generation information sent by a client, wherein the token generation information includes at least one of device information of a first device logged in by a first account, first behavior information corresponding to the first account, and network environment information of the first device; a generation module, used to generate a first token corresponding to the first account based on the token generation information, and send the first token to the client; a second receiving module, used to receive a request corresponding to the first account sent by the client, and extract a second token corresponding to the first account from the request; and a verification module, used to verify the second token based on the first token.

[0007] According to a fourth aspect of the present disclosure, a request sending device is proposed, comprising: a first sending module, used to obtain token generation information, and send the token generation information to a server, wherein the token generation information includes at least one of device information of a first device logged in by a first account, first behavior information corresponding to the first account, and network environment information of the first device; a receiving module, used to receive a first token corresponding to the first account sent by the server; an obtaining module, used to obtain a second token corresponding to the first account; and a second sending module, used to generate a request corresponding to the first account based on the second token, and send the request to the server.

[0008] According to the fifth aspect of the present disclosure, an electronic device is proposed, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the request processing method proposed in the first aspect above, and / or execute the request sending method proposed in the second aspect above.

[0009] According to the sixth aspect of the present disclosure, a non-transitory computer-readable storage medium storing computer instructions is proposed, wherein the computer instructions are used to enable the computer to execute the request processing method proposed in the first aspect above, and / or execute the request sending method proposed in the second aspect above.

[0010] According to a seventh aspect of the present disclosure, a computer program product is proposed, comprising a computer program, which, when executed by a processor, implements the request processing method proposed in the first aspect and / or implements the request sending method proposed in the second aspect.

[0011] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present disclosure, nor is it intended to limit the scope of the present disclosure. Other features of the present disclosure will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The accompanying drawings are used to better understand the present solution and do not constitute a limitation of the present disclosure.

[0013] Figure 1 A flowchart of a request processing method according to an embodiment of the present disclosure;

[0014] Figure 2 A flowchart of a request processing method according to another embodiment of the present disclosure;

[0015] Figure 3 A flowchart of a request processing method according to another embodiment of the present disclosure;

[0016] Figure 4 A schematic diagram of the structure of a request processing and sending system according to an embodiment of the present disclosure;

[0017] Figure 5 It is a structural diagram of a request processing device according to an embodiment of the present disclosure;

[0018] Figure 6 This is a schematic diagram of the structure of a request sending device according to an embodiment of the present disclosure;

[0019] Figure 7 A schematic block diagram of an electronic device according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0020] The following is a description of exemplary embodiments of the present disclosure in conjunction with the accompanying drawings, including various details of the embodiments of the present disclosure to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those of ordinary skill in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present disclosure. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0021] Network security refers to a series of technologies and practices that protect computer systems and networks from information leakage, damage or unauthorized access. It aims to ensure the confidentiality, integrity and availability of data, often referred to as the CIA triad. It involves encryption, firewalls, authentication and authorization, security protocols and other technologies.

[0022] Website development refers to the process of creating, building, and maintaining a website, including front-end development (user interface design) and back-end development (server-side logic implementation). It involves a variety of technologies and tools with the goal of providing a feature-rich and easy-to-use online experience. It involves front-end technology, back-end technology, user interface design and other technologies.

[0023] Request validation refers to the process of checking whether the requests received from the client are legal, safe, and in the expected format. This step is crucial to preventing XSS (Cross-Site Scripting) attacks, CSRF (Cross-Site Request Forgery) attacks, etc. It involves input validation, output encoding, signature verification, rate limiting and other technologies.

[0024] Figure 1 FIG. 1 is a flowchart of a request processing method according to an embodiment of the present disclosure. Figure 1 As shown, the method includes:

[0025] S101, receiving token generation information sent by a client, wherein the token generation information includes at least one of device information of a first device logged in by a first account, first behavior information corresponding to the first account, and network environment information of the first device.

[0026] It should be noted that the execution subject of the request processing method of the embodiment of the present disclosure is the server.

[0027] It should be noted that the account refers to the user's identity on the client (such as a browser), and there is no excessive limitation on the device, such as a mobile phone, a computer, a car terminal, etc. Behavior information refers to the behavior information of the user corresponding to the first account, such as the interaction information between the user corresponding to the first account and the client.

[0028] Exemplarily, the device information includes the device model, operating system type and version number, client type and version number, unique identifier of the device, etc. Among them, the unique identifier includes IMEI (International Mobile Equipment Identity) code, UUID (Universally Unique Identifier), etc.

[0029] Exemplarily, behavior information includes the path of user operations (such as entering a page, requesting resources), information corresponding to information modification behaviors (such as password modification, address modification, contact information modification), resource consumption methods, user operation speed, keyboard operation sequence for entering information (such as account number, password), etc.

[0030] Exemplarily, the network environment information includes network type (such as wireless network, mobile data network), network service provider information, IP (Internet Protocol) address, geographical location information to which the IP address belongs, and the like.

[0031] Exemplarily, the token generation information also includes the first account number.

[0032] In one embodiment, the method further includes storing the token generation information in a local storage space.

[0033] S102: Generate a first token corresponding to the first account based on the token generation information, and send the first token to the client.

[0034] It is understandable that different accounts may have different corresponding tokens. The first token refers to the token corresponding to the first account of the server. There are no excessive restrictions on the first token. For example, it may include an initial token generated based on token generation information, a token encrypted from the initial token, etc.

[0035] In one embodiment, the method further includes adding at least one of the first account number, the first timestamp, and the random number to the token generation information. It should be noted that the first timestamp refers to the time when the first token is generated.

[0036] In one implementation, based on the token generation information, a first token corresponding to the first account is generated, including fusing multiple token generation information to obtain the first token.

[0037] In some examples, based on the token generation information, a first token corresponding to the first account is generated, including fusing the device information of the first device, the first behavior information, the network environment information of the first device, the first account, the first timestamp and the random number to obtain the first token. As a result, the tokens generated by the same account in different devices, different behavior modes, different network environments and different times are different, and the token usage scenarios can be precisely limited. Even if the token in a certain scenario is leaked, the token cannot be reused in other scenarios, effectively preventing cross-scenario attacks after the token is leaked.

[0038] In one embodiment, based on the token generation information, a first token corresponding to the first account is generated, including processing the token generation information based on a set coding rule and / or encryption algorithm to obtain the first token.

[0039] In one embodiment, sending the first token to the client includes encrypting the first token based on the public key to obtain the encrypted first token, and sending the encrypted first token and the public key to the client. For example, the private key and the public key can be obtained based on an asymmetric encryption algorithm, wherein the asymmetric encryption algorithm includes an RSA algorithm.

[0040] In one embodiment, the method further includes storing the first token in a local storage space.

[0041] For example, the server receives the device information of device 1 logged in by account 1, the first behavior information corresponding to account 1, and the network environment information of device 1 sent by client A, and generates a token X1 corresponding to account 1 based on the device information of device 1, the first behavior information corresponding to account 1, the network environment information of device 1, account 1, timestamp and random number, and sends token X1 to client A. It should be noted that in this embodiment, account 1 is the first account, device 1 is the first device, and token X1 is the first token.

[0042] For example, the server receives the device information of device 2 logged in by account 2, the first behavior information corresponding to account 2, and the network environment information of device 2 sent by client B, and generates a token Y1 corresponding to account 2 based on the device information of device 2, the first behavior information corresponding to account 2, the network environment information of device 2, account 2, timestamp and random number, and sends token Y1 to client B. It should be noted that in this embodiment, account 2 is the first account, device 2 is the first device, and token Y1 is the first token.

[0043] S103, receiving a request corresponding to the first account sent by the client, and extracting a second token corresponding to the first account from the request.

[0044] S104: Verify the second token based on the first token.

[0045] It should be noted that there are no excessive restrictions on the request corresponding to the first account, for example, it may include the request initiated by the user corresponding to the first account, the request actively initiated by the client, etc. The request carries the second token corresponding to the first account, and the second token refers to the token corresponding to the first account of the client. There are no excessive restrictions on the second token, for example, it may include the initial token corresponding to the first account of the client, the token encrypted after the initial token, etc. The first token may be consistent with the second token or inconsistent with it.

[0046] It should be noted that the verification of the second token based on the first token can be implemented by using any token verification method in the relevant technology, and no further limitations are made here.

[0047] In one embodiment, based on the first token, the second token is verified, including determining that the second token has passed the verification in response to the first token being consistent with the second token, and determining that the second token has not passed the verification in response to the first token being inconsistent with the second token. In this way, it is possible to identify whether the first token corresponding to the local account of the server is consistent with the second token corresponding to the account in the request, so as to verify the second token.

[0048] In one embodiment, verifying the second token further includes determining that the second token fails verification in response to the second token failing to comply with a set token format.

[0049] In one embodiment, extracting the second token corresponding to the first account from the request includes extracting the third token corresponding to the first account from the request, and decrypting the third token based on the private key to obtain the second token. It should be noted that the third token refers to the encrypted second token.

[0050] For example, continuing to use client A as an example, the server receives the request corresponding to account 1 sent by client A, and extracts token X2 corresponding to account 1 from the request corresponding to account 1, and verifies token X2 based on token X1. It should be noted that token X2 is the second token in this embodiment.

[0051] For example, continuing to use client B as an example, the server receives the request corresponding to account 2 sent by client B, and extracts token Y2 corresponding to account 2 from the request corresponding to account 2, and verifies token Y2 based on token Y1. It should be noted that token Y2 is the second token in this embodiment.

[0052] The request processing method proposed in the present disclosure receives token generation information sent by a client, wherein the token generation information includes at least one of the device information of the first device logged in by the first account, the first behavior information corresponding to the first account, and the network environment information of the first device. Based on the token generation information, a first token corresponding to the first account is generated, and the first token is sent to the client. A request corresponding to the first account sent by the client is received, and a second token corresponding to the first account is extracted from the request. Based on the first token, the second token is verified. Thus, considering at least one of the device information of the device logged in by the account, the behavior information corresponding to the account, and the network environment information of the device logged in by the account, a token corresponding to the account is generated to verify the request corresponding to the account. The tokens generated by the same account in different devices and / or different behavior modes and / or different network environments are different. The token usage scenarios can be precisely limited. Even if the token in a certain scenario is leaked, the token cannot be reused in other scenarios, which effectively prevents cross-scenario attacks after the token is leaked, can effectively defend against CSRF attacks, and helps to improve network security.

[0053] Figure 2 FIG. 1 is a flowchart of a request processing method according to another embodiment of the present disclosure. Figure 2 As shown, the method includes:

[0054] S201, receiving token generation information sent by a client, wherein the token generation information includes at least one of device information of a first device logged in by a first account, first behavior information corresponding to the first account, and network environment information of the first device.

[0055] S202: Generate a first token corresponding to the first account based on the token generation information, and send the first token to the client.

[0056] S203: Receive a request corresponding to the first account sent by the client.

[0057] S204: Extract a second token corresponding to the first account from the request.

[0058] S205: Verify the second token based on the first token.

[0059] The relevant contents of steps S201-S205 can be found in the above embodiment and will not be repeated here.

[0060] S206, extracting verification information from the request, wherein the verification information includes at least one of device information of the second device logged in by the first account, second behavior information corresponding to the first account, and network environment information of the second device.

[0061] S207, verify the verification information.

[0062] It should be noted that there is no restriction on the execution order of steps S204-S207, which can be executed in series or in parallel. For example, the execution order of steps S204-S205 is earlier than that of steps S206-S207.

[0063] It should be noted that the token generation information and verification information are collected at different times. The device logged in by the first account, the device information corresponding to the first account, the behavior information and the network environment information may all change. That is, the first device may be different from the second device, the device information of the first device may be different from the device information of the second device, the first behavior information may be different from the second behavior information, and the network environment information of the first device may be different from the network environment information of the second device.

[0064] In one embodiment, verifying the verification information includes obtaining determination information, wherein the determination information includes at least one of device information of the first device, first behavior information, and network environment information of the first device, and verifying the verification information based on the determination information. Thus, the verification information can be verified by considering the determination information composed of at least one of the device information of the first device, the first behavior information, and the network environment information of the first device.

[0065] It should be noted that there are no excessive restrictions on the method of obtaining the determination information. For example, the determination information can be obtained from the local storage space of the server, and / or the determination information can be determined from the token generation information, and / or the determination information can be extracted from the first token. When the first token is consistent with the second token, the determination information can be extracted from the second token.

[0066] In the embodiments of the present disclosure, verification information is verified based on the determination information, including the following possible implementations:

[0067] Method 1: In response to the device information of the first device being consistent with the device information of the second device, it is determined that the device information of the second device has passed the verification; in response to the device information of the first device being inconsistent with the device information of the second device, indicating that the device information corresponding to the first account has changed, it is determined that the device information of the second device has not passed the verification.

[0068] In this way, it is possible to identify whether the device information of the first device is consistent with the device information of the second device in the request to verify the device information of the second device. When the device information of the first device is consistent with the device information of the second device, that is, when the device information corresponding to the first account has not changed, it is determined that the device information of the second device has passed the verification. When the device information of the first device is inconsistent with the device information of the second device, that is, when the device information corresponding to the first account has changed, it is determined that the device information of the second device has not passed the verification.

[0069] Method 2: obtaining a first difference parameter between the first behavior information and the second behavior information, and verifying the second behavior information based on the first difference parameter.

[0070] Thus, changes in the behavior information corresponding to the account may be taken into consideration to verify the second behavior information.

[0071] It should be noted that there are not too many restrictions on the difference parameters, for example, they may include consistency, difference (such as range), absolute value of difference, degree of difference, etc.

[0072] Exemplarily, based on the first difference parameter, the second behavior information is verified, including determining that the second behavior information has passed the verification in response to the first difference parameter being used to characterize that the first behavior information is consistent with the second behavior information, indicating that the behavior information corresponding to the first account has not changed, and determining that the second behavior information has not passed the verification in response to the first difference parameter being used to characterize that the first behavior information is inconsistent with the second behavior information, indicating that the behavior information corresponding to the first account has changed.

[0073] Exemplarily, based on the first difference parameter, the second behavior information is verified, including in response to the first difference parameter being less than or equal to a set threshold, indicating that the behavior information corresponding to the first account has not changed drastically, determining that the second behavior information has passed the verification, and in response to the first difference parameter being greater than the set threshold, indicating that the behavior information corresponding to the first account has changed drastically, determining that the second behavior information has not passed the verification.

[0074] Method 3: obtaining a second difference parameter between the network environment information of the first device and the network environment information of the second device, and verifying the network environment information of the second device based on the second difference parameter.

[0075] Thus, changes in the network environment information corresponding to the account can be taken into account to verify the network environment information of the second device.

[0076] It should be noted that, for the relevant content of verifying the network environment information of the second device based on the second difference parameter, reference may be made to the relevant content of verifying the second behavior information based on the first difference parameter, and will not be repeated here.

[0077] Exemplarily, based on the second difference parameter, the network environment information of the second device is verified, including determining that the network environment information of the second device has passed the verification in response to the second difference parameter being used to characterize that the IP address of the first device and the IP address of the second device belong to the same region, and determining that the network environment information of the second device has not passed the verification in response to the second difference parameter being used to characterize that the IP address of the first device and the IP address of the second device do not belong to the same region.

[0078] Mode 4: In response to the first account being consistent with the second account, determining that the second account has passed the verification; in response to the first account being inconsistent with the second account, determining that the second account has not passed the verification.

[0079] In this embodiment, the determination information includes a first account, and the verification information includes a second account. The first account is the account logged into the client at the time of collecting the token generation information, and the second account is the account logged into the client at the time of collecting the verification information. The account logged into the client may change, that is, the first account and the second account may be different.

[0080] In this way, it is possible to identify whether the first account is consistent with the second account in the request to verify the second account. When the first account is consistent with the second account, that is, when the account for logging into the client has not changed, it is determined that the second account has passed the verification. When the first account is inconsistent with the second account, that is, when the account for logging into the client has changed, it is determined that the second account has not passed the verification.

[0081] Mode 5: In response to the time interval between the first timestamp and the second timestamp being less than or equal to a fourth set time length, determining that the second timestamp has passed the verification; in response to the time interval being greater than the fourth set time length, determining that the second timestamp has not passed the verification.

[0082] In this embodiment, the determination information includes a first timestamp, and the verification information includes a second timestamp, where the second timestamp refers to the time when the request is generated or sent. There are no excessive restrictions on the fourth set duration, for example, it may include the valid duration of the first token, such as 15 minutes.

[0083] Therefore, the second timestamp may be verified by taking into account the relationship between the time interval between the first timestamp and the second timestamp in the request and the fourth set time length.

[0084] In one embodiment, verifying the verification information includes determining that the verification information passes the verification in response to the verification information meeting the set rules, and determining that the verification information fails the verification in response to the verification information not meeting the set rules.

[0085] In one embodiment, the verification information is verified, including determining that the second behavior information has passed the verification in response to the operation speed in the second behavior information being less than or equal to a set threshold, and determining that the second behavior information has failed the verification in response to the operation speed in the second behavior information being greater than the set threshold.

[0086] S208: In response to the second token and each verification information being verified, determining that the request is verified.

[0087] S209: In response to the second token and / or the at least one verification information failing verification, determine that the request fails verification.

[0088] In this embodiment, when the second token and each verification information pass the verification, it is determined that the request passes the verification; conversely, when the second token and / or at least one verification information fails the verification, it is determined that the request fails the verification. That is, a multiple verification mechanism of a token and at least one verification information can be adopted in the request processing scenario, thereby improving network security.

[0089] In one implementation, after determining that the request has passed the verification, the process further includes responding to the request, such as sending response data of the request to the client.

[0090] In one embodiment, after determining that the request has not passed the verification, it also includes adding at least one of the client source of the request, the time when the request is received, and the reason why the request has not passed the verification to the verification result of the request to record the relevant information of the request that has not passed the verification.

[0091] In one embodiment, after determining that the request has not passed the verification, it also includes rejecting the response request and sending indication information indicating the rejection of the response request to the client, so as to promptly inform the user that the request is rejected.

[0092] In one embodiment, the method further includes sending a verification result of the request to the client, wherein the verification result of the request is used to indicate whether the request passes the verification.

[0093] The request processing method proposed in the present disclosure extracts verification information from the request, wherein the verification information includes at least one of the device information of the second device logged in by the first account, the second behavior information corresponding to the first account, and the network environment information of the second device, and verifies the verification information. Thus, at least one of the device information of the device logged in by the account, the behavior information corresponding to the account, and the network environment information of the device logged in by the account in the request can be verified to verify the request corresponding to the account, thereby improving network security.

[0094] Based on any of the above embodiments, updating the first token includes at least one of the following possible implementations:

[0095] Method 1: In response to a first account logging into a client, the first token is updated.

[0096] In some examples, updating the first token includes sending a token update request to a client, receiving token generation information resent by the client, and updating the first token based on the re-acquired token generation information.

[0097] Exemplarily, based on the reacquired token generation information, the first token is updated, including adding a new first token based on the reacquired token generation information, and using the new first token as the final first token (ie, the updated first token).

[0098] For example, adding a first token based on the re-acquired token generation information includes adding a first token based on the re-acquired token generation information and the original token generation information.

[0099] Exemplarily, after the first token is added, the process further includes determining that the original first token is invalid and determining that the newly added first token is valid.

[0100] Exemplarily, the method further includes deleting the original first token from the local storage space.

[0101] Method 2: Update the first token according to a set period.

[0102] It should be noted that there are no excessive restrictions on the set period, and the set period can be a fixed value or dynamically updated. For example, the set period can be 15 minutes.

[0103] In some examples, updating the set period includes shortening the set period in response to a change in at least one of the device information, behavior information, and network environment information corresponding to the first account. Thus, when at least one of the device information, behavior information, and network environment information corresponding to the account changes, it indicates that there is a high risk of network security, and the set period is shortened.

[0104] In some examples, updating the set period includes shortening the set period in response to a change parameter of at least one of the device information, behavior information, and network environment information corresponding to the first account being greater than a set threshold. Thus, when at least one of the device information, behavior information, and network environment information corresponding to the first account changes dramatically, it indicates that there is a high risk of network security, and the set period is shortened.

[0105] In some examples, updating the set period includes shortening the set period in response to the second set behavior of the first account. Thus, when the second set behavior of the account exists, it can be indicated that there is a high risk of network security and the set period is shortened. It should be noted that there are no excessive restrictions on the second set behavior, for example, it may include information modification behavior, resource request behavior, resource consumption behavior, etc.

[0106] In some examples, updating the set period includes extending the set period in response to at least one of the device information, behavior information, and network environment information corresponding to the first account not changing within the first set time period. Thus, when at least one of the device information, behavior information, and network environment information corresponding to the account not changing within the first set time period, it can be indicated that there is a low risk of network security and the set period can be extended.

[0107] In some examples, updating the set period includes extending the set period in response to a change parameter of at least one of the device information, behavior information, and network environment information corresponding to the first account within a fifth set time period being less than or equal to a set threshold. Thus, when at least one of the device information, behavior information, and network environment information corresponding to the first account does not change dramatically within the fifth set time period, it indicates that there is a low risk in network security, and the set period is extended.

[0108] In some examples, updating the set period includes extending the set period in response to the first account not having the second set behavior within the second set time period. Thus, when the account does not have the second set behavior within the second set time period, it indicates that there is a low risk in network security, and the set period is extended.

[0109] In some examples, updating the set period includes extending the set period in response to multiple requests from the first account being verified successfully within the third set period. Thus, when multiple requests from the account are verified successfully within the third set period, it indicates that there is a low risk in network security, and the set period is extended.

[0110] Method 3: in response to the first account having a first setting behavior, updating the first token.

[0111] It should be noted that there are not too many restrictions on the first setting behavior, for example, it may include information modification behavior, resource request behavior, resource consumption behavior, etc.

[0112] Mode 4: In response to the request not being verified, the first token is updated.

[0113] Therefore, the token corresponding to the account can be updated each time the account logs into the client, and / or the first token can be updated periodically, and / or the first token can be updated when the account has a first set behavior, and / or the first token can be updated when the request corresponding to the account is not verified, which can avoid token leakage and improve the real-time and security of the token.

[0114] Based on any of the above embodiments, after the first token is updated, the method further includes sending the updated first token to the client to achieve synchronous update of the token on the server and the client.

[0115] Figure 3 FIG. 1 is a flow chart of a request sending method according to an embodiment of the present disclosure. Figure 3 As shown, the method includes:

[0116] S301, obtaining token generation information, and sending the token generation information to the server, wherein the token generation information includes at least one of device information of a first device logged in by a first account, first behavior information corresponding to the first account, and network environment information of the first device.

[0117] S302, receiving a first token corresponding to a first account sent by a server.

[0118] S303: Obtain a second token corresponding to the first account.

[0119] S304: Generate a request corresponding to the first account based on the second token, and send the request to the server.

[0120] It should be noted that the execution subject of the request processing method of the embodiment of the present disclosure is the client. The relevant contents of steps S301-S304 can be found in the above embodiment and will not be repeated here.

[0121] It should be noted that the request corresponding to the first account generated based on the second token can be implemented by using any request generation method in the relevant technology, and no excessive restrictions are made here.

[0122] In one implementation, generating a request corresponding to the first account based on the second token includes adding the second token to a request header and generating a request based on the request header.

[0123] In one embodiment, generating a request corresponding to the first account based on the second token includes obtaining verification information, wherein the verification information includes at least one of device information of the second device logged in by the first account, second behavior information corresponding to the first account, and network environment information of the second device, and generating the request based on the second token and the verification information. Thus, the request corresponding to the account can be generated by taking into account at least one of device information of the device logged in by the account, behavior information corresponding to the account, and network environment information of the device logged in by the account, and the token corresponding to the account locally on the client.

[0124] For example, continuing with client A, client A obtains the device information of device 1 logged in by account 1, the first behavior information corresponding to account 1, and the network environment information of device 1, and sends the device information of device 1, the first behavior information corresponding to account 1, and the network environment information of device 1 to the server, and receives token X1 corresponding to account 1 sent by the server.

[0125] Client A obtains token X2 corresponding to account 1, generates a request corresponding to account 1 based on token X2, device information of device 3 logged in by account 1, second behavior information corresponding to account 1, and network environment information of device 3, and sends the request corresponding to account 1 to the server. It should be noted that in this embodiment, device 3 is the second device.

[0126] For example, continuing with client B, client B obtains the device information of device 2 logged in by account 2, the first behavior information corresponding to account 2, and the network environment information of device 2, and sends the device information of device 2, the first behavior information corresponding to account 2, and the network environment information of device 2 to the server, and receives token Y1 corresponding to account 2 sent by the server.

[0127] Client B obtains token Y2 corresponding to account 2, generates a request corresponding to account 2 based on token Y2, device information of device 4 logged in by account 2, second behavior information corresponding to account 2, and network environment information of device 4, and sends the request corresponding to account 2 to the server. It should be noted that in this embodiment, device 4 is the second device.

[0128] In one implementation, after receiving the first token corresponding to the first account sent by the server, the method further includes storing the first token in a local storage space.

[0129] In one embodiment, the method further includes receiving a token update request sent by the server, reacquiring token generation information, and sending the reacquired token generation information to the server. Thus, when receiving a token update request sent by the server, the token generation information can be reacquired and sent to the server so that the server updates the first token.

[0130] In one embodiment, the method further includes receiving a token update request sent by the server, determining that the original first token is invalid, and / or deleting the original first token from the local storage space.

[0131] In one embodiment, the method further includes receiving an updated first token sent by the server, determining that the updated first token is effective, and / or storing the updated first token in a local storage space.

[0132] In one embodiment, the method further includes receiving a verification result of the request sent by the server, wherein the verification result of the request is used to indicate whether the request passes the verification.

[0133] In one embodiment, the method further includes generating a reminder message instructing to re-enter the login information of the first account in response to the request failing to pass the verification. It should be noted that the login information is not too limited, for example, it may include the first account, the login password of the first account, the verification code, etc. Thus, after the request fails to pass the verification, the client can force the user to log in again, thereby improving network security.

[0134] In one embodiment, the method further includes, in response to the request failing verification, determining that the original first token is invalid, and / or deleting the original first token from the local storage space.

[0135] The request sending method proposed in the present disclosure obtains token generation information and sends the token generation information to the server, wherein the token generation information includes at least one of the device information of the first device logged in by the first account, the first behavior information corresponding to the first account, and the network environment information of the first device, receives the first token corresponding to the first account sent by the server, obtains the second token corresponding to the first account, generates a request corresponding to the first account based on the second token, and sends the request to the server. Thus, at least one of the device information of the device logged in by the account, the behavior information corresponding to the account, and the network environment information of the device logged in by the account can be sent to the server as token generation information. The tokens generated by the same account in different devices and / or different behavior modes and / or different network environments are different, and the token usage scenarios can be precisely limited. Even if the token in a certain scenario is leaked, the token cannot be reused in other scenarios, which effectively prevents cross-scenario attacks after the token is leaked, can effectively defend against CSRF attacks, and helps to improve network security.

[0136] Based on any of the above embodiments, Figure 4 As shown, the request processing and sending system 400 includes a multi-factor data collection module 401, a dynamic token generation module 402, a request verification module 403 and a client interaction module 404. The multi-factor data collection module 401 and the client interaction module 404 are deployed on the client, and the dynamic token generation module 402 and the request verification module 403 are deployed on the server.

[0137] The multi-factor data collection module 401 includes a device information collection unit 1, a user behavior information collection unit 2, and a network environment information collection unit 3. The device information collection unit 1 is used to collect device information corresponding to the first account, the user behavior information collection unit 2 is used to collect behavior information corresponding to the first account, and the network environment information collection unit 3 is used to collect network environment information corresponding to the first account.

[0138] The dynamic token generation module 402 includes a multi-factor fusion unit 4, a dynamic update unit 5 and a token encryption unit 6. The multi-factor fusion unit 4 is used to fuse the token generation information, the first account, the first timestamp and the random number to obtain the first token, the dynamic update unit 5 is used to update the first token, and the token encryption unit 6 is used to encrypt the first token based on the public key to obtain the encrypted first token, and send the encrypted first token and the public key to the client.

[0139] The client interaction module 404 includes a token receiving unit 10 , a request building unit 11 and a feedback processing unit 12 .

[0140] The token receiving unit 10 is used to receive the encrypted first token and public key sent by the client.

[0141] The request construction unit 11 is used to encrypt the second token based on the public key to obtain the encrypted second token, and generate a request corresponding to the first account based on the encrypted second token and verification information, and send the request to the server.

[0142] The feedback processing unit 12 is used to receive the request verification result sent by the server, and if the request verification result indicates that the request has passed the verification, call the backend service interface to respond to the request. If the request verification result indicates that the request has not passed the verification, send an indication message indicating that the response request has been rejected to the message receiving object (such as a device or mailbox) associated with the first account.

[0143] The feedback processing unit 12 is further configured to delete the original first token from the local storage space and trigger an update operation of the first token if the request verification result indicates that the request has not passed the verification.

[0144] The feedback processing unit 12 is further configured to generate a reminder message instructing to re-enter the login information of the first account if the request verification result indicates that the request has not passed the verification.

[0145] Among them, the request verification module 403 includes a token extraction unit 7, a multi-factor verification unit 8 and a legitimacy determination unit 9. The token extraction unit 7 is used to extract the encrypted second token from the request. The multi-factor verification unit 8 is used to decrypt the encrypted second token based on the private key, obtain the second token, verify the second token, extract verification information from the request, and verify the verification information. The legitimacy determination unit 9 is used to determine whether the request is legal based on the verification results of the second token and the verification information, that is, to determine whether the request has passed the verification. If the request has passed the verification, the request is forwarded to the back-end business processing module. If the request has not passed the verification, the response request is rejected. It is also used to send the verification result of the request to the feedback processing unit 12.

[0146] In the technical solution of the present disclosure, the collection, storage, use, processing, transmission, provision and disclosure of user personal information involved are in compliance with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0147] According to an embodiment of the present disclosure, the present disclosure also provides a request processing device for implementing the above-mentioned request processing method.

[0148] Figure 5 is a block diagram of a request processing device according to an embodiment of the present disclosure.

[0149] like Figure 5 As shown, the request processing device 500 includes: a first receiving module 501, a generating module 502, a second receiving module 503 and a verifying module 504.

[0150] A first receiving module 501 is used to receive token generation information sent by a client, wherein the token generation information includes at least one of device information of a first device logged in by a first account, first behavior information corresponding to the first account, and network environment information of the first device;

[0151] A generating module 502, configured to generate a first token corresponding to the first account based on the token generation information, and send the first token to the client;

[0152] A second receiving module 503 is used to receive a request corresponding to the first account sent by the client, and extract a second token corresponding to the first account from the request;

[0153] The verification module 504 is configured to verify the second token based on the first token.

[0154] In one embodiment of the present disclosure, the verification module 504 is further used to: in response to the first token being consistent with the second token, determine that the second token has passed the verification; in response to the first token being inconsistent with the second token, determine that the second token has not passed the verification.

[0155] In one embodiment of the present disclosure, the verification module 504 is further used to: extract verification information from the request, wherein the verification information includes at least one of device information of the second device logged in by the first account, second behavior information corresponding to the first account, and network environment information of the second device; and verify the verification information.

[0156] In one embodiment of the present disclosure, the verification module 504 is further used to: obtain determination information, wherein the determination information includes at least one of device information of the first device, the first behavior information, and network environment information of the first device; and verify the verification information based on the determination information.

[0157] In one embodiment of the present disclosure, the verification module 504 is further used to: in response to the device information of the first device being consistent with the device information of the second device, determine that the device information of the second device has passed the verification; in response to the device information of the first device being inconsistent with the device information of the second device, determine that the device information of the second device has not passed the verification.

[0158] In one embodiment of the present disclosure, the verification module 504 is further used to: obtain a first difference parameter between the first behavior information and the second behavior information; and verify the second behavior information based on the first difference parameter.

[0159] In one embodiment of the present disclosure, the verification module 504 is further used to: obtain a second difference parameter between the network environment information of the first device and the network environment information of the second device; and verify the network environment information of the second device based on the second difference parameter.

[0160] In one embodiment of the present disclosure, the determination information includes the first account number, and the verification information includes a second account number;

[0161] The verification module 504 is further configured to: in response to the first account being consistent with the second account, determine that the second account has passed the verification; in response to the first account being inconsistent with the second account, determine that the second account has not passed the verification.

[0162] In one embodiment of the present disclosure, the verification module 504 is further configured to: in response to the second token and / or at least one of the verification information failing to pass verification, determine that the request fails to pass verification.

[0163] In one embodiment of the present disclosure, the device 500 also includes: an update module, used to: update the first token in response to the first account logging into the client; update the first token according to a set period; update the first token in response to the first account having a first set behavior; update the first token in response to the request not being verified.

[0164] In one embodiment of the present disclosure, the update module is also used to: shorten the setting period in response to a change in at least one of the device information, behavior information, and network environment information corresponding to the first account; shorten the setting period in response to the existence of a second setting behavior in the first account; extend the setting period in response to no change in at least one of the device information, behavior information, and network environment information corresponding to the first account within a first setting time period; extend the setting period in response to no second setting behavior in the first account within a second setting time period; extend the setting period in response to multiple requests of the first account being verified successfully within a third setting time period.

[0165] The request processing device proposed in the present disclosure receives token generation information sent by a client, wherein the token generation information includes at least one of the device information of the first device logged in by the first account, the first behavior information corresponding to the first account, and the network environment information of the first device. Based on the token generation information, a first token corresponding to the first account is generated, and the first token is sent to the client. The request corresponding to the first account sent by the client is received, and the second token corresponding to the first account is extracted from the request. Based on the first token, the second token is verified. Thus, considering at least one of the device information of the device logged in by the account, the behavior information corresponding to the account, and the network environment information of the device logged in by the account, a token corresponding to the account is generated to verify the request corresponding to the account. The tokens generated by the same account in different devices and / or different behavior modes and / or different network environments are different, and the token usage scenarios can be finely limited. Even if the token in a certain scenario is leaked, the token cannot be reused in other scenarios, which effectively prevents cross-scenario attacks after the token is leaked, can effectively defend against CSRF attacks, and helps to improve network security.

[0166] According to an embodiment of the present disclosure, the present disclosure also provides a request sending device, which is used to implement the above-mentioned request sending method.

[0167] Figure 6 is a block diagram of a request sending device according to an embodiment of the present disclosure.

[0168] like Figure 6 As shown, the request sending device 600 includes: a first sending module 601 , a receiving module 602 , an acquiring module 603 and a second sending module 604 .

[0169] A first sending module 601 is used to obtain token generation information and send the token generation information to a server, wherein the token generation information includes at least one of device information of a first device logged in by a first account, first behavior information corresponding to the first account, and network environment information of the first device;

[0170] A receiving module 602 is used to receive a first token corresponding to the first account sent by the server;

[0171] An acquisition module 603 is used to acquire a second token corresponding to the first account;

[0172] The second sending module 604 is used to generate a request corresponding to the first account based on the second token, and send the request to the server.

[0173] In one embodiment of the present disclosure, the second sending module 604 is further used to: obtain verification information, wherein the verification information includes at least one of device information of the second device logged in by the first account, second behavior information corresponding to the first account, and network environment information of the second device; and generate the request based on the first token and the verification information.

[0174] In one embodiment of the present disclosure, the first sending module 601 is further used to: receive a token update request sent by a server; reacquire the token generation information, and send the reacquired token generation information to the server.

[0175] The request sending device proposed in the present disclosure obtains token generation information and sends the token generation information to the server, wherein the token generation information includes at least one of the device information of the first device logged in by the first account, the first behavior information corresponding to the first account, and the network environment information of the first device, receives the first token corresponding to the first account sent by the server, obtains the second token corresponding to the first account, generates a request corresponding to the first account based on the second token, and sends the request to the server. Thus, at least one of the device information of the account login device, the behavior information corresponding to the account, and the network environment information of the account login device can be sent to the server as token generation information. The tokens generated by the same account in different devices and / or different behavior modes and / or different network environments are different, and the token usage scenarios can be precisely limited. Even if the token in a certain scenario is leaked, the token cannot be reused in other scenarios, which effectively prevents cross-scenario attacks after the token is leaked, can effectively defend against CSRF attacks, and helps to improve network security.

[0176] According to an embodiment of the present disclosure, the present disclosure also proposes an electronic device, a readable storage medium, and a computer program product.

[0177] Figure 7 A schematic block diagram of an example electronic device 700 that can be used to implement an embodiment of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present disclosure described and / or required herein.

[0178] like Figure 7 As shown, the device 700 includes a computing unit 701, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 702 or a computer program loaded from a storage unit 708 into a random access memory (RAM) 703. In the RAM 703, various programs and data required for the operation of the device 700 can also be stored. The computing unit 701, the ROM 702, and the RAM 703 are connected to each other via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0179] A number of components in the device 700 are connected to the I / O interface 705, including: an input unit 706, such as a keyboard, a mouse, etc.; an output unit 706, such as various types of displays, speakers, etc.; a storage unit 708, such as a disk, an optical disk, etc.; and a communication unit 709, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 709 allows the device 700 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

[0180] The computing unit 701 may be a variety of general and / or special processing components with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, digital signal processors (DSPs), and any appropriate processors, controllers, microcontrollers, etc. The computing unit 701 performs the various methods and processes described above, such as request processing methods and / or request sending methods. For example, in some embodiments, the request processing method and / or request sending method may be implemented as a computer software program, which is tangibly included in a machine-readable medium, such as a storage unit 708. In some embodiments, part or all of the computer program may be loaded and / or installed on the device 700 via the ROM 702 and / or the communication unit 709. When the computer program is loaded into the RAM 703 and executed by the computing unit 701, one or more steps of the request processing method and / or request sending method described above may be performed. Alternatively, in other embodiments, the computing unit 701 may be configured to execute the request processing method and / or the request sending method in any other appropriate manner (eg, by means of firmware).

[0181] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include: being implemented in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0182] The program code for implementing the method of the present disclosure may be written in any combination of one or more programming languages. These program codes may be presented to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device, so that the program code, when executed by the processor or controller, implements the functions / operations specified in the flow chart and / or block diagram. The program code may be executed entirely on the machine, partially on the machine, partially on the machine and partially on a remote machine as a stand-alone software package, or entirely on a remote machine or server.

[0183] In the context of the present disclosure, a machine-readable medium may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, device, or equipment. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0184] To propose interactions with a user account, the systems and techniques described herein may be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user account; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user account can propose input to the computer. Other types of devices may also be used to propose interactions with the user account; for example, feedback proposed to the user account may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user account may be received in any form (including acoustic input, voice input, or tactile input).

[0185] The systems and techniques described herein may be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user account computer with a graphical user account interface or a web browser through which a user account can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), and the Internet.

[0186] A computer system may include a client and a server. The client and the server are generally remote from each other and usually interact through a communication network. The relationship of client and server is generated by computer programs running on respective computers and having a client-server relationship with each other. The server may be a cloud server, a server of a distributed system, or a server combined with a blockchain.

[0187] According to an embodiment of the present disclosure, the present disclosure further provides a computer program product, including a computer program, wherein when the computer program is executed by a processor, the steps of the request processing method and / or the request sending method described in the above embodiments of the present disclosure are implemented.

[0188] It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps recorded in this disclosure can be executed in parallel, sequentially or in different orders, as long as the desired results of the technical solutions disclosed in this disclosure can be achieved, and this document does not limit this.

[0189] The above specific implementations do not constitute a limitation on the protection scope of the present disclosure. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present disclosure shall be included in the protection scope of the present disclosure.

Claims

1. A request processing method, characterized in that: include: Receive token generation information sent by the client, wherein the token generation information includes at least one of device information of a first device logged in by a first account, first behavior information corresponding to the first account, and network environment information of the first device; Based on the token generation information, generate a first token corresponding to the first account, and send the first token to the client; receiving a request corresponding to the first account sent by the client, and extracting a second token corresponding to the first account from the request; Based on the first token, the second token is verified.

2. The method according to claim 1, wherein: The verifying the second token based on the first token includes: In response to the first token being consistent with the second token, determining that the second token is authenticated; In response to the first token not being consistent with the second token, it is determined that the second token has failed verification.

3. The method according to claim 1, wherein: The method further comprises: Extracting verification information from the request, wherein the verification information includes at least one of device information of a second device logged in by the first account, second behavior information corresponding to the first account, and network environment information of the second device; The verification information is verified.

4. The method according to claim 3, wherein: The verifying the verification information includes: Acquire determination information, wherein the determination information includes at least one of device information of the first device, the first behavior information, and network environment information of the first device; The verification information is verified based on the determination information.

5. The method according to claim 4, wherein: The verifying the verification information based on the determination information includes: In response to the device information of the first device being consistent with the device information of the second device, determining that the device information of the second device passes verification; In response to the device information of the first device being inconsistent with the device information of the second device, it is determined that the device information of the second device has failed verification.

6. The method according to claim 4, wherein: The verifying the verification information based on the determination information includes: Acquire a first difference parameter between the first behavior information and the second behavior information; The second behavior information is verified based on the first difference parameter.

7. The method according to claim 4, wherein: The verifying the verification information based on the determination information includes: Acquire a second difference parameter between the network environment information of the first device and the network environment information of the second device; Based on the second difference parameter, the network environment information of the second device is verified.

8. The method according to claim 4, wherein: The determination information includes the first account number, and the verification information includes the second account number; The verifying the verification information based on the determination information includes: In response to the first account being consistent with the second account, determining that the second account has passed verification; In response to the first account being inconsistent with the second account, it is determined that the second account has failed verification.

9. The method according to any one of claims 3 to 8, wherein: The method further comprises: In response to the second token and / or at least one of the verification information failing to be verified, it is determined that the request has failed to be verified.

10. The method according to any one of claims 1 to 8, wherein: Updating the first token includes at least one of the following: In response to the first account logging into the client, updating the first token; Update the first token according to a set period; In response to the first account having a first setting behavior, updating the first token; In response to the request not being verified, the first token is updated.

11. The method according to claim 10, wherein: Updating the set period includes at least one of the following: In response to a change in at least one of the device information, behavior information, and network environment information corresponding to the first account, shortening the set period; In response to the first account having a second setting behavior, shortening the setting period; In response to at least one of the device information, behavior information, and network environment information corresponding to the first account not changing within a first set time period, extending the set period; In response to the first account not having the second set behavior within a second set time period, extending the set period; In response to multiple requests from the first account being successfully verified within a third set time period, the set period is extended.

12. A request sending method, characterized in that: include: Acquire token generation information, and send the token generation information to the server, wherein the token generation information includes at least one of device information of a first device logged in by a first account, first behavior information corresponding to the first account, and network environment information of the first device; Receiving a first token corresponding to the first account sent by the server; Obtain a second token corresponding to the first account; Generate a request corresponding to the first account based on the second token, and send the request to the server.

13. The method according to claim 12, wherein: The generating a request corresponding to the first account based on the second token includes: Acquire verification information, wherein the verification information includes at least one of device information of a second device logged in by the first account, second behavior information corresponding to the first account, and network environment information of the second device; The request is generated based on the first token and the verification information.

14. The method according to claim 12, wherein: The method further comprises: Receive token update request sent by the server; The token generation information is re-acquired, and the re-acquired token generation information is sent to the server.

15. A request processing device, characterized in that: include: A first receiving module, configured to receive token generation information sent by a client, wherein the token generation information includes at least one of device information of a first device logged in by a first account, first behavior information corresponding to the first account, and network environment information of the first device; A generating module, configured to generate a first token corresponding to the first account based on the token generation information, and send the first token to the client; A second receiving module is used to receive a request corresponding to the first account sent by the client, and extract a second token corresponding to the first account from the request; A verification module is used to verify the second token based on the first token.

16. The device according to claim 15, wherein: The verification module is further used for: In response to the first token being consistent with the second token, determining that the second token is authenticated; In response to the first token not being consistent with the second token, it is determined that the second token has failed verification.

17. The device according to claim 15, wherein: The verification module is further used for: Extracting verification information from the request, wherein the verification information includes at least one of device information of a second device logged in by the first account, second behavior information corresponding to the first account, and network environment information of the second device; The verification information is verified.

18. The device according to claim 17, wherein: The verification module is further used for: Acquire determination information, wherein the determination information includes at least one of device information of the first device, the first behavior information, and network environment information of the first device; The verification information is verified based on the determination information.

19. The device according to claim 18, wherein: The verification module is further used for: In response to the device information of the first device being consistent with the device information of the second device, determining that the device information of the second device passes verification; In response to the device information of the first device being inconsistent with the device information of the second device, it is determined that the device information of the second device has failed verification.

20. The device according to claim 18, wherein The verification module is further used for: Acquire a first difference parameter between the first behavior information and the second behavior information; The second behavior information is verified based on the first difference parameter.

21. The device according to claim 18, wherein The verification module is further used for: Acquire a second difference parameter between the network environment information of the first device and the network environment information of the second device; Based on the second difference parameter, the network environment information of the second device is verified.

22. The device according to claim 18, wherein The determination information includes the first account number, and the verification information includes the second account number; The verification module is further used for: In response to the first account being consistent with the second account, determining that the second account has passed verification; In response to the first account being inconsistent with the second account, it is determined that the second account has failed verification.

23. The device according to any one of claims 17 to 22, wherein: The verification module is further used for: In response to the second token and / or at least one of the verification information failing to be verified, it is determined that the request has failed to be verified.

24. The device according to any one of claims 15 to 22, wherein: The device further comprises: an updating module, configured to: In response to the first account logging into the client, updating the first token; Update the first token according to a set period; In response to the first account having a first setting behavior, updating the first token; In response to the request not being verified, the first token is updated.

25. The device according to claim 24, wherein: The update module is further used for: In response to a change in at least one of the device information, behavior information, and network environment information corresponding to the first account, shortening the set period; In response to the first account having a second setting behavior, shortening the setting period; In response to at least one of the device information, behavior information, and network environment information corresponding to the first account not changing within a first set time period, extending the set period; In response to the first account not having the second set behavior within a second set time period, extending the set period; In response to multiple requests from the first account being successfully verified within a third set time period, the set period is extended.

26. A request sending device, characterized in that: include: A first sending module, configured to obtain token generation information and send the token generation information to a server, wherein the token generation information includes at least one of device information of a first device logged in by a first account, first behavior information corresponding to the first account, and network environment information of the first device; A receiving module, used for receiving a first token corresponding to the first account sent by the server; An acquisition module, used to acquire a second token corresponding to the first account; The second sending module is used to generate a request corresponding to the first account based on the second token, and send the request to the server.

27. The device according to claim 26, wherein: The second sending module is further used for: Acquire verification information, wherein the verification information includes at least one of device information of a second device logged in by the first account, second behavior information corresponding to the first account, and network environment information of the second device; The request is generated based on the first token and the verification information.

28. The device according to claim 26, wherein The first sending module is further used for: Receive token update request sent by the server; The token generation information is re-acquired, and the re-acquired token generation information is sent to the server.

29. An electronic device, characterized in that: include: at least one processor; as well as a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1 to 14.

30. A non-transitory computer-readable storage medium storing computer instructions, characterized in that: The computer instructions are used to cause the computer to execute the method according to any one of claims 1-14.

31. A computer program product, characterized in that A computer program is included which, when executed by a processor, implements the method according to any one of claims 1 to 14.

Images