Cross-domain login state synchronization method and related device

By generating login status information on the main domain name backend server and passing it to other domain name backend servers, the problems of low security and long login caused by cookie plaintext delivery are solved, and safe and efficient cross-domain synchronous login is achieved.

CN120281497APending Publication Date: 2025-07-08TENCENT TECHNOLOGY (SHENZHEN) CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202410029792.9
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-01-08
Publication Date
2025-07-08

AI Technical Summary

Technical Problem

In the prior art, there are problems such as information leakage and low security during the cross-domain synchronous login process, and the login process takes too long.

Method used

Through the application corresponding to the main domain name and the backend server work together, login information is generated and passed, and cookies are avoided and page jumps are reduced.

Benefits of technology

Improve the security of cross-domain synchronous login, reduce the time consumption of the login process, and improve the user experience.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120281497A_ABST
    Figure CN120281497A_ABST
Patent Text Reader

Abstract

The invention relates to the technical field of computers, in particular to a cross-domain login state synchronization method and related device.The method comprises the steps that firstly, an application program corresponding to a main domain name obtains requester information in response to a triggered first login request, then the requester information is sent to a main back-end server, so that the main back-end server generates login state information, and the login state information is sent to a server; the method comprises the following steps: receiving login state information sent by a main back-end server, sending the login state information to other back-end servers, skipping to a main interface after receiving the login state information sent by the main back-end server, responding to a second login request triggered for an embedded page, and sending the second login request to a target back-end server; and finally, when the login state information sent by the target back-end server is received, skipping to the embedded page from the main interface, so that the login state information is transmitted at the back end, the requester information is not easy to leak, the security is relatively high, meanwhile, when the requester requests to log in the embedded page, multiple page skipping is not needed, and the time consumption in the login process is reduced.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular, to a method and related device for cross-domain synchronous login status. Background Art

[0002] In the design of Internet applications, the main interface of an application usually embeds multiple sub-pages that can implement different business functions, and the sub-pages and the main interface have different first-level domain names. For example, the main interface of a shopping application uses domain name A to display the home page, and multiple sub-pages can be entered through the home page. Each sub-page uses domain name B to display clothing categories and domain name C to display home appliance categories, and so on.

[0003] In the prior art, an iframe framework is usually used to implement the embedding of multiple sub-pages within the main interface of an application. Under the iframe framework, when a sub-page receives a login request from a requester, the login status information of the main interface is transmitted to the sub-page by transmitting the login status information between the main interface and the sub-page. Specifically, it is first necessary to log in to the main interface. After successfully obtaining the cookie that saves the requester information in the main interface, then jump to the authentication and authorization page of the main interface, and after the requester information passes the authentication, send the cookie to the iframe page, and then the iframe page sends the cookie to the sub-page, so as to log in to the sub-page.

[0004] However, using the above method has the following problems:

[0005] 1. The Cookie is transmitted in plain text between the main interface and the sub-page, which is likely to cause the leakage of requester information. In addition, the cookie has a long validity period, and the requester information saved in it is easily stolen, resulting in low security;

[0006] 2. There are multiple page jumps during the process of logging in to the sub-page, resulting in an overly long login process.

[0007] In view of this, a new method for cross-domain synchronous login status needs to be proposed to overcome the above defects. Summary of the Invention

[0008] This application provides a method and related device for cross-domain synchronous login status to improve the security of cross-domain synchronous login status and reduce the time consumption of the login process.

[0009] In a first aspect, an embodiment of this application provides a method for cross-domain synchronous login status, which is applied to an application program corresponding to the main domain name. The method includes:

[0010] In response to a first login request triggered for the application program, obtain the requester information;

[0011] Send the requester information to the main backend server corresponding to the main domain name, so that after the main backend server determines that the requester information passes the permission verification, it generates login state information and sends the login state information to at least one other backend server corresponding to each of the other domain names;

[0012] When receiving the login state information sent by the main backend server, jump to the main interface of the application;

[0013] In response to a second login request triggered for an embedded page corresponding to any one of the other domain names, send the second login request to the target backend server corresponding to any one of the other domain names; the embedded page is embedded in the application;

[0014] When receiving the login state information sent by the target backend server, jump from the main interface of the application to the embedded page.

[0015] In a second aspect, an embodiment of the present application provides a method for cross-domain synchronous login state, which is applied to the main backend server corresponding to the main domain name. The method includes:

[0016] Receive the requester information sent by the application based on the main domain name; the requester information is obtained after the application responds to a first login request triggered for the application;

[0017] After determining that the requester information passes the permission verification, generate login state information;

[0018] Send the login state information to the application, so that the application jumps to the corresponding main interface;

[0019] Send the login state information to at least one other backend server corresponding to each of the other domain names, so that after the target backend server corresponding to any one of the other domain names receives the second login request sent by the application, it sends the login state information to the embedded page corresponding to any one of the other domain names; the second login request is triggered for the embedded page; the embedded page is embedded in the application.

[0020] In a third aspect, an embodiment of the present application further provides a device for cross-domain synchronous login state, which is applied to the application corresponding to the main domain name. The device includes:

[0021] A first response module, configured to obtain the requester information in response to a first login request triggered for the application;

[0022] An information sending module, configured to send the requester information to the main backend server corresponding to the main domain name, so that after the main backend server determines that the requester information passes the permission verification, it generates login state information and sends the login state information to at least one other backend server corresponding to each of the other domain names;

[0023] The first receiving module is used to jump to the main interface of the application when receiving the login status information sent by the main backend server;

[0024] The second response module is used to send the second login request to the target backend server corresponding to any other domain name in response to the second login request triggered for the embedded page corresponding to any other domain name; the embedded page is embedded in the application;

[0025] The second receiving module is used to jump from the main interface of the application to the embedded page when receiving the login status information sent by the target backend server.

[0026] Optionally, in response to the first login request triggered for the application and obtaining the requester information, the first response module is further used for:

[0027] In response to the first login request triggered for the application, obtain the requester information from the pre-stored reference information set; the reference information is saved to the reference information set by the corresponding requester during registration; or,

[0028] In response to the first login request triggered for the application, call the authorized application associated with the application and obtain the requester information from the authorized information set corresponding to the authorized application.

[0029] Optionally, after responding to the first login request triggered for the application and before obtaining the requester information, the first response module is further used for:

[0030] Determine that the historical login status information of the requester does not exist in the login information set corresponding to the application, or determine that in the login information set, the historical login status information of the requester does not meet the preset time limit requirement;

[0031] Wherein, the login information is saved in the login information set by the relevant requester after successful login.

[0032] Optionally, when determining that the historical login status information of the requester in the login information set does not meet the preset time limit requirement, the first response module is further used for:

[0033] Send the historical login status information of the requester obtained from the login information set to the main backend server;

[0034] Receive the time limit verification result returned by the main backend server; the time limit verification result is sent by the main backend server after comparing the existing duration of the received historical login status information with the preset validity period;

[0035] When the time limit verification result indicates that the historical login status information has expired, delete the historical login status information in the login information set.

[0036] Optionally, in response to a second login request triggered for an embedded page corresponding to any other domain name, the second login request is sent to the target backend server corresponding to any other domain name. The second response module is further configured to:

[0037] In response to a second login request triggered for an embedded page corresponding to any other domain name, send the second login request to the main backend server; the second login request at least includes: an identification domain name preset for the embedded page;

[0038] Receive a domain name redirection response returned by the main backend server; the domain name redirection response includes any other domain name; the domain name redirection response is sent by the main backend server after determining any other domain name corresponding to the identification domain name from a preset domain name set;

[0039] Based on any other received domain name, send the second login request to the target backend server corresponding to any other domain name.

[0040] Fourthly, an embodiment of the present application further provides a device for cross-domain synchronous login state, which is applied to the main backend server corresponding to the main domain name. The device includes:

[0041] An information receiving module, configured to receive requestor information sent by an application program based on the main domain name; the requestor information is obtained by the application program in response to a first login request triggered for the application program;

[0042] A login state generation module, configured to generate login state information after determining that the requestor information passes the permission verification;

[0043] A first sending module, configured to send the login state information to the application program so that the application program jumps to the corresponding main interface;

[0044] A second sending module, configured to send the login state information to other backend servers corresponding to at least one other domain name respectively, so that after the target backend server corresponding to any other domain name receives a second login request sent by the application program, the login state information is sent to the embedded page corresponding to any other domain name; the second login request is triggered for the embedded page; the embedded page is embedded in the application program.

[0045] Optionally, after determining that the requestor information passes the permission verification and generating the login state information, the login state generation module is further configured to:

[0046] After determining that the requestor information passes the permission verification, create an allowed login identifier for the requestor information;

[0047] Use the requestor information and the allowed login identifier as the login state information.

[0048] Optionally, the requester information includes at least a login account name and a login password. If it is determined that the requester information passes the permission verification, the login state generation module is further configured to:

[0049] Determine that there is a login account name in the pre-stored reference account set; in the reference account set, the reference account name and the corresponding reference password are stored in an associated manner; the reference account is sent by the application program to the main backend server after the corresponding requester completes registration.

[0050] When the login password matches the reference password corresponding to the login account name in the reference account set, it is determined that the requester passes the permission verification.

[0051] In a fifth aspect, an embodiment of the present application provides an electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, the method according to any one of the first aspect and the second aspect is implemented.

[0052] In a sixth aspect, an embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the method according to any one of the first aspect and the second aspect are implemented.

[0053] In a seventh aspect, an embodiment of the present application provides a computer program product. When the computer program product is called by a computer, the computer is enabled to execute the methods according to the first aspect and the second aspect.

[0054] An embodiment of the present application provides a method for cross-domain synchronous login state. First, the application program corresponding to the main domain name responds to the triggered first login request, obtains the requester information, and then sends the requester information to the main backend server corresponding to the main domain name, so that after the main backend server determines that the requester information passes the permission verification, it generates login state information and sends the login state information to at least one other backend server corresponding to each other domain name. In this way, after the requester information passes the permission verification, the main backend server synchronizes the login state information to other backend servers, and the login state information is transmitted at the backend. The requester information included in the login state information is not easily leaked, and the security is relatively high;

[0055] Then, after the application program receives the login state information sent by the main backend server, it jumps to the main interface of the application program; in response to the second login request triggered by the embedded page corresponding to the other domain name, it sends the second login request to the target backend server corresponding to the other domain name; finally, when receiving the login state information sent by the target backend server, it jumps from the main interface of the application program to the embedded page. In this way, when the requester requests to log in to the embedded page, it can log in successfully at one time without multiple page jumps, reducing the time consumption during the login process. Description of the Drawings

[0056] Figure 1 This is a schematic diagram of the application scenario in the embodiment of the present application;

[0057] Figure 2 This is the first flow schematic diagram of a method for cross - domain synchronous login state in the embodiment of the present application;

[0058] Figure 3 This is the first logical schematic diagram of a method for cross - domain synchronous login state in the embodiment of the present application;

[0059] Figure 4 This is the schematic diagram of the application program interface jump in the embodiment of the present application;

[0060] Figure 5 This is the second logical schematic diagram of a method for cross - domain synchronous login state in the embodiment of the present application;

[0061] Figure 6 This is the flow schematic diagram of a domain name redirection method in the embodiment of the present application;

[0062] Figure 7 This is the logical schematic diagram of a domain name redirection method in the embodiment of the present application;

[0063] Figure 8 This is the second flow schematic diagram of a method for cross - domain synchronous login state in the embodiment of the present application;

[0064] Figure 9 This is the interaction framework schematic diagram of a method for cross - domain synchronous login state in the embodiment of the present application;

[0065] Figure 10 This is the structural schematic diagram of a device for cross - domain synchronous login state in the embodiment of the present application;

[0066] Figure 11 This is the structural schematic diagram of another device for cross - domain synchronous login state in the embodiment of the present application;

[0067] Figure 12 This is the structural schematic diagram of an electronic device in the embodiment of the present application. Detailed implementation manners

[0068] To make the objectives, technical solutions, and advantages of the embodiments of the present application clearer, the technical solutions of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the technical solutions of the present application, rather than all of them. Based on the embodiments described in this application document, all other embodiments obtained by those of ordinary skill in the art without making creative efforts belong to the scope protected by the technical solutions of the present application.

[0069] In the description and claims of this application and the above-mentioned drawings, terms such as "first", "second", etc. are used to distinguish similar objects and do not necessarily describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances so that the embodiments of the present invention described here can be implemented in an order other than those illustrated or described here.

[0070] In the embodiments of this application, the term "module" or "unit" refers to a computer program with a predetermined function or a part of a computer program, which works together with other related parts to achieve a predetermined goal and can be implemented in whole or in part by using software, hardware (such as a processing circuit or a memory), or a combination thereof. Similarly, a processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be a part of an overall module or unit that includes the function of that module or unit.

[0071] The following explains some terms in the embodiments of this application to facilitate the understanding of those skilled in the art.

[0072] (1) Top-level domain name: Also known as the top-level domain, common ones include ".com", ".org", ".net", ".cn", etc.

[0073] (2) iframe: An HTML tag, full name Inline Frame, that is, an inline frame, which can embed other pages or documents in a web page and display the content of other pages in the form of a frame on the current page.

[0074] (3) cookie: A small text file, which is data (usually encrypted) stored on the user's local terminal by some websites to identify the user's identity and record Session information, and is information temporarily or permanently saved by the user's client computer.

[0075] (4) Login state: A credential used by the server to distinguish the user's identity and record the user's login status.

[0076] The following briefly introduces the design concept of the embodiments of this application:

[0077] With the rapid development of Internet technology, many large-scale applications implement business logics by embedding multiple sub-pages. In the prior art, an iframe framework is usually adopted to embed multiple sub-pages within the main interface of an application. Under the iframe framework, when a sub-page receives a login request from a requester, the login state information of the main interface is transmitted to the sub-page by transmitting the login state information between the main interface and the sub-page. Specifically, it is first necessary to log in to the main interface. After successfully obtaining the cookie that stores the requester information saved on the main interface, the cookie is sent to the iframe page, and then the iframe page sends the cookie to the sub-page, thereby logging in to the sub-page.

[0078] However, by adopting this method, the Cookie is transmitted in plain text between the main interface and the sub-page, which is likely to cause the leakage of the requester information. Moreover, the cookie has a relatively long validity period, and the requester information stored therein is easily stolen, resulting in low security; in addition, there are multiple page jumps during the process of logging in to the sub-page, causing the login process to take too long.

[0079] In view of this, in the embodiments of the present application, a method and related device for cross-domain synchronous login state are proposed.

[0080] In the embodiments of the present application, first, the application program corresponding to the main domain name responds to the triggered first login request, obtains the requester information, and then sends the requester information to the main backend server corresponding to the main domain name, so that after the main backend server determines that the requester information passes the permission verification, it generates login state information and sends the login state information to at least one other backend server corresponding to each of the other domain names. In this way, after the requester information passes the permission verification, the main backend server synchronizes the login state information to other backend servers, and the login state information is transmitted at the backend. The requester information included in the login state information is not easily leaked, and the security is relatively high; then, after receiving the login state information sent by the main backend server, the application program jumps to the main interface of the application program; in response to the triggered second login request for the embedded page corresponding to the other domain name, the second login request is sent to the target backend server corresponding to the other domain name; finally, when receiving the login state information sent by the target backend server, the main interface of the application program jumps to the embedded page. In this way, when the requester requests to log in to the embedded page, the login can be successful at one time without multiple page jumps, reducing the time consumption of the login process.

[0081] Moreover, in the embodiments of the present application, in response to a triggered first login request, when it is determined that there is no historical login state information of the requester in the login information set corresponding to the application program, or when it is determined that the historical login state information of the requester in the login information set does not meet the preset time limit requirement, the requester information is obtained from the pre-stored reference information set or by invoking an authorized application associated with the application program. In this way, the requester information is obtained only under set conditions. When there is login state information that meets the preset time limit requirement in the login information set, direct login can be performed, reducing the time consumed in the login process, avoiding the inconvenience caused by the user's repeated login, and improving the user experience.

[0082] Further, the main backend server can perform a time limit verification on the historical login state information of the requester. When the login state information has expired, the historical login information is deleted. In this way, by adopting the method of verifying the validity period of the login state information, the verification security can be further improved.

[0083] The preferred embodiments of the present application are described below in conjunction with the accompanying drawings of 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. And without conflict, the embodiments of the present application and the features in the embodiments can be combined with each other.

[0084] As Figure 1 shown, it is a schematic diagram of an application scenario in the embodiments of the present application. This application scenario includes a terminal device 110, a main backend server 120, and other backend servers 130, which can communicate with each other through a communication network. An application program with multiple sub-pages is installed on the terminal device 110. The main backend server is the server corresponding to the application program domain name, and the other backend servers 130 are the servers corresponding to the domain names of certain sub-pages in the application program. The requester can trigger a login request for the application program on the terminal device 110. After successful login, the main interface of the application program is entered. A login request for the sub-page can be triggered on the main interface. The main backend server 120 can transmit the login state information to other backend servers, thereby realizing cross-domain login state synchronization.

[0085] In an alternative embodiment, the communication network is a wired network or a wireless network. The terminal device 110 and the servers 120 and 130 can be directly or indirectly connected through wired or wireless communication methods, which are not limited in the present application.

[0086] In the embodiments of the present application, the terminal device 110 is an electronic device used by a user, and this electronic device can be a computer device capable of installing application programs such as a personal computer, a mobile phone, a tablet computer, a notebook, an e-book reader, etc. The servers 120 and 130 can be independent physical servers, or a server cluster or a distributed system composed of multiple physical servers. They can also be cloud servers providing 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.

[0087] Next, in combination with the above-described application scenario, the method for generating a dialogue provided by the exemplary embodiment of the present application will be described with reference to the accompanying drawings. It should be noted that the above application scenario is only shown for the convenience of understanding the spirit and principle of the present application, and the embodiments of the present application are not limited in this regard.

[0088] Refer to Figure 2 and Figure 3 shown, which are respectively a schematic flowchart of a method for cross-domain synchronous login state and a schematic flowchart in the embodiments of the present application. Next, in combination with Figure 2 and Figure 3 , the specific steps to be executed will be described in detail:

[0089] Step 21: In response to a first login request triggered for an application program, obtain the information of the requester.

[0090] In the embodiments of the present application, as Figure 4 shown, the requester enters a certain lifestyle application program on the terminal device. The login interface of the application program displays entry points for relevant sub-pages such as food, hotels and homestays, leisure and entertainment, and train tickets. The requester clicks "Log in immediately" to trigger the first login request. Then, when historical login state information that meets the preset time limit condition is found in the login information set corresponding to the application program, the historical login state information is directly used for login. Among them, the historical login state information is usually recorded using cookies.

[0091] When it is determined that there is no historical login state information of the requester in the login information set corresponding to the application program, or when it is determined that the historical login state information of the requester in the login information set does not meet the preset time limit requirement, the information of the requester is obtained again.

[0092] In an embodiment of the present application, the login information set contains the login status information of multiple requesters who have logged in to the application. Each piece of login status information contains a login account name, a login password, and the most recent login time. The application determines through the main backend server that the historical login status information of the requester in the login information set does not meet the preset time limit requirement, which specifically includes the following steps 211-213:

[0093] Step 211: Send the historical login status information of the requester obtained from the login information set to the main backend server.

[0094] In an embodiment of the present application, after the application sends the obtained historical login status information of the requester to the main backend server, the main backend server performs a time limit verification on the historical login status information. A preset validity period is saved on the main backend server. The main backend server obtains the existing duration of the historical login status information based on the current time and the most recent login time. If the existing duration is greater than the validity period, the login status information fails the time limit verification; if the existing duration is not greater than the login period, the login status information passes the time limit verification.

[0095] Step 212: Receive the time limit verification result returned by the main backend server.

[0096] Among them, the time limit verification result is sent by the main backend server after comparing the existing duration of the received historical login status information with the preset validity period;

[0097] In an embodiment of the present application, the time limit verification result returned by the main backend server contains a flag bit "1" or "0", where "1" indicates passing the time limit verification and "0" indicates failing the time limit verification.

[0098] Step 213: When the time limit verification result indicates that the historical login status information has expired, delete the historical login status information in the login information set.

[0099] In an embodiment of the present application, when there is a flag bit "1" in the time limit verification result, the application can use the historical login status information to log in to the application, and the application jumps to the main interface; when there is a flag bit "0" in the verification result, it indicates that the historical login status information is unavailable, and the corresponding historical login status information in the login information set is deleted. In this way, it can be avoided that when the user logs in next time, the application sends the historical login status information that has expired to the main backend server again, resulting in repeated and invalid time limit verifications.

[0100] Further, there are two ways for the application to obtain the requester information:

[0101] 1. In response to a first login request triggered for the application, obtain the requester information from the pre-stored reference information set;

[0102] Among them, the reference information is saved to the reference information set by the corresponding requester during registration;

[0103] In the embodiments of the present application, when the requester registers an application, the registered account name and password are saved to the local storage of the terminal device as the reference information set. Therefore, as Figure 4 shown, after the requester clicks "Log in immediately" to trigger the first login request, the application will automatically retrieve the requester information in the reference information set, and the requester information at least includes the login account name and password.

[0104] 2. In response to the first login request triggered for the application, call the authorized application associated with the application, and obtain the requester information from the authorized information set corresponding to the authorized application.

[0105] In the embodiments of the present application, Figure 4 the life application in

[0106] Step 22: Send the requester information to the main backend server corresponding to the main domain name, so that after the main backend server determines that the requester information passes the permission verification, generate login state information, and send the login state information to the other backend servers corresponding to at least one other domain name respectively.

[0107] In the embodiments of the present application, the application and the embedded sub-pages use different domain names, and the resources corresponding to each domain name are managed by different backend servers. The application sends a first login request to the main backend server, and the request header contains the requester information and the main domain name. After the main backend server determines that the requester information passes the permission verification, it generates login state information. Among them, the login state information includes the requester information, the permission to log in flag, and the validity period corresponding to the login state information. The main backend server sends the login state information to the other backend servers corresponding to each embedded sub-page to achieve the synchronization of the login state.

[0108] For example, refer to Figure 5As shown, after the main back-end server verifies the permission of the requester information sent by the application, it creates a session object for the requester to store the data corresponding to the main domain name. The session object corresponds to a unique identifier sessionID. The main back-end server sends the requester information, sessionID, and validity period as cookie login status information to each other back-end server and the application, where the sessionID is used as the allowed login identifier.

[0109] Step 23: When receiving the login status information sent by the main back-end server, jump to the main interface of the application.

[0110] In the embodiment of the present application, the application receives the login request response returned by the main back-end server, which contains cookie login status information. The application saves the cookie login status information to the local storage of the terminal device, obtains the sessionID in the cookie, and sends a data acquisition request carrying the sessionID to the main back-end server. After receiving the data acquisition request, the main back-end server finds the corresponding session object according to the sessionID, and sends the main interface file corresponding to the session object to the application. Then, the application is based on the main interface file to perform Figure 4 the display of the main interface of the application as shown in

[0111] Step 24: In response to a second login request triggered for an embedded page corresponding to any other domain name, send the second login request to the target back-end server corresponding to any other domain name.

[0112] Among them, the embedded page is embedded in the application.

[0113] In the embodiment of the present application, after the requester enters the application login interface, a second login request can be triggered by clicking the entry icon of an embedded page. After that, perform a 302 redirect as shown in Figure 6 and Figure 7 and specifically execute the following steps:

[0114] Step 241: In response to a second login request triggered for an embedded page corresponding to any other domain name, send the second login request to the main back-end server.

[0115] Among them, the second login request at least includes: the identification domain name preset for the embedded page.

[0116] In the embodiment of the present application, a corresponding identification domain name is set for each embedded page in the application. For example, for Figure 4For the "train ticket" embedded page shown, with the identification domain name being www.ticket.com, after the user clicks the "train ticket" entry on the main interface of the application, the application sends a second login request carrying www.ticket.com to the main backend server to request data resources.

[0117] Step 242: Receive the domain name redirection response returned by the main backend server.

[0118] Among them, the domain name redirection response contains any one of other domain names. The domain name redirection response is sent by the main backend server after determining any one of the other domain names corresponding to the identification domain name from the preset domain name set.

[0119] In the embodiment of the present application, for each embedded page of the application in the main backend server, the identification domain name and the real domain name are associated and stored in the domain name set. After receiving the second login request sent by the application, the main backend server matches the identification domain name www.ticket.com with the domain name set to obtain the real domain name www.train.com corresponding to www.ticket.com.

[0120] In this way, when the resource address corresponding to a certain embedded page in the application changes, only the real domain name corresponding to the sub-page needs to be changed on the backend server, without changing the identification domain name on each terminal device, which simplifies the steps of domain name setting and improves the efficiency of application operation and maintenance.

[0121] Step 243: Based on any one of the other domain names received, send the second login request to the target backend server corresponding to any one of the other domain names.

[0122] In the embodiment of the present application, the application determines the target backend server based on the real domain name www.train.com and sends a second login request to the target backend server. The second login request contains a sessionID. The target backend server matches the sessionID sent by the application with the sessionID sent by the main backend server. If the match is successful, it proves that the embedded page corresponding to www.train.com has the permission of synchronous login state. Then, it obtains the validity period from the login state information and performs a time limit verification on the login state information. When it is determined that the login state information does not exceed the validity period, it sends a login request response to the application, which contains the login state information composed of the login account name, login password, and sessionID.

[0123] Step 25: When receiving the login state information sent by the target backend server, the main interface of the application jumps to the embedded page.

[0124] In an embodiment of the present application, after the application receives the login request response, it sends a sub-page data acquisition request to the target back-end server, which includes the real domain name www.train.com. The target back-end server returns the corresponding embedded page file, and the application jumps to the Figure 4 embedded page shown.

[0125] On the other hand, an embodiment of the present application also provides another method for cross-domain synchronization of the login state, which is applied to the main back-end server and specifically executed as Figure 8 shown in the steps:

[0126] Step 81: Receive the requester information sent by the application based on the main domain name.

[0127] Among them, the requester information is obtained after the application responds to the first login request triggered for the application.

[0128] In an embodiment of the present application, the main back-end server receives the login request sent by the application, which includes the requester information and the main domain name.

[0129] Step 82: After determining that the requester information passes the permission verification, generate the login state information.

[0130] Specifically, the requester information at least includes the login account name and the login password. A reference account set is pre-stored in the main back-end server. In the reference account set, the reference account name and the reference password are stored in an associated manner. The reference account is sent by the application to the main back-end server after the corresponding requester registration is completed.

[0131] Determining that the requester information passes the permission verification is specifically implemented according to the following steps:

[0132] First, determine that there is a login account name in the pre-stored reference account set. Then, when the login password matches the reference password corresponding to the login account name in the reference account set, determine that the requester passes the permission verification.

[0133] In an embodiment of the present application, when the requester information fails to pass the permission verification, the main back-end server sends a prompt message indicating that the permission verification fails to the application, and the requester re-enters the login account name and the login password, and the application sends them to the main back-end server again for permission verification.

[0134] In an embodiment of the present application, after the main back-end server determines that the requester information passes the permission verification, it creates an allow-login flag and generates the login state information. Among them, the login state information includes the requester information, the allow-login flag, and the validity period corresponding to the login state information.

[0135] For example, after the main back-end server verifies the permission of the requester information sent by the application, it creates a session object for the requester to store the data corresponding to the main domain name. The session object corresponds to a unique identifier sessionID. The main back-end server sends the requester information, sessionID, and validity period to the application as cookie login status information, where the sessionID is used as the allowed login identifier.

[0136] Step 83: Send the login status information to the application so that the application can jump to the corresponding main interface.

[0137] In the embodiment of the present application, the main back-end server sends a login request response to the application, which includes cookie login status information, and then receives a data acquisition request sent by the application. After receiving the data acquisition request, the main back-end server finds the corresponding session object according to the sessionID and sends the main interface file corresponding to the session object to the application.

[0138] Step 83: Send the login status information to at least one other back-end server corresponding to each other domain name, so that after any target back-end server corresponding to an other domain name receives a second login request sent by the application, it sends the login status information to an embedded page corresponding to any other domain name.

[0139] Among them, the second login request is triggered for the embedded page; the embedded page is embedded in the application.

[0140] In the embodiment of the present application, the main back-end server sends the cookie login status information to each other back-end server corresponding to each embedded page. When the requester clicks on the entry of any embedded page on the main interface of the application and triggers the second login request, the application will send a login request carrying the sessionID to the target back-end server. The target back-end server matches the sessionID sent by the application with the sessionID sent by the main back-end server. If the match is successful, it proves that the embedded page has the permission to synchronize the login status, and then obtains the validity period from the login status information to verify the time limit of the login status information. When it is determined that the login status information has not exceeded the validity period, a login request response is sent to the application, which includes the login status information composed of the login account name, login password, and sessionID.

[0141] Further, the embodiment of the present application also provides an interaction flow chart for cross-domain synchronization of login status. Refer to Figure 9 As shown below, the specific steps are described in detail:

[0142] Step 901: The application responds to a first login request triggered for the application;

[0143] Step 902: The application determines that there is no historical login state information of the requester in the set of login information corresponding to the application, or determines that the historical login state information of the requester in the set of login information does not meet the preset time limit requirement;

[0144] Step 903: The application obtains the requester information from the pre-stored set of reference information or calls an authorized application associated with the application;

[0145] Step 904: The application sends the requester information to the main backend server;

[0146] Step 905: The main backend server performs a permission verification on the requester information;

[0147] Step 906: After the requester information passes the permission verification, the main backend server generates login state information;

[0148] Step 907: The main backend server sends the login state information to other backend servers and applications corresponding to other domain names;

[0149] Step 908: The application jumps to the main interface;

[0150] Step 909: The application responds to a second login request triggered for an embedded page corresponding to any other domain name;

[0151] Step 910: The application sends the second login request carrying the identifying domain name to the main backend server;

[0152] Step 911: The main backend server determines the real domain name corresponding to the identifying domain name;

[0153] Step 912: The main backend server sends the real domain name to the application;

[0154] Step 913: Based on the real domain name, the application sends the second login request to the corresponding target backend server;

[0155] Step 914: The target backend server sends the login state information to the application;

[0156] Step 915: The application jumps to the embedded page.

[0157] In addition, although the operations of the method of the present application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step for execution, and / or one step may be decomposed into multiple steps for execution.

[0158] Based on the same inventive concept, referring to Figure 10 as shown, an embodiment of the present application further provides a device for cross-domain synchronous login state, and the device includes:

[0159] A first response module 1001, configured to obtain requester information in response to a first login request triggered for an application;

[0160] An information sending module 1002, configured to send the requester information to a main back-end server corresponding to the main domain name, so that after the main back-end server determines that the requester information passes the permission verification, generate login state information, and send the login state information to at least one other back-end server corresponding to each of the other domain names;

[0161] A first receiving module 1003, configured to jump to the main interface of the application when receiving the login state information sent by the main back-end server;

[0162] A second response module 1004, configured to send a second login request to a target back-end server corresponding to any one of the other domain names in response to a second login request triggered for an embedded page corresponding to any one of the other domain names; the embedded page is embedded in the application;

[0163] A second receiving module 1005, configured to jump from the main interface of the application to the embedded page when receiving the login state information sent by the target back-end server.

[0164] Optionally, in response to a first login request triggered for an application and obtaining requester information, the first response module 1001 is further configured to:

[0165] In response to a first login request triggered for an application, obtain the requester information from a pre-stored reference information set; the reference information is saved to the reference information set by the corresponding requester during registration; or,

[0166] In response to a first login request triggered for an application, call an authorized application associated with the application, and obtain the requester information from an authorization information set corresponding to the authorized application.

[0167] Optionally, after responding to a first login request triggered for an application and before obtaining the requester information, the first response module 1001 is further configured to:

[0168] It is determined that the historical login state information of the requester does not exist in the set of login information corresponding to the application, or it is determined that, in the set of login information, the historical login state information of the requester does not meet the preset time limit requirement;

[0169] Wherein, the login information is saved in the set of login information by the relevant requester after successful login.

[0170] Optionally, when it is determined that, in the set of login information, the historical login state information of the requester does not meet the preset time limit requirement, the first response module 1001 is further configured to:

[0171] Send the historical login state information of the requester obtained from the set of login information to the main back-end server;

[0172] Receive the time limit verification result returned by the main back-end server; the time limit verification result is sent by the main back-end server after comparing the existing duration of the received historical login state information with the preset validity period;

[0173] When the time limit verification result indicates that the historical login state information has expired, delete the historical login state information in the set of login information.

[0174] Optionally, in response to a second login request triggered for an embedded page corresponding to any other domain name, send the second login request to the target back-end server corresponding to any other domain name, and the second response module 1004 is further configured to:

[0175] In response to a second login request triggered for an embedded page corresponding to any other domain name, send the second login request to the main back-end server; the second login request at least includes: the identification domain name preset for the embedded page;

[0176] Receive the domain name redirection response returned by the main back-end server; the domain name redirection response includes any other domain name; the domain name redirection response is sent by the main back-end server after determining any other domain name corresponding to the identification domain name from the preset set of domain names;

[0177] Based on the received any other domain name, send the second login request to the target back-end server corresponding to any other domain name.

[0178] Refer to Figure 11 As shown, an embodiment of the present application further provides another device for cross-domain synchronous login state, and the device includes:

[0179] An information receiving module 1101, configured to receive the requester information sent by the application based on the main domain name; the requester information is obtained by the application after responding to a first login request triggered for the application;

[0180] The login state generation module 1102 is configured to generate login state information after determining that the requester information passes the permission verification;

[0181] The first sending module 1103 is configured to send the login state information to the application program so that the application program jumps to the corresponding main interface;

[0182] The second sending module 1104 is configured to send the login state information to at least one other backend server corresponding to each of the other domain names, so that after receiving the second login request sent by the application program, the target backend server corresponding to any one of the other domain names sends the login state information to the embedded page corresponding to any one of the other domain names; the second login request is triggered for the embedded page; the embedded page is embedded in the application program.

[0183] Optionally, after determining that the requester information passes the permission verification and generating the login state information, the login state generation module 1102 is further configured to:

[0184] After determining that the requester information passes the permission verification, create an allow-login identifier for the requester information;

[0185] Use the requester information and the allow-login identifier as the login state information.

[0186] Optionally, the requester information includes at least a login account name and a login password. After determining that the requester information passes the permission verification, the login state generation module 1102 is further configured to:

[0187] Determine that there is a login account name in the pre-stored reference account set; in the reference account set, the reference account name and the corresponding reference password are stored in an associated manner; the reference account is sent by the application program to the main backend server after the corresponding requester completes registration.

[0188] When the login password matches the reference password corresponding to the login account name in the reference account set, determine that the requester passes the permission verification.

[0189] Based on the same technical concept, an embodiment of the present application further provides an electronic device, and this electronic device can implement the method flow of cross-domain synchronous login state provided in the above embodiments of the present application.

[0190] In one embodiment, the electronic device may be a server, or a terminal device or other electronic devices.

[0191] Refer to Figure 12 As shown, the electronic device may include:

[0192] At least one processor 1201 and a memory 1202 connected to the at least one processor 1201. In the embodiments of the present application, the specific connection medium between the processor 1201 and the memory 1202 is not limited. Figure 12 Taking the connection between the processor 1201 and the memory 1202 through the bus 1200 as an example. The bus 1200 is Figure 12 shown as a thick line. The connection manners between other components are only for illustrative purposes and are not limiting. The bus 1200 can be divided into an address bus, a data bus, a control bus, etc. For the convenience of representation, Figure 12 it is only shown as a thick line, but it does not mean that there is only one bus or one type of bus. Alternatively, the processor 1201 can also be called a controller, and the name is not limited.

[0193] In the embodiments of the present application, the memory 1202 stores instructions executable by the at least one processor 1201. By executing the instructions stored in the memory 1202, the at least one processor 1201 can execute a method for cross-domain synchronous login state described above. The processor 1201 can implement Figure 10 and Figure 11 the functions of each module in the device shown.

[0194] Among them, the processor 1201 is the control center of the device, and can connect various parts of the entire control device through various interfaces and lines. By running or executing the instructions stored in the memory 1202 and calling the data stored in the memory 1202, various functions of the device and process data, so as to monitor the device as a whole.

[0195] In a possible design, the processor 1201 may include one or more processing units. The processor 1201 may integrate an application processor and a modem processor. Among them, the application processor mainly processes the operating system, user interface, application programs, etc., and the modem processor mainly processes wireless communication. It can be understood that the above modem processor may not be integrated into the processor 1201. In some embodiments, the processor 1201 and the memory 1202 can be implemented on the same chip, and in some embodiments, they can also be separately implemented on independent chips.

[0196] The processor 1201 may be a general-purpose processor, such as a CPU, a digital signal processor, an application-specific integrated circuit, a field-programmable gate array, or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, and can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of the present application. The general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of a method for cross-domain synchronous login state disclosed in combination with the embodiments of the present application may be directly embodied as being executed by a hardware processor, or executed by a combination of hardware and software modules in the processor.

[0197] The memory 1202, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. The memory 1202 may include at least one type of storage medium, for example, it may include flash memory, a hard disk, a multimedia card, a card-type memory, a random access memory (RAM), a static random access memory (SRAM), a programmable read-only memory (PROM), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic memory, a magnetic disk, an optical disk, and so on. The memory 1202 is any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 1202 in the embodiments of the present application may also be a circuit or any other device capable of implementing a storage function, for storing program instructions and / or data.

[0198] By designing and programming the processor 1201, the code corresponding to the method for cross-domain synchronous login state introduced in the foregoing embodiments can be solidified into the chip, so that the chip can execute Figure 2 and Figure 8 the steps of the method for cross-domain synchronous login state of the embodiments shown. How to design and program the processor 1201 is a well-known technology to those skilled in the art and will not be elaborated here.

[0199] Based on the same inventive concept, the embodiments of the present application also provide a storage medium that stores computer instructions, and when the computer instructions are run on a computer, the computer is caused to execute the method for cross-domain synchronous login state discussed above.

[0200] In some possible embodiments, various aspects of a method for cross-domain synchronous login states provided by the present application may also be implemented in the form of a program product, which includes program code. When the program product runs on a device, the program code is used to cause the control device to execute the steps in a method for cross-domain synchronous login states according to various exemplary embodiments of the present application described above in this specification.

[0201] It should be noted that although several units or subunits of the device are mentioned in the above detailed description, this division is merely exemplary and not mandatory. In fact, according to the embodiments of the present application, the features and functions of two or more of the above-described units may be embodied in one unit. Conversely, the features and functions of one unit described above may be further divided and embodied by multiple units.

[0202] In addition, although the operations of the method of the present application are described in a specific order in the drawings, this does not require or imply that these operations must be performed in that specific order, or that all the shown operations must be performed to achieve the desired result. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step for execution, and / or one step may be decomposed into multiple steps for execution.

[0203] Those skilled in the art should understand that the embodiments of the present application may be provided as a method, a system, or a computer program product. Therefore, the present application may be implemented in the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application may be implemented in the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0204] The present application is described with reference to the flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to the present application. It should be understood that each flow and / or block in the flowchart and / or block diagram, and the combination of flows and / or blocks in the flowchart and / or block diagram, may be implemented by computer program instructions. These computer program instructions may be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing device generate a device for implementing the functions specified in Figure 1 one process or multiple processes and / or blocks Figure 1 one block or multiple blocks.

[0205] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce a manufacture including instruction means embodying the functionality specified in the flowchart(s) Figure 1 one or more flowcharts and / or block diagrams Figure 1 or blocks thereof.

[0206] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable apparatus provide steps for implementing the functionality specified in the flowchart(s) Figure 1 one or more flowcharts and / or block diagrams Figure 1 or blocks thereof.

[0207] It will be apparent to those skilled in the art that various modifications and variations can be made to the present application without departing from the spirit and scope of the application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalent technologies, the present application is also intended to cover these modifications and variations.

Claims

1. A method for cross - domain synchronous login state, characterized in that, The application for the application corresponding to the main domain name includes: In response to a first login request triggered for the application, obtain requester information; Send the requester information to the main backend server corresponding to the main domain name, so that after the main backend server determines that the requester information passes the permission verification, generate login state information and send the login state information to the other backend servers corresponding to at least one other domain name respectively; When receiving the login state information sent by the main backend server, jump to the main interface of the application; In response to a second login request triggered for an embedded page corresponding to any other domain name, send the second login request to the target backend server corresponding to the any other domain name; the embedded page is embedded in the application; When receiving the login state information sent by the target backend server, jump from the main interface of the application to the embedded page.

2. The method according to claim 1, characterized in that The step of, in response to a first login request triggered for the application, obtaining requester information includes: In response to a first login request triggered for the application, obtain requester information from a pre-stored reference information set; the reference information is saved to the reference information set by the corresponding requester during registration; or, In response to a first login request triggered for the application, call an authorized application associated with the application and obtain requester information from the authorized information set corresponding to the authorized application.

3. The method according to claim 1, characterized in that, Before obtaining the requester information after responding to the first login request triggered for the application, it further includes: Determine that there is no historical login state information of the requester in the login information set corresponding to the application, or determine that the historical login state information of the requester in the login information set does not meet the preset time limit requirement; Wherein, the login information is saved in the login information set by the relevant requester after successful login.

4. The method according to claim 3, wherein The step of determining that the historical login state information of the requester in the login information set does not meet the preset time limit requirement includes: Send the historical login state information of the requester obtained from the login information set to the main backend server; Receive the time limit verification result returned by the main backend server; the time limit verification result is sent by the main backend server after comparing the existing duration of the received historical login state information with the preset validity period; When the time limit verification result indicates that the historical login state information has expired, delete the historical login state information in the login information set.

5. The method according to any one of claims 1-4, characterized in that, The step of, in response to a second login request triggered for an embedded page corresponding to any other domain name, sending the second login request to the target backend server corresponding to the any other domain name includes: In response to a second login request triggered for an embedded page corresponding to any other domain name, send the second login request to the main backend server; at least included in the second login request is: the identification domain name preset for the embedded page; Receive the domain name redirection response returned by the main backend server; the domain name redirection response contains any one of the other domain names; the domain name redirection response is sent by the main backend server after determining any one of the other domain names corresponding to the identification domain name from a preset domain name set; Based on any one of the other domain names received, send the second login request to the target backend server corresponding to any one of the other domain names.

6. A method for cross - domain synchronous login state, characterized in that, Applied to the main backend server corresponding to the main domain name, including: Receive the requester information sent by the application program based on the main domain name; the requester information is obtained by the application program after responding to the first login request triggered for the application program; Generate login state information after determining that the requester information passes the permission verification; Send the login state information to the application program so that the application program jumps to the corresponding main interface; Send the login state information to the other backend servers corresponding to at least one other domain name respectively, so that when the target backend server corresponding to any one of the other domain names receives the second login request sent by the application program, the login state information is sent to the embedded page corresponding to any one of the other domain names; the second login request is triggered for the embedded page; the embedded page is embedded in the application program.

7. The method according to claim 6, wherein The generating login state information after determining that the requester information passes the permission verification includes: Create an allowed login identifier for the requester information after determining that the requester information passes the permission verification; Use the requester information and the allowed login identifier as the login state information.

8. The method according to claim 7, wherein The requester information includes at least a login account name and a login password; Then the determining that the requester information passes the permission verification includes: Determine that the login account name exists in the pre-stored reference account set; in the reference account set, the reference account name and the corresponding reference password are stored in association; the reference account is sent by the application program to the main backend server after the corresponding requester completes registration; When the login password matches the reference password corresponding to the login account name in the reference account set, determine that the requester passes the permission verification.

9. A device for cross-domain synchronous login state, characterized in that, Applied to the application program corresponding to the main domain name, including: A first response module, configured to obtain requester information in response to a first login request triggered for the application program; An information sending module, configured to send the requester information to the main backend server corresponding to the main domain name, so that the main backend server generates login state information after determining that the requester information passes the permission verification, and sends the login state information to the other backend servers corresponding to at least one other domain name respectively; A first receiving module, configured to jump to the main interface of the application program when receiving the login state information sent by the main backend server; A second response module, configured to send the second login request to a target backend server corresponding to any one of the other domain names in response to a second login request triggered for an embedded page corresponding to any one of the other domain names; the embedded page is embedded in the application. A second receiving module, configured to, when receiving the login status information sent by the target backend server, cause the main interface of the application to jump to the embedded page.

10. A device for cross-domain synchronous login state, characterized in that, Applied to a main backend server corresponding to a main domain name, including: An information receiving module, configured to receive requester information sent by the application based on the main domain name; the requester information is obtained after the application responds to a first login request triggered for the application. A login status generation module, configured to generate login status information after determining that the requester information passes the permission verification. A first sending module, configured to send the login status information to the application, so that the application jumps to the corresponding main interface. A second sending module, configured to send the login status information to other backend servers corresponding to at least one other domain name respectively, so that, after receiving the second login request sent by the application, a target backend server corresponding to any one of the other domain names sends the login status information to the embedded page corresponding to any one of the other domain names; the second login request is triggered for the embedded page; the embedded page is embedded in the application.

11. An electronic device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the processor executes the computer program, the method described in any one of claims 1-8 is implemented.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, the steps of the method described in any one of claims 1-8 are implemented.

13. A computer program product, characterized in that, When the computer program product is called by a computer, the computer is caused to execute the method described in any one of claims 1-8.