CN115277072B

CN115277072B - Account number opening method and device, storage medium and computer equipment

Info

Publication number: CN115277072B
Application number: CN202210695606.6A
Authority: CN
Inventors: 赵志胜
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2022-06-17
Filing date: 2022-06-17
Publication date: 2024-03-15
Anticipated expiration: 2042-06-17
Also published as: CN115277072A

Abstract

The specification discloses an account opening method, an account opening device, a storage medium and computer equipment, wherein the method comprises the following steps: the server receives an information verification request sent by the second client, verifies that the session token is effective according to the session token in the information verification request, first client information of the first client, first account information of the first client and second client information of the second client, returns a verification passing message to the second client, receives confirmation binding information sent by the second client, and then constructs a binding relation between the first client and the second client according to the second client information of the second client and the second account information of the second client in the confirmation binding information, and the first client information and the first account information, so that the first client obtains account data corresponding to the second account information of the second client based on the binding relation, and account opening efficiency is improved.

Description

Account number opening method and device, storage medium and computer equipment

Technical Field

The present disclosure relates to the field of computer technologies, and in particular, to a method and apparatus for opening an account, a storage medium, and a computer device.

Background

With the vigorous development of computer technology, various applications are presented, and each application has an independent account system, so that when a user uses different applications, the user can input different account passwords for the different applications. In order to reduce complicated account passwords, accounts among all applications are opened, wherein the account opening refers to user data of the same user, and the user data are communicated and shared among a plurality of applications, so that all applications can interact aiming at the same user.

Disclosure of Invention

The specification provides an account opening method, an account opening device, a storage medium and computer equipment, which can solve the technical problem of how to improve the account opening efficiency.

In a first aspect, the present disclosure provides an account opening method, which is applied to a server of an account opening system, where the account opening system further includes a first client, a second client, and a server, and the server is communicatively connected to the first client and the second client, and includes:

receiving an information verification request sent by the second client, wherein the information verification request comprises a session token, first client information of the first client, first account information of the first client and second client information of the second client;

Verifying that the session token is valid based on the first client information, the first account information and the second client information, and returning a verification passing message to the second client;

receiving confirmation binding information sent by the second client, wherein the confirmation binding information comprises second client information of the second client and second account information of the second client;

and constructing a binding relation between the first client and the second client based on the first client information, the first account information, the second client information and the second account information, so that the first client obtains account data corresponding to the second account information of the second client based on the binding relation.

In a second aspect, the present disclosure provides an account opening method, which is applied to a first client of an account opening system, where the account opening system further includes a first client, a second client, and a server, and the first client is communicatively connected with the server and the second client, and includes:

receiving a session token sent by the server, and generating an account opening message based on the session token, first client information of the first client and first account information of the first client;

Sending the account number opening message to the second client so that the second client can determine to construct a binding relationship with the first client based on the account number opening message;

if the server has the binding relation between the first client and the second client, sending an account data acquisition request to the second client based on the binding relation;

and receiving the account data sent by the second client.

In a third aspect, the present disclosure provides an account opening method, which is applied to a second client of an account opening system, where the account opening system further includes a first client, a second client, and a server, where the second client is communicatively connected to the server and the first client, and includes:

an account opening message sent by the first client is received, an information verification request is generated based on the account opening message, the account opening message comprises a session token, first client information of the first client and first account information of the first client, and the information verification request comprises the account opening message and second client information of the second client;

Sending the information verification request to the server so that the server verifies whether the session token is valid or not based on the first client information, the first account information and the second client information;

if a verification passing message sent by the server is received, acquiring second account information of the second client;

and generating confirmation binding information comprising the second client information and the second account information, and sending the confirmation binding information to the server so that the server builds a binding relationship between the first client and the second client, wherein the first client acquires account data corresponding to the second account information of the second client based on the binding relationship.

In a fourth aspect, the present specification provides a server comprising:

the verification request receiving module is used for receiving an information verification request sent by the second client, wherein the information verification request comprises a session token, first client information of the first client, first account information of the first client and second client information of the second client;

the token verification module is used for verifying that the session token is valid based on the first client information, the first account information and the second client information, and returning a verification passing message to the second client;

The confirmation information receiving module is used for receiving confirmation binding information sent by the second client, wherein the confirmation binding information comprises second client information of the second client and second account information of the second client;

and the binding relation construction module is used for constructing the binding relation between the first client and the second client based on the first client information, the first account information, the second client information and the second account information so that the first client can acquire account data corresponding to the second account information of the second client based on the binding relation.

In a fifth aspect, the present specification provides a first client, comprising:

the communication information generation module is used for receiving the session token sent by the server and generating account communication information based on the session token, the first client information of the first client and the first account information of the first client;

the opening information sending module is used for sending the account opening information to the second client so that the second client can determine to construct a binding relation with the first client based on the account opening information;

The account data request module is used for sending an account data acquisition request to the second client based on the binding relation if the binding relation between the first client and the second client exists in the server;

and the account data receiving module is used for receiving the account data sent by the second client.

In a sixth aspect, the present specification provides a second client, comprising:

the verification request generation module is used for receiving an account opening message sent by the first client and generating an information verification request based on the account opening message, wherein the account opening message comprises a session token, first client information of the first client and first account information of the first client, and the information verification request comprises the account opening message and second client information of the second client;

a verification request sending module, configured to send the information verification request to the server, so that the server verifies whether the session token is valid based on the first client information, the first account information, and the second client information;

the account information acquisition module is used for acquiring second account information of the second client if receiving the verification passing message sent by the server;

The confirmation information generation module is used for generating confirmation binding information comprising the second client information and the second account information, and sending the confirmation binding information to the server so that the server builds a binding relationship between the first client and the second client, and the first client obtains account data corresponding to the second account information of the second client based on the binding relationship.

In a seventh aspect, the present description provides a storage medium storing a computer program adapted to be loaded by a processor and to perform the steps of the above method.

In an eighth aspect, the present description provides a computer program product comprising instructions which, when run on a computer or processor, cause the computer or processor to perform the steps of the above method.

In a ninth aspect, one or more embodiments of the present description provide a computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the steps of the above method when the program is executed.

In one or more embodiments of the present disclosure, an account opening service is provided for a first client and a second client through a server, specifically, the server verifies an information verification request sent by the second client, so that after the second client receives a verification passing message, a binding determination message is sent to the server, and the server constructs a binding relationship between the first client and the second client based on the binding confirmation information sent by the second client, so that the first client obtains account data corresponding to second account information of the second client based on the binding relationship.

Drawings

In order to more clearly illustrate the technical solutions of the present specification or the prior art, the following description will briefly introduce the drawings that are required to be used in the embodiments or the prior art descriptions, it is obvious that the drawings in the following description are only some embodiments of the present specification, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

Fig. 1 is an interaction schematic diagram of an account opening method according to one or more embodiments of the present disclosure;

fig. 2 is a flowchart of an account opening method according to one or more embodiments of the present disclosure;

fig. 3 is a flowchart of an account opening method according to one or more embodiments of the present disclosure;

fig. 4 is a flowchart of an account opening method according to one or more embodiments of the present disclosure;

fig. 5 is a flowchart of an account opening method according to one or more embodiments of the present disclosure;

fig. 6 is a flowchart of an account opening method according to one or more embodiments of the present disclosure;

fig. 7 is a flowchart of an account opening method according to one or more embodiments of the present disclosure;

FIG. 8 is a schematic diagram of a server according to one or more embodiments of the present disclosure;

FIG. 9 is a schematic diagram of a server according to one or more embodiments of the present disclosure;

FIG. 10 is a schematic diagram of a first client according to one or more embodiments of the present disclosure;

FIG. 11 is a schematic diagram of a first client according to one or more embodiments of the present disclosure;

FIG. 12 is a schematic diagram of a second client according to one or more embodiments of the present disclosure;

FIG. 13 is a schematic diagram of a second client according to one or more embodiments of the present disclosure;

FIG. 14 is a schematic diagram of an electronic device provided in one or more embodiments of the present disclosure;

FIG. 15 is a schematic diagram of an operating system and user space provided by one or more embodiments of the present disclosure;

FIG. 16 is an architecture diagram of the android operating system of FIG. 14;

FIG. 17 is an architecture diagram of the IOS operating system of FIG. 14.

Detailed Description

So that the manner in which the features and advantages of one or more embodiments of the present disclosure can be understood more readily, a more particular description of the invention, briefly summarized above, may be had by reference to the embodiments thereof which are illustrated in the appended drawings, and in which some, but not all, embodiments of the invention are illustrated. All other embodiments, which are derived from one or more embodiments of the present specification without creative effort, by a person skilled in the art shall fall within the protection scope of one or more embodiments of the present specification.

When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with aspects of one or more embodiments of the present description as detailed in the accompanying claims. The flow diagrams depicted in the figures are exemplary only and are not necessarily to be taken in the order shown. For example, some steps are juxtaposed and there is no strict order of logic, so the actual order of execution is variable. In addition, the terms "first," "second," "third," "fourth," "fifth," "sixth," "seventh," "eighth" are used for distinguishing purposes only and should not be taken as a limitation of the present disclosure.

Because the service manufacturers to which the existing applications belong are different, and the designs of the network layer and the interface layer of the server used for providing the service by each service manufacturer are different, account opening flows among different applications are also different, namely when any two applications are opened, the link butt joint of the servers corresponding to the two applications needs to be realized, so that the existing account opening method has complex butt joint link process and higher cost. Meanwhile, account numbers in any two applications cannot be effectively bound and mapped due to different account number systems adopted by the existing applications.

In order to better improve the account opening efficiency, please refer to fig. 1, which is an interaction schematic diagram of an account opening method provided in one or more embodiments of the present disclosure.

As shown in fig. 1, the account opening system includes a first client 10, a server 20, and a second client 30, where the first client 10, the server 20, and the second client 30 may be various electronic devices, including but not limited to a smart phone, a tablet computer, a laptop portable computer, a desktop computer, etc., and further, the first client 10 and the second client 20 may be various application products.

The first client 10 obtains the second client information of the second client 30, and then generates an account opening request based on the first client information of the first client 10, the first account information of the first client 10 and the second client information of the second client 30, and then sends the account opening request to the server 20.

The server 20 generates a session token corresponding to the account opening request based on the first client information, the first account information and the second client information, and returns the session token to the first client 10.

The first client 10 generates an account opening message based on the session token, the first client information of the first client 10 and the first account information of the first client 10, and then sends the account opening message to the second client 30.

The second client 30 generates an information authentication request based on the account opening message and then transmits the information authentication request to the server 20.

The server 20 determines a pre-stored session token set in advance based on the first client information, the first account information and the second client information, if the pre-stored session token is consistent with the session token, it determines that the session token is valid, and then returns a verification passing message to the second client 30.

The second client 30 obtains third account information in the login state in the second client 30, and then generates an account binding prompt based on the third account information.

The second client 30 transmits binding rejection information to the server 20 in response to the binding rejection instruction.

The second client 30 may also respond to the binding confirmation instruction, use the third account information as the second account information of the second client 30, or respond to the binding replacement instruction, generate an account replacement interface, obtain fourth account information based on the account replacement interface, use the fourth account information as the second account information of the second client 30, then generate binding confirmation information including the second client information and the second account information, and send the binding confirmation information to the server 20.

The server 20 constructs a binding relationship between the first client 10 and the second client 20 based on the first client information, the first account information, the second client information and the second account information, then generates binding information based on the binding relationship between the first client 10 and the second client 20, and then sends the binding information to the first client 10.

The first client 10 generates an account data acquisition request carrying the binding information, and then sends the account data acquisition request to the second client 30.

The second client 30 generates an account determination request based on the binding information, and then transmits the account determination request to the server 20.

The server 20 verifies the binding information in the account number determination request, and if the binding information is invalid, an error prompt that the binding information is invalid is sent to the second client 30; and if the binding information is valid, acquiring second account information corresponding to the second client 30 based on the binding relation corresponding to the binding information, and then sending the second account information to the second client 30.

The second client 30 obtains the account data corresponding to the second account information, and then sends the account data corresponding to the second account information to the first client 10.

The first client 10 generates a session end notification and then sends the session end notification to the server 20.

The server 20 destroys the binding information.

The account number opening method provided in one or more embodiments of the present disclosure will be described in detail below with reference to fig. 2-7.

Referring to fig. 2, a flowchart of an account opening method is provided for one or more embodiments of the present disclosure. As shown in fig. 2, the method may include the following steps.

S102, receiving an information verification request sent by the second client, wherein the information verification request comprises a session token, first client information of the first client, first account information of the first client and second client information of the second client.

In one implementation, the information verification request includes a session token, first client information of a first client, first account information of the first client, and second client information of a second client, where the session token, the first client information of the first client, and the first account information of the first client are related information of the first client sent by the first client to the second client, so that the second client determines whether the first client is a trusted client based on the foregoing information, and it can be understood that the trusted client refers to a client authenticated by a server. A session token (token) is a token generated by a server for a first client and a second client, the session token being an encrypted string. The first client information includes, but is not limited to, a client identifier and a client name of the first client, and the first client information may also be any indication information for determining the first client. Likewise, the second client information includes, but is not limited to, a client identifier and a client name of the second client, and the second client information may also be any indication information for determining the second client. The first account information is related information of accounts which need to be communicated with other accounts in the first client, and the first account information comprises but is not limited to account identification and account name. It should be emphasized that the first client is a client that initiates the account opening request, and the second client is a client that receives the account opening request, where the first client and the second client may be different applications in different electronic devices or different applications in the same electronic device.

The server receives an information verification request sent by the second client, and then obtains a session token, first client information of the first client, first account information of the first client and second client information of the second client in the information verification request.

S104, based on the first client information, the first account information and the second client information, verifying that the session token is valid, and returning a verification passing message to the second client.

In one implementation, the session token (token) is temporary, and therefore, when the session token is valid, the information sent by the first client to the second client is valid information. The verification passing message indicates that the information carried by the information verification request is valid information.

The server acquires a pre-stored session token corresponding to the information based on the first client information, the first account information and the second client information, wherein the pre-stored session token is generated by the server aiming at the first client information, the first account information and the second client information and is in an effective state, then judges whether the session token in the information verification request is an effective session token or not based on the pre-stored session token, namely judges whether the session token is in an effective state, and generates a verification passing message when judging that the session token is effective, and returns the verification passing message to the second client.

When the server does not acquire the pre-stored session tokens corresponding to the first client information, the first account information and the second client information, judging that the session token in the information verification request is an invalid session token, generating a verification failure message, and then returning the verification failure message to the second client.

When the server determines that the session token in the information verification request is invalid based on the pre-stored session token, generating a verification failure message, and then returning the verification failure message to the second client, wherein the verification failure message is used for indicating that the information carried by the information verification request is invalid, and it can be understood that the second client can refuse to make account number opening with the first client based on the verification failure message.

S106, receiving confirmation binding information sent by the second client, wherein the confirmation binding information comprises second client information of the second client and second account information of the second client.

In one implementation, the confirmation binding information includes a session token, second client information of the second client, and second account information of the second client, and is configured to instruct the second client to confirm account opening with the first client. And the second account information is related information of the account which is opened by the first account corresponding to the first account information and is confirmed in the second client, and the second account information comprises but is not limited to account identification and account name.

And the server receives the confirmation binding information sent by the second client, and then acquires second client information and second account information of the second client in the confirmation binding information.

S108, based on the first client information, the first account information, the second client information and the second account information, a binding relation between the first client and the second client is constructed, so that the first client obtains account data corresponding to the second account information of the second client based on the binding relation.

In one implementation, the server obtains, based on the second client information of the second client, the first client information and the first account information corresponding to the session token in a storage medium of the server, and it is understood that the server may store the first client information, the first account information, the second client information, and the pre-stored session token in association with each other in the storage medium.

The server establishes a first mapping relation between the first client information and the second client information, and establishes a second mapping relation between the first account information and the second account information, wherein the first mapping relation and the second mapping relation jointly form a binding relation between the first client and the second client, and the first client can acquire account data corresponding to the second account information of the second client based on the binding relation.

Referring to fig. 3, a flowchart of an account opening method is provided for one or more embodiments of the present disclosure. As shown in fig. 3, the method may include the following steps.

S201, an account number opening request sent by the first client is received, and the account number opening request comprises first client information of the first client, first account number information of the first client and second client information of the second client.

In one implementation, the account opening request includes first client information of the first client, first account information of the first client, and second client information of the second client. The first client information includes, but is not limited to, a client identifier and a client name of the first client, and the first client information may also be any indication information for determining the first client. Likewise, the second client information includes, but is not limited to, a client identifier and a client name of the second client, and the second client information may also be any indication information for determining the second client. The first account information includes, but is not limited to, account identification, account name.

The method comprises the steps that a server receives an account opening request sent by a first client, and first client information of the first client, first account information of the first client and second client information of a second client are obtained in the account opening request.

In one implementation, the first client information is a registration identification generated by the server for the first client. Specifically, when the first client sends a client registration request to the server, the server generates first client information based on the client registration request, and then returns the first client information to the first client, where the client registration request carries relevant information of the first client, and the information includes, but is not limited to, a client identifier, a client attribute, a client version, and a client name of the first client, and the server generates a registration identifier of the first client based on the relevant information of the first client carried in the client registration request. Similarly, the server generates second client information of the second client based on the same registration process, and returns to the second client. Further, the server may further determine, based on information carried in the client registration request, whether the server supports an account opening request of the client, that is, whether an account opening service can be provided for the client, and execute the foregoing client registration procedure when determining that the account opening service can be provided for the client.

Optionally, when executing the client registration procedure, the server generates a communication key for the client, so that in a communication process between the client and the server, encrypted communication is performed based on the communication key.

It can be understood that in the current implementation manner, after receiving the account opening request, the server verifies whether the first client is a registered client based on the first client information in the account opening request, that is, whether the first client has the registered information (i.e., the first client information) in the server, and similarly, verifies whether the second client is a registered client based on the second client information in the account opening request, and when the first client and the second client are both registered clients, the subsequent account opening process is executed.

S203, based on the first client information, the first account information and the second client information, a session token corresponding to the account opening request is generated.

In one implementation, a session token (token) is a token generated by a server for a first client and a second client, the session token being an encrypted string.

The server generates a session token based on the first client information, the first account information and the second client information, and then stores the session token and the first client information, the first account information and the second client information in an associated mode.

In one implementation, after receiving an account number opening request, the server generates an encrypted character string according to a set token generation algorithm, then uses the encrypted character string as a session token corresponding to the first client information, the first account number information and the second client information, and then stores the session token and the first client information, the first account number information and the second client information in an associated manner.

S205, returning the session token to the first client so that the first client sends an account opening message carrying the session token to the second client, and the second client sends an information verification request to the server based on the account opening message.

In one implementation, the server returns the session token to the first client that sent the account opening request. It can be understood that after the first client receives the session token, it can be determined that the server supports the account opening service between the first client and the second client, and then an account opening message is sent to the second client based on the session token, so that the second client can enter an account opening process based on the account opening message, that is, send an information verification request to the server.

The server generates the session token corresponding to the first client and the second client, so that the second client can verify the first client based on the session token, and account opening operation with the first client is performed after the second client passes the verification, and account data is prevented from flowing into a malicious client, so that the security of an account opening flow is improved.

S207, receiving an information verification request sent by the second client, wherein the information verification request comprises a session token, first client information of the first client, first account information of the first client and second client information of the second client.

In particular, reference may be made to step S102, which is not described herein.

S209, determining a pre-stored session token which is preset based on the first client information, the first account information and the second client information.

In one implementation, the pre-stored session token is a session token generated by the server based on an account opening request sent by the first client, and the session token is stored in a storage medium of the server in association with the first client information, the first account information and the second client information. Alternatively, the session token, the first client information, the first account information, and the second client information may be stored as a set of data in a session token database of the server.

The server determines a pre-stored session token corresponding to the information in a storage medium based on the first client information, the first account information and the second client information, acquires the pre-stored session token in the storage medium, and compares the session token in the information verification request with the pre-stored session token. It can be understood that the first client information, the first account information, and the second client information are respectively consistent with the pre-stored first client information, the pre-stored first account information, and the pre-stored second client information corresponding to the pre-stored session token.

When the server does not acquire the pre-stored session tokens corresponding to the first client information, the first account information and the second client information, that is, the pre-stored session tokens associated with the first client information, the first account information and the second client information do not exist in a storage medium of the server, the session tokens in the information verification request are judged to be invalid session tokens, verification failure information is generated, and then the verification failure information is returned to the second client, wherein the verification failure information is used for indicating that the information carried by the information verification request is invalid information, and it can be understood that the second client can refuse to open the account with the first client based on the verification failure information.

S211, if the pre-stored session token is consistent with the session token, determining that the session token is valid, and returning a verification passing message to the second client.

The server determines that the session token is a valid session token when it is determined that the pre-stored session token is consistent with the session token in the information authentication request, then generates an authentication pass message for the session token, and returns the authentication pass message to the second client.

When the server judges that the pre-stored session token is inconsistent with the session token in the information verification request, the server determines that the session token is an invalid session token, then generates a verification failure message aiming at the session token, and returns the verification failure message to the second client, wherein the verification failure message is used for indicating that the information carried by the information verification request is invalid information, and it can be understood that the second client can refuse to make account number communication with the first client based on the verification failure message.

The method comprises the steps of obtaining a pre-stored session token corresponding to an information verification request, verifying whether the session token in the information verification request is valid or not based on the pre-stored session token, and returning a verification result of the session token to a second client, so that the second client determines the legitimacy of a first client sending an account opening message based on a judgment result of the session token, and the account opening operation is carried out only when the first client is a legal client, thereby avoiding the flow of account data to a malicious client and further improving the safety of an account opening process.

S213, receiving confirmation binding information sent by the second client, wherein the confirmation binding information comprises second client information of the second client and second account information of the second client.

See step S106, which is not described herein.

S215, based on the first client information, the first account information, the second client information and the second account information, a binding relation between the first client and the second client is constructed, so that the first client obtains account data corresponding to the second account information of the second client based on the binding relation.

See step S108, which is not described in detail herein.

S217, binding information is generated based on the binding relation between the first client and the second client.

In one implementation, the server generates binding information for the first client and the second client based on a first mapping relationship between the first client information and the second client information and a second mapping relationship between the first account information and the second account information, where the binding information (session) is an encrypted string used to indicate a binding relationship between the first client and the second client.

S219, sending the binding information to the first client, so that the first client sends an account data acquisition request to the second client based on the binding information.

In one implementation manner, the server sends binding information to the first client, so that the first client sends an account data acquisition request to the second client based on the binding information, and it can be understood that the account data acquisition request is used for requesting account data corresponding to the second account information, and the second account information is second account information in a binding relationship corresponding to the binding information.

Optionally, the server may further send binding information to the second client, so that the second client initiates the related communication of the account opening procedure to the first client based on the binding information.

S221, receiving an account number determining request sent by the second client, wherein the account number determining request comprises the binding information.

In one implementation, the account determination request includes binding information, the account determination request being used to determine whether an account data acquisition request sent by the first client is a legitimate request.

And the server receives an account number determining request sent by the second client, and then obtains binding information in the account number determining request.

S223, acquiring second account information corresponding to the second client based on the binding relation corresponding to the binding information.

In one implementation, the server determines the binding relationship corresponding to the binding information based on the binding information in the account determination request, and then obtains the second account information based on the second mapping relationship in the binding relationship, so that it can be understood that the second account information refers to the second account information corresponding to the second client of the first mapping relationship in the binding relationship.

Further, if the binding relation corresponding to the binding information does not exist, generating an error prompt that the binding information does not exist, and returning the error prompt that the binding information does not exist to the second client, so that the second client judges that the account data acquisition request sent by the first client is an illegal request based on the error prompt, and further refuses to send the account data corresponding to the second account information to the first client.

In one implementation manner, the obtaining the second account information corresponding to the second client based on the binding relationship corresponding to the binding information includes:

verifying binding information in the account number determination request;

if the binding information is valid, acquiring second account information corresponding to the second client based on a binding relationship corresponding to the binding information;

and if the binding information is invalid, sending an error prompt that the binding information is invalid to the second client.

The server determines, based on the account number, binding information in the request, and determines whether the binding information is in a valid state, and it can be understood that after the server generates binding information for the first client and the second client, the server sets an information state based on the binding information, where the information state includes a valid state and an invalid state. When the binding information is in a valid state, the binding information is valid, and the binding relation corresponding to the binding information is also valid; when the binding information is in an invalid state, the binding information is invalid, but the binding relationship corresponding to the binding information may be valid or invalid. It may be appreciated that the binding information is only used to indicate whether the first client may request account data from the second client based on the valid information, and does not indicate whether the binding relationship between the first client and the second client is persistent.

When the binding information is valid, the server determines a binding relationship corresponding to the binding information, then obtains second account information based on a second mapping relationship in the binding relationship, and understands that the second account information is second account information corresponding to a second client of the first mapping relationship in the binding relationship.

When the binding information is invalid, the server generates an error prompt that the binding information is invalid, and returns the error prompt that the binding information is invalid to the second client, so that the second client judges that the account data acquisition request sent by the first client is an illegal request based on the error prompt, and further refuses to send account data corresponding to the second account information to the first client.

And whether the binding information is valid or not is judged, and then based on a judging result of the binding information, the second account information or error information is returned to the second client, so that the second client confirms that the binding information is valid based on the fact that the second account information is received, and further the account opening operation is continued, and the account opening operation with the sending end (the first client) of the binding information can be refused based on the received error information, so that the account data is prevented from flowing into a malicious client, and the safety of the account opening flow is improved.

Optionally, in one implementation manner, if a binding relationship between the first client information and the second client information, and between the first account information and the second account information already exists in the server, the server may directly generate new binding information based on an account opening application sent by the first client, and then return the binding information to the first client, so that the first client directly sends an account data acquisition request to the second client based on the binding information, without repeatedly executing the foregoing account binding process. It should be emphasized that the binding information is in a valid state, and the account opening application carries the first client information, the first account information, the second client information and the second account information.

S225, the second account information is sent to the second client, so that the second client obtains account data corresponding to the second account information, and the account data is returned to the first client.

In one implementation, the server sends the second account information to the second client, so that the second client obtains account data corresponding to the second account information based on the received second account information, and then returns the obtained account data to the first client.

Because one or more accounts and account data generated by the accounts exist in the second client, whether the account data requested by the first client is the account data generated by the accounts confirmed through three-party binding cannot be determined only based on the binding information, and therefore the second client acquires and returns corresponding account data based on the received second account information by acquiring the second account information corresponding to the binding information and then sending the second account information to the second client, illegal outflow of the account data of the unbound account is avoided, the problem of information leakage of the unbound account is reduced, and the security of the open flow of the account is improved.

S227, receiving a session end notification sent by the first client, wherein the session end notification comprises the binding information.

In one implementation, the session end notification includes binding information.

The server receives a session ending notification sent by the first client, and then obtains binding information in the session ending notification. It should be emphasized that the session end notification is only used to end the current account opening procedure, and does not mean that the binding relationship generated based on the account opening procedure is also ended.

S229, destroying the binding information to invalidate the binding information.

In one implementation, the server determines pre-stored binding information and pre-stored binding relation corresponding to the binding information based on the binding information in the session end notification, deletes the pre-stored binding relation corresponding to the pre-stored binding relation, or sets the pre-stored binding information as invalid binding information, so that the pre-stored binding information corresponding to the binding information is invalid.

By destroying the binding information, the binding information is effective only in a limited time, the problem that account data is revealed due to the fact that the first client continuously acquires account data corresponding to the binding information through the binding information repeatedly under the condition that the first client is not allowed by the second client is avoided, and the safety of an account opening process is improved.

Referring to fig. 4, a flowchart of an account opening method is provided for one or more embodiments of the present disclosure. As shown in fig. 4, the method may include the following steps.

S302, receiving a session token sent by the server, and generating an account opening message based on the session token, the first client information of the first client and the first account information of the first client.

In one implementation, a session token (token) is a token generated by a server for a first client and a second client, the session token being an encrypted string. The first client information includes, but is not limited to, a client identifier and a client name of the first client, and the first client information may also be any indication information for determining the first client. The first account information is related information of accounts which need to be communicated with other accounts in the first client, and the first account information comprises but is not limited to account identification and account name. It should be emphasized that the first client is a client that initiates the account opening request, and the second client is a client that receives the account opening request, where the first client and the second client may be different applications in different electronic devices or different applications in the same electronic device. The account opening message comprises a session token, first client information and first account information, and it can be understood that the session token is used for confirming legal identity of the first client, the first client information is used for confirming a client main body to which the account belongs, and the first account information is used for confirming one account needing to be opened, namely one of a plurality of accounts which are opened mutually.

The first client receives the session token sent by the server, and then obtains first client information and first account information of the first client, and it can be understood that the first account information is account information of a first account which needs to be bound by an account among a plurality of accounts of the first client, and then opens a message based on the session token, the first client information and the account of the first account information.

S304, the account opening message is sent to the second client, so that the second client determines to construct a binding relation with the first client based on the account opening message.

In one implementation, the first client sends an account opening message to the second client, so that after the second client receives the account opening message, based on a session token, first client information and first account information carried in the account opening message, validity of the session token is verified, and further after the session token is judged to be valid, related information for constructing a binding relationship is sent to the server, so that construction of the binding relationship is realized.

S306, if the server has the binding relation between the first client and the second client, sending an account data acquisition request to the second client based on the binding relation.

In one implementation, the binding relationship of the first client and the second client includes: a first mapping relationship between the first client information and the second client information, and a second mapping relationship between the first account information and the second account information. Further, the account data acquisition request is used for requesting account data corresponding to the second account information.

When the first client determines that the binding relationship between the first client and the second client exists in the server, generating an account data acquisition request carrying the second account information based on the second account information corresponding to the binding relationship, sending the account data acquisition request to the second client, so that the second client acquires account data corresponding to the second account information based on the second account information carried in the account data acquisition request, and then returning the account data to the first client.

S308, receiving account data sent by the second client.

In one implementation, the first client receives the account data sent by the second client, and then stores the account data corresponding to the second account information as the account data associated with the first account information, so as to realize account intercommunication between the first account corresponding to the first account information and the second account corresponding to the second account information.

In one or more embodiments of the present disclosure, by acquiring a session token issued by a server, and then generating account opening information based on the session token, so that a second client may perform authentication on a first client based on the session token in the account opening information, and after the authentication is passed, the server constructs a binding relationship between the first client and the second client, and then the first client may acquire account data corresponding to second account information of the second client based on the binding relationship, it may be understood that the server provides a standardized account opening flow and a general flow for the first client and the second client, so that the first client does not need to consider an account system adopted by the second client, does not need to consider a link design of the second client, does not need to refer to the account opening flow corresponding to the second client design, and may perform opening with the second client, thereby improving opening efficiency.

Referring to fig. 5, a flowchart of an account opening method is provided for one or more embodiments of the present disclosure. As shown in fig. 5, the method may include the following steps.

S401, second client information of the second client is acquired.

In one implementation manner, the first client responds to an account number opening instruction to obtain second client information of the second client, and it can be understood that the account number opening instruction carries the second client information, the second client information is client information of a target client selected by a user, and the account number opening instruction is a control instruction triggered by the user.

S403, generating an account opening request based on the first client information of the first client, the first account information of the first client and the second client information of the second client.

In one implementation, the account opening request carries first client information of the first client, first account information of the first client, and second client information of the second client. The first client information includes, but is not limited to, a client identifier and a client name of the first client, and the first client information may also be any indication information for determining the first client. Likewise, the second client information includes, but is not limited to, a client identifier and a client name of the second client, and the second client information may also be any indication information for determining the second client. The first account information includes, but is not limited to, account identification, account name.

The method comprises the steps that a first client obtains first client information of the first client, a first account needing account binding is determined in a plurality of accounts of the first client, first account information of the first account is obtained, and then an account opening request is generated based on the first client information, the first account information and the second client information.

And S405, sending the account number opening request to the server so that the server generates a session token based on the account number opening request and returns the session token to the first client.

In one implementation, a session token (token) is a token generated by a server for a first client and a second client, the session token is an encrypted string, and the session token is a verification basis for authenticating the first client by the second client.

The first client sends an account number opening request to the server, so that the server generates session tokens for the first client and the second client based on relevant information in the account number opening request, encrypts the session tokens, and returns the encrypted session tokens to the first client.

Optionally, when executing the client registration procedure, the server generates a communication key for the client, so that in a communication process between the client and the server, encrypted communication is performed based on the communication key. It will be appreciated that the first client, when communicating with the server, needs to encrypt information based on the communication key. The first client encrypts the account opening request based on the communication key after generating the account opening request, and then sends the encrypted account opening request to the server.

By generating an account opening request and sending the account opening request to the server, session tokens generated by the server for the first client and the second client are obtained, so that the first client proves the legitimacy of the first client through the session tokens, the account data is prevented from flowing into a malicious client, and the security of an account opening process is improved.

S407, receiving a session token sent by the server, and generating an account opening message based on the session token, the first client information of the first client and the first account information of the first client.

See step S302, which is not described herein.

S409, sending the account number opening message to the second client, so that the second client determines to construct a binding relationship with the first client based on the account number opening message.

See step S304, which is not described herein.

S411, receiving the binding information sent by the server.

In one implementation, the binding information (session) is an encrypted string, and is used to indicate a binding relationship between the first client and the second client, where the binding relationship between the first client and the second client includes a first mapping relationship between the first client information and the second client information, and a second mapping relationship between the first account information and the second account information.

The first client receives the binding information sent by the server, and determines that a binding relationship exists between the first client and the second client in the server.

S413, generating an account data acquisition request carrying the binding information.

In one implementation, the account data acquisition request includes binding information, the account data acquisition request is used for requesting account data corresponding to second account information, and the second account information is second account information in a binding relationship corresponding to the binding information.

And the first client generates an account data acquisition request carrying the binding information based on the received binding information.

S415, the account data acquisition request is sent to the second client, so that the second client acquires account data corresponding to the account data acquisition request, and the account data is returned to the first client.

In one implementation, the first client sends an account data acquisition request to the second client, so that the second client determines a legal identity of the first client based on binding information in the account data acquisition request, determines second account information corresponding to the binding information, acquires account data corresponding to the second account information, and returns to the first client.

By acquiring the binding information corresponding to the binding relation between the first client and the second client, legal certificates aiming at the binding relation, namely the binding information, are obtained, and then corresponding account data are acquired based on the binding information, so that illegal outflow of the account data of the unbound account is avoided, the problem of information leakage of the unbound account is reduced, and the security of the account opening flow is improved.

S417, receiving account data sent by the second client.

See step S308, and will not be described in detail herein.

S419, generating a session ending notification, wherein the session ending notification comprises the binding information.

In one implementation, the session end notification includes binding information. It should be emphasized that the session end notification is only used to end the current account opening procedure, and does not mean that the binding relationship generated based on the account opening procedure is also ended.

After receiving the account data sent by the second client, the first client determines that the account intercommunication between the first account corresponding to the first account information and the second account corresponding to the second account information is achieved, and then generates a session ending notification based on the binding information.

And S421, sending the session end notification to the server.

In one implementation, the first client sends the session end notification to the server, so that the server destroys pre-stored binding information corresponding to the binding information based on the binding information in the session end notification, and invalidates the binding information.

Referring to fig. 6, a flowchart of an account opening method is provided for one or more embodiments of the present disclosure. As shown in fig. 6, the method may include the following steps.

S502, an account opening message sent by the first client is received, an information verification request is generated based on the account opening message, the account opening message comprises a session token, first client information of the first client and first account information of the first client, and the information verification request comprises the account opening message and second client information of the second client.

In one implementation, the account opening message includes a session token, first client information of the first client, and first account information of the first client, the session token (token) is a token generated by a server for the first client and the second client, and the session token is an encrypted string. The first client information includes, but is not limited to, a client identifier and a client name of the first client, and the first client information may also be any indication information for determining the first client. The first account information is related information of accounts which need to be communicated with other accounts in the first client, and the first account information comprises but is not limited to account identification and account name. It should be emphasized that the first client is a client that initiates the account opening request, and the second client is a client that receives the account opening request, where the first client and the second client may be different applications in different electronic devices or different applications in the same electronic device. It may be understood that the session token is used to confirm the legal identity of the first client, the first client information is used to determine the client principal to which the account belongs, and the first account information is used to determine one account number of the accounts that needs to be opened, i.e. one of the accounts that need to be opened.

The information verification request includes an account opening message and second client information of the second client. The information verification request is used to verify the legitimate identity of the first client. The second client information includes, but is not limited to, a client identifier and a client name of the second client, and the second client information may also be any indication information for determining the second client.

The second client receives an account opening request sent by the first client, acquires a session token, first client information and first account information in the account opening request, acquires second client information in the second client, and generates an information verification request based on the session token, the first client information, the first account information and the second client information.

S504, the information verification request is sent to the server, so that the server verifies whether the session token is valid or not based on the first client information, the first account information and the second client information.

The second client sends an information verification request to the server, so that the server determines a pre-stored session token corresponding to the first client information, the first account information and the second client information based on the first client information, verifies whether the session token is valid according to the pre-stored session token, and returns a verification result to the second client.

S506, if the verification passing message sent by the server is received, obtaining second account information of the second client.

In one implementation manner, if the second client receives the verification passing message sent by the server, the second client determines that the first client is a legal client, the account opening message sent by the first client is reliable, then a second account needing account opening is determined in a plurality of accounts of the second client, and then second account information of the second account is obtained.

S508, generating confirmation binding information comprising the second client information and the second account information, and sending the confirmation binding information to the server so that the server builds a binding relationship between the first client and the second client, wherein the first client obtains account data corresponding to the second account information of the second client based on the binding relationship.

In one implementation, the confirmation binding information includes a session token, second client information, and second account information, and is used to instruct the second client to confirm that account opening is performed with the first client. The binding relationship between the first client and the second client comprises a first mapping relationship between the first client information and the second client information, and a second mapping relationship between the first account information and the second account information.

The second client generates confirmation binding information based on the second client information, the second account information and the session token, and then sends the confirmation binding information to the server, so that the server obtains first client information and first account information corresponding to the session token based on the session token in the confirmation binding information, and builds a binding relationship between the first client and the second client based on the first client information, the first account information and the second client information and the second account information in the confirmation binding information, and further enables the first client to obtain account data corresponding to the second account information of the second client based on the binding relationship.

In one or more embodiments of the present disclosure, an information verification request is sent to a server to verify a legal identity of a first client through the server, so that when the first client is legal, confirmation binding information is generated, and a binding relationship between the first client and a second client is constructed through the server, so that the first client can obtain account data corresponding to second account information of the second client based on the binding relationship.

Referring to fig. 7, a flowchart of an account opening method is provided for one or more embodiments of the present disclosure. As shown in fig. 7, the method may include the following steps.

S601, receiving an account opening message sent by the first client, and generating an information verification request based on the account opening message, wherein the account opening message comprises a session token, first client information of the first client and first account information of the first client, and the information verification request comprises the account opening message and second client information of the second client.

Optionally, when executing the client registration procedure, the server generates a communication key for the client, so that in a communication process between the client and the server, encrypted communication is performed based on the communication key. It will be appreciated that the second client, when communicating with the server, needs to encrypt information based on the communication key. Illustratively, after generating the information authentication request, the second client encrypts the information authentication request based on the communication key, and then sends the encrypted information authentication request to the server.

S603, the information verification request is sent to the server, so that the server verifies whether the session token is valid or not based on the first client information, the first account information and the second client information.

See step S504, which is not described herein.

S605, if a verification passing message sent by the server is received, third account information in a login state in the second client is obtained.

In one implementation manner, if the second client receives the verification passing message sent by the server, the second client determines that the first client is a legal client, and the account number sent by the first client is trusted to open the message, then a third account number in a login state is determined in a plurality of account numbers of the second client, and then third account number information of the third account number is obtained.

S607, generating an account binding prompt based on the third account information.

In one implementation, the second client generates an account binding prompt based on the third account information, and then outputs the account binding prompt in an account binding interface, so that a user performs account binding selection based on an account binding boundary surface and triggers a corresponding account binding instruction, wherein the account binding instruction comprises but is not limited to a confirmation binding instruction, a replacement binding instruction and a rejection binding instruction.

S609, responding to the binding confirmation instruction, and taking the third account information as second account information of the second client.

In one implementation, the second client responds to a confirmation binding instruction triggered by the user based on the account binding boundary surface, and takes the third account information as second account information of the second client.

By generating the account binding prompt, the user selects a second account which is in account intercommunication with the first account of the first client based on the account binding prompt, so that the second account in account opening is ensured to confirm the bound account for the user, inconvenience caused by directly binding the current login account is avoided, and the accuracy of the account opening flow is improved.

S611, responding to the replacement binding instruction, and generating an account replacement interface.

In one implementation, the second client responds to a replacement binding instruction triggered by the user based on the account binding interface, and then generates an account replacement interface and outputs the account replacement interface. The account changing interface may be an input interface of account information, or may be a display interface of a plurality of accounts of the second client, which is not limited herein.

S613, fourth account information is obtained based on the account replacement interface.

In one implementation manner, the second client obtains the fourth account information of the bound account selected by the user based on the account replacement interface, and for example, the user may directly input the fourth account information based on the account replacement interface, or may select any account from a plurality of accounts displayed on the account replacement interface, and then obtain the fourth account information of the selected account.

S615, the fourth account information is used as second account information of a second client.

In one implementation, the second client uses the fourth account information as the second account information of the second client.

By generating the account changing interface, the user selects a second account which is in account intercommunication with the first account of the first client based on the account changing interface, so that the second account in account opening is ensured to be a bound account which is confirmed by the user, inconvenience caused by directly binding the current login account is avoided, and the accuracy of an account opening flow is improved.

S617, in response to the binding rejection instruction, sending binding rejection information to the server.

In one implementation, the second client generates binding rejection information in response to a binding rejection instruction triggered by the user based on the account binding boundary, then sends the binding rejection information to the server, and ends communication with the server, and simultaneously ends the account opening flow.

Optionally, the second client may also return binding rejection information to the first client to end communication with the first client, and end the account opening procedure.

By generating the binding rejection information, the unauthorized account data is prevented from being leaked out, and the security of the account data in the second client is improved.

S619, generating confirmation binding information comprising the second client information and the second account information, and sending the confirmation binding information to the server, so that the server builds a binding relationship between the first client and the second client, and the first client obtains account data corresponding to the second account information of the second client based on the binding relationship.

See step S508, which is not described herein.

S621, an account data acquisition request sent by the first client is received, wherein the account data acquisition request comprises binding information.

In one implementation, the account data acquisition request includes binding information, the account data acquisition request is used for requesting account data corresponding to second account information, and the second account information is second account information in a binding relationship corresponding to the binding information. The binding information (session) is an encrypted string, and is used for indicating a binding relationship between the first client and the second client, where the binding relationship between the first client and the second client includes a first mapping relationship between the first client information and the second client information, and a second mapping relationship between the first account information and the second account information.

The second client receives an account data acquisition request sent by the first client, and then acquires binding information in the account data acquisition request.

S623, an account determination request is generated based on the binding information, and the account determination request is sent to the server, so that after the server determines that the binding information is valid based on the account determination request, second account information corresponding to the second client is obtained based on a binding relationship corresponding to the binding information, and the second account information is sent to the second client.

In one implementation, the account determination request includes binding information, and the account determination request is used for determining that the binding information is valid and determining second account information corresponding to the binding information.

The second client generates an account number determining request based on the binding information, then sends the account number determining request to the server, so that the server judges whether the binding information is effective based on the binding information in the account number determining request, acquires second account number information corresponding to the binding information when the binding information is effective, and sends the second account number information to the second client.

It can be appreciated that the server may also generate an error prompt that the binding information is invalid when the binding information is invalid, and then send the error prompt that the binding information is invalid to the second client. Further, when the second client receives the false prompt that the binding information is invalid, generating reject account opening information rejecting to send account data, and sending the reject account opening information to the first client to end communication with the first client, and simultaneously ending the account opening process.

S625, receiving the second account information sent by the server.

In one implementation, the second client receives the second account information sent by the server.

S627, acquiring account data corresponding to the second account information, and sending the account data corresponding to the second account information to the first client.

In one implementation manner, the second client determines a second account corresponding to the second account information from a plurality of accounts of the second client based on the second account information, then obtains account data generated by the second account, and sends the obtained account data to the first client to achieve data synchronization between the first account corresponding to the first account information and the second account of the second account information, so that account opening purposes of the two accounts are achieved.

In one implementation manner, after the second client obtains the account data generated by the second account, the target account data meeting the set data screening rule can be obtained from the account data generated by the second account based on the set data screening rule, and then the target account data is returned to the first client as the account data corresponding to the second account information. The method and the device have the advantages that account opening between the first account and the second account is achieved, and resource waste caused by sending irrelevant data or redundant data to the first client is avoided.

The account number determining request carrying the binding information is generated and sent to the server, so that the binding information is verified through the server, the situation that the first client side still requests account number data from the second client side through the destroyed binding information is avoided, and the problem of account number data leakage is avoided; meanwhile, through determining the second account information corresponding to the binding information, corresponding account data is obtained according to the second account information corresponding to the binding information, illegal outflow of account data of the unbound account is avoided, the problem of information leakage of the unbound account is reduced, and the safety of the account opening process is improved.

The following provides a detailed description of related devices provided in connection with one or more embodiments of the present description in connection with fig. 8-13. It should be noted that, the apparatus related to fig. 8 to fig. 13 is used to perform the method of the embodiment shown in fig. 2 to fig. 7 according to one or more embodiments of the present disclosure, for convenience of description, only a portion related to the embodiment or embodiments of the present disclosure is shown, and specific technical details are not disclosed, and reference is made to the embodiment or embodiments shown in fig. 2 to fig. 7 according to the present disclosure.

Referring to fig. 8, a schematic structural diagram of a server is provided for one or more embodiments of the present disclosure. As shown in fig. 8, the server 1 of one or more embodiments of the present specification may include: the device comprises a verification request receiving module 11, a token verification module 12, a confirmation information receiving module 13 and a binding relation constructing module 14.

A verification request receiving module 11, configured to receive an information verification request sent by the second client, where the information verification request includes a session token, first client information of the first client, first account information of the first client, and second client information of the second client;

a token verification module 12, configured to verify that the session token is valid based on the first client information, the first account information, and the second client information, and return a verification passing message to the second client;

a confirmation information receiving module 13, configured to receive confirmation binding information sent by the second client, where the confirmation binding information includes second client information of the second client and second account information of the second client;

the binding relationship construction module 14 is configured to construct a binding relationship between the first client and the second client based on the first client information, the first account information, the second client information, and the second account information, so that the first client obtains account data corresponding to the second account information of the second client based on the binding relationship.

Optionally, referring to fig. 9, a schematic structural diagram of a server is provided for one or more embodiments of the present disclosure. As shown in fig. 9, the server 1 of one or more embodiments of the present specification may further include: a token acquisition module 15.

The token acquisition module 15 is specifically configured to:

receiving an account number opening request sent by the first client, wherein the account number opening request comprises first client information of the first client, first account number information of the first client and second client information of the second client;

generating a session token corresponding to the account opening request based on the first client information, the first account information and the second client information;

and returning the session token to the first client so that the first client sends an account opening message carrying the session token to the second client, and the second client sends an information verification request to the server based on the account opening message.

Optionally, the token verification module 12 is specifically configured to:

determining a pre-stored session token which is preset based on the first client information, the first account information and the second client information;

and if the pre-stored session token is consistent with the session token, determining that the session token is valid, and returning a verification passing message to the second client.

Optionally, as shown in fig. 9, the server 1 in one or more embodiments of the present specification may further include: an account data acquisition module 16.

The account data acquisition module 16 is specifically configured to:

generating binding information based on the binding relation between the first client and the second client;

sending the binding information to the first client so that the first client sends an account data acquisition request to the second client based on the binding information;

receiving an account number determining request sent by the second client, wherein the account number determining request comprises the binding information;

acquiring second account information corresponding to the second client based on the binding relation corresponding to the binding information;

and sending the second account information to the second client so that the second client obtains account data corresponding to the second account information and returns the account data to the first client.

Optionally, the account data obtaining module 16 is specifically configured to:

verifying binding information in the account number determination request;

Optionally, as shown in fig. 9, the server 1 in one or more embodiments of the present specification may further include: the information destruction module 17.

The information destruction module 17 is specifically configured to:

receiving a session end notification sent by the first client, wherein the session end notification comprises the binding information;

destroying the binding information to invalidate the binding information.

Referring to fig. 10, a schematic structural diagram of a first client is provided for one or more embodiments of the present disclosure. As shown in fig. 10, the first client 2 of one or more embodiments of the present specification may include: the system comprises a communication information generation module 21, a communication information transmission module 22, an account data request module 23 and an account data receiving module 24.

A break-through information generating module 21, configured to receive a session token sent by the server, and generate an account break-through message based on the session token, first client information of the first client, and first account information of the first client;

the opening information sending module 22 is configured to send the account opening message to the second client, so that the second client determines to construct a binding relationship with the first client based on the account opening message;

An account data request module 23, configured to send an account data acquisition request to the second client based on a binding relationship between the first client and the second client if the binding relationship exists in the server;

and the account data receiving module 24 is configured to receive account data sent by the second client.

Optionally, referring to fig. 11, a schematic structural diagram of a first client is provided for one or more embodiments of the present disclosure. As shown in fig. 11, the first client 2 of one or more embodiments of the present specification may further include: the token acquisition module 25.

The token acquisition module 25 is specifically configured to:

acquiring second client information of the second client;

generating an account number opening request based on first client information of the first client, first account number information of the first client and second client information of the second client;

and sending the account number opening request to the server so that the server generates a session token based on the account number opening request and returns the session token to the first client.

Optionally, the account data request module 23 is specifically configured to:

receiving binding information sent by the server;

generating an account data acquisition request carrying the binding information;

and sending the account data acquisition request to the second client so that the second client acquires the account data corresponding to the account data acquisition request, and returning the account data to the first client.

Optionally, as shown in fig. 11, the first client 2 in one or more embodiments of the present disclosure may further include: the information destruction module 26.

The information destruction module 26 is specifically configured to:

generating a session end notification, the session end notification including the binding information;

and sending the session end notification to the server.

Referring to fig. 12, a schematic structural diagram of a second client is provided for one or more embodiments of the present disclosure. As shown in fig. 12, the second client 3 of one or more embodiments of the present specification may include: the authentication request generation module 31, the authentication request transmission module 32, the account information acquisition module 33, and the confirmation information generation module 34.

A verification request generation module 31, configured to receive an account opening message sent by the first client, generate an information verification request based on the account opening message, where the account opening message includes a session token, first client information of the first client, and first account information of the first client, and the information verification request includes the account opening message and second client information of the second client;

a verification request sending module 32, configured to send the information verification request to the server, so that the server verifies whether the session token is valid based on the first client information, the first account information, and the second client information;

The account information obtaining module 33 is configured to obtain second account information of the second client if receiving a verification passing message sent by the server;

the confirmation information generating module 34 is configured to generate confirmation binding information including the second client information and the second account information, and send the confirmation binding information to the server, so that the server constructs a binding relationship between the first client and the second client, and the first client obtains account data corresponding to the second account information of the second client based on the binding relationship.

Optionally, the account information obtaining module 33 is specifically configured to:

acquiring third account information in a login state in the second client;

generating an account binding prompt based on the third account information;

and responding to the binding confirmation instruction, and taking the third account information as second account information of the second client.

Optionally, referring to fig. 13, a schematic structural diagram of the second client is provided for one or more embodiments of the present disclosure. As shown in fig. 13, the second client 3 of one or more embodiments of the present specification may further include: the account information acquisition module 35.

The account information obtaining module 35 is specifically configured to:

responding to a replacement binding instruction, and generating an account replacement interface;

acquiring fourth account information based on the account replacement interface;

and taking the fourth account information as second account information of a second client.

Optionally, as shown in fig. 13, the second client 3 in one or more embodiments of the present disclosure may further include: the binding module 36 is rejected.

The binding rejection module 36 is specifically configured to:

and sending binding rejection information to the server in response to the binding rejection instruction.

Optionally, as shown in fig. 13, the second client 3 in one or more embodiments of the present disclosure may further include: an account data transmission module 37.

The account data sending module 37 is specifically configured to:

receiving an account data acquisition request sent by the first client, wherein the account data acquisition request comprises binding information;

generating an account determination request based on the binding information, sending the account determination request to the server, so that after the server determines that the binding information is effective based on the account determination request, acquiring second account information corresponding to the second client based on a binding relationship corresponding to the binding information, and sending the second account information to the second client;

receiving second account information sent by the server;

and acquiring account data corresponding to the second account information, and sending the account data corresponding to the second account information to the first client.

One or more embodiments of the present disclosure further provide a storage medium, where the storage medium may store a plurality of program instructions, where the program instructions are adapted to be loaded by a processor and execute the method steps of the embodiments shown in fig. 2 to 7, and the specific execution process may refer to the specific description of the embodiments shown in fig. 2 to 7, which is not repeated herein.

One or more embodiments of the present disclosure further provide a computer program product, where the computer program product stores at least one instruction, where the at least one instruction is loaded by the processor and executed by the processor to perform the account number opening method as described in the embodiments shown in fig. 2 to fig. 7, and the specific execution process may refer to the specific description of the embodiments shown in fig. 2 to fig. 7, which is not repeated herein.

Referring to fig. 14, a block diagram of an electronic device according to one or more exemplary embodiments of the present disclosure is shown. The electronic device in one or more embodiments of the present description may include one or more of the following: processor 110, memory 120, input device 130, output device 140, and bus 150. The processor 110, the memory 120, the input device 130, and the output device 140 may be connected by a bus 150.

Processor 110 may include one or more processing cores. The processor 110 utilizes various interfaces and lines to connect various portions of the overall electronic device, perform various functions of the electronic device 100, and process data by executing or executing instructions, programs, code sets, or instruction sets stored in the memory 120, and invoking data stored in the memory 120. Alternatively, the processor 110 may be implemented in at least one hardware form of digital signal processing (digital signal processing, DSP), field-programmable gate array (field-programmable gate array, FPGA), programmable logic array (programmable logic Array, PLA). The processor 110 may integrate one or a combination of several of a processor (central processing unit, CPU), an image processor (graphics processing unit, GPU), and a modem, etc. The CPU mainly processes an operating system, a user interface, an application program and the like; the GPU is used for being responsible for rendering and drawing of display content; the modem is used to handle wireless communications. It will be appreciated that the modem may not be integrated into the processor 110 and may be implemented solely by a single communication chip.

The memory 120 may include a random access memory (random Access Memory, RAM) or a read-only memory (ROM). Optionally, the memory 120 includes a non-transitory computer readable medium (non-transitory computer-readable storage medium). Memory 120 may be used to store instructions, programs, code, sets of codes, or sets of instructions. The memory 120 may include a stored program area and a stored data area, wherein the stored program area may store instructions for implementing an operating system, which may be an Android (Android) system, including an Android system-based deep development system, an IOS system developed by apple corporation, including an IOS system-based deep development system, or other systems, instructions for implementing at least one function (such as a touch function, a sound playing function, an image playing function, etc.), instructions for implementing various method embodiments described below, and the like. The storage data area may also store data created by the electronic device in use, such as phonebooks, audiovisual data, chat log data, and the like.

Referring to FIG. 15, the memory 120 may be divided into an operating system space in which the operating system is running and a user space in which native and third party applications are running. In order to ensure that different third party application programs can achieve better operation effects, the operating system allocates corresponding system resources for the different third party application programs. However, the requirements of different application scenarios in the same third party application program on system resources are different, for example, under the local resource loading scenario, the third party application program has higher requirement on the disk reading speed; in the animation rendering scene, the third party application program has higher requirements on the GPU performance. The operating system and the third party application program are mutually independent, and the operating system often cannot timely sense the current application scene of the third party application program, so that the operating system cannot perform targeted system resource adaptation according to the specific application scene of the third party application program.

In order to enable the operating system to distinguish specific application scenes of the third-party application program, data communication between the third-party application program and the operating system needs to be communicated, so that the operating system can acquire current scene information of the third-party application program at any time, and targeted system resource adaptation is performed based on the current scene.

Taking an operating system as an Android system as an example, as shown in fig. 16, a program and data stored in the memory 120 may be stored in the memory 120 with a Linux kernel layer 320, a system runtime library layer 340, an application framework layer 360 and an application layer 380, where the Linux kernel layer 320, the system runtime library layer 340 and the application framework layer 360 belong to an operating system space, and the application layer 380 belongs to a user space. The Linux kernel layer 320 provides the underlying drivers for various hardware of the electronic device, such as display drivers, audio drivers, camera drivers, bluetooth drivers, wi-Fi drivers, power management, and the like. The system runtime layer 340 provides the main feature support for the Android system through some C/c++ libraries. For example, the SQLite library provides support for databases, the OpenGL/ES library provides support for 3D graphics, the Webkit library provides support for browser kernels, and the like. Also provided in the system runtime library layer 340 is a An Zhuoyun runtime library (Android run) which provides mainly some core libraries that can allow developers to write Android applications using the Java language. The application framework layer 360 provides various APIs that may be used in building applications, which developers can also build their own applications by using, for example, campaign management, window management, view management, notification management, content provider, package management, call management, resource management, location management. At least one application program is running in the application layer 380, and these application programs may be native application programs of the operating system, such as a contact program, a short message program, a clock program, a camera application, etc.; and may also be a third party application developed by a third party developer, such as a game-like application, instant messaging program, photo beautification program, wallpaper setting program, etc.

Taking an operating system as an IOS system as an example, the program and data stored in the memory 120 are as shown in fig. 17, the IOS system includes: core operating system layer 420 (Core OS layer), core service layer 440 (Core Services layer), media layer 460 (Media layer), and touchable layer 480 (Cocoa Touch Layer). The core operating system layer 420 includes an operating system kernel, drivers, and underlying program frameworks that provide more hardware-like functionality for use by the program frameworks at the core services layer 440. The core services layer 440 provides system services and/or program frameworks required by the application, such as a Foundation (Foundation) framework, an account framework, an advertisement framework, a data storage framework, a network connection framework, a geographic location framework, a sports framework, and the like. The media layer 460 provides an interface for applications related to audiovisual aspects, such as a graphics-image related interface, an audio technology related interface, a video technology related interface, an audio video transmission technology wireless play (AirPlay) interface, and so forth. The touchable layer 480 provides various commonly used interface-related frameworks for application development, with the touchable layer 480 being responsible for user touch interactions on the electronic device. Such as a local notification service, a remote push service, an advertisement framework, a game tool framework, a message User Interface (UI) framework, a User Interface UIKit framework, a map framework, and so forth.

Among the frameworks illustrated in fig. 17, frameworks related to most applications include, but are not limited to: the infrastructure in core services layer 440 and the UIKit framework in touchable layer 480. The infrastructure provides many basic object classes and data types, providing the most basic system services for all applications, independent of the UI. While the class provided by the UIKit framework is a basic UI class library for creating touch-based user interfaces, iOS applications can provide UIs based on the UIKit framework, so it provides the infrastructure for applications to build user interfaces, draw, process and user interaction events, respond to gestures, and so on.

The manner and principle of implementing data communication between the third party application program and the operating system in the IOS system may refer to the Android system, and one or more embodiments of the present disclosure are not described herein.

The input device 130 is configured to receive input instructions or data, and the input device 130 includes, but is not limited to, a keyboard, a mouse, a camera, a microphone, or a touch device. The output device 140 is used to output instructions or data, and the output device 140 includes, but is not limited to, a display device, a speaker, and the like. In one example, the input device 130 and the output device 140 may be combined, and the input device 130 and the output device 140 are a touch display screen for receiving a touch operation thereon or thereabout by a user using a finger, a touch pen, or any other suitable object, and displaying a user interface of each application program. Touch display screens are typically provided on the front panel of an electronic device. The touch display screen may be designed as a full screen, a curved screen, or a contoured screen. The touch display screen may also be designed as a combination of a full screen and a curved screen, a combination of a contoured screen and a curved screen, one or more embodiments of which are not limited in this disclosure.

In addition, those skilled in the art will appreciate that the configuration of the electronic device shown in the above-described figures does not constitute a limitation of the electronic device, and the electronic device may include more or less components than illustrated, or may combine certain components, or may have a different arrangement of components. For example, the electronic device further includes components such as a radio frequency circuit, an input unit, a sensor, an audio circuit, a Wi-Fi module, a power supply, and a bluetooth module, which are not described herein.

In one or more embodiments of the present specification, the execution subject of each step may be the electronic device described above. Optionally, the execution subject of each step is an operating system of the electronic device. The operating system may be an android system, an IOS system, or other operating systems, as one or more embodiments of the present disclosure are not limited in this regard.

The electronic device of one or more embodiments of the present specification may further have a display device mounted thereon, and the display device may be various devices capable of implementing a display function, for example: cathode ray tube displays (cathode ray tubedisplay, CR), light-emitting diode displays (light-emitting diode display, LED), electronic ink screens, liquid crystal displays (liquid crystal display, LCD), plasma display panels (plasma display panel, PDP), and the like. A user may utilize a display device on electronic device 101 to view displayed text, images, video, etc. The electronic device may be a smart phone, a tablet computer, a gaming device, an AR (Augmented Reality ) device, an automobile, a data storage device, an audio playing device, a video playing device, a notebook, a desktop computing device, a wearable device such as an electronic watch, electronic glasses, an electronic helmet, an electronic bracelet, an electronic necklace, an electronic article of clothing, etc.

In the electronic device shown in fig. 14, the processor 110 may be configured to call an account opening program stored in the memory 120 and specifically perform the following operations:

Optionally, before executing the receiving the information verification request sent by the second client, the processor 110 further executes the following operations:

Optionally, when executing the verification that the session token is valid based on the first client information, the first account information, and the second client information, the processor 110 specifically executes the following operations when returning a verification passing message to the second client:

Optionally, after executing the construction of the binding relationship between the first client and the second client based on the first client information, the first account information, the second client information, and the second account information, the processor 110 further executes the following operations:

Optionally, when the processor 110 obtains the second account information corresponding to the second client based on the binding relationship corresponding to the binding information, the following operations are specifically performed:

verifying binding information in the account number determination request;

Optionally, after performing the sending of the binding information to the first client and the second client, the processor 110 further performs the following operations:

destroying the binding information to invalidate the binding information.

Optionally, the processor 110 may be further configured to invoke an account opening program stored in the memory 120 and specifically perform the following operations:

and receiving the account data sent by the second client.

Optionally, before executing receiving the session token sent by the server, the processor 110 further executes the following operations:

acquiring second client information of the second client;

Optionally, when executing the binding relationship between the first client and the second client if the server exists, the processor 110 specifically executes the following operations when sending an account data acquisition request to the second client based on the binding relationship:

receiving binding information sent by the server;

Optionally, after executing the step of receiving the account data sent by the second client, the processor 110 further executes the following operations:

and sending the session end notification to the server.

receiving an account opening message sent by the first client, and generating an information verification request based on the account opening message, wherein the account opening message comprises first client information of the first client and first account information of the first client of a session token, and the information verification request comprises the account opening message and second client information of the second client;

Optionally, when executing the obtaining the second account information of the second client, the processor 110 specifically executes the following operations:

acquiring third account information in a login state in the second client;

generating an account binding prompt based on the third account information;

Optionally, after executing the generation of the account binding prompt based on the third account information, the processor 110 further executes the following operations:

Optionally, after executing the generation of the confirmation binding information including the second client information and the second account information, and sending the confirmation binding information to the server, the processor 110 further executes the following operations:

receiving second account information sent by the server;

It should be noted that, for simplicity of description, the foregoing method embodiments are all described as a series of acts, but one skilled in the art should appreciate that one or more embodiments of the present disclosure are not limited by the order of acts described, as some steps may occur in other orders or concurrently with other steps from that shown and described herein. Further, those skilled in the art will appreciate that the embodiments described in the specification are presently preferred, and that the acts and modules referred to are not necessarily all required in one or more embodiments of the specification.

In the foregoing embodiments, the descriptions of the embodiments are emphasized, and for parts of one embodiment that are not described in detail, reference may be made to the related descriptions of other embodiments.

The foregoing describes a method, server, first client, second client, storage medium, and computer device for account opening provided in one or more embodiments of the present disclosure, and is not to be construed as limiting the one or more embodiments of the present disclosure, as long as modifications are possible in terms of the one or more embodiments of the present disclosure.

Claims

1. An account opening method is applied to a server of an account opening system, the account opening system further comprises a first client, a second client and a server, the server is in communication connection with the first client and the second client, and the method comprises the following steps:

2. The method of claim 1, further comprising, prior to receiving the information verification request sent by the second client:

receiving an account opening request sent by the first client, wherein the account opening request comprises first client information of the first client, first account information of the first client and second client information of the second client;

3. The method of claim 1, the verifying that the session token is valid based on the first client information, the first account information, and the second client information, and returning a verification pass message to the second client, comprising:

4. The method of claim 1, wherein after the constructing the binding relationship between the first client and the second client based on the first client information, the first account information, the second client information, and the second account information, further comprises:

5. The method of claim 4, wherein the obtaining the second account information corresponding to the second client based on the binding relationship corresponding to the binding information includes:

verifying binding information in the account number determination request;

6. The method of claim 5, after the sending the binding information to the first client and the second client, further comprising:

destroying the binding information to invalidate the binding information.

7. An account opening method is applied to a first client of an account opening system, the account opening system further comprises a first client, a second client and a server, the first client is in communication connection with the server and the second client, and the method comprises the following steps:

acquiring second client information of the second client;

sending the account number opening request to the server so that the server generates a session token based on the account number opening request and returns the session token to the first client;

and receiving the account data sent by the second client.

8. The method according to claim 7, wherein if the server has a binding relationship between the first client and the second client, sending an account data acquisition request to the second client based on the binding relationship, includes:

Receiving binding information sent by the server;

9. The method of claim 8, further comprising, after the receiving the account data sent by the second client:

and sending the session end notification to the server.

10. An account opening method is applied to a second client of an account opening system, the account opening system further comprises a first client, a second client and a server, the second client is in communication connection with the server and the first client, and the method comprises the following steps:

11. The method of claim 10, the obtaining the second account information of the second client, comprising:

acquiring third account information in a login state in the second client;

generating an account binding prompt based on the third account information;

12. The method of claim 11, further comprising, after generating an account binding hint based on the third account information:

13. The method of claim 11, further comprising, after generating an account binding hint based on the third account information:

14. The method of claim 10, the generating acknowledgement binding information including the second client information and the second account information, and after transmitting the acknowledgement binding information to the server, further comprising:

Receiving second account information sent by the server;

15. A server, comprising:

the system comprises a verification request receiving module, a verification request receiving module and a verification module, wherein the verification request receiving module is used for receiving an information verification request sent by a second client, and the information verification request comprises a session token, first client information of a first client, first account information of the first client and second client information of the second client;

16. A first client, comprising:

the token acquisition module is used for acquiring second client information of a second client; generating an account opening request based on first client information of a first client, first account information of the first client and second client information of the second client; sending the account number opening request to a server so that the server generates a session token based on the account number opening request and returns the session token to the first client;

17. A second client, comprising:

the system comprises a verification request generation module, a verification request generation module and a verification module, wherein the verification request generation module is used for receiving an account opening message sent by a first client and generating an information verification request based on the account opening message, the account opening message comprises a session token, first client information of the first client and first account information of the first client, and the information verification request comprises the account opening message and second client information of the second client;

a verification request sending module, configured to send the information verification request to a server, so that the server verifies whether the session token is valid based on the first client information, the first account information, and the second client information;

18. A computer readable storage medium having instructions stored therein which, when executed on a computer or processor, cause the computer or processor to perform the account opening method of any of claims 1-17.

19. A computer device, comprising: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to perform the steps of the account opening method according to any one of claims 1-17.