CN112953965A

CN112953965A - Client login method and system, client, medium and computing device

Info

Publication number: CN112953965A
Application number: CN202110292779.9A
Authority: CN
Inventors: 李永刚; 贾斌; 蒋能学; 张丹; 严新宇; 高文豪; 袁志远
Original assignee: Hangzhou Netease Cloud Music Technology Co Ltd
Current assignee: Hangzhou Netease Cloud Music Technology Co Ltd
Priority date: 2021-03-18
Filing date: 2021-03-18
Publication date: 2021-06-11
Anticipated expiration: 2041-03-18
Also published as: CN112953965B

Abstract

The present disclosure provides a client login method and system, a client, a medium, and a computing device, wherein the method includes: under the condition that a target sub-client responds to a starting instruction of a main client to finish resource loading, the main client acquires an authorization code corresponding to the target sub-client; the target sub-client is one of N sub-clients associated with the main client, wherein N is an integer greater than or equal to 1; the target sub-client acquires user identity information according to the authorization code; the main client side sends the authorization code to the target sub-client side; under the condition that the target sub-client successfully logs in the first server based on the user identity information, the main client displays the login state of the target sub-client in a target display area; and the first server is a server associated with the target sub-client runtime.

Description

Client login method and system, client, medium and computing device

Technical Field

Embodiments of the present disclosure relate to the field of information processing, and more particularly, to a client login method and system, a client, a medium, and a computing device.

Background

This section is intended to provide a background or context to the embodiments of the disclosure recited in the claims. The description herein is not admitted to be prior art by inclusion in this section.

In the related art, one or more sub-clients may be associated with a main client used by a user, and any one of the one or more sub-clients can be called and run through the main client. Before a certain sub-client is called and operated through a main client, the sub-client is required to complete login. However, in the above process, the user needs to input the account and the corresponding password to complete the login each time the user logs in to one of the sub-clients of the main client, which causes a problem of low efficiency of login process.

Disclosure of Invention

The present disclosure is intended to provide a client login method and system, a client, a medium, and a computing device, so as to at least solve the above technical problems.

A first aspect of the embodiments of the present disclosure provides a client login method, where the method includes:

under the condition that a target sub-client responds to a starting instruction of a main client to finish resource loading, the main client acquires an authorization code corresponding to the target sub-client; the target sub-client is one of N sub-clients associated with the main client, wherein N is an integer greater than or equal to 1; the target sub-client acquires user identity information according to the authorization code;

the main client side sends the authorization code to the target sub-client side;

under the condition that the target sub-client successfully logs in the first server based on the user identity information, the main client displays the login state of the target sub-client in a target display area; and the first server is a server associated with the target sub-client runtime.

In an embodiment of the present disclosure, the obtaining, by the host client, an authorization code corresponding to the target sub-client includes:

the main client displays the authorization page of the target sub-client in a target display area;

and the main client responds to the operation of a target key in the authorization page of the target sub-client to acquire the authorization code corresponding to the target sub-client.

the main client side obtains an authorization code corresponding to the target sub-client side from a second server; and the second server is a server associated with the running of the main client.

A second aspect of the embodiments of the present disclosure provides a client login method, where the method includes:

under the condition that a target sub-client responds to a starting instruction of a main client to complete resource loading, the target sub-client acquires an authorization code sent by the main client; the target sub-client is one of N sub-clients associated with the main client, wherein N is an integer greater than or equal to 1;

the target sub-client generates request information based on the authorization code;

the target sub-client acquires user identity information from a second server based on the request information; the second server is a server associated with the running of the main client;

the target sub-client logs in the first server based on the user identity information, and when the login is successful, the main client is informed to display the login state of the target sub-client in a target display area; and the first server is a server associated with the target sub-client runtime.

In an embodiment of the present disclosure, the generating, by the target sub-client, request information based on the authorization code includes:

and the target sub-client encrypts the authorization code based on a preset key to obtain the request information.

In an embodiment of the disclosure, the encrypting, by the target sub-client, the authorization code based on a preset key to obtain the request information includes:

the target sub-client takes the current timestamp, the signature algorithm type, the identification of the target sub-client and the authorization code as initial request parameters;

the target sub-client splices the initial request parameters to obtain a character string;

the target sub-client processes the preset key and the character string to obtain a signature string;

and the target sub-client adds the signature string to the initial request parameter to obtain a target request parameter, and generates the request information based on the target request parameter.

In one embodiment of the present disclosure, the method further comprises:

under the condition that the second server fails to verify the authorization code in the request information, the target sub-client controls a target display area of the main client to display a login page; the login page comprises an input area of an account number and/or a password.

In one embodiment of the present disclosure, the method further comprises:

starting a first timer when the target sub-client finishes resource loading;

when the timing duration of the first timer reaches a first preset duration and an authorization code sent by the main client is not received, the target sub-client controls the target display area of the main client to display a login page; the login page comprises an input area of an account number and/or a password.

In one embodiment of the present disclosure, the target sub-client logging in the first server based on the user identity information includes:

and the target sub-client acquires account related information of the account which is successfully logged in from the first server based on the user identity information.

A third aspect of the embodiments of the present disclosure provides a host client, including:

the authorization code acquiring unit is used for acquiring an authorization code corresponding to a target sub-client under the condition that the target sub-client completes resource loading in response to a starting instruction; the target sub-client is one of N sub-clients associated with the main client, wherein N is an integer greater than or equal to 1; the target sub-client acquires user identity information according to the authorization code;

the first internal communication unit is used for sending the authorization code to the target sub-client;

the display unit is used for displaying the login state of the target sub-client in a target display area under the condition that the target sub-client successfully logs in the first server based on the user identity information; and the first server is a server associated with the target sub-client runtime.

In an embodiment of the present disclosure, the presentation unit is configured to present an authorization page of the target sub-client in a target presentation area;

the authorization code obtaining unit is configured to obtain an authorization code corresponding to the target sub-client in response to an operation on a target key in an authorization page of the target sub-client.

In an embodiment of the disclosure, the authorization code obtaining unit is configured to obtain an authorization code corresponding to the target sub-client from a second server; and the second server is a server associated with the running of the main client.

A fourth aspect of the embodiments of the present disclosure provides a target sub-client, including:

the second internal communication unit is used for acquiring an authorization code sent by a main client under the condition that resource loading is completed in response to a starting instruction of the main client; the target sub-client is one of N sub-clients associated with the main client, wherein N is an integer greater than or equal to 1;

a request generation unit configured to generate request information based on the authorization code;

an identity information obtaining unit, configured to obtain user identity information from the second server based on the request information; the second server is a server associated with the running of the main client;

the login unit is used for logging in the first server based on the user identity information and informing the main client to display the login state of the target sub-client in a target display area when the login is successful; and the first server is a server associated with the target sub-client runtime.

In an embodiment of the disclosure, the request generating unit is configured to encrypt the authorization code based on a preset key to obtain the request information.

In an embodiment of the present disclosure, the request generating unit is configured to use a current timestamp, a signature algorithm type, an identifier of the target sub-client, and the authorization code as initial request parameters; splicing the initial request parameters to obtain a character string; processing based on the preset key and the character string to obtain a signature string; and adding the signature string to the initial request parameter to obtain a target request parameter, and generating the request information based on the target request parameter.

In one embodiment of the present disclosure, further comprising:

the display control unit is used for controlling a login page to be displayed in a target display area of the main client under the condition that the second server fails to verify the authorization code in the request information; the login page comprises an input area of an account number and/or a password.

In one embodiment of the present disclosure, further comprising:

the display control unit is used for starting a first timer under the condition that the resource loading is completed; controlling the login page to be displayed in the target display area of the main client under the condition that the timing duration of the first timer reaches a first preset duration and an authorization code sent by the main client is not received; the login page comprises an input area of an account number and/or a password.

In an embodiment of the present disclosure, the login unit is configured to obtain account related information of a successfully logged-in account from the first server based on the user identity information.

A fifth aspect of the embodiments of the present disclosure provides a client login system, including: the system comprises terminal equipment, a first server and a second server; the terminal equipment comprises a main client and a target sub-client; the target sub-client is one of N sub-clients associated with the main client, and N is an integer greater than or equal to 1; wherein the content of the first and second substances,

the main client is used for acquiring an authorization code corresponding to the target sub-client under the condition that the target sub-client completes resource loading in response to a starting instruction of the main client; sending the authorization code to the target sub-client; displaying the login state of the target sub-client in a target display area;

the target sub-client is used for acquiring an authorization code sent by a main client under the condition that resource loading is completed in response to a starting instruction of the main client; generating request information based on the authorization code; acquiring user identity information from a second server based on the request information; logging in at the first server based on the user identity information; when the login is successful, the main client is informed to display the login state of the target sub-client in a target display area;

the first server is used for providing login state related information for the target sub-client;

and the second server is used for providing user identity information for the target sub-client.

In an embodiment of the present disclosure, the primary client is configured to obtain, from a second server, an authorization code corresponding to the target secondary client;

and the second server is used for generating an authorization code corresponding to the target sub-client.

In an embodiment of the disclosure, the second server is configured to perform encryption processing based on the identifier of the target sub-client, the authorization range, the current timestamp, and the global incremental digital to generate an authorization code corresponding to the target sub-client.

In an embodiment of the disclosure, the second server is further configured to set the authorization code corresponding to the target sub-client to be in a failure state when the storage duration of the authorization code corresponding to the target sub-client reaches the valid duration.

In an embodiment of the present disclosure, the second server is configured to receive request information sent by a target sub-client, and verify an authorization code included in the request information; and sending user identity information to the target sub-client under the condition of passing the verification.

In an embodiment of the present disclosure, the target sub-client is configured to obtain account related information of a successfully logged-in account from the first server based on the user identity information;

and the first server is used for sending account related information of the successfully logged-in account to the target sub-client based on the user identity information.

A sixth aspect of the embodiments of the present disclosure provides a medium storing a computer program, characterized in that the program, when executed by a processor, implements the method as in the previous embodiments.

A seventh aspect of embodiments of the present application provides a computing device, including:

one or more processors;

storage means for storing one or more programs;

the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the methods as in the previous embodiments.

According to the embodiment of the disclosure, the main client acquires the authorization code of the target sub-client associated with the main client, and sends the authorization code to the target sub-client, so that the target sub-client completes login on the first server after acquiring the user identity information based on the authorization code. Therefore, the operation that the user needs to input the account and the password when logging in the target sub-client every time is avoided by the mode of transmitting the authorization code across the clients, and the efficiency of login processing is improved. In addition, the authorization and login processing aiming at the target sub-client can be completed in the main client, so that the transmission of the authorization code of the target sub-client is protected by the container of the main client, the information leakage can be avoided, and the login processing safety of the target sub-client is ensured.

Drawings

The above and other objects, features and advantages of exemplary embodiments of the present disclosure will become readily apparent from the following detailed description read in conjunction with the accompanying drawings. Several embodiments of the present disclosure are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which:

fig. 1 schematically shows a flow chart of a client login method according to an embodiment of the present disclosure;

FIG. 2 is a schematic diagram illustrating a scenario in which a user selects a sub-client to trigger resource loading according to an embodiment of the present disclosure;

FIG. 3 schematically shows a schematic diagram of an authorization page according to an embodiment of the present disclosure;

FIG. 4 schematically illustrates a client login method flow diagram two according to an embodiment of the present disclosure;

FIG. 5 schematically shows a flow chart of a client login method according to an embodiment of the present disclosure;

FIG. 6 schematically illustrates a landing page schematic according to an embodiment of the present disclosure;

FIG. 7 is a schematic diagram illustrating a client login system component structure according to another embodiment of the present disclosure;

FIG. 8 schematically illustrates a fourth flowchart of a client login method according to yet another embodiment of the present disclosure;

FIG. 9 schematically shows a media schematic according to an embodiment of the present disclosure;

FIG. 10 schematically illustrates a schematic structural diagram of a host client according to an embodiment of the present disclosure;

FIG. 11 is a schematic diagram illustrating the structure of a target sub-client according to an embodiment of the present disclosure;

FIG. 12 schematically shows a computing device configuration diagram according to an embodiment of the disclosure.

In the drawings, the same or corresponding reference numerals indicate the same or corresponding parts.

Detailed Description

The principles and spirit of the present disclosure will be described with reference to a number of exemplary embodiments. It is understood that these embodiments are given solely for the purpose of enabling those skilled in the art to better understand and to practice the present disclosure, and are not intended to limit the scope of the present disclosure in any way. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

As will be appreciated by one skilled in the art, embodiments of the present disclosure may be embodied as a system, apparatus, device, method, or computer program product. Accordingly, the present disclosure may be embodied in the form of: entirely hardware, entirely software (including firmware, resident software, micro-code, etc.), or a combination of hardware and software.

According to the embodiment of the disclosure, a client login method, a client login system, a client, a medium and a computing device are provided.

In this document, any number of elements in the drawings is by way of example and not by way of limitation, and any nomenclature is used solely for differentiation and not by way of limitation.

The principles and spirit of the present disclosure are explained in detail below with reference to several representative embodiments of the present disclosure.

Summary of The Invention

The applicant finds that one or more sub-clients may be associated with a main client used by a user, and any one of the one or more sub-clients can be called and run through the main client. Before a certain sub-client is called and operated through a main client, the sub-client is required to complete login. However, each time a user logs in to a sub-client of the main client, the user needs to input an account and a password corresponding to the account to complete the login. It can be seen that in the prior art, the problem of low efficiency exists in the process of logging in a sub-client associated with a certain one of the main clients.

In view of this, the present disclosure provides a client login method and system, a client, a medium, and a computing device, wherein the method includes:

And the number of the first and second groups,

In this way, the main client acquires the authorization code of the target sub-client associated with the main client and sends the authorization code to the target sub-client, so that the target sub-client completes login on the first server after acquiring the user identity information based on the authorization code. Therefore, the operation that the user needs to input the account and the password when logging in the target sub-client every time is avoided by the mode of transmitting the authorization code across the clients, and the efficiency of login processing is improved. In addition, the authorization and login processing aiming at the target sub-client can be completed in the main client, so that the transmission of the authorization code of the target sub-client is protected by the container of the main client, the information leakage can be avoided, and the login processing safety of the target sub-client is ensured.

Having described the general principles of the present disclosure, various non-limiting embodiments of the present disclosure are described in detail below.

Exemplary method

A first aspect of the present disclosure provides a client login method, as shown in fig. 1, including:

s101: under the condition that a target sub-client responds to a starting instruction of a main client to finish resource loading, the main client acquires an authorization code corresponding to the target sub-client; the target sub-client is one of N sub-clients associated with the main client, wherein N is an integer greater than or equal to 1; the target sub-client acquires user identity information according to the authorization code;

s102: the main client side sends the authorization code to the target sub-client side;

s103: under the condition that the target sub-client successfully logs in the first server based on the user identity information, the main client displays the login state of the target sub-client in a target display area; and the first server is a server associated with the target sub-client runtime.

The scheme provided by the embodiment is executed by the main client. The host client may be a client installed in the terminal device. The main client may be associated with N sub-clients. Any one of the N sub-clients may specifically be an intermodal sub-client in the host client. The target sub-client may be any one of N sub-clients associated with the host client.

Before executing S101, the method may include: displaying icons corresponding to the N sub-clients in a display interface of the main client; and the main client responds to the click operation of the icon corresponding to the target sub-client in the N sub-clients, and the main client sends a starting instruction to the target sub-client.

Illustratively, referring to the left side of fig. 2, the presentation interface of the main client includes icons of 3 sub-clients, namely an icon of the sub-client-1, an icon of the sub-client-2, and an icon of the sub-client-3; when a user clicks an icon of a sub-client-1, the sub-client-1 is the target sub-client, and the main client sends a starting instruction to the sub-client-1 (namely the target sub-client).

The start instruction may be used to instruct the target sub-client to acquire a resource and load the resource.

After the host client sends a start instruction to the target sub-client, the target sub-client may obtain resources from the first server to start resource loading, and at this time, a loading page of the target sub-client may be displayed in a target display area of the host client.

The loading page can show the resource loading progress of the target sub-client; the load schedule may include at least: in resource loading, resource loading is completed, etc., which are not exhaustive here.

Illustratively, as shown in the right side of fig. 2, in the target display area of the host client, the load page of the target sub-client is displayed, and the load progress displayed in the load page is "resource loading".

The target display area of the host client may be within the display interface of the host client, wherein the size of the target display area is not larger than the display interface, and the borders (or boundaries) of the target display area are all located within the display interface, and in addition, the specific position of the target display area within the display interface may be set according to the actual situation. For example, still referring to the right side of fig. 2, the target presentation area 22 of the host client may be located within the presentation interface 21 of the host client.

After the host client sends a start instruction to the target sub-client, the method may further include:

the main client can judge whether the target sub-client completes resource loading, and under the condition that the target sub-client does not complete resource loading, the main client can continuously judge whether the target sub-client completes resource loading; and executing the step S101 when the target sub-client completes the resource loading, that is, when the target sub-client completes the resource loading in response to the start instruction of the host client, the host client obtains the authorization code corresponding to the target sub-client.

The manner in which the host client determines whether the target sub-client completes resource loading may be that the host client determines whether the target sub-client completes resource loading by determining whether a first indication sent by the target sub-client is received; for example, if the host client receives the first indication sent by the target sub-client, it is determined that the target sub-client completes resource loading.

The first indication may be a login instruction, and the login instruction may be an instruction for requesting login of the target sub-client; alternatively, the first indication may be an indication for characterizing that the target sub-client completes resource loading.

Before executing S101, the host client may further obtain relevant information of the target sub-client; the related information of the target sub-client may include an identifier of the target sub-client, for example, an ID of the target sub-client (i.e., APP ID of the target sub-client).

In S101, the obtaining, by the host client, the authorization code corresponding to the target sub-client may include the following two processing manners:

the first processing mode is as follows: and the main client side directly acquires the authorization code corresponding to the target sub-client side.

In this processing manner, the authorization code corresponding to the target sub-client may be directly obtained when the host client determines that the target sub-client completes resource loading without user operation. The processing mode can acquire the authorization code of the target sub-client more quickly, and can reduce the operation of a user, so that the whole processing is more convenient.

Still further, the obtaining, by the host client, an authorization code corresponding to the target sub-client may be: the main client side obtains an authorization code corresponding to the target sub-client side from a second server; and the second server is a server associated with the running of the main client.

Specifically, the obtaining, by the host client, the authorization code corresponding to the target sub-client from the second server may include: the main client sends an authorization code acquisition request to the second server; and the main client receives the authorization code corresponding to the target sub-client fed back by the second server.

Correspondingly, on the second server side, after receiving the authorization code acquisition request sent by the main client, the second server generates an authorization code corresponding to the target sub-client; and the second server sends the authorization code corresponding to the target sub-client to the main client.

Here, the authorization code acquisition request may include at least an identifier of the target sub-client. Correspondingly, the processing of the second server generating the authorization code corresponding to the target sub-client may include: and carrying out encryption processing based on the identification, the authorization range, the current timestamp and the global self-increment digital of the target sub-client to generate an authorization code corresponding to the target sub-client.

The authorization range may be an authorization range corresponding to the authorization code, for example, the authorization range may be user-related information of a user at the host client; the user-related information may include user identity information of the user at the host client, such as a user ID (or an account ID) of the user at the host client.

The current timestamp may be a time accurate to a nanosecond level, specifically, the time when the second server starts the authorization code generation process, or the time when the second server receives the authorization code acquisition request sent by the host client.

The global incremental numbers may be different each time the authorization code is generated, that is, the second server uses different global incremental numbers each time the authorization code is generated. In an example, when receiving an authorization code acquisition request corresponding to the target sub-client sent by a host client, the second server may add a preset value to an original global incremental number to obtain the current global incremental number. The preset value may be set according to actual conditions, and may be 1, for example.

Wherein the encryption processing may be processing performed using an SHA encryption algorithm.

In the specific processing, the following may be included: the second server splices the identification, the authorization range, the current timestamp and the global self-increment number of the target sub-client into a character string to be encrypted; encrypting the character string to be encrypted to obtain an authorization code corresponding to the target sub-client; and storing the authorization code, the corresponding authorization range and the user related information.

In one example, the implementation code that generates the authorization code may include:

@Resource(name＝”userRedisClient”)

private RedisClusterService redisClient；

private static final time 10 × 60; // effective duration 10 x 60 seconds;

private final string userPrefix ═ user: "; // the stored user prefix is "user: ";

private final string UNIQUE_KEY＝”user:unique:key:index”；

/**

the method comprises the following steps: createGrantCode < br >

Description of the drawings: authorization code generation procedure < br >

*@param clientIdStr

*@param scopestr

*@param user

*@return

*@throws Exception

*/

public String createGrantCode(String appIdStr,String scopeStr,User user)throws Exception{

Long incr ═ redisclient. incr (unity _ KEY); acquiring a global auto-increment number;

string str ═ appldstr + scope + string.value of (system. negative ()) + incr; assembling a string to be encrypted (clientId (identification of the target sub-client) + scope) + current timestamp);

string encrypted str ═ shaencode (str); generating an authorization code based on the character string to be encrypted;

setwithexpiretime (userprofix + encryptedStr + ": scope", scopeStr, time); storing the authorization range corresponding to the authorization code of the request;

setWithExpiretime (userPrefix + encrypted Str + ": user", JSO NObject. toJSONString (user), time); storing the user related information corresponding to the authorization code of the request;

return encrypted str; // returning an authorization code;

}

it should be further noted that the length of the authorization code may be a preset length, for example, 40 bits, and an exemplary authorization code may be "fec 1cdc7b5c5f0f4e32c36dc08a5b35bee83e8e 9".

The authorization code may be for a subsequent exchange of tokens (access _ tokens); the authorization code may have a valid duration, and may be set to a failure state when the duration of the storage of the authorization code at the second server side exceeds the valid duration. That is to say, the second server side may further store the authorization code when the authorization code is generated, and the second server side may detect a storage duration of the authorization code, and set the authorization code to a failure state by the second server when the storage duration of the authorization code reaches a valid duration. The effective time period may be set according to actual conditions, and may be, for example, 10 minutes, or 5 minutes, 15 minutes, or the like.

In addition, one authorization code is only used for exchanging the token once, and on the second server side, if it is determined that one authorization code is successfully exchanged for the corresponding token, the authorization code may also be set to be in a failure state.

The second treatment method comprises the following steps: the main client displays the authorization page of the target sub-client in a target display area; and the main client responds to the operation of a target key in the authorization page of the target sub-client to acquire the authorization code corresponding to the target sub-client.

The second processing mode is different from the first processing mode in that the second processing mode shows the authorization page of the target sub-client for the user, and the authorization code corresponding to the target sub-client is obtained when the main client detects that the user clicks the target key in the authorization page. According to the processing mode, the authorization code can be obtained only by simple clicking of the user, so that the information security of the target sub-client is guaranteed.

The operation on the target key in the authorization page of the target sub-client may specifically be a click operation, such as a touch click operation. The target key may be a virtual key displayed in the authorization page; in addition, corresponding text prompt information, such as 'authorized login', can be displayed in the target key. It should be further noted that the authorization page may also show related information of the target sub-client, such as an icon of the target sub-client and the like.

For example, referring to fig. 3, an icon of the target sub-client and a target key 31 may be included in the authorization page; corresponding text prompt information, such as "authorized login" as shown in fig. 3, or other text, which is not exhaustive, may be displayed in the target key 31.

In the second processing mode, the manner in which the primary client obtains the authorization code corresponding to the target secondary client is the same as the first processing mode, and a description thereof is not repeated.

In addition, the two processing methods can also be used in combination, specifically:

in an example, in the foregoing S101, when the target sub-client completes resource loading in response to the start instruction of the host client, the obtaining, by the host client, an authorization code corresponding to the target sub-client by the host client may include:

under the condition that the target sub-client responds to a starting instruction of the main client to complete resource loading, the main client inquires whether the target sub-client is an authorized sub-client from a database, and if so, the main client acquires an authorization code corresponding to the target sub-client;

otherwise, the main client displays the authorization page of the target sub-client in a target display area, the main client responds to the operation of a target key in the authorization page of the target sub-client, and the main client acquires the authorization code corresponding to the target sub-client.

That is, when the target sub-client completes resource loading in response to the start instruction of the host client, the host client determines whether the target sub-client is an authorized sub-client; under the condition that the target sub-client is an authorized sub-client, processing by adopting the first processing mode; and under the condition that the target sub-client is not an authorized sub-client, processing by adopting the second processing mode.

Here, the manner of the host client determining whether the target sub-client is an authorized sub-client may be: the main client side inquires whether the target sub-client side is an authorized sub-client side from a database; the database may be a mysql database.

The database may store an identifier of an authorized sub-client, for example, a certain sub-client is an authorized sub-client, the identifier of the sub-client may be stored in the database, and in addition, the identifier of the sub-client and an authorized mark may be stored in the database. That is, the host client may search, from the database, whether the identifier of the target sub-client and the authorized flag corresponding to the identifier are stored, if yes, the target sub-client may be determined to be an authorized sub-client, and otherwise, the target sub-client may be determined to be an unauthorized sub-client.

For another example, in the foregoing S101, when the target sub-client completes resource loading in response to the start instruction of the host client, the obtaining, by the host client, an authorization code corresponding to the target sub-client by the host client may include:

under the condition that a target sub-client responds to a starting instruction of a main client to complete resource loading, the main client inquires whether the target sub-client is an authorized sub-client within a second preset time length from a database, and if yes, the main client acquires an authorization code corresponding to the target sub-client;

and otherwise, the main client displays the authorization page of the target sub-client in a target display area, and the main client responds to the operation of a target key in the authorization page of the target sub-client and acquires the authorization code corresponding to the target sub-client from a second server.

That is to say, when the target sub-client completes resource loading in response to the start instruction of the host client, the host client determines whether the target sub-client is an authorized sub-client within a second preset duration; under the condition that the target sub-client is an authorized sub-client within a second preset time length, processing by adopting the first processing mode; and under the condition that the target sub-client is not the authorized sub-client within the second preset time length, processing by adopting the second processing mode.

The second preset time period may be set according to actual conditions, for example, may be within 3 days, or within 10 days, and the like.

Here, the manner of determining, by the host client, whether the target sub-client is an authorized sub-client within a second preset time period may be: the main client side inquires whether the target sub-client side is an authorized sub-client side within a second preset time length from a database; the database may be a mysql database.

The database may store an identifier of an authorized sub-client, an authorized flag, and a last authorization time.

The method specifically comprises the following steps: the main client can search whether the identification of the target sub-client and the corresponding authorized mark are stored in the database, and if not, the subsequent processing is carried out by adopting the second processing mode;

if the identifier of the target sub-client and the corresponding authorized mark are stored in the database, determining whether the target sub-client is a sub-client authorized within a second preset time length or not based on the last authorization time and the current time associated with the identifier of the target sub-client in the database, and if so, processing by adopting the first processing mode; otherwise, processing by adopting the second processing mode.

After the foregoing S101 is completed, the main client executes S102 to send the authorization code corresponding to the target sub-client.

Here, the host client and the target sub-client may communicate through a communication SDK (Software Development Kit).

The communication SDK can provide a communication function for the client and the terminal device and can be realized through a Websocket at the bottom layer. Correspondingly, the sending, by the primary client, the authorization code to the target secondary client may be: and the main client side sends the authorization code to the target sub-client side through a communication SDK.

Further, the communication SDK may include a first communication SDK of the host client and a second communication SDK of the target sub-client. Correspondingly, the sending, by the primary client, the authorization code to the target secondary client may be: and the main client side sends the authorization code to the second communication SDK through the first communication SDK, and the second communication SDK sends the authorization code to the target sub-client side.

When the target sub-client receives the authorization code, the corresponding user identity information may be acquired from the second server based on the authorization code, and then the user identity information is used to log in the first server.

In S103, when the target sub-client successfully logs in the first server based on the user identity information, the host client displays a login state of the target sub-client in a target display area.

The displaying, by the host client, the login state of the target sub-client in the target display area may specifically be: and the main client displays the account related information of the successfully logged account of the target sub-client in the target display area.

For example, in a case where the target sub-client is a game client, the account history related information may include: the game progress corresponding to the user account, and the role, the prop, the skin and other related information corresponding to the user account.

An embodiment of the first aspect described above is exemplarily described with reference to fig. 4, and may include:

s4011: clicking on the identification of a target sub-client in the host client;

the method specifically comprises the following steps: the main client responds to the click operation aiming at the identification of the target sub-client to generate a starting instruction; and the main client can also send the starting instruction to the target sub-client through a communication SDK.

S4012: the main client monitors the login instruction sent by the target sub-client; specifically, the host client may monitor the login instruction sent by the target sub-client through the communication SDK.

The main client can further judge whether the target sub-client is logged in, and if so, the relevant information of the target sub-client is obtained; otherwise, popping up a login page, and acquiring the account and the password input by the user.

After the relevant information of the target sub-client is obtained, S4013 is executed: the main client judges whether the target sub-client is an authorized sub-client, if not, S4014 is executed; if yes, go to S4016.

Here, the processing manner of the host client determining whether the target sub-client is an authorized sub-client is the same as that of the foregoing embodiment, and a repeated description is not given.

S4014: the main client displays the authorization page of the target sub-client in a target display area;

s4015: the main client detects the operation of a target key in an authorization page aiming at the target sub-client;

s4016: and the main client acquires the authorization code corresponding to the target sub-client.

S4017: the main client side sends the authorization code to the target sub-client side; specifically, the main client may send the authorization code to the target sub-client through a communication SDK.

S4018: and the main client displays the login state of the target sub-client in a target display area. The method may specifically be displaying account related information of the account that the target sub-client has logged in successfully.

Finally, it should be noted that the aforementioned main client may be a music client, and the target sub-client may be a game client; of course, the host client and the target sub-client may also be other types of clients, and as long as the target sub-client is any one of the plurality of sub-clients associated with the host client, the protection scope of the embodiment is included.

Therefore, by adopting the scheme, the main client acquires the authorization code of the associated target sub-client and sends the authorization code to the target sub-client, so that the target sub-client finishes logging in the first server after acquiring the user identity information based on the authorization code. Therefore, the operation that the user needs to input the account and the password when logging in the target sub-client every time is avoided by the mode of transmitting the authorization code across the clients, and the efficiency of login processing is improved. In addition, the authorization and login processing aiming at the target sub-client can be completed in the main client, so that the transmission of the authorization code of the target sub-client is protected by the container of the main client, the information leakage can be avoided, and the login processing safety of the target sub-client is ensured.

A second aspect of the present disclosure provides a client login method, as shown in fig. 5, including:

s501: under the condition that a target sub-client responds to a starting instruction of a main client to complete resource loading, the target sub-client acquires an authorization code sent by the main client; the target sub-client is one of N sub-clients associated with the main client, wherein N is an integer greater than or equal to 1;

s502: the target sub-client generates request information based on the authorization code;

s503: the target sub-client acquires user identity information from a second server based on the request information; the second server is a server associated with the running of the main client;

s504: the target sub-client logs in the first server based on the user identity information, and when the login is successful, the main client is informed to display the login state of the target sub-client in a target display area; and the first server is a server associated with the target sub-client runtime.

The scheme provided by the embodiment is executed by the target sub-client. The target sub-client may be any one of N sub-clients associated with a main client installed in the terminal device.

Before performing S501, the method may include: and the target sub-client responds to a starting instruction sent by the main client, and the target sub-client acquires resources from the first server and loads the resources. At this time, the loaded page of the target sub-client may be displayed in the target display area of the host client. The starting instruction may be used to instruct the target sub-client to acquire a resource and load the resource.

The resource loading progress of the target sub-client can be displayed in the loading page; the load schedule may include at least: in resource loading, resource loading is completed, etc., which are not exhaustive here. Illustratively, as shown in the right side of fig. 2, in the target display area of the host client, the load page of the target sub-client is displayed, and the load progress displayed in the load page is "resource loading".

Further, the target sub-client may also send a first indication to the host client when the resource loading is completed. The first indication may be a login instruction, and the login instruction may be an instruction for requesting login of the target sub-client; alternatively, the first indication may be an indication for characterizing that the target sub-client completes resource loading.

Correspondingly, the main client acquires the authorization code corresponding to the target sub-client and sends the authorization code to the target sub-client under the condition that the target sub-client is determined to respond to the starting instruction of the main client to complete resource loading. Here, the manner in which the main client obtains the authorization code corresponding to the target sub-client is the same as that in the foregoing embodiment, and a repeated description is not given.

It should be further noted that, when determining that the resource loading is completed, the target sub-client sends a first indication to the host client, which may further include: the target sub-client judges whether the terminal equipment is cloud equipment or not under the condition of finishing resource loading, and if so, sends a first instruction to the main client; otherwise, the process is ended.

The manner of determining whether the terminal device is a cloud device may be: acquiring configuration information stored by the terminal equipment; and detecting whether the configuration information contains preset content, if so, determining that the terminal equipment is cloud equipment, otherwise, determining that the terminal equipment is not the cloud equipment. For example, the configuration information may be information preset in a designated storage location of the terminal device according to actual conditions; the preset content may be a specified content included in a field in the configuration information for indicating the type of the terminal device, for example, the information corresponding to "type" in the configuration information may be yes, yes or "cloud device". The terminal device refers to a terminal device where the host client and the target sub-client are located, or a terminal device where the host client and the target sub-client are installed and operated.

The cloud device may be a terminal device capable of implementing a cloud service through a cloud server, for example, a smartphone deeply combined with a network service.

After the foregoing processing is completed, the target sub-client performs S501, that is, the target sub-client obtains the authorization code sent by the host client when the target sub-client completes resource loading in response to the start instruction of the host client.

Specifically, in the processing of S501, the following two modes may be included:

in the first mode, under the condition that the target sub-client responds to the starting instruction of the main client to complete resource loading, the authorization code sent by the main client is directly obtained.

In this way, the target sub-client may not inform the host client of displaying any page, but only monitor the authorization code sent by the host client; correspondingly, the main client only needs to determine that the target sub-client completes resource loading in response to the start instruction of the main client, and can directly obtain the authorization code corresponding to the target sub-client from the corresponding second server and send the authorization code to the target sub-client.

The second way,

Under the condition that a target sub-client finishes resource loading in response to a starting instruction of a main client, the target sub-client informs the main client to display an authorization page of the target sub-client in a target display area; correspondingly, the main client responds to the operation of a target key in the authorization page of the target sub-client, acquires the authorization code corresponding to the target sub-client and sends the authorization code to the target sub-client;

and the target sub-client receives the authorization code sent by the main client.

Here, the host client and the target sub-client may communicate through a communication SDK. Illustratively, the target sub-client receives the authorization code sent by the host client through a communication SDK.

Further, the primary client may correspond to the first communication SDK, and the target sub-client may correspond to the second communication SDK. Correspondingly, the obtaining, by the target sub-client, the authorization code sent by the host client may be: the main client side sends the authorization code to the first communication SDK; then the first communication SDK sends the authorization code to the second communication SDK; and the target sub-client receives the authorization code through the second communication SDK.

The method may further comprise: starting a first timer when the target sub-client finishes resource loading; when the timing duration of the first timer reaches a first preset duration and an authorization code sent by the main client is not received, the target sub-client controls the target display area of the main client to display a login page; the login page comprises an input area of an account number and/or a password.

When the target sub-client completes resource loading, starting a first timer, which may be: the target sub-client can directly start the first timer under the condition of finishing resource loading; or, the target sub-client sends the first indication to the host client and starts the first timer when completing resource loading.

When the target sub-client completes resource loading, after starting the first timer, the method may include:

the target sub-client starts to monitor whether an authorization code sent by the main client is received;

if the timing duration of the first timer does not reach the first preset duration and the authorization code sent by the host client is received, executing S502;

if the timing duration of the first timer reaches the first preset duration and the authorization code sent by the main client is not received, the target sub-client controls the target display area of the main client to display a login page; the login page comprises an input area of an account number and/or a password.

Here, whether the target sub-client monitors to receive the authorization code sent by the main client may be: and the target sub-client monitors whether the authorization code sent by the main client is received or not in a polling mode. For example, whether the authorization code sent by the primary client is received may be monitored in a polling manner based on a preset period. Wherein the preset period may be 1 second, 30 milliseconds, and the like.

The first preset time period may be set according to practical situations, for example, may be 1 minute, or may be 1.5 minutes, or may be longer or shorter, which is not exhaustive herein.

The reason why the timing duration of the first timer reaches the first preset duration and the authorization code sent by the main client is not received by the target sub-client may include that the main client may not obtain the authorization code within the first preset duration. This is because the authorization code is stored in the second server associated with the main client when the main client operates, and when the second server receives the authorization code acquisition request sent by the main client, if the authorization code is in an invalid state (for example, the storage duration of the authorization code exceeds the valid duration and is set to the invalid state), the second server does not feed back the authorization code to the main client, and accordingly, the main client does not send the authorization code to the target sub-client.

The size and position of the login page can be set according to actual conditions, and the login page only needs to be located in the target display area.

The login page at least needs to include an input area of an account number and/or a password, and in addition, the login page can also include related information such as an icon or a name of the target sub-client. The login page is illustrated with reference to fig. 6, and the login page includes an account number input area 61 and a password input area 62.

In one example, the login page only includes an input area of an account, and the user can only input the account; the target sub-client may send the account to the first server and the second server, so that the account is bound with the identifier of the main client and the identifier of the target sub-client at the first server and the second server, thereby completing login.

In another example, the login page may only include an input area of a password, and at this time, an account of the user may already be displayed, and in this example, only the user needs to input the password corresponding to the account; the target sub-client can send the account and the password to the first server and the second server so as to bind the account and the password with the identifier of the main client and the identifier of the target sub-client on the first server and the second server side, and therefore login is completed.

In another example, the login page may include an input area of a password and an input area of an account, and at this time, the user may input the account and the password in the two input areas respectively; the target sub-client can send the account and the password to the first server and the second server so as to bind the account and the password with the identifier of the main client and the identifier of the target sub-client on the first server and the second server side, and therefore login is completed.

In S502, the target sub-client generates request information based on the authorization code, including: and the target sub-client encrypts the authorization code based on a preset key to obtain the request information.

The preset key may be a key preset according to an actual situation.

Specifically, the encrypting, by the target sub-client, the authorization code based on the preset key to obtain the request information may include:

Here, the current time stamp, that is, the current time, may be a time in the order of milliseconds. The current timestamp may specifically be a time when the authorization code is received, or may be a time when processing is performed based on the authorization code to generate the request information.

The type of signature algorithm may be determined according to actual conditions, for example, the signature algorithm may be an RSA algorithm.

The RSA algorithm is an asymmetric encryption algorithm, decryption can be completed under the condition that a secret key is not directly transmitted, safety of information can be guaranteed, and the risk of being cracked caused by directly transmitting the secret key is avoided. The RSA algorithm is a process of encryption and decryption by a pair of keys, which are called a public key and a private key, respectively, and the principle of the RSA algorithm is to ensure security by the difficulty of factorization of a very large integer. In the RSA algorithm, it is specified that the private key is kept for an individual and the public key is public (possibly held by multiple people at the same time). In the following embodiments, the private key is referred to as a preset key for explanation.

For example, the target sub-client may encrypt the authorization code based on a preset key to obtain the request information by using the following codes:

private static String appKey ═ gate _ appKey; v/request message tagging

public static String signRequest()throws Expectation{

/**

1. Assemble request parameters

*/

Map<String,string>params＝new HashMap<String,string>()；

JSONObject josnObject＝new JSONObject()；

put ("timing", string. value of (system. currenttimeMillis ())); // UNIX Current timestamp, millisecond;

put ("signType", "RSA _ SHA 256"); // the type of signature algorithm used, in this example RSA _ SHA 256;

put ("appId", "afferent appId"); // application ID assigned to the developer by the host client (identification of target sub-client);

put ("grantCode", "uea 9b569bb6180 o"); // authorization code;

put ("bizContent", jsonobject. tostring ()); // set of request parameters (i.e., initial request parameters)

/**

Request message is spliced into character string format (namely character string)

*/

string signCheckContent＝getSignCheckContent(params)；

/**

3 the request message is signed by a private key (namely a signature string)

*/

Sting sign＝rsa256Sign(signCheckContent,appkey,“UTF-8”)；

params.put(“sign”,sign)；

/**

4. request data is assembled into http protocol message format (i.e. request information is generated)

*/

Sting urlParams＝asUrlParams(params)；

/**

5 execution of http post request

*/

return httpPost(http://openapi.qa-bear.igame.163.com/openapi/music/basic/user/info/get/v2,urlp)

}

The target sub-client splices the initial request parameters to obtain a character string, and may include: preprocessing the initial request parameter to obtain a preprocessed initial request parameter; sequencing the initial request parameters after the preprocessing; and splicing the sequenced initial request parameters to obtain the character string.

The preprocessing may include removing parameters that do not meet the preset requirement from the initial request parameters, for example, if the initial request parameters include a "sign" parameter, the subsequent tagging processing may be affected, where the "sign" parameter is a parameter that does not meet the preset requirement, and in the preprocessing, the parameter that does not meet the preset requirement is deleted.

The sorting of the initial request parameters after the preprocessing may be performed according to a preset order. For example, the predetermined sequence may include the following parameters in sequence: and sequencing the initial request parameters after preprocessing according to the sequence of the current timestamp, the signature algorithm type, the identification of the target sub-client and the authorization code.

For example, the target sub-client splicing the initial request parameters to obtain the character string may be implemented by using the following codes:

the target sub-client performs processing based on the preset key and the character string to obtain a signature string, which may include: and processing the preset key and the character string based on the specified encoding type to obtain the signature string.

By way of example, the following code may be used:

v/RSA encryption algorithm

// content request parameter (authorization code)

// appkey client signing key (Preset key)

// charset data encoding format

public static string rsa256Sign(String content,String appkey,String charset)throws RuntimeExpection{

try{

Privatekey privey key getfropkcs 8 ("RSA", new bytearrayiinputstream ()); v/encapsulate the private key into java.security.privatekey, specifying the RSA private key type;

signature. initsign (private); v/initialize the signature to private key relationship;

if(StringUtils.isEmpty(charset)){

signature.update(content.getBytes())；

}else{

signature.update(content.getBytes(charset))；

}// specifies the coding type;

byte[]signed＝signature.sign()；

return base64.encodeBase64String (signed); // return signature string;

}catch(Exception e){

throw new RuntimeException(“RSA content＝”+content”；charset＝”charset,e)；

}

the aforementioned adding the signature string to the initial request parameter to obtain the target request parameter may be implemented by using the following codes: "params. put (" sign "), i.e., adding the signature string in the target request argument; wherein, the 'params' is the finally obtained target request parameter; "put ()" indicates processing of addition; "sign" denotes the signature string.

The generating the request information based on the target request parameter may include: and generating the request information based on the target request parameter and the network address information. The network address information may be network address information for acquiring user identity information from the second server.

The request information may be a POST request of HTTP (HyperText Transfer Protocol).

With respect to generating the request information, the following code may be used:

after obtaining the request information, S503 is executed, that is, the target sub-client executes the request information to obtain the user identity information from the second server.

The processing of executing the request information and acquiring the user identity information fed back by the second server may be implemented by using the following codes:

it should be noted that the above is only one implementation code for executing the request information, and other codes may be used in actual processing, and as long as the user identity information that can be obtained by the second server is within the protection scope of this embodiment, the implementation code is not exhaustive.

Correspondingly, the second server may verify the signature of the signature string in the target request parameter included in the request information and verify the authorization code therein, in the case that the request information is received.

The method can also comprise the following steps: and under the condition that the second server fails to verify the authorization code in the request information, the target sub-client controls the target display area of the main client to display a login page.

Here, the failure of the second server to verify the authorization code in the request information may be due to: and when the authorization code stored in the second server is in a failure state, failing to verify the authorization code in the request information. In addition, the reason why the authentication of the authorization code in the request information by the second server fails may further include: the authorization code of the second server is tampered, or the authorization code in the request information is tampered in the transmission process of the request information. Aiming at the two conditions, the authorization cannot be successful, so that the security of one-key authorization is further ensured.

The reason why the authorization code is in the failure state may be: and the storage time of the authorization code in the second server reaches the effective time.

That is, if the time when the target sub-client sends the request information to the second server is the time when the second server is set to the failure state, the authorization code may fail to be verified, and at this time, when the target sub-client determines that the authorization code fails to be verified, the target sub-client may control the login page to be displayed in the target display area of the main client.

Here, the content included in the login page and the subsequent processing in response to the account and/or the password input in the login page are the same as those in the foregoing embodiment, and details are not repeated here.

In addition, the second server sends user identity information to the target sub-client under the condition that the second server passes the authorization code verification based on the request information; correspondingly, the target sub-client acquires the user identity information from the second server.

Here, the user identity information may specifically include: the user ID. In addition, the target sub-client can also acquire other relevant information of the user from the second server; the user other relevant information may include at least one of: user name, user avatar, token (i.e., user login token), token expiration time, and the like. The information of the present embodiment that is focused on is the user identity information, and therefore other related information of the user is not exhaustive.

And then executing S504, wherein the target sub-client logs in the first server based on the user identity information, and when the login is successful, the main client is informed to display the login state of the target sub-client in a target display area.

Here, the target sub-client logging in at the first server based on the user identity information includes: and the target sub-client acquires account related information of the account which is successfully logged in from the first server based on the user identity information.

That is to say, when the user identity information is obtained, the target sub-client obtains account related information of the successfully logged-in account from the first server by using the user ID in the user identity information.

The notifying the host client to display the login state of the target sub-client in the target display area when the login is successful may specifically be: and informing the main client to display a page containing account related information of the account which is successfully logged in by the target sub-client in the target display area at the target sub-client.

An embodiment of the second aspect described above is exemplarily described with reference to fig. 4, and may include:

s4021: and the target sub-client responds to the starting instruction of the main client to start resource loading.

Here, the start instruction of the host client may be sent to the target sub-client through the communication SDK.

S4022: and the target sub-client finishes resource loading.

S4023: and the target sub-client sends a login instruction to the main client.

Here, before executing S4023, the target sub-client may further determine whether the terminal device is a cloud device, and if so, execute S4023; otherwise, the target sub-client controls the target display area of the main client to display the login page. The manner for determining whether the terminal device is a cloud device has been described in the foregoing embodiments, and details are not repeated here.

In addition, when executing S4023, the target sub-client may further determine whether the login instruction is successfully sent, and if so, execute S4024; otherwise, the target sub-client controls the target display area of the main client to display the login page.

The reason why the sending of the login instruction of the target sub-client fails can include that network communication is in problem or abnormal; or the version of the main client is a version which does not support subsequent processing, that is, the current version of the main client is too low (or not upgraded) so as not to support the processing of acquiring the authorization code and enabling the target sub-client to log in based on the authorization code.

S4024: the target sub-client listens for an authorization code.

S4025: and the target sub-client generates request information based on the authorization code, and acquires user identity information from a second server based on the request information.

Here, the processing of S4025 may specifically include: the target sub-client judges whether an authorization code sent by the main client is monitored within a first preset time (such as 60 seconds) after the login instruction is sent, if yes, request information is generated based on the authorization code, and user identity information is obtained from a second server based on the request information; otherwise, the target sub-client controls the target display area of the main client to display the login page.

In addition, the master client may send the authorization code to the target sub-client through a communication SDK.

S4026: and the target sub-client logs in the first server based on the user identity information, and informs the main client to display the login state of the target sub-client in a target display area when the login is successful.

The subsequent processing of the target sub-client to display the login page is also described in the foregoing embodiment, and therefore, is not described in detail.

Therefore, by adopting the scheme, the main client acquires the authorization code of the associated target sub-client and sends the authorization code to the target sub-client, so that the target sub-client finishes logging in the first server after acquiring the user identity information based on the authorization code. Therefore, the operation that the user needs to input the account and the password when logging in the target sub-client every time is avoided by the mode of transmitting the authorization code across the clients, and the efficiency of login processing is improved.

In addition, the authorization and login processing aiming at the target sub-client can be completed in the main client, so that the transmission of the authorization code of the target sub-client is protected by the container of the main client, the information leakage can be avoided, and the login safety of the target sub-client is ensured.

And thirdly, because the encryption processing is carried out in the processing of generating the request information in the target sub-client through the authorization code, the message can be ensured not to be tampered, and the safety of the whole processing is further ensured.

Exemplary System

Having described the method of the exemplary embodiment of the present disclosure, the client login system of the exemplary embodiment of the present disclosure will be explained next.

A third aspect of the present disclosure provides a client login system, referring to fig. 7, including: a terminal device 71, a first server 72, and a second server 73; the terminal device 71 includes a main client 711 and a target sub-client 712; the target sub-client is one of N sub-clients associated with the main client, and N is an integer greater than or equal to 1; wherein the content of the first and second substances,

the main client 711 is configured to obtain an authorization code corresponding to the target sub-client when the target sub-client completes resource loading in response to a start instruction of the main client; sending the authorization code to the target sub-client; displaying the login state of the target sub-client in a target display area;

the target sub-client 712 is configured to obtain an authorization code sent by a host client when the resource loading is completed in response to a start instruction of the host client; generating request information based on the authorization code; acquiring user identity information from a second server based on the request information; logging in at the first server based on the user identity information; when the login is successful, the main client is informed to display the login state of the target sub-client in a target display area;

the first server 72 is configured to provide login state related information for the target sub-client;

the second server 73 is configured to provide user identity information for the target sub-client.

The host client 711 is configured to display an authorization page of the target sub-client in a target display area; and responding to the operation of a target key in the authorization page of the target sub-client, and acquiring an authorization code corresponding to the target sub-client.

The primary client 711 is configured to obtain an authorization code corresponding to the target secondary client from a second server; the second server 73 is configured to generate an authorization code corresponding to the target sub-client.

The second server 73 is configured to perform encryption processing based on the identifier of the target sub-client, the authorization range, the current timestamp, and the global incremental launching number, and generate an authorization code corresponding to the target sub-client.

The second server 73 is specifically configured to concatenate the identifier of the target sub-client, the authorization range, the current timestamp, and the global incremental digital into a string to be encrypted; encrypting the character string to be encrypted to obtain an authorization code corresponding to the target sub-client; and storing the authorization code, the corresponding authorization range and the user related information.

In one example, the code implemented by the second server 73 to generate the authorization code may include:

@Resource(name＝”userRedisClient”)

private RedisClusterService redisClient；

private static final time 10 × 60; // effective duration 10 x 60 seconds;

private final string UNIQUE_KEY＝”user:unique:key:index”；

/**

the method comprises the following steps: createGrantCode < br >

Description of the drawings: authorization code generation procedure < br >

*@param clientIdStr

*@param scopestr

*@param user

*@return

*@throws Exception

*/

return encrypted str; // returning an authorization code;

}

the length of the authorization code may be a preset length, for example, 40 bits, and for example, one authorization code may be "fec 1cdc7b5c5f0f4e32c36dc08a5b35bee83e8e 9".

The authorization code may be for a subsequent exchange of tokens (access _ tokens); the authorization code may have a valid duration, and may be set to a failure state when the duration of the storage of the authorization code at the second server side exceeds the valid duration. In addition, one authorization code is only used for exchanging the token once, and on the second server side, if it is determined that one authorization code is successfully exchanged for the corresponding token, the authorization code may also be set to be in a failure state.

The second server 73 is further configured to store the authorization code when the authorization code is generated; the second server 73 is further configured to set the authorization code corresponding to the target sub-client to be in a failure state when the storage duration of the authorization code corresponding to the target sub-client reaches the valid duration. The effective time period may be set according to actual conditions, and for example, may be 10 minutes, or may be 5 minutes, and the like.

The target sub-client 712 is configured to start a first timer when the resource loading is completed; when the timing duration of the first timer reaches a first preset duration and an authorization code sent by the main client is not received, the target sub-client controls the target display area of the main client to display a login page; the login page comprises an input area of an account number and/or a password.

The target sub-client 712 is configured to encrypt the authorization code based on a preset key to obtain the request information.

The target sub-client 712 is specifically configured to use the current timestamp, the signature algorithm type, the identifier of the target sub-client, and the authorization code as initial request parameters; the target sub-client splices the initial request parameters to obtain a character string; the target sub-client processes the preset key and the character string to obtain a signature string; and the target sub-client adds the signature string to the initial request parameter to obtain a target request parameter, and generates the request information based on the target request parameter.

The second server 73 is configured to receive request information sent by a target sub-client, and verify an authorization code included in the request information; and sending user identity information to the target sub-client under the condition of passing the verification.

Here, the second server may verify the authorization code included in the request information based on the stored authorization code corresponding to the target sub-client and the valid duration corresponding to the authorization code. For example, whether the authorization code corresponding to the target sub-client is within the valid duration is determined based on the receiving time of the request information, and if yes, the verification is passed (or the verification is successful); otherwise, the verification fails (or fails).

The target sub-client 712, configured to, when the authorization code in the request information is verified by the second server unsuccessfully, control the target sub-client to display a login page in a target display area of the host client; the login page comprises an input area of an account number and/or a password.

The target sub-client 712, configured to obtain account related information of a successfully logged-in account from the first server based on the user identity information; the first server 72 is configured to send account related information of a successfully logged-in account to the target sub-client based on the user identity information.

The detailed processing of the host client 711 and the target sub-client 712, and the interaction between the host client 711 and the target sub-client 712 have been described in detail in the foregoing embodiments of the first aspect and the second aspect, and will not be repeated here.

Finally, referring to fig. 8, taking an example that the main client is a cloud music client, the target sub-client is an associated game client of the cloud music client, the second server is a cloud music account server associated when the cloud music client operates, and the first server is a game server associated when the associated game client operates, the processing of the system is exemplarily described:

s801: and clicking a game trial button in the cloud music client by the user, and triggering the associated intermodal game client of the cloud music client to start resource loading.

Specifically, as shown in fig. 8, the cloud music client may send a start instruction to the intermodal game client through the first communication SDK and the second communication SDK of the intermodal game client, so that the intermodal game client starts to load resources.

In addition, after the intermodal game client finishes resource loading, an indication of loading completion can be fed back to the cloud music client.

S802: and the intermodal game client completes resource loading and sends a login instruction to the cloud music client.

In addition, the method can also comprise the following steps: if the login instruction fails to be sent, the intermodal game client can control the cloud music client to display a login page in the target display area, so that the user can input an account and/or a password to log in. Here, the reason why the transmission of the login instruction fails, the style of the login page, and the process of inputting the account number and/or the password are the same as those in the foregoing embodiment, and a description thereof will not be repeated.

Here, as shown in fig. 8, the login instruction may specifically be an OAUTH (authentication) service sent to the cloud music client, or an authentication service function called the cloud music client; in addition, the login instruction may be transmitted through the second communication SDK of the intermodal game client and the first communication SDK in the cloud music client.

In addition, the first communication SDK in the cloud music client may also feed back information that the receiving instruction is successful to the intermodal game client, and at this time, the intermodal game client may wait for the user to complete authorization, that is, wait for receiving an authorization code.

S803: the cloud music client sends an authorization code acquisition request to the cloud music account server.

Here, the cloud music client may query, through an internal OAUTH service (or an authentication service function), from the mysql database whether the user has authorized the intermodal game client, and if so, the OAUTH service in the cloud music client directly sends an authorization code acquisition request to the cloud music account server; if the authorization is not authorized, displaying an authorization page, and under the condition that the user clicks an authorization key, the OAUTH service in the cloud music client side obtains a request from the authorization code of the cloud music account server. Wherein the description of the authorization page is the same as the previous embodiment.

The specific obtaining and generating manner of the authorization code has been described in detail in the foregoing embodiments, and is not described herein again.

S804: the cloud music client obtains the authorization code.

S805: the cloud music client sends the authorization code to the intermodal game client. Accordingly, the intermodal game client receives the authorization code.

Here, the client end of the intermodal game may monitor the authorization code in a polling manner after completing S802, and if the authorization code is not received in 1 minute, directly pop up a login page to allow the user to input account and password information to complete login (for specific processing, refer to the foregoing embodiment, which is not described repeatedly). If the authorization code is received within 1 minute, the intermodal game client performs the process of S806.

S806: the intermodal game client generates request information based on the authorization code, sends the request information to the cloud music account server, and acquires user identity information from the cloud music account server.

Specifically, the intermodal game client calls the cloud music account server through the cloud music open platform to acquire the following information: user name, user avatar, (user login) token, user id (i.e., user identity information), token expiration time, and the like.

In addition, if the authorization code verification fails on the cloud music account server side, for example, the authorization code verification fails due to the fact that the authorization code is tampered or fails due to timeout, the intermodal game client controls the cloud music client to pop up a login page, and a user inputs an account and/or a password to complete login.

S807: after the intermodal game client side obtains the user identity information, the account related information of the account which has successfully logged in is obtained from the game server according to the user identity information, and the login state of the intermodal game client side is displayed in the target display area of the cloud music client side.

The account related information of the login successful account may be information of a character, a used property, a used skin, and the like created by the user under the login successful account in the client of the intermodal game.

The intermodal game client can be obtained by implanting an intermodal SDK provided by a cloud music party into the game client of a hand game developer; the intermodal game client can only log in using the account number (i.e., user identity information) of the cloud music client.

In addition, the authorization and login processing aiming at the target sub-client can be completed in the main client, so that the transmission of the authorization code of the target sub-client is protected by the container of the main client, the information leakage can be avoided, and the login processing safety of the target sub-client is ensured.

Exemplary Medium

Having described the method of the exemplary embodiment of the present disclosure, the medium of the exemplary embodiment of the present disclosure is explained next with reference to fig. 9.

In some possible embodiments, various aspects of the present disclosure may also be implemented as a computer-readable medium having a program stored thereon, which when executed by a processor, is used to implement the steps in the client login method according to various exemplary embodiments of the present disclosure described in the "exemplary methods" section above in this specification.

Specifically, the processor is configured to implement the following steps when executing the program:

And the number of the first and second groups,

It should be noted that: the above-mentioned medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example but not limited to: an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of the readable storage medium include: an electrical connection having one or more wires, a portable disk, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

As shown in fig. 9, a medium 900 that can employ a portable compact disc read only memory (CD-ROM) and include a program and can be run on a device according to an embodiment of the present disclosure is described. However, the disclosure is not so limited, and in this document, a readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

A readable signal medium may include a propagated data signal with readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take a variety of forms, including, but not limited to: an electromagnetic signal, an optical signal, or any suitable combination of the foregoing. A readable signal medium may also be any readable medium that is not a readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code for carrying out operations for the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user computing device, partly on a remote computing device, or entirely on the remote computing device or server. In the case of a remote computing device, the remote computing device may be connected to the user computing device through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN).

Exemplary devices

Having described the method of the exemplary embodiments of the present disclosure, the apparatus of the exemplary embodiments of the present disclosure will now be described.

A fourth aspect of the present disclosure provides a host client, as shown in fig. 10, including:

an authorization code obtaining unit 1001, configured to obtain an authorization code corresponding to a target sub-client when the target sub-client completes resource loading in response to a start instruction; the target sub-client is one of N sub-clients associated with the main client, wherein N is an integer greater than or equal to 1; the target sub-client acquires user identity information according to the authorization code;

a first internal communication unit 1002, configured to send the authorization code to the target sub-client;

a display unit 1003, configured to display, in a target display area, a login state of the target sub-client when the target sub-client successfully logs in the first server based on the user identity information; and the first server is a server associated with the target sub-client runtime.

In an embodiment of the present disclosure, the presenting unit 1003 is configured to present an authorization page of the target sub-client in a target presentation area;

the authorization code obtaining unit 1001 is configured to obtain an authorization code corresponding to the target sub-client in response to an operation on a target key in an authorization page of the target sub-client.

In an embodiment of the present disclosure, the authorization code obtaining unit 1001 is configured to obtain an authorization code corresponding to the target sub-client from a second server; and the second server is a server associated with the running of the main client.

A fifth aspect of the embodiments of the present disclosure provides a target sub-client, as shown in fig. 11, including:

a second internal communication unit 1101, configured to, in a case that resource loading is completed in response to a start instruction of a host client, obtain an authorization code sent by the host client; the target sub-client is one of N sub-clients associated with the main client, wherein N is an integer greater than or equal to 1;

a request generating unit 1102 configured to generate request information based on the authorization code;

an identity information obtaining unit 1103 configured to obtain user identity information from the second server based on the request information; the second server is a server associated with the running of the main client;

a login unit 1104, configured to log in to the first server based on the user identity information, and notify the host client to display a login status of the target sub-client in a target display area when the login is successful; and the first server is a server associated with the target sub-client runtime.

In an embodiment of the present disclosure, the request generating unit 1102 is configured to encrypt the authorization code based on a preset key to obtain the request information.

In an embodiment of the present disclosure, the request generating unit 1102 is configured to use a current timestamp, a signature algorithm type, an identifier of the target sub-client, and the authorization code as initial request parameters; splicing the initial request parameters to obtain a character string; processing based on the preset key and the character string to obtain a signature string; and adding the signature string to the initial request parameter to obtain a target request parameter, and generating the request information based on the target request parameter.

In one embodiment of the present disclosure, further comprising:

a display control unit 1105, configured to control to display a login page in a target display area of the host client when the second server fails to verify the authorization code in the request information; the login page comprises an input area of an account number and/or a password.

In one embodiment of the present disclosure, further comprising:

the display control unit 1105 is configured to start a first timer when the resource loading is completed; controlling the login page to be displayed in the target display area of the main client under the condition that the timing duration of the first timer reaches a first preset duration and an authorization code sent by the main client is not received; the login page comprises an input area of an account number and/or a password.

In an embodiment of the present disclosure, the login unit 1104 is configured to obtain account related information of a successfully logged-in account from the first server based on the user identity information.

Exemplary computing device

Having described the methods, media, and apparatus of the exemplary embodiments of the present disclosure, a computing device of the exemplary embodiments of the present disclosure is described next with reference to fig. 12.

As will be appreciated by one skilled in the art, aspects of the present disclosure may be embodied as a system, method or program product. Accordingly, various aspects of the present disclosure may be embodied in the form of: an entirely hardware embodiment, an entirely software embodiment (including firmware, microcode, etc.) or an embodiment combining hardware and software aspects that may all generally be referred to herein as a "circuit," module "or" system.

In some possible implementations, a computing device according to embodiments of the present disclosure may include at least one processing unit and at least one memory unit. Wherein the storage unit stores program code which, when executed by the processing unit, causes the processing unit to perform the steps in the client login method according to various exemplary embodiments of the present disclosure described in the above section "exemplary method" of the present specification.

A computing device 1200 according to such an embodiment of the disclosure is described below with reference to fig. 12. The computing device 1200 shown in fig. 12 is only one example and should not impose any limitations on the functionality or scope of use of embodiments of the disclosure.

As shown in fig. 12, computing device 1200 is embodied in the form of a general purpose computing device. Components of computing device 1200 may include, but are not limited to: the at least one processing unit 1201 and the at least one storage unit 1202 may be coupled together via a bus 1203 to the various system components including the processing unit 1201 and the storage unit 1202.

The bus 1203 includes a data bus, a control bus, and an address bus.

The storage unit 1202 may include readable media in the form of volatile memory, such as Random Access Memory (RAM)12021 and/or cache memory 12022, and may further include readable media in the form of non-volatile memory, such as Read Only Memory (ROM) 12023.

The storage unit 1202 may also include a program/utility 12025 having a set (at least one) of program modules 12024, such program modules 12024 including, but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which, or some combination thereof, may comprise an implementation of a network environment.

Computing device 1200 may also communicate with one or more external devices 1204, such as a keyboard, pointing device, etc. Such communication may occur via input/output (I/O) interfaces 1205. Moreover, computing device 1200 may also communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network, such as the internet) through network adapter 1206. As shown in FIG. 12, a network adapter 1206 communicates with the other modules of the computing device 1200 via a bus 1203. It should be understood that although not shown in the figures, other hardware and/or software modules may be used in conjunction with computing device 1200, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, among others.

It should be noted that although in the above detailed description several units/modules or sub-units/sub-modules of the music generating apparatus are mentioned, such division is merely exemplary and not mandatory. Indeed, the features and functionality of two or more of the units/modules described above may be embodied in one unit/module, in accordance with embodiments of the present disclosure. Conversely, the features and functions of one unit/module described above may be further divided into embodiments by a plurality of units/modules.

Further, while the operations of the disclosed methods are depicted in the drawings in a particular order, this does not require or imply that these operations must be performed in this particular order, or that all of the illustrated operations must be performed, to achieve desirable results. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step execution, and/or one step broken down into multiple step executions.

While the spirit and principles of the present disclosure have been described with reference to several particular embodiments, it is to be understood that the present disclosure is not limited to the particular embodiments disclosed, nor is the division of aspects, which is for convenience only as the features in such aspects may not be combined to benefit. The disclosure is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

Claims

1. A client login method comprises the following steps:

2. The method according to claim 1, wherein the obtaining, by the host client, the authorization code corresponding to the target sub-client includes:

3. A client login method comprises the following steps:

4. The method of claim 3, wherein the target sub-client generates request information based on the authorization code, comprising:

5. The method according to claim 4, wherein the obtaining of the request information by the target sub-client encrypting the authorization code based on a preset key includes:

6. A host client, comprising:

7. A target sub-client, comprising:

8. A client login system, comprising: the system comprises terminal equipment, a first server and a second server; the terminal equipment comprises a main client and a target sub-client; the target sub-client is one of N sub-clients associated with the main client, and N is an integer greater than or equal to 1; wherein the content of the first and second substances,

9. A medium storing a computer program, characterized in that the program, when being executed by a processor, carries out the method according to any one of claims 1-5.

10. A computing device, comprising:

one or more processors;

storage means for storing one or more programs;

the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the method recited in any of claims 1-5.