Session sharing method, device, equipment, medium and product

Abstract

The invention discloses a session sharing method and device, equipment, a medium and a product, and the method comprises the steps: obtaining session verification information of a first session corresponding to a first application client in response to a second application calling request initiated by the first application client, and generating a session verification result based on the session verification information; a second session of a second application front end is determined according to the session verification result, a resource processing result corresponding to the second application calling request is displayed through the first application client based on the second session, and login information corresponding to the second session is consistent with login information corresponding to the first session. According to the technical scheme, cross-application non-inductive session synchronization is realized, and the use experience of a user is improved on the premise of ensuring session security.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method, apparatus, device, medium, and product for sharing sessions. Background Technology

[0002] With the popularization of mobile applications, HyperText Markup Language 5 (H5) applications are often embedded in host applications (APPs), forming a hybrid development model. In this model, H5 pages and host APPs need to work together, such as user login, data synchronization, and function navigation.

[0003] However, H5 runs in a WebView environment, while the host APP is a native environment. The data storage and session mechanisms of the two are naturally isolated, which leads to a fragmented user experience. After logging in to the APP, users need to log in again when they are redirected to the H5 page, and H5 and the host APP cannot share user status and data. Summary of the Invention

[0004] This invention provides a method, apparatus, device, medium, and product for sharing sessions, which enables seamless session synchronization across applications and improves the user experience while ensuring session security.

[0005] In a first aspect, embodiments of this disclosure provide a shared session method, including:

[0006] In response to a second application invocation request initiated by a first application client, the session verification information of the first session corresponding to the first application client is obtained, and a session verification result is generated based on the session verification information.

[0007] The second session of the second application frontend is determined based on the session verification result. Based on the second session, the resource processing result corresponding to the second application invocation request is displayed through the first application client. The login information corresponding to the second session is consistent with that of the first session.

[0008] Secondly, embodiments of this disclosure provide a shared session device, including:

[0009] The session verification module is used to respond to a second application invocation request initiated by a first application client, obtain session verification information of the first session corresponding to the first application client, and generate a session verification result based on the session verification information.

[0010] The shared session module is used to determine the second session of the second application front-end based on the session verification result, and display the resource processing result corresponding to the second application invocation request through the first application client based on the second session, wherein the login information corresponding to the second session is consistent with that of the first session.

[0011] Thirdly, embodiments of this disclosure provide an electronic device, including:

[0012] At least one processor; and

[0013] A memory that is communicatively connected to at least one processor; wherein,

[0014] The memory stores a computer program that can be executed by at least one processor, such that the at least one processor is able to perform a shared session method provided in the first aspect embodiment described above.

[0015] Fourthly, embodiments of this disclosure provide a computer-readable storage medium storing computer instructions that, when executed by a processor, implement a shared session method provided in the first aspect of the embodiments described above.

[0016] Fifthly, this disclosure provides a computer program product, which includes a computer program that, when executed by a processor, implements a shared session method provided in the first aspect of the embodiments described above.

[0017] This invention discloses a shared session method, apparatus, device, medium, and product, comprising responding to a second application invocation request initiated by a first application client, obtaining session verification information of a first session corresponding to the first application client, and generating a session verification result based on the session verification information; determining a second session of a second application frontend based on the session verification result; and displaying, based on the second session, a resource processing result corresponding to the second application invocation request through the first application client, wherein the login information corresponding to the second session is consistent with that of the first session. This technical solution achieves seamless cross-application session synchronization, improving the user experience while ensuring session security.

[0018] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart of a shared session method provided in Embodiment 1 of the present invention;

[0021] Figure 2 This is a schematic diagram of the structure of a shared session system corresponding to a shared session method provided in Embodiment 1 of the present invention;

[0022] Figure 3 This is a flowchart of a shared session method provided in Embodiment 2 of the present invention;

[0023] Figure 4 This is a signaling diagram of a shared session system interaction provided in Embodiment 2 of the present invention;

[0024] Figure 5 This is a schematic diagram of the structure of a shared session device provided in Embodiment 3 of the present invention;

[0025] Figure 6 This is a schematic diagram of the structure of an electronic device provided in Embodiment 4 of the present invention. Detailed Implementation

[0026] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0027] It should be noted that the terms "first," "second," and "target," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0028] Due to the separation between H5 applications and the host app, they need to share information to ensure user authentication, improve user convenience, and avoid security risks. User login information is typically stored and controlled using Session, with Sessionid as a unique identifier. The required user information can be retrieved through the sessionid. In web applications, Session refers to session control, a special object created by the server to save user state. The Sessionid is the object identifier for this object. For banking system apps, the number of integrated H5 applications varies greatly in sensitivity and scenario, making direct sharing of session resources impossible. Therefore, the host app provides an interface to retrieve user state based on the sessionid. However, the more scenarios where sessionid is shared, the wider its exposure, the greater the risk of leakage, and the performance risks to the host server.

[0029] Currently, existing technologies employ the following methods for H5 pages to interact with the host login state:

[0030] Step 1: The user initiates a login operation from the APP. The APP bank saves the user's login status and user session information in advance.

[0031] Step two: The user initiates a request to access the H5 page from the app. The app determines whether the user is already logged in. If not, it directly returns an error message indicating that the user is not authorized to access the page and requests to log in first. If the user is already logged in, it requests a token (ticket) from the backend system to access the H5 page.

[0032] Step 3: The backend system generates a ticket to access the H5 page and returns it to the front-end APP. The front-end APP returns to the APP, and the APP then initiates access. At this time, an additional ticket is attached to the access. The ticket is valid only once and expires after one authentication.

[0033] Step 4: After receiving the resource access request, the H5 page first requests the backend system to verify the ticket and processes it according to the ticket verification result of the backend system. If the ticket is invalid, it directly returns that access is not authorized; if the ticket is valid, it checks whether the user is logged into the H5 page. If not, it performs a silent login and then returns the resource.

[0034] Step 5: Maintain the APP's front-end session. The H5 page's front-end accesses the APP's native functions via JS code to maintain the session.

[0035] This method requires frequent access to the backend. Each time an H5 page is accessed, a token verification request must be sent to the backend server, which may increase the service load and potentially affect performance, especially under high concurrency. Secondly, it does not explicitly mention how to prevent security risks such as replay attacks, and it does not bind the token to device information.

[0036] Therefore, embodiments of the present invention propose a shared session method to solve the above-mentioned technical problems.

[0037] Example 1

[0038] Figure 1 This is a flowchart of a shared session method provided in Embodiment 1 of the present invention. This embodiment is applicable to the scenario where an H5 application and a host APP share a session. The method can be executed by a shared session device, which can be implemented in hardware and / or software.

[0039] Figure 2 This is a schematic diagram of the structure of a shared session system corresponding to a shared session method provided in Embodiment 1 of the present invention, as shown below. Figure 2 As shown, the first application client is connected to the first application server, the first application client is connected to the second application frontend, the second application frontend is connected to the second application server, and the second application server is connected to the first application server.

[0040] In this context, the first application client can be understood as the client of the first application, and the first application server can be understood as the server of the first application. The first application can be understood as an app, such as a banking app. The first application is a native application, which can be understood as an application created using a native programming language and development tools for a specific mobile platform, running directly on the target device's operating system. The second application frontend can be understood as the frontend of the second application, and the second application server can be understood as the server of the second application. The second application can be understood as a web application associated with the first application, such as an H5 application. An H5 application can be understood as a mobile application developed using web technologies, primarily employing frontend technologies to run on mobile devices through the WebView component embedded in a web browser. The first application serves as the host application for the second application.

[0041] like Figure 1 As shown, the method includes:

[0042] S101. In response to the second application invocation request initiated by the first application client, obtain the session verification information of the first session corresponding to the first application client, and generate a session verification result based on the session verification information.

[0043] In this embodiment, the second application initiation request can be understood as a request to initiate the second application, and the session verification information can be understood as information used to verify whether the first application and the second application are using the same session (or sharing a session). The first session can be understood as the current session of the first application client, i.e., the APP session of the APP client. The session verification information includes the first application session hash value and the first application device fingerprint. The first application session hash value can be understood as the hash value of the first session of the first application client. A hash is an algorithm that maps input data of arbitrary length to output data of fixed length. This output is called a hash value or message digest. The first application device fingerprint can be understood as the device fingerprint (device token) of the first application client. The device fingerprint can be used to uniquely identify the characteristics of the device or a unique device identifier. The session verification result can be understood as the result used to verify whether the login information of the first application and the login information of the second application are consistent, including verification pass and verification fail. Verification pass indicates that the first application client is still in the previous shared session with the second application frontend, and verification fail indicates that the first application client has exited the previous shared session. Here, a shared session refers to the consistency of the login information of the first application client and the second application frontend. Login information can be understood as the information required for a user to log in, including at least the username and user ID.

[0044] Specifically, the second application front-end, which is the execution subject of this embodiment of the invention, responds to the second application invocation request initiated by the first application client, obtains the session verification information of the first session corresponding to the first application client, verifies the first application session hash value in the session verification message, and if the verification result meets the conditions, determines that the session verification result is verified successfully; if the verification result does not meet the conditions, determines that the session verification result is verified unsuccessfully.

[0045] S102. Determine the second session of the second application frontend based on the session verification result. Based on the second session, display the resource processing result corresponding to the second application's invocation request through the first application client. The login information corresponding to the second session is consistent with that of the first session.

[0046] In this embodiment, the second session can be understood as the session of the second application frontend, that is, the H5 session of the H5 frontend. The resource processing result can be understood as the resource information lookup result to be presented on the first application client. The resource processing result is related to the second application initiation request and its corresponding resource request.

[0047] Specifically, if the session verification result indicates that the verification is successful, the second application frontend sends a resource request related to the second application initiation request to the second application server. The second application server verifies the resource request. If the verification is successful, it indicates that the first session of the first application client and the second session corresponding to the second application frontend use the same login information to form a shared session. The second application server then pulls the resource processing result corresponding to the resource request to the second application frontend so that the resource processing result can be displayed through the first application client.

[0048] If the session verification result indicates that the verification failed, the second application frontend requests an authorization code from the first application server through the first application client. After obtaining the authorization code, a second session is created. The second application frontend then requests login information from the first application server through the second application server. After obtaining the login information, the second application server writes the login information into the second session of the second application frontend to ensure that the login information of the first application client and the login information of the second application frontend are consistent. The second application frontend initiates a resource request to the second application server, and the second application server retrieves the resource processing result corresponding to the resource request and sends it to the second application frontend so that the resource processing result can be displayed through the first application client.

[0049] This invention provides a shared session method, comprising responding to a second application invocation request initiated by a first application client, obtaining session verification information of a first session corresponding to the first application client, and generating a session verification result based on the session verification information; determining a second session of a second application frontend based on the session verification result; and displaying, based on the second session, the resource processing result corresponding to the second application invocation request through the first application client, wherein the login information corresponding to the second session is consistent with that of the first session. This technical solution achieves seamless cross-application session synchronization, improving the user experience while ensuring session security.

[0050] As a first optional embodiment of this method, the method further includes:

[0051] Receive the logout system broadcast sent by the first application client when the logout conditions are met, delete the cached historical application session hash value based on the logout system broadcast, and notify the second application server to delete the second session.

[0052] In this embodiment, the logout condition can be understood as the condition for disconnecting the shared session between the first application client and the second application frontend. For example, the login information of the first application client may show a device switch, the first application client may be logged out by the user, or the login time of the first application client may exceed a certain time threshold. The logout system broadcast can be understood as a notification issued by the first application client that the logout condition is currently met. It is understood that when the login information is consistent, the session hash values ​​of the APP session and the H5 session are consistent. The historical application session hash value can be understood as the host session hash value of the APP session corresponding to the first application client or the H5 session hash value of the H5 session corresponding to the second application frontend during the last shared session.

[0053] Specifically, when the first application client meets the logout conditions, it will send a logout system broadcast, which indicates that the first application client has logged out. Therefore, based on the logout system broadcast, the cached historical application session hash value is deleted, and the second application server is notified to delete the second session. This is to prevent the first application client from directly sharing the first session with the second application front-end based on the same login information when the user logs in to the first application client next time, thus avoiding the security problems caused by unimpeded access to the shared session.

[0054] Example 2

[0055] Figure 3 This is a flowchart of a shared session method provided in Embodiment 2 of the present invention. This embodiment is a further optimization of any of the above embodiments and can be applied to the situation where H5 applications and host APPs share sessions. The method can be executed by a shared session device, which can be implemented in hardware and / or software.

[0056] Figure 4 This is a signaling diagram of a shared session system interaction provided in Embodiment 2 of the present invention, wherein the H5 front-end is the second application front-end, the APP client is the first application client, the H5 server is the second application server, and the APP server is the first application server.

[0057] like Figure 3 and Figure 4 As shown, the method includes:

[0058] S201. In response to the second application invocation request initiated by the first application client, obtain the session verification information of the first session corresponding to the first application client, compare the first application session hash value in the session verification information with the cached historical application session hash value, and obtain the comparison result.

[0059] In this embodiment, the comparison result can be understood as a verification result used to confirm whether the first application client is still in a historical session. It is understood that since the second application frontend deletes the corresponding historical application session hash value after the previous shared session logout, the historical application session hash value can be empty.

[0060] Specifically, in response to the second application invocation request initiated by the first application client, the second application's front-end H5 page is accessed. The second application's front-end sends a verification information retrieval request to the first application client, obtains the first application session hash value and the first application device fingerprint from the first application client, and compares the first application session hash value with the cached historical application session hash value to confirm whether the two are consistent and obtain the comparison result.

[0061] S202. If the comparison results are consistent, the session verification result is determined to be successful; if the comparison results are inconsistent, the session verification result is determined to be unsuccessful.

[0062] In this embodiment, if the comparison result is consistent when the historical application session hash value is not empty, it indicates that a second session consistent with the first session login information of the first application client has been generated in the second application front end. Therefore, if the session verification result is determined to be verified, the first session and the second session can be directly indicated as a shared session, and a resource request can be generated and initiated.

[0063] If the comparison result is inconsistent when the historical application session hash value is not empty, it indicates that the second application frontend has not generated a second session or the session of the first application client has changed state. In order to ensure the security of the session, if the session verification result is determined to be verification failure, the first session and the second session cannot be directly shared. It is necessary to create a second session that matches the first session through the second application server and then initiate a resource request.

[0064] If the historical application session hash value is empty, it indicates that the second application frontend has not generated a second session, directly indicating that the session verification result is verification failure. It is necessary to create a second session that matches the first session through the second application server and then initiate a resource request.

[0065] S203. If the session verification result is successful, send a resource request to the second application server and receive the resource request verification result from the second application server.

[0066] In this embodiment, the resource request corresponds to the second application invocation request, and can be understood as a request to the second application server to process and transmit corresponding information resources. The resource request includes a resource acquisition request and session verification information. The resource request verification result is information generated by the second application server after verifying the first application session hash value and the first application device fingerprint in the session verification information.

[0067] Specifically, if the hash value of the first application session is consistent with the hash value of the historical application session, it indicates that the session verification result is successful. The second application frontend sends a resource request to the second application server. The second application server receives the resource request and verifies the hash value of the first application session and the fingerprint of the first application device based on the session verification information contained in the resource request. If both the hash value of the first application session and the fingerprint of the first application device pass the verification, the resource request verification result is determined to be successful. If either the hash value of the first application session or the fingerprint of the first application device fails the verification, the resource request verification result is determined to be unsuccessful.

[0068] S204. In response to the resource request verification result from the second application server being verified as successful, the second session of the second application frontend is invoked.

[0069] In this embodiment, if the resource request verification result returned by the second application server is verified as successful, it indicates that both the first application client and the second application frontend are securely in the previous login information sharing session. The first session of the first application client and the second session of the second application frontend are invoked, and the resource acquisition request is processed through the second application server to find and process the resource processing result corresponding to the resource acquisition request.

[0070] S205. In response to the resource request verification result from the second application server being unsuccessful, a second application access interface is generated and displayed through the first application client so that the first application client can initiate a second application invocation request.

[0071] In this embodiment, the second application access interface can be understood as an H5 login interface that is not used to log in to the second application.

[0072] Specifically, if the resource request verification result returned by the second application server is that the verification failed, it indicates that the login information of the first session of the first application client and the second session of the second application front-end are inconsistent at the current moment. Therefore, the second application front-end generates the second application access interface and displays the second application access interface through the first application client so that the first application client can initiate the second application invocation request, and then return to re-execute step S201.

[0073] S206. If the session verification result is that the verification fails, when the request acquisition conditions are met, request an authorization code from the first application client and receive the authorization code returned by the first application client.

[0074] In this embodiment, the request condition can be understood as a defined time interval condition used to avoid frequent access. For example, an authorization code can only be requested from the first application client once within a set time interval, and the next call must be made after the set time interval, which could be, for example, 2 minutes. The authorization code can be understood as authorization information used to enable the second application frontend to create a second session. The authorization code is information generated and returned by the first application server in response to the first application client's request to obtain the authorization code.

[0075] Specifically, if the hash value of the first application session is inconsistent with the hash value of the historical application session, it indicates that the session verification result is that the verification failed. If no authorization code is requested from the first application client within the set time interval, it is determined that the current request condition is met, and an authorization code is requested from the first application client. The first application client then sends an authorization code retrieval request to the first application server. The first application server generates the authorization code and sends it back to the first application client. The first application client then sends the authorization code back to the second application frontend so that the second application frontend can create a second session based on the authorization code.

[0076] S207. Establish a second session for the second application front-end based on the authorization code.

[0077] In this embodiment, a second session of the second application frontend is created based on the authorization code. After the creation of the second session is completed, login information is requested from the first application server and written into the second session, thereby realizing the sharing of login information between the first session and the second session.

[0078] Optionally, establishing a second session for the second application frontend based on the authorization code includes:

[0079] S2071. Create a second session for the second application frontend based on the authorization code, request login information from the second application server, receive the login information from the second application server, write the login information into the second session, and store the session hash value of the second session as the historical application session hash value.

[0080] In this embodiment, the login information is generated and returned by the first application server in response to the second application server's request to obtain login information.

[0081] Specifically, after obtaining the authorization code, the second application frontend establishes a corresponding second session based on the authorization code and requests login information from the second application server. The second application server sends a corresponding login information retrieval request to the first application server. The first application server returns login information to the second application server based on the login information retrieval request. The second application server then writes the login information into the newly created second session, thus completing the establishment of the second session. At this point, the login information of the first application client's first session and the second application frontend's second session are consistent. The second application frontend caches the session hash value of the first application client corresponding to the shared session as a historical application session hash value for use the next time it receives a second application invocation request.

[0082] S2072. Send a resource request to the second application server and receive the resource request verification result from the second application server.

[0083] The same steps as S203 will not be repeated here.

[0084] S2073. In response to the resource request verification result from the second application server being verified as passed, the second session of the second application front-end established based on the authorization code is determined to be valid.

[0085] In this embodiment, in response to the resource request verification result fed back by the second application server, the verification is passed, and it is determined that the second session newly established based on the authorization code is secure and valid, and is consistent with the login information of the first session, and can be directly applied.

[0086] S2074. In response to the resource request verification result from the second application server being unsuccessful, a second application access interface is generated and displayed through the first application client so that the first application client can initiate a second application invocation request.

[0087] The same steps as S205 will not be repeated here.

[0088] S208, Destroy the authorization code.

[0089] In this embodiment, to ensure the security of the shared session, the authorization code is set as one-time data and is destroyed immediately after use to avoid secondary use.

[0090] S209. Display the resource processing result corresponding to the second application's invocation request through the first application client.

[0091] The shared session method provided in this embodiment of the invention includes responding to a second application invocation request initiated by a first application client, obtaining session verification information of a first session corresponding to the first application client, comparing the first application session hash value in the session verification information with cached historical application session hash values ​​to obtain a comparison result; if the comparison result is consistent, the session verification result is determined to be successful; if the comparison result is inconsistent, the session verification result is determined to be unsuccessful; if the session verification result is successful, a resource request is sent to a second application server, and a resource request verification result is received from the second application server. The resource request includes a resource acquisition request and session verification information, and the resource request verification result is generated by the second application server after verifying the first application session hash value and the first application device fingerprint in the session verification information. The system processes the following steps: If the resource request verification result from the second application server is successful, it invokes the second session of the second application frontend; if the resource request verification result from the second application server is unsuccessful, it generates a second application access interface and displays it through the first application client for the first application client to initiate a second application invocation request; if the session verification result is unsuccessful, and the request acquisition conditions are met, it requests an authorization code from the first application client and receives the authorization code returned by the first application client. The authorization code is information generated and returned by the first application server in response to the first application client's authorization code acquisition request; a second session of the second application frontend is established based on the authorization code; the authorization code is destroyed; and the resource processing result corresponding to the second application invocation request is displayed through the first application client.The above technical solution proposes a method for seamless cross-application session synchronization between H5 applications and the host APP, meeting the needs of information sharing between H5 applications and the host APP. It establishes its own session mechanism for H5 applications, enabling user information sharing through self-built sessions. Information from its own sessions is prioritized, avoiding frequent calls to the host backend interface and reducing the traffic pressure on the host backend during verification. In addition to storing user information, the H5 session also stores the host session hash and device fingerprint. An authorization code is used instead of a session to obtain user login information; this code is generated by the host server and expires after one use, reducing the risk of session leakage. Device binding is added to the session to enhance system security, and hash verification is used to further strengthen security. The system uses verification and system broadcasting to maintain sessions, minimizing backend system resources and protecting backend system stability. Before each H5 request, it first obtains the session hash from the host client and performs a consistency check between the session hash in the request and the hash recorded in the H5 session. If they do not match, it proves that the host session has changed, prompting the user to log in again. At the same time, a broadcast is triggered when the user logs out of the app, clearing the first session. This dual protection ensures the security of shared session information. Device fingerprint binding is also added. Before each H5 request, it first obtains the device fingerprint from the host client. When the H5 server receives a request, it performs a consistency check between the device fingerprint in the request and the device fingerprint saved in the session, binding the session and device and strengthening the security of shared information.

[0092] Example 3

[0093] Figure 5 This is a schematic diagram of a shared session device provided in Embodiment 3 of the present invention. Figure 5 As shown, the device includes:

[0094] The session verification module 31 is used to respond to the second application invocation request initiated by the first application client, obtain the session verification information of the first session corresponding to the first application client, and generate a session verification result based on the session verification information.

[0095] The shared session module 32 is used to determine the second session of the second application front-end based on the session verification result, and display the resource processing result corresponding to the second application invocation request through the first application client based on the second session, wherein the login information corresponding to the second session is consistent with that of the first session.

[0096] The shared session device used in this technical solution enables seamless session synchronization across applications, improving the user experience while ensuring session security.

[0097] Optional, session verification module 31, specifically used for:

[0098] Obtain the session verification information of the first session corresponding to the first application client, compare the first application session hash value in the session verification information with the cached historical application session hash value, and obtain the comparison result;

[0099] If the comparison results are consistent, the session verification result is determined to be successful; if the comparison results are inconsistent, the session verification result is determined to be unsuccessful.

[0100] Optional, shared session module 32 includes:

[0101] The resource request unit is configured to send a resource request to the second application server if the session verification result is successful, and receive the resource request verification result fed back by the second application server. The resource request includes a resource acquisition request and session verification information. The resource request verification result is information generated by the second application server after verifying the first application session hash value and the first application device fingerprint in the session verification information.

[0102] The shared session invocation unit is used to invoke the second session of the second application frontend in response to the resource request verification result fed back by the second application server being verified as passed.

[0103] The access interface generation unit is used to generate a second application access interface in response to the resource request verification result fed back by the second application server being that the verification failed, and to display the second application access interface through the first application client so that the first application client can initiate a second application invocation request.

[0104] Optional, shared session module 32 includes:

[0105] The authorization code request unit is used to request an authorization code from the first application client when the session verification result is verification failure and the request acquisition conditions are met, and to receive the authorization code fed back by the first application client. The authorization code is information generated and fed back by the first application server in response to the first application client's authorization code acquisition request.

[0106] A shared session creation unit is used to establish a second session for creating a second application front-end based on the authorization code;

[0107] An authorization code destruction unit is used to destroy the authorization code.

[0108] Optional, a shared session creation unit, specifically used for:

[0109] Based on the authorization code, a second session of the second application frontend is created, and login information is requested from the second application server. The login information fed back by the second application server is received, the login information is written into the second session, and the session hash value of the second session is stored as the historical application session hash value. The login information is generated and fed back by the first application server in response to the second application server's request to obtain login information.

[0110] Send a resource request to the second application server and receive the resource request verification result from the second application server;

[0111] If the resource request verification result from the second application server is successful, the second session of the second application frontend established based on the authorization code is determined to be valid.

[0112] In response to the resource request verification result from the second application server indicating that the verification failed, a second application access interface is generated and displayed through the first application client so that the first application client can initiate a second application invocation request.

[0113] Optionally, the device also includes a shared session logout module, specifically used for:

[0114] The system receives a logout system broadcast sent by the first application client when the logout conditions are met, deletes the cached historical application session hash value based on the logout system broadcast, and notifies the second application server to delete the second session.

[0115] The shared session device provided in the embodiments of the present invention can execute the shared session method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of executing the method.

[0116] Example 4

[0117] Figure 6 This is a schematic diagram of the structure of an electronic device provided in Embodiment 4 of the present invention. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0118] like Figure 6As shown, the electronic device 40 includes at least one processor 41 and a memory, such as a read-only memory (ROM) 42 or a random access memory (RAM) 43, communicatively connected to the at least one processor 41. The memory stores computer programs executable by the at least one processor. The processor 41 can perform various appropriate actions and processes based on the computer program stored in the ROM 42 or loaded into the RAM 43 from storage unit 48. The RAM 43 may also store various programs and data required for the operation of the electronic device 40. The processor 41, ROM 42, and RAM 43 are interconnected via a bus 44. An input / output (I / O) interface 45 is also connected to the bus 44.

[0119] Multiple components in electronic device 40 are connected to I / O interface 45, including: input unit 46, such as keyboard, mouse, etc.; output unit 47, such as various types of monitors, speakers, etc.; storage unit 48, such as disk, optical disk, etc.; and communication unit 49, such as network card, modem, wireless transceiver, etc. Communication unit 49 allows electronic device 40 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0120] Processor 41 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 41 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 41 performs the various methods and processes described above, such as the shared session method.

[0121] In some embodiments, the shared session method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 48. In some embodiments, part or all of the computer program may be loaded and / or mounted on electronic device 40 via ROM 42 and / or communication unit 49. When the computer program is loaded into RAM 43 and executed by processor 41, one or more steps of the shared session method described above may be performed. Alternatively, in other embodiments, processor 41 may be configured to perform the shared session method by any other suitable means (e.g., by means of firmware).

[0122] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0123] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0124] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

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

[0126] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0127] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0128] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0129] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A shared session method, characterized in that, include: In response to a second application invocation request initiated by a first application client, the session verification information of the first session corresponding to the first application client is obtained, and a session verification result is generated based on the session verification information. The second session of the second application frontend is determined based on the session verification result. Based on the second session, the resource processing result corresponding to the second application invocation request is displayed through the first application client. The login information corresponding to the second session is consistent with that of the first session.

2. The method according to claim 1, characterized in that, The step of obtaining session verification information for the first session corresponding to the first application client and generating a session verification result based on the session verification information includes: Obtain the session verification information of the first session corresponding to the first application client, compare the first application session hash value in the session verification information with the cached historical application session hash value, and obtain the comparison result; If the comparison results are consistent, the session verification result is determined to be successful; if the comparison results are inconsistent, the session verification result is determined to be unsuccessful.

3. The method according to claim 1, characterized in that, If the session verification result is successful, determining the second session of the second application frontend based on the session verification result includes: Send a resource request to the second application server and receive the resource request verification result fed back by the second application server. The resource request includes a resource acquisition request and session verification information. The resource request verification result is information generated by the second application server after verifying the first application session hash value and the first application device fingerprint in the session verification information. In response to the resource request verification result returned by the second application server being verified as successful, the second session of the second application frontend is invoked; In response to the resource request verification result from the second application server indicating that the verification failed, a second application access interface is generated and displayed through the first application client so that the first application client can initiate a second application invocation request.

4. The method according to claim 1, characterized in that, If the session verification result is a verification failure, determining the second session of the second application frontend based on the session verification result includes: When the request conditions are met, an authorization code is requested from the first application client, and the authorization code fed back by the first application client is received. The authorization code is information generated and fed back by the first application server in response to the first application client's request to obtain the authorization code. A second session is established based on the authorization code for the second application front-end; Destroy the authorization code.

5. The method according to claim 4, characterized in that, The establishment of the second session for the second application frontend based on the authorization code includes: Based on the authorization code, a second session of the second application frontend is created, and login information is requested from the second application server. The login information fed back by the second application server is received, the login information is written into the second session, and the session hash value of the second session is stored as the historical application session hash value. The login information is generated and fed back by the first application server in response to the second application server's request to obtain login information. Send a resource request to the second application server and receive the resource request verification result from the second application server; If the resource request verification result from the second application server is successful, the second session of the second application frontend established based on the authorization code is determined to be valid. In response to the resource request verification result from the second application server indicating that the verification failed, a second application access interface is generated and displayed through the first application client so that the first application client can initiate a second application invocation request.

6. The method according to claim 1, characterized in that, Also includes: The system receives a logout system broadcast sent by the first application client when the logout conditions are met, deletes the cached historical application session hash value based on the logout system broadcast, and notifies the second application server to delete the second session.

7. A shared session device, characterized in that, include: The session verification module is used to respond to a second application invocation request initiated by a first application client, obtain session verification information of the first session corresponding to the first application client, and generate a session verification result based on the session verification information. The shared session module is used to determine the second session of the second application front-end based on the session verification result, and display the resource processing result corresponding to the second application invocation request through the first application client based on the second session, wherein the login information corresponding to the second session is consistent with that of the first session.

8. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor to enable the at least one processor to perform a shared session method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute and implement a shared session method according to any one of claims 1-6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements a shared session method according to any one of claims 1-6.

Images