Account synchronization method, device, electronic device and storage medium

Abstract

The present application relates to the field of computer technology, and in particular to a method, device, electronic device and storage medium for synchronizing an account, the method comprising: receiving a subprogram login request sent by a first client, determining based on the first object identifier and target subprogram identifier carried in the subprogram login request that the corresponding first object has recorded target historical login information, obtaining the target historical login information, and then obtaining the login account and login password used by the first object when logging into the target-associated subprogram on the second client based on the target historical login information, determining the login data, and sending the login data to the first client. Based on the method provided by the present application, the target object does not need to frequently enter the login account and login password of the same target-associated subprogram under the same target application on each client, thereby effectively reducing the operational complexity of the login process for the same target-associated subprogram between each client.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to an account synchronization method, device, electronic device and storage medium. Background Art

[0002] With the rapid development of computer technology, target objects can use multiple terminal devices of different types based on their own usage needs to log in to the same associated subroutine in the same application to perform transaction processing.

[0003] However, under the relevant technology, in the above scenario, the target object needs to enter the account and password corresponding to the same associated subprogram in the same application on multiple terminal devices of different types, so that he can successfully log in to the same associated subprogram of the same application through multiple terminal devices of different types.

[0004] For example, the target object needs to log in to application A on the mobile device first, then click the "Mailbox" function key in the display interface corresponding to application A on the mobile device, and then enter the account and password of the "Mailbox" associated subprogram, so that the mobile device can obtain the schedule data in the "Mailbox" associated subprogram; and the target object needs to log in to application A on the computer device first, then click the "Mailbox" function key in the display interface corresponding to application A on the computer device, and then enter the account and password of the "Mailbox" associated subprogram, so that the mobile device can obtain the schedule data in the "Mailbox" associated subprogram, so that the target object can use the "Mailbox" associated subprogram on the mobile device and the computer device synchronously.

[0005] It can be seen that in this case, the target object needs to frequently enter the same account and password on different terminal devices, which significantly increases the operational complexity of the login process, reduces the operational efficiency and smoothness of the login process, and thus affects the target object's usage experience to a certain extent. Summary of the Invention

[0006] The embodiments of the present application provide an account synchronization method, device, electronic device and storage medium for simplifying the login process of account synchronization, thereby improving the operational efficiency of the account synchronization login process.

[0007] In a first aspect, an embodiment of the present application provides an account synchronization method, applied to a business server, comprising:

[0008] Receive a subprogram login request sent by a first client, wherein the subprogram login request carries: a first object identifier of a first object that has logged into a target application, and a target subprogram identifier of a target associated subprogram of the target application that the first object requests to log into;

[0009] When it is determined based on the first object identifier and the target subprogram identifier that target historical login information has been recorded corresponding to the first object, the target historical login information is obtained, where the target historical login information indicates that the first object has logged into the target associated subprogram under the target application program through the second client;

[0010] Based on the target historical login information, obtaining the login account and login password used by the first object when logging into the target-associated subprogram on the second client;

[0011] Based on the login account and login password, login data is determined, and the login data is sent to the first client, so that the target associated subprogram corresponding to the login account successfully logs in to the first client.

[0012] In a second aspect, an embodiment of the present application provides an account synchronization method, applied to a first client, comprising:

[0013] Sending a subprogram login request to the business server; the subprogram login request carries: a first object identifier of a first object that has logged into a target application, and a target subprogram identifier of a target associated subprogram of the target application that the first object requests to log into;

[0014] Receiving login data sent by the business server, wherein the login data is determined based on a login account and login password used by the first object when logging into the target-associated subprogram on the second client; the login account and login password are obtained by the business server based on historical login information of the target corresponding to the first object identifier and the target subprogram identifier;

[0015] Based on the login data, the target-related subprogram is registered under the target application program.

[0016] In a third aspect, an embodiment of the present application provides an account synchronization device, applied to a business server, comprising:

[0017] A first receiving unit is configured to receive a subprogram login request sent by a first client, wherein the subprogram login request carries: a first object identifier of a first object that has logged into a target application, and a target subprogram identifier of a target associated subprogram of the target application that the first object requests to log into;

[0018] a processing unit configured to, when determining based on the first object identifier and the target subprogram identifier that target historical login information has been recorded corresponding to the first object, obtain the target historical login information, wherein the target historical login information indicates that the first object has logged into the target associated subprogram under the target application program through a second client;

[0019] The processing unit is further configured to obtain, based on the target historical login information, a login account and a login password used by the first object when logging into the target-associated subprogram on the second client;

[0020] The first sending unit is configured to determine login data based on the login account and login password, and send the login data to the first client, so that the target associated subprogram corresponding to the login account successfully logs in to the first client.

[0021] In a possible implementation, before receiving the subprogram login request sent by the first client, the processing unit is further configured to:

[0022] Receiving historical login information sent by the second client; wherein the historical login information is triggered after the first object performs the following operations: logging into the target application on the second client, and further logging into the target associated subprogram;

[0023] The historical login information is stored in a storage area corresponding to the target application.

[0024] In a possible implementation, after receiving the subprogram login request sent by the first client, and before determining, based on the first object identifier and the target subprogram identifier, that target historical login information has been recorded for the first object, the apparatus further includes a verification unit configured to:

[0025] Sending identity authentication prompt information to the second client; the identity authentication prompt information is used to prompt the target object corresponding to the second client to confirm whether the first client is a secure client.

[0026] In a possible implementation, the verification unit is further configured to:

[0027] When receiving the identity authentication confirmation information sent by the second client, determining the time interval between the time of receiving the identity authentication confirmation information and the time of sending the identity authentication prompt information;

[0028] When it is determined that the time interval is not greater than the limit time interval, it is determined whether target historical login information has been recorded corresponding to the first object based on the first object identifier and the target subroutine identifier.

[0029] In a possible implementation, after receiving the subprogram login request sent by the first client, and before determining, based on the first object identifier and the target subprogram identifier, that target historical login information has been recorded for the first object, the apparatus further includes a verification unit configured to:

[0030] Determining device information of the first client;

[0031] When it is determined that the device information belongs to the preset device information set, it is determined whether target historical login information has been recorded corresponding to the first object based on the first object identifier and the target subroutine identifier.

[0032] In a possible implementation, after receiving the subprogram login request sent by the first client, and before determining, based on the first object identifier and the target subprogram identifier, that target historical login information has been recorded for the first object, the apparatus further includes a verification unit configured to:

[0033] Determining biometric information corresponding to the first client;

[0034] When it is determined that the biometric information belongs to a preset biometric information set, it is determined whether target historical login information has been recorded corresponding to the first object based on the first object identifier and the target subroutine identifier.

[0035] In a possible implementation, after obtaining the target historical login information and before obtaining the login account and login password used by the first object when logging into the target-associated subprogram on the second client, the processing unit is further configured to:

[0036] Determine whether the storage time of the login password reaches the time threshold;

[0037] When it is determined that the storage time of the login password does not reach the time threshold, the login account and login password used by the first object when logging into the target-associated subprogram on the second client are obtained.

[0038] In a possible implementation, the processing unit is further configured to:

[0039] When it is determined that the storage time of the login password reaches the time threshold, clearing the login password in the target historical login information; and

[0040] A prompt message is sent to the second client, where the prompt message is used to prompt the client to send the historical login information again.

[0041] In a possible implementation manner, the first client and the second client are two clients of different types.

[0042] In a possible implementation manner, if the program attribute information of the target associated subprogram is of an external caldav type, the first sending unit is specifically configured to:

[0043] Sending a verification request carrying the login account and the login password to the subprogram server corresponding to the target associated subprogram;

[0044] When receiving the verification success information sent by the sub-program server, sending a policy key policykey acquisition request to the sub-program server;

[0045] When the policy key sent by the subprogram server is received, the business data of the login account under the target associated subprogram is obtained from the subprogram server based on the policy key, so as to determine the login data based on the business data.

[0046] In a possible implementation manner, if the program attribute information of the target associated subprogram is of an exchange type, the first sending unit is specifically configured to:

[0047] Sending a verification request carrying the login account and the login password to the subprogram server corresponding to the target associated subprogram;

[0048] When the verification success information sent by the subprogram server is received, the business data of the login account under the target associated subprogram is obtained from the subprogram server to determine the login data based on the business data.

[0049] In a possible implementation manner, the first sending unit is specifically configured to:

[0050] The login account and login password are encapsulated to determine the login data.

[0051] In a fourth aspect, an embodiment of the present application provides an account synchronization device, applied to a first client, comprising:

[0052] The second sending unit is configured to send a subprogram login request to the business server; the subprogram login request carries: a first object identifier of a first object that has logged into a target application, and a target subprogram identifier of a target associated subprogram of the target application that the first object requests to log into;

[0053] a second receiving unit, configured to receive login data sent by the business server, wherein the login data is determined based on a login account and a login password used by the first object when logging into the target-associated subprogram on the second client; the login account and the login password are obtained by the business server based on historical login information of the target corresponding to the first object identifier and the target subprogram identifier;

[0054] A login unit is used to log in the target-related subprogram under the target application based on the login data.

[0055] In a possible implementation, if the login data is data encapsulating the login account and login password, then after receiving the login data sent by the business server and before logging into the target-associated subprogram under the target application based on the login data, the device further includes a determining unit configured to:

[0056] Determine the domain name information in the login account;

[0057] Based on the domain name information and a preset matching table, the program attribute information of the target associated subprogram is determined; the preset matching table includes a matching relationship between each domain name information and each program attribute information.

[0058] In a possible implementation, if the login data is data encapsulating the login account and login password, and the program attribute information is of an external cal dav type, then the login unit is specifically configured to:

[0059] Sending a verification request carrying the login account and the login password to the subprogram server corresponding to the target associated subprogram;

[0060] When receiving the verification success information sent by the sub-program server, sending a policy key policykey acquisition request to the sub-program server;

[0061] When the policykey sent by the subprogram server is received, the business data of the login account under the target associated subprogram is obtained from the subprogram server based on the policykey, so as to log in to the target associated subprogram under the target application based on the business data.

[0062] In a possible implementation, if the login data is data encapsulating the login account and login password, and the program attribute information is of an exchange type, then the login unit is specifically configured to:

[0063] Sending a verification request carrying the login account and the login password to the subprogram server corresponding to the target associated subprogram;

[0064] When the verification success information sent by the subprogram server is received, the business data of the login account under the target associated subprogram is obtained from the subprogram server to log in to the target associated subprogram under the target application based on the business data.

[0065] In a fifth aspect, an embodiment of the present application provides an electronic device comprising a processor and a memory, wherein the memory stores a program code, and when the program code is executed by the processor, the processor executes the steps of any one of the methods described in the first aspect or any one of the second aspect.

[0066] In a sixth aspect, an embodiment of the present application provides a computer storage medium, which stores computer instructions. When the computer instructions are executed on a computer, the computer executes the steps of any one of the methods described in the first aspect or the second aspect.

[0067] In a seventh aspect, an embodiment of the present application provides a computer program product, comprising a computer program / instruction, which, when executed by a processor, implements the steps of any one of the methods described in the first aspect or any one of the second aspects.

[0068] The beneficial effects of this application are as follows:

[0069] The account synchronization method, device, electronic device and storage medium provided in the embodiments of the present application have a business server that records the login account and login password of the target-associated subprogram that has been logged in under the target application through the second client before the first client logged in to the target application. Therefore, when the business server receives the subprogram login request sent by the first client, it can send the login data to the first client, so that the first client can log in to the target-associated subprogram based on the login data.

[0070] In this way, the target object does not need to frequently enter the login account and login password of the same target-associated subprogram under the same target application on each client. Instead, it only needs to enter it once during the first login, and then it can log in to the same target-associated subprogram on each client synchronously, thereby effectively reducing the operational complexity of the login process for the same target-associated subprogram between each client, and significantly improving the operational efficiency and smoothness of the login process.

[0071] Other features and advantages of the present application will be described in the following description, and in part will become apparent from the description, or will be understood by practicing the present application. The purposes and other advantages of the present application can be realized and obtained by the structures particularly pointed out in the written description, claims, and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0072] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0073] Figure 1 A schematic diagram of an application scenario of an account synchronization method provided in an embodiment of the present application;

[0074] Figure 2 A schematic diagram of an application scenario of another account synchronization method provided in an embodiment of the present application;

[0075] Figure 3 A signaling interaction diagram of an account synchronization method provided in an embodiment of the present application;

[0076] Figure 4 A schematic diagram of a target association subroutine for logging into a target application provided in an embodiment of the present application;

[0077] Figure 5 A schematic diagram of another target association subroutine for logging into a target application provided by an embodiment of the present application;

[0078] Figure 6 A schematic diagram of another target-associated subroutine for logging into a target application provided by an embodiment of the present application;

[0079] Figure 7 A schematic diagram of a storage system for a database corresponding to a business server provided in an embodiment of the present application;

[0080] Figure 8 A schematic diagram of a display interface of a first client provided in an embodiment of the present application;

[0081] Figure 9 A schematic diagram showing a prompt message provided in an embodiment of the present application;

[0082] Figure 10 A schematic diagram of a target-associated subroutine of a logged-in target application provided in an embodiment of the present application;

[0083] Figure 11A schematic diagram of interaction between a first client and a subprogram server provided in an embodiment of the present application;

[0084] Figure 12 A schematic diagram of synchronizing accounts between a mobile terminal and a computer terminal provided in an embodiment of the present application;

[0085] Figure 13 A schematic diagram of the interaction between multiple clients, a business server, and a subprogram server provided in an embodiment of the present application;

[0086] Figure 14 A flowchart of a method for synchronizing an account on a service server side of an account provided in an embodiment of the present application;

[0087] Figure 15 A flowchart of a method for synchronizing an account of a first client terminal provided in an embodiment of the present application;

[0088] Figure 16 A structural block diagram of an account synchronization device provided in an embodiment of the present application;

[0089] Figure 17 A structural block diagram of another account synchronization device provided in an embodiment of the present application;

[0090] Figure 18 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application;

[0091] Figure 19 A schematic diagram of the structure of a terminal device provided in an embodiment of the present application;

[0092] Figure 20 This is a structural diagram of a server in an embodiment of the present application. DETAILED DESCRIPTION

[0093] To make the objectives, technical solutions, and advantages of this application more clear, this application will be further described in detail below with reference to the accompanying drawings. Obviously, the embodiments described are only some of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making any creative efforts are within the scope of protection of this application.

[0094] In order to help those skilled in the art better understand the technical solution of this application, the terms involved in this application are introduced below.

[0095] 1. Client: Also known as the user end, this refers to the program that corresponds to the server and provides local services to the client. Except for some applications that only run locally, it is generally installed on a common client computer and needs to work in conjunction with the server. Specifically, clients can be categorized, for example, based on different carriers, into mobile clients and computer clients. They can also be categorized based on different operating systems, but this is not limited in the present embodiments.

[0096] 2. Application: refers to a computer program that is used to complete one or more specific tasks. It runs in user mode, can interact with the user, and has a visual user interface.

[0097] 3. Associated subprogram: refers to a program that runs nested within an application. For example, the mailbox in an instant messaging application can be called an associated subprogram, and the same account can log in to the associated subprogram "mailbox" and the corresponding application "mailbox".

[0098] The word “exemplary” is used hereinafter to mean “serving as an example, example, or illustration.” Any embodiment described as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.

[0099] The terms "first" and "second" are used for descriptive purposes only and should not be construed as explicitly or implicitly indicating relative importance or the number of the technical features indicated. Therefore, features specified as "first" or "second" may explicitly or implicitly include one or more of such features. In the description of the embodiments of this application, unless otherwise specified, "plurality" means two or more.

[0100] In related technologies, when the target object can use multiple terminal devices of different types based on its own usage needs to simultaneously log in to the same associated subroutine in the same application to perform transaction processing, the target object needs to frequently enter the same account and password on different terminal devices, that is, to simultaneously log in to the same associated subroutine in the same application on multiple different terminal devices. The operational complexity of the login process reduces the operational efficiency and smoothness of the login process, which in turn affects the target object's usage experience to a certain extent.

[0101] In view of this, an embodiment of the present application provides an account synchronization method, in which when a user logs in to a target-associated subprogram in a target application for the first time on a client, he or she can choose to perform operations on the client, and then send the login account and login password of the target-associated subprogram to the business server corresponding to the target application.

[0102] Furthermore, when a user logs in to a target-associated subprogram in a target application based on a client other than the aforementioned client, a corresponding subprogram login request can be sent to the business server based on the other client, so that the business server can determine the login account and login password of the target-associated subprogram corresponding to the user based on the user's account for logging in to the target application carried in the subprogram login request, and the target subprogram identifier for requesting to log in to the target-associated subprogram, so that the business server sends the login account and login password for logging in to the target-associated subprogram to other clients, and other clients can log in to the target-associated subprogram based on the login account and login password.

[0103] Obviously, the target object does not need to frequently enter the login account and password of the same target-associated subprogram under the same target application on each client. Instead, it only needs to enter it once during the first login, and then it can log in to the same target-associated subprogram on each client simultaneously, thereby simplifying the login process for the same target-associated subprogram between each client, and significantly improving the operational efficiency and smoothness of the login process.

[0104] The preferred embodiments of the present application are described below in conjunction with the drawings in the specification. It should be understood that the preferred embodiments described herein are only used to illustrate and explain the present application and are not used to limit the present application. In addition, the embodiments of the present application and the features in the embodiments may be combined with each other if there is no conflict.

[0105] See Figure 1 FIG2 is a schematic diagram of an optional application scenario in an embodiment of the present application. The application scenario schematic includes a terminal device 100 and a server 200. The terminal device 100 and the server 200 can communicate with each other via a communication network. Optionally, the communication network can be a wired network or a wireless network. The terminal device 100 and the server 200 can be directly or indirectly connected via wired or wireless communication, which is not limited in this application.

[0106] In the embodiment of the present application, the terminal device 100 is an electronic device used by the user, which may be a personal computer, a smart phone, a tablet computer, a notebook, an e-book reader, a smart home device, an in-vehicle terminal, or the like. Various applications may be installed in the terminal device 100, such as an instant messaging application, an email application, etc., and the application may include associated subprograms, such as an instant messaging application may include a "mailbox" associated subprogram, a payment application may include a "shopping" associated subprogram, etc. The server 200 may be an independent physical server, or a server cluster or distributed system composed of multiple physical servers. It may also be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0107] In an embodiment of the present application, after the user uses the terminal device 100 to log in to the target application, he can continue to log in to the target associated subprogram under the target application based on the terminal device 100. The terminal device 100 can send a subprogram login request for logging into the target associated subprogram to the server 200. The server 200 can use the account synchronization method of the embodiment of the present application to process the subprogram login request and send the login data to the terminal device 100, so that the terminal device 100 can log in to the target associated subprogram based on the login data.

[0108] See Figure 2 FIG. 1 is another optional application scenario diagram in an embodiment of the present application, which includes a first client 101 , a second client 102 , a service server 201 , and a subprogram server 202 .

[0109] In the embodiments of the present application, for ease of description, a user who logs into an associated subprogram under an application using the first client 101 or the second client 102 is referred to as a target object, an account that logs into an application using the first client 101 or the second client 102 is referred to as a first object, an application that the user wishes to synchronize logins with the account is referred to as a target application, and an associated subprogram under the application that the user wishes to synchronize logins with the account is referred to as a target associated subprogram. Furthermore, a client that does not require manual user input to log into the target application and the target associated subprogram under the target application is referred to as the first client 101, and a client that requires manual user input to log into the target application and the target associated subprogram under the target application is referred to as the second client 102.

[0110] In an embodiment of the present application, the first client 101 can communicate with the second client 102 through a communication network, the first client 101 can communicate with the business server 201 and the sub-program server 202 through a communication network, and the second client 201 can communicate with the business server 201 and the sub-program server 202 through a communication network, wherein the communication network can be a wired network or a wireless network, and this application does not impose any restrictions on this.

[0111] In the embodiments of the present application, the first client 101 and the second client 102 can be different types of terminal devices. Specifically, the categories can be different products. For example, the first client 101 can be a smartphone, and the second client 102 can be a personal computer. Of course, the categories can also be different operating systems. For example, the first client 101 can be an Android terminal device, and the second client can be a MacOS terminal device. Furthermore, the first client 101 can be an Android smartphone or an iOS smartphone, and the second client 102 can be a Windows personal computer or a MacOS personal computer. This application does not limit this.

[0112] It can be seen that the account synchronization solution provided in the embodiment of the present application can be applied to four different clients, that is, the account synchronization solution can be adapted to different types of clients and has strong adaptability.

[0113] In the embodiment of the present application, multiple applications can be installed on the first client 101 and the second client 102, and each application can include multiple associated sub-programs. The first client 101 and the second client 102 can also have the same application installed, and the application can include the same associated sub-programs. Thus, a user can use the login account and login password of the same application to log in to the same application on the first client 101 and the second client 102. Furthermore, a user can use the login account and login password of the same associated sub-program under the same application to log in to the same associated sub-program under the same application on the first client 101 and the second client 102.

[0114] In a specific implementation, the target object can enter the login account and login password for logging into the target application on the second client 102. The second client 102 can then use the received login account and login password for logging into the target application to obtain the corresponding business data from the business server 201, thereby logging into the target application. Furthermore, the target object can enter the login account and login password for logging into a target associated subprogram under the target application on the second client 102. The second client 102 can then use the received login account and login password for logging into the target associated subprogram under the target application to obtain the corresponding business data from the subprogram server 202, thereby logging into the target associated subprogram.

[0115] Specifically, when the target object logs in to the target associated subprogram, it can trigger an operation on the second client 102 to send historical login information to the business server 201, so that the business server 201 can receive the historical login information sent by the second client 102, and then the business server 201 can store the historical login information in the storage area corresponding to the target application.

[0116] During the specific implementation process, after logging into the target associated subprogram under the target application on the second client 102, the target object can enter the same login account and login password as on the second client 102 on the first client 101, so that the first client 101 can use the received login account and login password for logging into the target application to obtain the corresponding business data from the business server 201, thereby realizing the login of the target application.

[0117] Furthermore, the target object can trigger the operation of logging into the target associated subroutine under the target application on the first client 101, so that the first client 101 can generate a login subroutine request and send the login subroutine request to the business server 201. Then the business server 201 processes the login subroutine request and sends login data to the first client 101.

[0118] Specifically, when the login data is data encapsulating a login account and login password or data including business data, the first client 101 can use the received login account and login password for the target associated subprogram under the target application to obtain the corresponding business data from the subprogram server 202, thereby logging into the target associated subprogram. Alternatively, when the login data is data including business data, the first client 101 can log into the target associated subprogram based on the login data.

[0119] It should be noted that the above Figure 1 and Figure 2 This is an example introduction to the application scenarios of the account synchronization method. In fact, the application scenarios to which the method in the embodiments of the present application can be applied are not limited to this.

[0120] The following describes the specific implementation of the account synchronization method according to the embodiment of the present application.

[0121] See Figure 3 The figure shows a signaling interaction diagram of an account synchronization method provided by an embodiment of the present application. The method can be executed by a server and a terminal device in cooperation. The method can include the following steps:

[0122] Step 301: The second client sends historical login information to the business server; wherein the historical login information is triggered after the first object performs the following operations: logging into the target application on the second client, and further logging into the target associated subprogram.

[0123] In an embodiment of the present application, the target user enters the target application login account and password on the second client. The second client can then log in to the target application based on the target application login account and password. Furthermore, the target user can click a function key for displaying all associated subprograms of the target application, thereby causing the second client's display page to jump from the target application display page to a page displaying the target application's associated subprograms.

[0124] Optionally, if the target-associated subroutine is a subroutine that adds another type of functionality to the existing functionality of the target application, for example, the target-associated subroutine is a mailbox calendar subroutine, and the second client includes a calendar function, then when the target subject performs a preset operation on the target-associated subroutine in the target application, such as a click operation, a long press operation, etc., the corresponding page of the second client displaying the associated subroutine under the target application can jump to the page for adding an account. Furthermore, the target subject can operate the add account function key on the add account page, so that the second client jumps from the currently displayed add account page to the page for entering a login account.

[0125] For example, see Figure 4 As shown, Figure 4 This is a schematic diagram of a target-associated subroutine for logging into a target application program provided in an embodiment of the present application. Figure 4, a schematic diagram of a page displaying multiple associated subprograms is shown, including associated subprogram 1, associated subprogram 2, associated subprogram 3, associated subprogram 4, associated subprogram 5, associated subprogram 6, associated subprogram 7, associated subprogram 8, and associated subprogram 9. It should be noted that "Associated Subprogram X" is only used to distinguish different associated subprograms and does not limit the order of associated subprograms. Associated subprograms can be functionally partitioned based on other parameters such as their assigned functions or uses, and this application does not impose any restrictions on this.

[0126] Specifically, when the target object determines that the target associated subprogram is associated subprogram 8, the target object can click the function icon corresponding to associated subprogram 8, so that the second client can jump from the currently displayed page to the page for adding an account.

[0127] In one optional embodiment, after the target user enters the login account for the target associated subprogram on the second client, the second client is redirected from the currently displayed login account input page to a login password input page, where a function key corresponding to the function of adding the account to another client is displayed. Specifically, the target user enters the login password for the target associated subprogram on the second client and selects "Add the account to another client."

[0128] For example, see Figure 5 As shown, Figure 5 This is a schematic diagram of a target-associated subroutine for logging into a target application program provided in an embodiment of the present application. Figure 5 "Add this account on the computer at the same time" is the function key corresponding to adding this account on other clients.

[0129] Specifically, after the target object operates the "Add another account calendar" function icon, the second client jumps from the current page to the page for entering the login account. Furthermore, after the target object enters the login account "example.qq.com" in the login account input area of the second client, the second client's page jumps from the page for entering the login account to the page for entering the login password and selecting whether to "Synchronize this account on the computer side at the same time." Specifically, when the target object enters the login password in the second client and selects whether to synchronize this account on the computer side at the display page, enters the login password "14029*208" and checks "Synchronize this account on the computer side at the same time", the second client can successfully log in to the target-associated subprogram and sends historical login information to the business server indicating that the target object has successfully logged in to the target-associated subprogram on the second client.

[0130] It should be noted that, in actual implementation, the display form of the "function key for adding this account in other clients" can be: a box of any shape and / or size including text that can express "add this account in other clients", and this application does not impose any restrictions on this.

[0131] Optionally, if the target-associated subprogram is a subprogram that does not have a corresponding function in the target application, for example, the target-associated subprogram is a document subprogram, and the second client does not include functions related to writing documents, then after the target object operates the target-associated subprogram in the target application, the page on the second client that displays the associated subprogram under the target application can jump to the page for entering an account. Furthermore, the target object can enter the account number for logging into the target-associated subprogram on the account input page, so that the page on the second client that enters the account number can jump to the interface for entering a password and selecting whether to display the page for "Synchronize this account on the computer at the same time."

[0132] For example, see Figure 6 As shown, Figure 6 This is a schematic diagram of a target associated subroutine for logging into a target application program provided in an embodiment of the present application. Figure 6 In the example, the associated subroutines can be functionally partitioned based on the overall functional direction or other parameters, and this application does not impose any restrictions on this.

[0133] Specifically, when user A determines that associated subprogram 5 is the target associated subprogram, user A can click on associated subprogram 5 displayed on the page corresponding to the second client. Then, on the page that the second client redirects to, user A can enter their own login account number for associated subprogram 5, i.e., "16078023918." Furthermore, on the page that the second client redirects to again, user A can enter their own login password for associated subprogram 5, i.e., "2mow024*212," and check the "Also synchronize this account on the mobile device" checkbox. This allows the second client to successfully log in to associated subprogram 5 based on the login account number and password entered by user A, and send historical login information to the service server.

[0134] In an embodiment of the present application, the target object can operate the relevant function key provided on the second client to express the meaning of "synchronizing the account on other clients at the same time", so that the second client can send historical login information to the business server. Specifically, the historical login information may include the login account and login password of the target-associated subprogram, the target-associated subprogram identifier of the target-associated subprogram, and the first object identifier of the first object.

[0135] It can be seen that a functional interface is provided in the embodiment of the present application to select whether to synchronize accounts. Based on this functional interface, the user can choose whether to send the login account and login password of the login target associated subprogram to the business server, so that the business server can save the historical login information including the login account and login password of the login target associated subprogram.

[0136] Step 302: The service server receives the historical login information sent by the second client, and stores the historical login information in a storage area corresponding to the target application.

[0137] In an embodiment of the present application, the service server may receive the historical login information sent by the second client, and then store the historical login information in a storage area corresponding to the target application.

[0138] In a specific implementation process, the business server may receive a plurality of historical login information sent by a plurality of second clients, and then store the plurality of historical login information in a storage area corresponding to the target application.

[0139] Exemplarily, a database corresponding to a business server stores at least one first object identifier and historical login information corresponding to the first object identifier. The historical login information includes the first object identifier, a subprogram identifier associated with the first object identifier, and a login account and password for logging into the subprogram stored in association with the subprogram identifier.

[0140] For example, see Figure 7 The figure shows a storage diagram of a database corresponding to a business server provided in an embodiment of the present application. Each first object identifier is provided with a corresponding storage sub-area, and each storage sub-area stores the first object identifier, the sub-program identifier associated with the first object identifier, and the login account and login password of the login sub-program stored in association with the sub-program identifier.

[0141] Specifically, the data stored in the database corresponding to the business server, namely, the first object identifier and the historical login information corresponding to the first object identifier, can be triggered when the target subject manually enters the first object identifier on the second client, thereby logging into the target application on the first client, and the target subject manually enters the login account and login password for logging into the target-associated subprogram on the second client. Therefore, the historical login information stored in the database corresponding to the business server indicates that the first subject has logged into the target-associated subprogram under the target application through the second client.

[0142] Step 303: The first client sends a subprogram login request to the business server; the subprogram login request carries: the first object identifier of the first object that has logged into the target application, and the target subprogram identifier of the target associated subprogram of the target application that the first object requests to log into.

[0143] In an embodiment of the present application, a target user can input a first object for logging into a target application on a display interface of a first client. The first client can then log into the target application based on the first object. Furthermore, the target user can operate a function key of a target subprogram on the display interface of the first client, thereby generating a subprogram login request for the first client, which can then be sent to a service server.

[0144] For example, see Figure 8 , Figure 8 This is a schematic diagram of the display interface of the first client provided in the embodiment of the present application. Figure 8 The first object that has logged into the target application on the first client is included in the avatar. Specifically, the target object can click the function key of the mailbox association subprogram, that is, Figure 8 The first client can generate a subprogram login request for the mailbox association subprogram by clicking the "Add another calendar account" function key in the mailbox association subprogram.

[0145] Specifically, the subprogram login request carries: a first object identifier of a first object that has logged into a target application program, and a target subprogram identifier of a target associated subprogram of the target application program that the first object requests to log into.

[0146] In the embodiment of the present application, the first object identifier and the target subroutine identifier can be based on one or more of numbers, characters, Chinese characters or other text, and the present application does not limit this. For example, the first object identifier can be User_A, and the target associated subroutine can be Program 1.

[0147] Step 304: The service server receives the subprogram login request sent by the first client.

[0148] In an embodiment of the present application, after the service server receives the subprogram login request sent by the first client, it can perform security verification on the first client that sent the subprogram login request or the target object that uses the first client. Specifically, the verification can be implemented in the following ways, but not limited to:

[0149] Method 1:

[0150] In an embodiment of the present application, the business server may send identity authentication prompt information to the second client; the identity authentication prompt information is used to prompt the target object corresponding to the second client and confirm whether the first client is a secure client.

[0151] Specifically, the business server can search for the information of the corresponding second client based on the first object identifier of the first object, and then send an identity authentication prompt message to the second client. The prompt message is, for example: Please confirm whether to log in to the target associated subroutine on device a at 13:21 on August 13, 2021. When the user performs a first operation based on the prompt information on the second client, that is, after confirming that the target associated subroutine can be logged in on device a, the second client can send an identity authentication confirmation message to the business server. Among them, the first operation can be a click operation on the "Confirm" button, or it can be a "Confirm" control instruction output by voice. Of course, it can also be other operations, and this application does not limit this.

[0152] It should be noted that the identity authentication prompt information can be displayed in the form of a floating box on the display page of the second client, or sent to the second client in the form of a text message. Of course, it can also be in other ways, which is not limited in this application.

[0153] Furthermore, when the business server receives the authentication confirmation information sent by the second client, it can determine the time interval between the time of receiving the authentication confirmation information and the time of sending the authentication prompt information. If the time interval is determined to be no greater than the limit time interval, the business server can determine, based on the first object identifier and the target subroutine identifier, whether the corresponding first object has recorded the target's historical login information. The limit time interval can be 5 seconds, 3 seconds, or another time interval determined based on actual implementation, and this application does not impose any limitation thereto.

[0154] Obviously, since the second client is a login account and login password manually entered by the user for the target-associated subprogram, the first client can be verified based on the information fed back by the second client, thereby ensuring that the first client, which does not need to use a password to log in to the target-associated subprogram, is safe and reliable, thereby avoiding sending the login data of the target-associated subprogram to an unsafe client, thereby ensuring the security of login data transmission. In addition, since this application also compares the time interval between the time of receiving the identity verification confirmation information and the time of sending the identity verification prompt information with the restricted time interval, it can avoid the theft of information between the second client and the business server, resulting in the problem of verification failure, further improving the security of information transmission.

[0155] Method 2:

[0156] In an embodiment of the present application, the business server can determine the device information of the first client, and when it is determined that the device information belongs to the preset device information set, it determines whether the corresponding first object has recorded the target historical login information based on the first object identifier and the target subroutine identifier.

[0157] Specifically, the business server can determine the device information of the first client based on the device information carried when receiving the subroutine login request sent by the first client; the business server can also determine the device information of the first client based on the device information carried when receiving the login request of the target application sent by the first client. Of course, other methods are also possible, and this application does not limit this. Among them, the device information can be the device model corresponding to the first client, such as the device model is xxx_xx10. Of course, the device information can also be other information that can uniquely identify the first client, and this application does not limit this. In addition, the preset device information set can be determined based on the usage habits of the user using the second client, such as the device information of multiple devices used by the user to log in to the target application.

[0158] It can be seen that since the device information corresponding to the first client belongs to the preset device information set, it can be determined that the first client is a client frequently used by the user, thereby confirming that the first client is a safe and reliable client, that is, the first client is verified to be successful.

[0159] Method 3:

[0160] In an embodiment of the present application, the service server may determine the biometric information corresponding to the first client; wherein the biometric information may be any one of fingerprint information, facial information, palm print information, and iris information, and the present application does not impose any restrictions on this.

[0161] Specifically, the service server may receive biometric information sent by the first client. The biometric information is, for example, determined by the first client when the user logs into the target application using the first client.

[0162] In an embodiment of the present application, when the service server determines that the biometric information belongs to a preset biometric information set, it determines whether the target historical login information has been recorded for the corresponding first object based on the first object identifier and the target subroutine identifier. The preset biometric information set may be determined based on the biometric information of the user determined by the second client, and the preset biometric information set includes the user's fingerprint information, facial information, palm print information, and iris information.

[0163] It can be seen that in the embodiment of the present application, the business server can determine whether the first client is used by a secure user based on whether the biometric information of the user who logs into the target application is the same as the biometric information of the user who logs into the target application in the second client, thereby determining that the target-associated subroutine based on the first client login is secure and trustworthy, thereby enhancing the security of data transmission.

[0164] Obviously, the embodiment of the present application provides a method for judging the security of information transmission between the first client and the business server from the dimension of the user using the second client and the dimension of the device information of the first client, thereby improving the security of data transmission.

[0165] Step 305: When the business server determines that the target historical login information has been recorded for the first object based on the first object identifier and the target subroutine identifier, it obtains the target historical login information, which indicates that the first object has logged into the target associated subroutine under the target application through the second client.

[0166] In an embodiment of the present application, after the first client sends a subprogram login request to the business server, the business server can receive the subprogram login request sent by the first client, and then the business server can obtain the target historical login information when it determines that the corresponding first object has recorded the target historical login information based on the first object identifier and the target subprogram identifier.

[0167] Therefore, when the business server receives a subprogram login request sent by the first client, it can search for historical login information corresponding to the first object identifier in the database corresponding to the business server based on the first object identifier carried in the subprogram login request, and then determine the corresponding target historical login information from the historical login information corresponding to the first object identifier based on the target subprogram identifier.

[0168] Step 306: The service server determines whether the storage time of the login password reaches the time threshold.

[0169] Step 307: When the business server determines that the storage time of the login password does not reach the time threshold, the business server obtains the login account and login password used by the first object when logging into the target associated subprogram on the second client based on the target historical login information.

[0170] In an embodiment of the present application, the business server can also determine whether the storage time of the login password of the target associated subprogram has reached a time threshold. The time threshold can be determined by the business server based on its own storage status, or it can be set by the target object when sending historical login information based on the second client. This application does not impose any restrictions on this. The time threshold is, for example, 30 days or 45 days. This application does not impose any restrictions on this. Further, when the business server determines that the storage time of the target associated subprogram login password from the time it obtains the target associated subprogram login password to the time it receives the subprogram login request sent by the first client does not reach the time threshold, step 304 is executed.

[0171] It can be seen that the embodiment of the present application also limits the storage time of the login password stored in the business server. This approach can ensure the security of the login password to a certain extent and maintain the storage stability of the business server.

[0172] It should be noted that in the embodiment of the present application, the login account of the target associated subroutine can be stored in the business server for a long time, and the storage time of the login account can also be limited. This application does not impose any restrictions on this.

[0173] In this embodiment of the present application, when the service server determines that the storage time of the login password has reached the storage time threshold, the login password in the target historical login information can be cleared. Thus, in this embodiment of the present application, the service server can clear the login password of the target associated subprogram that has reached the storage time threshold, thereby reducing the storage pressure of the service server.

[0174] In addition, in the embodiment of the present application, the service server may also send a prompt message to the second client, the prompt message being used to prompt the second client to resend the historical login information. In this way, the historical login information stored in the service server may be updated.

[0175] For example, see Figure 9 , which is a schematic diagram showing a prompt message provided by an embodiment of the present application. In which, the second client can receive a prompt message sent by the business server, namely: the password-free login time has expired, please select the synchronization account operation again.

[0176] In an embodiment of the present application, after the service server obtains the target historical login information, it can obtain the login account and login password used by the first object when logging into the target-associated subprogram on the second client based on the target historical login information.

[0177] Step 308: The business server determines the login data based on the login account and login password.

[0178] In an embodiment of the present application, the business server may interact with the subprogram server to determine login data including business data, and then send the login data to the first client.

[0179] Optionally, when the target subprogram is an email subprogram, and the business server determines that the program attribute information of the email subprogram is an external cal dav type, the business server can send a verification request carrying the login account and login password to the subprogram server corresponding to the target associated subprogram; when receiving the verification success information sent by the subprogram server, send a policy key policykey acquisition request to the subprogram server; when receiving the policykey sent by the subprogram server, based on the policykey, obtain the business data of the login account under the target associated subprogram from the subprogram server to determine the login data based on the business data.

[0180] In this way, it is possible to avoid the situation where the business server cannot obtain the business data of the login account under the target associated subprogram due to compatibility issues of the mailbox subprogram.

[0181] Optionally, when the target subprogram is an email subprogram, and the business server determines that the program attribute information of the email subprogram is an exchange type, the business server sends a verification request carrying the login account and login password to the subprogram server corresponding to the target associated subprogram; when receiving the verification success information sent by the subprogram server, the business data of the login account under the target associated subprogram is obtained from the subprogram server to determine the login data based on the business data.

[0182] It can be seen that this application provides a specific implementation process for the interaction between the business server and the subprogram server, that is, when the program attribute information of the mailbox subprogram is of exchange type, the business data can be obtained based on two interactions, so that the business server can determine the login data based on the business data.

[0183] In the embodiment of the present application, the business server may further encapsulate the login account and login password to determine the login data.

[0184] Obviously, in the embodiments of the present application, the business server may interact with the subprogram server to determine the login data including the business data, or may directly encapsulate the login account and password to determine the login data. In addition, the business server may determine the login data determination method based on its own load situation, or determine the login data determination method based on other methods, which is not limited by the present application.

[0185] Step 309: The service server sends login data to the first client.

[0186] In the embodiment of the present application, since the first client has successfully logged into the target application, and the target application needs to complete authentication and login based on the user's operation, it can be understood that the interaction between the first client and the business server is safe and reliable, so that the business server can securely transmit login data to the first client.

[0187] Step 310: The first client receives the login data sent by the business server, wherein the login data is determined based on the login account and login password used when the first object logs in to the target associated subprogram on the second client; the login account and login password are obtained by the business server based on the target historical login information corresponding to the first object identifier and the target subprogram identifier.

[0188] Step 311: The first client logs in the target associated subprogram under the target application based on the login data.

[0189] For example, see Figure 10 As shown, it is a schematic diagram of successfully logging into the target associated subroutine under the target application provided by the embodiment of the present application. Specifically, Figure 10 What is currently shown is the calendar schedule data of the account "example.qq.com" displayed on the first client, where the schedule data includes communication with Customer A at 2:00 PM on August 2, fishing on August 8, and Project 1 meeting at 10:00 AM on August 16. That is, the target object can synchronously use the calendar schedule data in the target-associated subroutine on the first client.

[0190] It can be seen that in the embodiment of the present application, when the user logs in to the target-associated subprogram in the target application based on the second client, he can choose to operate on the client and then send the login account and login password for logging into the target-associated subprogram to the business server corresponding to the target application.

[0191] Furthermore, when the user logs in to the target-associated subprogram in the target application based on the first client, the corresponding subprogram login request can be sent to the business server based on the first client, so that the business server can determine the login account and login password of the target-associated subprogram corresponding to the user based on the user's account for logging into the target application carried in the subprogram login request, and the target subprogram identifier for requesting to log in to the target-associated subprogram, and then the business server sends the login account and login password for logging into the target-associated subprogram to the first client, and the first client can log in to the target-associated subprogram based on the login account and login password.

[0192] In this way, the user only needs to enter it once when logging in for the first time on the second client, and then he can simultaneously log in to the same target-associated subprogram on the first client, that is, there is no need to frequently enter the login account and login password of the same target-associated subprogram under the same target application. Therefore, the operational complexity of the login process for the same target-associated subprogram between the first client and the second client can be effectively reduced, thereby significantly improving the operational efficiency and smoothness of the login process.

[0193] In an embodiment of the present application, before executing step 310, the first client can determine the domain name information in the login account, and determine the program attribute information of the target associated subroutine based on the domain name information and the preset matching table; the preset matching table includes the matching relationship between each domain name information and each program attribute information.

[0194] For example, assuming that the target associated subprogram is an email subprogram and the login account is xxx.qq.com, it can be determined that the program attribute information corresponding to the email subprogram is of the exchange type.

[0195] For another example, assuming that the target associated subprogram is an email subprogram and the login account is xxxx.365.site, it can be determined that the program attribute information corresponding to the email subprogram is of type cal dav.

[0196] It can be seen that the embodiment of the present application provides a specific method for determining the program attribute information of the target-associated subprogram, which provides a good implementation basis for subsequently obtaining the account for logging into the target-associated subprogram and the business data under the target-associated subprogram.

[0197] In an optional embodiment, if the login data is data encapsulating a login account and a login password, and the first client determines that the program attribute information of the target associated subprogram is of the external cal dav type, then the first client logs in the target associated subprogram under the target application based on the login data, including the following steps:

[0198] Step a: The first client sends a verification request containing a login account and password to the subprogram server;

[0199] Step b: The subprogram server sends a verification success message to the first client;

[0200] Step c: When the first client receives the verification success information sent by the subprogram server, it sends a policy key policykey acquisition request to the subprogram server;

[0201] Step d: The subprogram server sends the policykey to the first client;

[0202] Step e: When the first client receives the policykey sent by the subprogram server, it obtains the business data of the login account under the target associated subprogram from the subprogram server based on the policykey, so as to log in to the target associated subprogram under the target application based on the business data.

[0203] It can be seen that the embodiment of the present application provides a specific and feasible implementation plan for the compatibility problem of the target-associated subroutine of the cal dav type, thereby avoiding the situation where the first client is unable to obtain the business data of the login account under the target-associated subroutine due to the compatibility problem of the target-associated subroutine.

[0204] See Figure 11 FIG. 1 is a schematic diagram of the interaction between the first client and the subroutine server in an embodiment of the present application. Figure 11 In this example, the first client is computer 1, and the subprogram server is the mailbox subprogram server. Specifically, computer 1 can send a verification request containing a login account and password to the mailbox subprogram server. When the login verification service in the mailbox subprogram server successfully verifies the sent login account and password, it can send a verification success message to computer 1. Then, when computer 1 receives the verification success message from the mailbox subprogram server, it sends a policy key acquisition request to the mailbox subprogram server. The policykey server in the mailbox subprogram server can respond to the acquisition request and send the policykey to computer 1.

[0205] Furthermore, when computer 1 receives the policykey sent by the mailbox subprogram server, it sends a request to pull the schedule directory and schedule acquisition to the mailbox subprogram server based on the policykey, and then the schedule directory and schedule acquisition service in the mailbox subprogram server sends business data to computer 1, so that computer 1 can log in to the mailbox subprogram under the target application based on the business data.

[0206] In an optional embodiment, if the login data is data encapsulating a login account and a login password, when the first client determines that the program attribute information of the target associated subprogram is of the exchange type, the first client logs in the target associated subprogram under the target application based on the login data, including the following steps:

[0207] Step A: The first client sends a verification request carrying a login account and password to the subprogram server corresponding to the target associated subprogram;

[0208] Step B: When the first client receives the verification success information sent by the subprogram server, it obtains the business data of the login account under the target associated subprogram from the subprogram server, and logs in to the target associated subprogram under the target application based on the business data.

[0209] In an embodiment of the present application, when the first client determines that the program attribute information of the target associated subprogram is of exchange type, the first client can interact with the subprogram server twice to obtain the business data.

[0210] In the embodiment of the present application, target-associated subroutines with different program attributes are taken into consideration, and the processes for logging into target-associated subroutines are different. Multiple ways of logging into target-associated subroutines are provided, thereby adapting to various usage requirements. That is, the solution provided in the embodiment of the present application has a wider scope of application.

[0211] For example, see Figure 12 As shown in FIG, it is a schematic diagram of the synchronization of mobile terminal and computer terminal account shown in the embodiment of the present application. Specifically, the target associated subroutine is a mailbox subroutine as an example for explanation. Among them, as Figure 12 As shown in , the mailbox subprogram server includes a login service and a schedule data service, the mobile terminal includes a login account and a login password for logging into the mailbox subprogram, the business server includes an account for the target application, and a stored login account and password for logging into the mailbox subprogram, and the computer terminal includes a login account and a login password for logging into the mailbox subprogram, as well as a login account for logging into the mailbox subprogram.

[0212] In the specific implementation process, Figure 12 The mobile terminal can be understood as the second client. After the user successfully logs in to the target application on the mobile terminal, he can enter the login account and login password of the mailbox subprogram. The mobile terminal can then send a login request to the mailbox subserver based on the input login account and login password of the mailbox subprogram. Then, when the login service in the mailbox subprogram server verifies the login account and login password of the mailbox subprogram, the mailbox subserver can feedback the schedule data corresponding to the login account of the mailbox subprogram to the mobile terminal through the schedule data service, that is, the mobile terminal realizes the login of the mailbox subprogram.

[0213] Furthermore, when the user logs into the mailbox subprogram on the mobile terminal and selects the function key corresponding to the account synchronization, the mobile terminal can send the login account and login password for logging into the mailbox subprogram to the business server. The business server then stores the user's corresponding account for logging into the target application and the login account and login password for logging into the mailbox subprogram in association. Therefore, when the business server receives the login subprogram request sent by the computer terminal, it can search the directory for historical login information based on the information carried in the login subprogram request, and can then send the target historical login information, the account corresponding to logging into the target application, and the login account and login password for the login mailbox subprogram used when the mobile terminal triggers the login mailbox subprogram to the computer terminal.

[0214] exist Figure 12 In the example above, when the service server determines that the time limit has not been reached, the login account and password for the login email subroutine are sent to the computer. Furthermore, when the service server determines that the time limit has been reached, the login account for the login email subroutine is sent to the computer. This shows that when the time limit is reached, not only is the security of the login password taken into account, but the need to enter a login account is also reduced, which reduces the operational complexity of the login process and thereby improves its operational efficiency.

[0215] In a possible implementation, the service server may receive a subprogram login request sent by one first client, and may also receive subprogram login requests sent by multiple first clients simultaneously.

[0216] For example, see Figure 13 As shown, Figure 13 This is a schematic diagram of the interaction between multiple terminal devices and a business server in an embodiment of the present application. Specifically, the business server stores multiple first object identifiers corresponding to computer 1, computer 2, ..., computer m, and historical login information corresponding to the first object identifiers, the historical login information including the login account and login password of the associated subroutine. Figure 13 Computer 1, computer 2...computer m respectively send subroutine login requests to the business server, so that computer 1, computer 2...computer m can receive historical login information sent by the business server, and then computer 1, computer 2...computer m can interact with the subroutine based on their respective historical login information, where m is a positive integer greater than 2.

[0217] It should be noted that Figure 13Any terminal device in the can be used by the same target object to log in to the same associated subprogram under the same target application. For example, user A can use "computer 1" to send a subprogram login request to the business server, or use "computer 2" to send a subprogram login request to the business server. That is, the account synchronization solution in this application does not restrict the device that obtains historical login information from the business server, that is, it does not restrict the parameters of the physical device of the first client.

[0218] It can be seen that in the embodiment of the present application, the business server and the subroutine server can process the synchronization of multiple different clients in parallel, thereby improving the synchronization efficiency of the entire account.

[0219] The following describes the account synchronization method on the service server side of this application with reference to the accompanying drawings.

[0220] See Figure 14 As shown in FIG, a flowchart of a method for synchronizing an account in an embodiment of the present application is provided, which can be applied to a business server. Figure 14 As shown, the synchronization method of the account may include the following steps:

[0221] Step 1401: Receive a subprogram login request sent by a first client, the subprogram login request carrying: a first object identifier of a first object that has logged into a target application, and a target subprogram identifier of a target associated subprogram of the target application that the first object requests to log into;

[0222] Step 1402: When it is determined based on the first object identifier and the target subprogram identifier that target historical login information has been recorded for the first object, the target historical login information is obtained, where the target historical login information indicates that the first object has logged into the target associated subprogram under the target application program through the second client.

[0223] Step 1403: Based on the target's historical login information, obtain the login account and login password used by the first subject when logging into the target-associated subprogram on the second client;

[0224] Step 1404: Determine login data based on the login account and login password, and send the login data to the first client, so that the target associated subprogram corresponding to the login account successfully logs in to the first client.

[0225] In a possible implementation, the following steps are included before step 1401:

[0226] (1) receiving historical login information sent by the second client; wherein the historical login information is triggered after the first object performs the following operations: logging into the target application on the second client, and further logging into the target associated subroutine;

[0227] (2) Store the historical login information in the storage area corresponding to the target application.

[0228] In a possible implementation, after the above step 1402 and before step 1403, it also includes: determining whether the storage time of the login password reaches the time threshold; when it is determined that the storage time of the login password does not reach the time threshold, obtaining the login account and login password used by the first object when logging in to the target associated subprogram on the second client.

[0229] Furthermore, when it is determined that the storage time of the login password reaches the time threshold, the login password in the target historical login information is cleared; and a prompt message is sent to the second client, the prompt message being used to prompt the user to send the historical login information again.

[0230] The following describes the method for synchronizing an account on the first client side in an embodiment of the present application with reference to the accompanying drawings.

[0231] See Figure 15 As shown in FIG, it is a schematic diagram of the steps of a synchronization method of an account in an embodiment of the present application, which can be applied to the first client. Figure 15 As shown, the synchronization method of the account may include the following steps:

[0232] Step 1501: Send a subprogram login request to the business server; the subprogram login request carries: a first object identifier of a first object that has logged into a target application, and a target subprogram identifier of a target associated subprogram of the target application that the first object requests to log into;

[0233] Step 1502: Receive login data sent by the business server, where the login data is determined based on the login account and login password used by the first object when logging into the target associated subprogram on the second client; the login account and login password are obtained by the business server based on the target's historical login information corresponding to the first object identifier and the target subprogram identifier;

[0234] Step 1503: Based on the login data, log in the target associated subprogram under the target application.

[0235] In a possible implementation, after step 1502 and before step 1503, the following steps are further included:

[0236] Confirm the domain name information in the login account;

[0237] Based on the domain name information and a preset matching table, the program attribute information of the target associated subprogram is determined; the preset matching table includes a matching relationship between each domain name information and each program attribute information.

[0238] In a possible implementation manner, if the program attribute information is of the external cal dav type, step 1503 specifically includes the following steps:

[0239] Send a verification request with the login account and password to the subroutine server corresponding to the target associated subroutine;

[0240] When receiving the verification success information sent by the sub-program server, send a policy key policykey acquisition request to the sub-program server;

[0241] When the policykey sent by the subprogram server is received, the business data of the login account under the target associated subprogram is obtained from the subprogram server based on the policykey, so as to log in to the target associated subprogram under the target application based on the business data.

[0242] In a possible implementation, if the program attribute information is of exchange type, step 1503 specifically includes the following steps:

[0243] Send a verification request with the login account and password to the subroutine server corresponding to the target associated subroutine;

[0244] When the verification success information sent by the subprogram server is received, the business data of the login account under the target associated subprogram is obtained from the subprogram server to log in to the target associated subprogram under the target application based on the business data.

[0245] Based on the same inventive concept, an embodiment of the present application provides an account synchronization device. The principle of solving the problem by this device is similar to the method on the business server side of the above embodiment. Therefore, the implementation of this device can refer to the implementation of the above method, and the repeated parts will not be repeated.

[0246] Figure 16 An account synchronization device provided by an embodiment of the present application is shown. The device can be set in a business server. Figure 16 As shown, the account synchronization device includes a first receiving unit 1601 , a processing unit 1602 and a first sending unit 1603 .

[0247] The first receiving unit 1601 is configured to receive a subprogram login request sent by a first client, the subprogram login request carrying: a first object identifier of a first object that has logged into a target application, and a target subprogram identifier of a target associated subprogram of the target application that the first object requests to log into;

[0248] Processing unit 1602 is configured to obtain the target historical login information when determining that the target historical login information has been recorded for the first object based on the first object identifier and the target subprogram identifier, the target historical login information indicating that the first object has logged into the target associated subprogram under the target application program through the second client;

[0249] The processing unit 1602 is further configured to obtain, based on the target historical login information, a login account and a login password used by the first subject when logging into the target-associated subprogram on the second client;

[0250] The first sending unit 1603 is configured to determine login data based on the login account and the login password, and send the login data to the first client, so that the target associated subprogram corresponding to the login account successfully logs in to the first client.

[0251] In a possible implementation, before receiving the subprogram login request sent by the first client, the processing unit 1602 is further configured to:

[0252] Receive historical login information sent by the second client; wherein the historical login information is triggered after the first object performs the following operations: logging into the target application on the second client, and further logging into the target associated subprogram;

[0253] The historical login information is stored in the storage area corresponding to the target application.

[0254] In one possible implementation, after receiving the subprogram login request sent by the first client, and before determining, based on the first object identifier and the target subprogram identifier, that the target historical login information has been recorded for the first object, the apparatus further includes a verification unit configured to:

[0255] Send an identity authentication prompt message to the second client; the identity authentication prompt message is used to prompt the target object corresponding to the second client to confirm whether the first client is a safe client.

[0256] In one possible implementation, the verification unit is further configured to:

[0257] When receiving the identity authentication confirmation information sent by the second client, determining the time interval between the time of receiving the identity authentication confirmation information and the time of sending the identity authentication prompt information;

[0258] When it is determined that the time interval is not greater than the limit time interval, it is determined whether the corresponding first object has recorded the target historical login information based on the first object identifier and the target subroutine identifier.

[0259] In one possible implementation, after receiving the subprogram login request sent by the first client, and before determining, based on the first object identifier and the target subprogram identifier, that the target historical login information has been recorded for the first object, the apparatus further includes a verification unit configured to:

[0260] Determining device information of the first client;

[0261] When it is determined that the device information belongs to the preset device information set, it is determined whether the corresponding first object has recorded the target historical login information based on the first object identifier and the target subroutine identifier.

[0262] In one possible implementation, after receiving the subprogram login request sent by the first client, and before determining, based on the first object identifier and the target subprogram identifier, that the target historical login information has been recorded for the first object, the apparatus further includes a verification unit configured to:

[0263] Determining biometric information corresponding to the first client;

[0264] When it is determined that the biometric information belongs to the preset biometric information set, it is determined whether the corresponding first object has recorded the target historical login information based on the first object identifier and the target subroutine identifier.

[0265] In one possible implementation, after obtaining the target's historical login information and before obtaining the login account and login password used by the first subject to log in to the target-associated subprogram on the second client, the processing unit 1602 is further configured to:

[0266] Determine whether the storage time of the login password reaches the time threshold;

[0267] When it is determined that the storage time of the login password does not reach the time threshold, the login account and login password used by the first object to log in to the target associated subprogram on the second client are obtained.

[0268] In a possible implementation, the processing unit 1602 is further configured to:

[0269] When it is determined that the storage time of the login password reaches the time threshold, clearing the login password in the target historical login information; and

[0270] A prompt message is sent to the second client, where the prompt message is used to prompt the second client to send the historical login information again.

[0271] In a possible implementation, the first client and the second client are two clients of different types.

[0272] In a possible implementation manner, if the program attribute information of the target associated subprogram is of the external cal dav type, the first sending unit 1603 is specifically configured to:

[0273] Send a verification request with the login account and password to the subroutine server corresponding to the target associated subroutine;

[0274] When receiving the verification success information sent by the sub-program server, send a policy key policykey acquisition request to the sub-program server;

[0275] When the policy key sent by the subprogram server is received, the business data of the login account under the target associated subprogram is obtained from the subprogram server based on the policy key, so as to determine the login data based on the business data.

[0276] In a possible implementation, if the program attribute information of the target associated subprogram is of exchange type, the first sending unit 1603 is specifically configured to:

[0277] Send a verification request with the login account and password to the subroutine server corresponding to the target associated subroutine;

[0278] When the verification success information sent by the subprogram server is received, the business data of the login account under the target associated subprogram is obtained from the subprogram server to determine the login data based on the business data.

[0279] In a possible implementation, the first sending unit 1603 is specifically configured to:

[0280] The login account and password are encapsulated to confirm the login data.

[0281] Based on the same inventive concept, an embodiment of the present application also provides an account synchronization device. The principle of solving the problem by this device is similar to the method on the first client side of the above embodiment. Therefore, the implementation of this device can refer to the implementation of the above method, and the repeated parts will not be repeated.

[0282] Figure 17 An account synchronization device provided by an embodiment of the present application is shown. The device can be set on a first client. Figure 17 As shown, the account synchronization device includes a second sending unit 1701 , a second receiving unit 1702 and a login unit 1703 .

[0283] The second sending unit 1701 is configured to send a subprogram login request to the business server; the subprogram login request carries: a first object identifier of a first object that has logged into a target application, and a target subprogram identifier of a target associated subprogram of the target application that the first object requests to log into;

[0284] The second receiving unit 1702 is configured to receive login data sent by the business server, wherein the login data is determined based on the corresponding login account and login password used by the first object when logging into the target associated subprogram on the second client; the login account and login password are obtained by the business server based on the target's historical login information corresponding to the first object identifier and the target subprogram identifier;

[0285] The login unit 1703 is used to log in the target associated subprogram under the target application based on the login data.

[0286] In one possible implementation, if the login data sent by the service server is data encapsulating a login account and a login password, then after receiving the login data sent by the service server and before logging into the target associated subprogram under the target application based on the login data, the apparatus further includes a determining unit configured to:

[0287] Confirm the domain name information in the login account;

[0288] Based on the domain name information and a preset matching table, the program attribute information of the target associated subprogram is determined; the preset matching table includes a matching relationship between each domain name information and each program attribute information.

[0289] In a possible implementation, if the login data is data encapsulating a login account and a login password, and the program attribute information is of an external cal dav type, the login unit 1703 is specifically configured to:

[0290] Send a verification request with the login account and password to the subroutine server corresponding to the target associated subroutine;

[0291] When receiving the verification success information sent by the sub-program server, send a policy key policykey acquisition request to the sub-program server;

[0292] When the policykey sent by the subprogram server is received, the business data of the login account under the target associated subprogram is obtained from the subprogram server based on the policykey, so as to log in to the target associated subprogram under the target application based on the business data.

[0293] In a possible implementation, if the login data is data encapsulating a login account and a login password, and the program attribute information is of an exchange type, the login unit 1703 is specifically configured to:

[0294] Send a verification request with the login account and password to the subroutine server corresponding to the target associated subroutine;

[0295] When the verification success information sent by the subprogram server is received, the business data of the login account under the target associated subprogram is obtained from the subprogram server to log in to the target associated subprogram under the target application based on the business data.

[0296] For the convenience of description, the above parts are divided into modules according to their functions and described separately. Of course, when implementing this application, the functions of each module can be implemented in the same or multiple software or hardware.

[0297] Those skilled in the art will appreciate that various aspects of the present application can be implemented as systems, methods, or program products. Therefore, various aspects of the present application can be specifically implemented in the following forms: a complete hardware implementation, a complete software implementation (including firmware, microcode, etc.), or an implementation that combines hardware and software aspects, which may be collectively referred to herein as a "circuit," "module," or "system."

[0298] Regarding the device in the above embodiment, the specific execution method of each module has been described in detail in the embodiment of the method, and will not be elaborated here.

[0299] Based on the same inventive concept as the above-mentioned method embodiment of the present application, an electronic device is also provided in the embodiment of the present application. The principle of solving the problem by the electronic device is similar to the method of the above-mentioned embodiment. Therefore, the implementation of the electronic device can refer to the implementation of the above-mentioned method, and the repeated parts will not be repeated.

[0300] See Figure 18 As shown, Figure 18 1 is a block diagram of an electronic device 1800 according to an exemplary embodiment. The device includes:

[0301] Processor 1801;

[0302] a memory 1802 for storing operations executable by the processor 1801;

[0303] The processor 1801 is configured to execute the operations to implement the content sharing control method in the embodiment of the present disclosure, for example Figure 14 or Figure 15 Follow the steps shown in .

[0304] In an exemplary embodiment, a storage medium including operations is also provided, for example, a memory 1802 including operations, and the operations can be executed by the processor 1801 of the electronic device 1800 to complete the above method. Alternatively, the storage medium can be a non-transitory computer-readable storage medium, for example, the non-transitory computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0305] Based on the same inventive concept, the embodiment of the present application further provides a terminal device 100, which can be an electronic device such as a smart phone, a tablet computer, a laptop or a PC. The aforementioned first client and the second client can both be understood as a terminal device.

[0306] See Figure 19 As shown, the terminal device 100 includes a display unit 1940, a processor 1980, and a memory 1920. The display unit 1940 includes a display panel 1941 for displaying information input by a user or information provided to a user, as well as various object selection interfaces of the terminal device 100. In the embodiment of the present application, the display panel 1941 is mainly used to display relevant operation interfaces and shortcut windows of social software installed in the terminal device 100. Optionally, the display panel 1941 can be configured in the form of an LCD (Liquid Crystal Display) or an OLED (Organic Light-Emitting Diode).

[0307] The processor 1980 is configured to read a computer program and then execute the method defined by the computer program. For example, the processor 1980 reads a social software application, thereby running the social software on the terminal device 100 and displaying the relevant operation interface of the social software on the display unit 1940. The processor 1980 may include one or more general-purpose processors and may also include one or more DSPs (Digital Signal Processors) to perform related operations to implement the technical solutions provided in the embodiments of the present application.

[0308] The memory 1920 generally includes internal memory and external memory. The internal memory may be a random access memory (RAM), a read-only memory (ROM), and a cache (CACHE), etc. The external memory may be a hard disk, an optical disk, a USB disk, a floppy disk, or a tape drive, etc. The memory 1920 is used to store computer programs and other data. The computer program includes applications corresponding to various software, etc. Other data may include data generated after the operating system or application is run, and the data includes system data (such as configuration parameters of the operating system) and user data. In the embodiment of the present application, program instructions are stored in the memory 1920, and the processor 1980 executes the program instructions stored in 1920 to implement the function of the account synchronization method discussed above.

[0309] In addition, the terminal device 100 may also include a display unit 1940 for receiving input digital information, character information, or contact touch operations / contactless gestures, as well as generating signal inputs related to user settings and function control of the terminal device 100. Specifically, in an embodiment of the present application, the display unit 1940 may include a display panel 1941. The display panel 1941, such as a touch screen, can collect user touch operations on or near it (such as operations of a target object using a finger, stylus, or any other suitable object or accessory on or on the display panel 1941) and drive corresponding connected devices according to a pre-set program. Optionally, the display panel 1941 may include two parts: a touch detection device and a touch controller. The touch detection device detects the user's touch direction and detects signals generated by the touch operation, transmitting the signals to the touch controller; the touch controller receives the touch information from the touch detection device, converts it into touch point coordinates, and then sends it to the processor 1980. It can also receive commands sent by the processor 1980 and execute them. In an embodiment of the present application, if the user selects an associated subroutine, the touch detection device in the display panel 1941 detects the touch operation, and sends a signal corresponding to the detected touch operation to the touch controller. The touch controller converts the signal into contact coordinates and sends them to the processor 1980. The processor 1980 determines the associated subroutine selected by the user based on the received contact coordinates, and controls the display panel 1941 to display an interface for entering the login account and login password, or controls the display panel 1941 to display an interface for successfully logging into the associated subroutine.

[0310] The display panel 1941 can be implemented using various types such as resistive, capacitive, infrared, and surface acoustic wave. In addition to the display unit 1940, the terminal device 100 can also include an input unit 1930, which can include but is not limited to one or more of a physical keyboard, function keys (such as volume control keys, power keys, etc.), a trackball, a mouse, and a joystick. Figure 19In the figure, the input unit 1930 includes an image input device 1931 and other input devices 1932 as an example.

[0311] In addition to the above, the terminal device 100 may also include a power supply 1990 for powering other modules, an audio circuit 1960, a near-field communication module 1970, and an RF circuit 1910. The terminal device 100 may also include one or more sensors 1950, such as an accelerometer, a light sensor, a pressure sensor, etc. The audio circuit 1960 specifically includes a speaker 1961 and a microphone 1962. For example, a user can use voice control. The terminal device 100 can collect the user's voice through the microphone 1962, can be controlled by the user's voice, and when a prompt is required, the corresponding prompt tone is played through the speaker 1961.

[0312] Based on the same inventive concept, the embodiment of the present application further provides a server 200, which may be the aforementioned business server or subprogram server.

[0313] See Figure 20 As shown, the server 200 is a general-purpose server. Components of the server 200 may include, but are not limited to, the at least one processing unit 2001, the at least one storage unit 2002, and a bus 2003 connecting different system components (including the storage unit 2002 and the processing unit 2001).

[0314] Bus 2003 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a processor or local bus using any of a variety of bus architectures.

[0315] The storage unit 2002 may include a readable medium in the form of a volatile memory, such as a random access memory (RAM) 2021 and / or a cache memory unit 2022 , and may further include a read-only memory (ROM) 2023 .

[0316] The storage unit 2002 may also include a program / utility 2025 having a set (at least one) of program modules 2024, such program modules 2024 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 may include an implementation of a network environment.

[0317] The server 200 may also communicate with one or more external devices 2004 (e.g., keyboards, pointing devices, etc.), one or more devices that enable a user to interact with the server 200, and / or any device that enables the server 200 to communicate with one or more other servers (e.g., routers, modems, etc.). Such communication may occur via an input / output (I / O) interface 2005. Furthermore, the server 200 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) via a network adapter 2006. As shown, the network adapter 2006 communicates with other modules of the server 200 via a bus 2003. It should be understood that, although not shown in the figure, other hardware and / or software modules may be used in conjunction with the server 200, including but not limited to microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0318] Based on the same inventive concept as the above-mentioned method embodiment, various aspects of the account synchronization method provided in this application can also be implemented in the form of a program product, which includes program code. When the program product is run on an electronic device, the program code is used to enable the electronic device to execute the steps in the account synchronization method according to various exemplary embodiments of the present application described above in this specification. For example, the electronic device can execute the following steps: Figure 14 or Figure 15 Steps shown.

[0319] The program product may employ any combination of one or more readable media. The readable 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, device, or component, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection with 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 disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.

[0320] The program product of the embodiment of the present application may be a portable compact disc read-only memory (CD-ROM) and include program code, and can be run on a server. However, the program product of the present application is not limited thereto. In this document, a readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with a command execution system, apparatus, or device.

[0321] A readable signal medium may include a data signal transmitted in baseband or as part of a carrier wave, which carries readable program code. Such a transmitted data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in conjunction with a command execution system, apparatus, or device.

[0322] The program code embodied on the readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0323] Although the preferred embodiments of the present application have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present application.

[0324] Obviously, those skilled in the art may make various changes and modifications to this application without departing from the spirit and scope of this application. Thus, if these modifications and variations of this application fall within the scope of the claims of this application and their equivalents, this application is intended to include these modifications and variations.

Claims

1. A method for synchronizing an account, characterized in that: Applied to a business server, the method includes: Receive a subprogram login request sent by a first client, wherein the subprogram login request carries: a first object identifier of a first object that has logged into a target application, and a target subprogram identifier of a target associated subprogram of the target application that the first object requests to log into; When it is determined based on the first object identifier and the target subprogram identifier that target historical login information has been recorded corresponding to the first object, the target historical login information is obtained, where the target historical login information indicates that the first object has logged into the target associated subprogram under the target application program through the second client; Based on the target historical login information, obtaining the login account and login password used by the first object when logging into the target-associated subprogram on the second client; Based on the login account and login password, login data is determined, and the login data is sent to the first client, so that the target associated subprogram corresponding to the login account successfully logs in to the first client.

2. The method according to claim 1, wherein Before receiving the subprogram login request sent by the first client, the method further includes: Receiving historical login information sent by the second client; wherein the historical login information is triggered after the first object performs the following operations: logging into the target application on the second client, and further logging into the target associated subprogram; The historical login information is stored in a storage area corresponding to the target application.

3. The method according to claim 1, wherein After receiving the subprogram login request sent by the first client, and before determining, based on the first object identifier and the target subprogram identifier, that target historical login information has been recorded for the first object, the method further includes: Sending identity authentication prompt information to the second client; the identity authentication prompt information is used to prompt the target object corresponding to the second client to confirm whether the first client is a secure client.

4. The method according to claim 3, wherein The method further comprises: When receiving the identity authentication confirmation information sent by the second client, determining the time interval between the time of receiving the identity authentication confirmation information and the time of sending the identity authentication prompt information; When it is determined that the time interval is not greater than the limit time interval, it is determined whether target historical login information has been recorded corresponding to the first object based on the first object identifier and the target subroutine identifier.

5. The method according to claim 1, wherein After receiving the subprogram login request sent by the first client, and before determining, based on the first object identifier and the target subprogram identifier, that target historical login information has been recorded for the first object, the method further includes: Determining device information of the first client; When it is determined that the device information belongs to a preset device information set, it is determined whether target historical login information has been recorded corresponding to the first object based on the first object identifier and the target subroutine identifier.

6. The method according to claim 1, wherein After receiving the subprogram login request sent by the first client, and before determining, based on the first object identifier and the target subprogram identifier, that target historical login information has been recorded for the first object, the method further includes: Determining biometric information corresponding to the first client; When it is determined that the biometric information belongs to a preset biometric information set, it is determined whether target historical login information has been recorded corresponding to the first object based on the first object identifier and the target subroutine identifier.

7. The method according to claim 1 or 2, wherein: After obtaining the target historical login information and before obtaining the login account and password used by the first object when logging into the target-associated subprogram on the second client, the method further includes: Determine whether the storage time of the login password reaches the time threshold; When it is determined that the storage time of the login password does not reach the time threshold, the login account and login password used by the first object when logging into the target-associated subprogram on the second client are obtained.

8. The method according to claim 7, wherein The method further comprises: When it is determined that the storage time of the login password reaches the time threshold, clearing the login password in the target historical login information; and A prompt message is sent to the second client, where the prompt message is used to prompt the client to send the historical login information again.

9. The method according to claim 1 or 2, wherein: The first client and the second client are two clients of different types.

10. The method according to claim 1, wherein If the program attribute information of the target associated subprogram is of the external cal dav type, the login data is determined based on the login account and login password, including: Sending a verification request carrying the login account and the login password to the subprogram server corresponding to the target associated subprogram; When receiving the verification success information sent by the sub-program server, sending a policy key policykey acquisition request to the sub-program server; When the policy key sent by the subprogram server is received, the business data of the login account under the target associated subprogram is obtained from the subprogram server based on the policy key, so as to determine the login data based on the business data.

11. The method according to claim 1, wherein If the program attribute information of the target associated subprogram is of exchange type, the login data is determined based on the login account and login password, including: Sending a verification request carrying the login account and the login password to the subprogram server corresponding to the target associated subprogram; When the verification success information sent by the subprogram server is received, the business data of the login account under the target associated subprogram is obtained from the subprogram server to determine the login data based on the business data.

12. The method according to claim 1, wherein Based on the login account and login password, the login data is determined, including: The login account and login password are encapsulated to determine the login data.

13. A method for synchronizing an account, characterized in that: Applied to a first client, the method includes: Sending a subprogram login request to the business server; the subprogram login request carries: a first object identifier of a first object that has logged into a target application, and a target subprogram identifier of a target associated subprogram of the target application that the first object requests to log into; Receiving login data sent by the business server, wherein the login data is determined based on a login account and login password used by the first object when logging into the target-associated subprogram on the second client; the login account and login password are obtained by the business server based on historical login information of the target corresponding to the first object identifier and the target subprogram identifier; Based on the login data, the target-related subprogram is registered under the target application program.

14. The method according to claim 8, wherein If the login data is data encapsulating the login account and login password, after receiving the login data sent by the business server and before logging into the target-associated subprogram under the target application based on the login data, the method further includes: Determine the domain name information in the login account; Based on the domain name information and a preset matching table, the program attribute information of the target associated subprogram is determined; the preset matching table includes a matching relationship between each domain name information and each program attribute information.

15. The method according to claim 14, wherein If the login data is data encapsulating the login account and login password, and the program attribute information is of an external cal dav type, then logging in the target associated subprogram under the target application based on the login data includes: Sending a verification request carrying the login account and the login password to the subprogram server corresponding to the target associated subprogram; When receiving the verification success information sent by the sub-program server, sending a policy key policykey acquisition request to the sub-program server; When the policykey sent by the subprogram server is received, the business data of the login account under the target associated subprogram is obtained from the subprogram server based on the policykey, so as to log in to the target associated subprogram under the target application based on the business data.

16. The method according to claim 14, wherein If the login data is data encapsulating the login account and login password, and the program attribute information is of exchange type, then logging in the target associated subprogram under the target application based on the login data includes: Sending a verification request carrying the login account and the login password to the subprogram server corresponding to the target associated subprogram; When the verification success information sent by the subprogram server is received, the business data of the login account under the target associated subprogram is obtained from the subprogram server to log in to the target associated subprogram under the target application based on the business data.

17. An account synchronization device, characterized in that: Applied to a business server, the device includes: A first receiving unit is configured to receive a subprogram login request sent by a first client, wherein the subprogram login request carries: a first object identifier of a first object that has logged into a target application, and a target subprogram identifier of a target associated subprogram of the target application that the first object requests to log into; a processing unit configured to, when determining based on the first object identifier and the target subprogram identifier that target historical login information has been recorded for the first object, obtain the target historical login information, wherein the target historical login information indicates that the first object has logged into the target associated subprogram under the target application program through a second client; The processing unit is further configured to obtain, based on the target historical login information, a login account and a login password used by the first object when logging into the target-associated subprogram on the second client; The first sending unit is configured to determine login data based on the login account and login password, and send the login data to the first client, so that the target associated subprogram corresponding to the login account successfully logs in to the first client.

18. An account synchronization device, characterized in that: Applied to a first client, the device includes: The second sending unit is configured to send a subprogram login request to the business server; the subprogram login request carries: a first object identifier of a first object that has logged into a target application, and a target subprogram identifier of a target associated subprogram of the target application that the first object requests to log into; a second receiving unit, configured to receive login data sent by the business server, wherein the login data is determined based on a login account and a login password used by the first object when logging into the target-associated subprogram on the second client; the login account and the login password are obtained by the business server based on historical login information of the target corresponding to the first object identifier and the target subprogram identifier; A login unit is used to log in the target-related subprogram under the target application based on the login data.

19. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the steps of the method of any one of claims 1 to 12 or the steps of the method of any one of claims 13 to 16 are implemented.

20. A computer-readable storage medium, characterized in that It includes program code. When the program product is run on an electronic device, the program code is used to enable the electronic device to execute the steps of any method described in claims 1-12 or the steps of any method described in claims 13-16.

Images