HTTP and WebSocket protocol collaborative login ticket sharing method and system

Abstract

The present application relates to the technical field of network communication and identity authentication, and particularly relates to a HTTP and WebSocket protocol collaborative login ticket sharing method and system. The method comprises the following steps: receiving an HTTP login request and verifying user identity authentication information, generating a login ticket state record associated with a ticket state and a version, and generating an HTTP access credential; generating a one-time WebSocket connection credential based on the record, checking the use state, the valid time and the ticket version in the handshake stage, establishing a WebSocket session and a protocol channel binding record; querying the same record before processing an HTTP business request and a WebSocket message, updating the state and the version when the ticket state changes, rejecting the request and the message when the ticket state is invalid or the version is inconsistent, and closing the corresponding session. The present application can reduce the login state asynchronization of the two types of protocol channels and the lag of invalid treatment.

Description

Technical Field

[0001] This invention relates to the field of network communication and identity authentication technology, and in particular to a method and system for sharing login tickets using HTTP and WebSocket protocols. Background Technology

[0002] In the field of network communication and identity authentication technology, front-end and back-end separation systems, single sign-on systems, and multi-service systems typically use the Hypertext Transfer Protocol (HTTP) to complete login authentication, interface access, and business requests, and use the WebSocket protocol to establish a long-lived connection between the client and the server. After logging in via HTTP, users obtain a login ticket, session token, or access token, and subsequent HTTP business requests carry the corresponding credentials. The WebSocket connection is established based on the user identifier, session information, or connection parameters, and is responsible for real-time message reception, business status push, and logout notification. This approach can complete login authentication and bidirectional communication, but in scenarios where HTTP short connections and WebSocket long connections coexist, limitations such as separate maintenance of authentication status, untimely transmission of login status changes, and inconsistencies in status between different protocol channels can easily arise.

[0003] Existing solutions largely rely on request-level verification of HTTP access credentials, the mapping between user identifiers and WebSocket connection identifiers, and WebSocket logout messages for state management. HTTP business requests typically verify credentials on each access, while the WebSocket connection persists after the handshake is complete. When login tickets are refreshed, logged out, permissions change, accounts are frozen, or timeouts occur, the HTTP access credentials and the established WebSocket session may be at different authentication stages. Even when only a logout message is pushed to the client via WebSocket, state handling still depends on the client receiving and executing the corresponding operation; if the message is not delivered, the connection fails, or the client fails to update its local state in a timely manner, the original WebSocket session may still persist.

[0004] Furthermore, existing connection relationships typically use user identifiers as the primary index, making it difficult to distinguish between different login tickets, different client instances, and different login stages for the same user. When a WebSocket connection is lost and reconnected, if the session is re-established solely based on the network connection status, the changed authentication state may continue to be used. When HTTP business requests and WebSocket messages arrive concurrently, there is a lack of a unified state verification basis between the two types of protocol channels, easily leading to discontinuities in the transition between request rejection, connection persistence, and logout states. Therefore, it is necessary to address the difficulty in synchronizing the login ticket states of the two types of protocol channels in scenarios where HTTP short connections and WebSocket long connections coexist. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides a method for sharing login tickets using a collaborative approach combining HTTP and WebSocket protocols, comprising: S100: Receive HTTP login request; verify user identity authentication information; generate login ticket status record and HTTP access credential associated with login ticket identifier, ticket status and ticket version; S200. Based on the login ticket status record and WebSocket connection authorization request, verify the ticket status and ticket version, and generate a WebSocket connection credential with a one-time use status; S300: Receive a WebSocket handshake request carrying the WebSocket connection credential; when the WebSocket connection credential is unused, not expired, and has the same ticket version, update its usage status to used, establish a WebSocket session and generate a connection identifier, bind the connection identifier to the login ticket status record, and generate a protocol channel binding record. S400. Based on the protocol channel binding record, before processing HTTP service requests and WebSocket messages, query the same login ticket status record and verify the ticket status and ticket version using the HTTP access credential and connection identifier respectively; when a ticket status change event is received, update the ticket status and ticket version, reject HTTP service requests and WebSocket messages whose associated ticket status is not valid or whose ticket version is inconsistent, close the corresponding WebSocket session, and generate a cross-protocol ticket status handling result.

[0006] Furthermore, the HTTP login request includes user authentication information, client instance identifier, and business system identifier; The login ticket status record is also associated with user identifier, client instance identifier, business system scope, generation time, and expiration time; The HTTP access credentials are associated with the login ticket identifier, ticket version, and business system identifier.

[0007] Furthermore, the WebSocket connection authorization request includes a login ticket identifier, the current ticket version, the client instance identifier, and the target WebSocket service identifier; Based on the login ticket identifier, query the login ticket status record, compare the current ticket version with the ticket version in the login ticket status record, compare the client instance identifier in the WebSocket connection authorization request with the client instance identifier in the login ticket status record, and verify the target WebSocket service identifier with the business system scope; The WebSocket connection credentials include a connection credential identifier, a login ticket identifier, a ticket version, a client instance identifier, a target WebSocket service identifier, an expiration time, a random number, usage status, and integrity verification information.

[0008] Furthermore, after receiving the WebSocket handshake request, the integrity verification information is verified, and the validity period and usage status of the WebSocket connection credential are queried. Compare the ticket version in the WebSocket connection credential with the ticket version in the login ticket status record; If the integrity verification passes, the current time does not exceed the validity period, the usage status is unused and the ticket version is consistent, the usage status is updated to used based on the connection credential identifier, the usage status being unused and the current time not exceeding the validity period. If the usage status update fails, a connection credential verification result is generated and the establishment of a WebSocket session is refused.

[0009] Furthermore, the protocol channel binding record includes login ticket identifier, ticket version, HTTP access credential identifier, client instance identifier, business system identifier, WebSocket connection identifier, WebSocket server node identifier, binding status, and establishment time; When establishing the protocol channel binding record, the login ticket identifier and the ticket version are written into the connection state of the WebSocket session.

[0010] Furthermore, before processing the HTTP service request, the login ticket identifier and ticket version are obtained based on the HTTP access credentials, and the login ticket status record is queried based on the login ticket identifier; Before processing the WebSocket message, query the protocol channel binding record based on the connection identifier, and obtain the login ticket identifier and ticket version based on the protocol channel binding record; The system compares the obtained ticket status with the valid status and compares the obtained ticket version with the current ticket version in the login ticket status record; if the ticket status is not valid or the ticket version is inconsistent, the HTTP service request or the WebSocket message is rejected.

[0011] Furthermore, the ticket status change events include ticket refresh requests, cancellation requests, permission change events, account freeze events, and ticket timeout events; Upon receiving the ticket status change event, first update the ticket status and ticket version in the login ticket status record, and then query the protocol channel binding record based on the login ticket identifier; If the associated ticket status is not valid, or the version of the ticket carried or bound is inconsistent with the updated ticket version, the corresponding HTTP service request and WebSocket message are rejected, the WebSocket session corresponding to the protocol channel binding record is closed, and the binding status is updated to "released".

[0012] Furthermore, a disconnection reconnection request is received, the disconnection reconnection request including the login ticket identifier, the current ticket version, the client instance identifier, and the original connection identifier; The login ticket status record is queried based on the login ticket identifier, and the protocol channel binding record is queried based on the original connection identifier; A new WebSocket connection credential is generated when the ticket status is valid, the current ticket version is consistent with the ticket version in the logged-in ticket status record, the client instance identifier is consistent, and the original connection binding status is unbound. A WebSocket session is established based on the new WebSocket connection credentials, and the original connection identifier is replaced with the new connection identifier.

[0013] Furthermore, when the WebSocket session fails to close or the WebSocket server node becomes unavailable, the ticket status in the login ticket status record is kept as invalid, the binding status in the protocol channel binding record is updated to pending closure, and the WebSocket connection handling result is recorded. Based on the WebSocket connection handling result, the closing operation of the WebSocket session is retried; before the binding status is updated to be unbound, the corresponding WebSocket message is rejected.

[0014] This invention also provides a collaborative login ticket sharing system using HTTP and WebSocket protocols, for performing the above-described method, including: The login ticket generation module is used to receive HTTP login requests, verify user identity authentication information, and generate login ticket status records and HTTP access credentials associated with login ticket identifier, ticket status and ticket version. The connection credential generation module, connected to the login ticket generation module, is used to verify the ticket status and ticket version based on the login ticket status record and the WebSocket connection authorization request, and generate a WebSocket connection credential with a one-time use status. The WebSocket connection binding module is connected to the connection credential generation module. It is used to receive a WebSocket handshake request carrying the WebSocket connection credential. When the WebSocket connection credential is unused, not expired, and has the same ticket version, it updates its usage status to "used", establishes a WebSocket session and generates a connection identifier, binds the connection identifier to the login ticket status record, and generates a protocol channel binding record. The cross-protocol status control module, connected to the WebSocket connection binding module, is used to query the same login ticket status record and verify the ticket status and ticket version based on the protocol channel binding record before processing HTTP business requests and WebSocket messages, respectively, using HTTP access credentials and connection identifiers; when a ticket status change event is received, the ticket status and ticket version are updated, HTTP business requests and WebSocket messages with associated ticket statuses that are not valid or have inconsistent ticket versions are rejected, the corresponding WebSocket session is closed, and a cross-protocol ticket status handling result is generated.

[0015] The main technical features of this invention include: (1) The login ticket status record is used as the authentication status object that is referenced by both the HTTP protocol channel and the WebSocket protocol channel. The HTTP access credential, WebSocket connection credential and connection identifier are associated with the same login ticket identifier, ticket status and ticket version, so that the two types of protocol channels perform identity verification according to the unified ticket status and ticket version.

[0016] (2) Set up a one-time connection authorization and ticket-level binding mechanism between the login ticket status record and the WebSocket session; associate the WebSocket connection credential with the login ticket identifier, ticket version, client instance identifier and target WebSocket service identifier, update it to used according to the conditions of unused, not expired and consistent ticket version during the handshake phase, and then bind the generated connection identifier with the login ticket status record to form a protocol channel binding record.

[0017] (3) Adopt a cross-protocol status control mechanism that updates the login ticket status first; before HTTP business requests and WebSocket messages enter business processing, check the current ticket status and ticket version respectively. After ticket refresh, cancellation, permission change, account freeze or ticket timeout, update the login ticket status record first, then reject the old version HTTP business requests and WebSocket messages, and close or release the corresponding WebSocket session according to the protocol channel binding record; if the connection closure is not completed, continue to restrict the corresponding message according to the updated ticket status and ticket version.

[0018] The following are its main beneficial effects: (1) HTTP access credentials and WebSocket connections no longer depend on each other's independent authentication status. Both types of protocol channels can locate the same login ticket status record. When the login status changes, HTTP business requests and WebSocket messages can be checked according to the same ticket status and ticket version, reducing the inconsistency between short connection access status and long connection maintenance status.

[0019] (2) WebSocket connection credentials are consumed only when they are unused, not expired and the associated ticket version is still the current version. Repeated handshake requests for the same connection credentials cannot form multiple valid WebSocket sessions. After the connection identifier is bound to the specific login ticket status record and ticket version, different login tickets, client instances and login stages of the same user can be distinguished, reducing the situation where long-term login tickets are directly reused to establish long connections.

[0020] (3) After the login ticket status and ticket version are updated, old version HTTP business requests and WebSocket messages are rejected before business processing. Whether the WebSocket session has been physically closed is no longer a valid condition for login failure. In the case of connection closure failure, temporary unavailability of server node or disconnection and reconnection, the original connection is still constrained by the current ticket status and ticket version, reducing the continuation of authentication status caused by failure to deliver the cancellation notice or delay in connection processing. Attached Figure Description

[0021] Figure 1 A flowchart illustrating a method for sharing login tickets using HTTP and WebSocket protocols, provided in an embodiment of the present invention; Figure 2 This is a structural block diagram of a collaborative login ticket sharing system using HTTP and WebSocket protocols, provided as an embodiment of the present invention. Detailed Implementation

[0022] Example 1: Refer to Figure 1 This is a flowchart illustrating a collaborative login ticket sharing method using HTTP and WebSocket protocols provided in an embodiment of the present invention. The process may include at least steps S100 to S400: S100: Receive HTTP login request; verify user identity authentication information; generate login ticket status record and HTTP access credential associated with login ticket identifier, ticket status and ticket version; S200. Based on the login ticket status record and WebSocket connection authorization request, verify the ticket status and ticket version, and generate a WebSocket connection credential with a one-time use status; S300: Receive a WebSocket handshake request carrying the WebSocket connection credential; when the WebSocket connection credential is unused, not expired, and has the same ticket version, update its usage status to used, establish a WebSocket session and generate a connection identifier, bind the connection identifier to the login ticket status record, and generate a protocol channel binding record. S400. Based on the protocol channel binding record, before processing HTTP service requests and WebSocket messages, query the same login ticket status record and verify the ticket status and ticket version using the HTTP access credential and connection identifier respectively; when a ticket status change event is received, update the ticket status and ticket version, reject HTTP service requests and WebSocket messages whose associated ticket status is not valid or whose ticket version is inconsistent, close the corresponding WebSocket session, and generate a cross-protocol ticket status handling result.

[0023] S100: Receive HTTP login request; verify user identity authentication information, and generate login ticket status record and HTTP access credentials associated with login ticket identifier, ticket status and ticket version.

[0024] In one implementation, this embodiment runs on a front-end and back-end separated business system. The client submits an HTTP login request to the authentication server via the Hypertext Transfer Protocol (HTTP). After receiving the request, the authentication server's login ticket generation module reads the user authentication information, client instance identifier, and business system identifier from the request. The user authentication information can be a username and password, temporary authentication parameters returned by single sign-on, or authentication data recognized by the business system. The client instance identifier is used to distinguish the access source of the same user on different browsers, application terminals, or login instances. The business system identifier is used to limit the scope of business systems that this login ticket can be associated with.

[0025] When processing an HTTP login request, the login ticket generation module first verifies the user's authentication information. Upon successful verification, the authentication server generates a login ticket identifier for this login process and configures an initial ticket state and version for that ticket. The ticket state indicates whether the login ticket is currently valid, invalid, frozen, or expired, while the ticket version distinguishes different authentication stages of the same login ticket before and after refresh, logout, permission changes, or status updates. If user authentication verification fails, the authentication server does not generate a login ticket state record and returns a login failure result to the client. If the client instance identifier is missing, the authentication server may reject the HTTP login request, or, in one implementation, generate a new client instance identifier based on the client session information and continue the login process.

[0026] After generating a login ticket, the authentication server associates and saves the login ticket identifier, user identifier, client instance identifier, business system scope, ticket status, ticket version, generation time, and expiration time to form a login ticket status record. The business system scope is determined by the business system identifier in the HTTP login request and the access authorization relationship configured in the authentication server. When the business system identifier does not fall within the user's authorization scope, the login ticket generation module does not write the business system identifier into the business system scope and returns an authentication result that does not match the business system scope. The login ticket status record is stored in the ticket status store for subsequent WebSocket connection authorization, HTTP business request verification, and WebSocket message verification queries.

[0027] After the login ticket status record is generated, the authentication server generates an HTTP access credential. This HTTP access credential is associated with the login ticket identifier, ticket version, and business system identifier. The client subsequently sends HTTP business requests with this HTTP access credential. The HTTP access credential does not independently determine the validity of the user's identity; rather, it serves as an index entry point for the HTTP application server to query the login ticket status record. This way, if the login ticket status or ticket version changes, the HTTP application server can use the HTTP access credential to look up the current login ticket status record, rather than relying solely on the credential content stored locally on the client.

[0028] The login ticket status record and HTTP login authentication result output by S100 are processed further. The HTTP login authentication result is returned to the client, which includes the login ticket identifier that can locate the login ticket status record, the current ticket version, and the HTTP access credentials. The login ticket identifier and the current ticket version are then used for WebSocket connection authorization in S200; the HTTP access credentials serve as the entry point for the HTTP business request side to query the same login ticket status record in S400.

[0029] S200: Based on the login ticket status record and WebSocket connection authorization request, verify the ticket status and ticket version, and generate a WebSocket connection credential with a one-time use status.

[0030] After obtaining the HTTP login authentication result, if the client needs to establish a persistent WebSocket connection, it sends a WebSocket connection authorization request to the authentication server or connection credential generation module. This request does not directly use the HTTP access credentials to establish a persistent connection; instead, it carries the login ticket identifier, the current ticket version, the client instance identifier, and the target WebSocket service identifier, requesting the authentication server to issue a one-time-use WebSocket connection credential based on the existing login ticket state record. The target WebSocket service identifier points to the WebSocket server, WebSocket server node, or the WebSocket service corresponding to the business system that the client intends to connect to.

[0031] After receiving a WebSocket connection authorization request, the connection credential generation module queries the login ticket status record generated by S100 based on the login ticket identifier. If no login ticket status record is found, or the found ticket status is invalid, frozen, or expired, no WebSocket connection credential is generated, and a connection authorization failure result is generated. If the found login ticket status record is valid, the connection credential generation module continues to compare the current ticket version in the WebSocket connection authorization request with the ticket version in the login ticket status record, verifying whether the client instance identifier matches the client instance identifier in the login ticket status record, and verifying whether the target WebSocket service identifier falls within the scope of the business system. If the current ticket version is inconsistent, it indicates that the authorization request is based on a different authentication phase; if the client instance identifier is inconsistent, it indicates that the connection authorization request is not from the original login instance; if the target WebSocket service identifier does not belong to the scope of the business system, it indicates that the login ticket is not applicable to the WebSocket service. If any of the above conditions are met, the connection credential generation module does not issue a WebSocket connection credential.

[0032] After the ticket status, ticket version, client instance identifier, and target WebSocket service identifier are all verified, the connection credential generation module reads the current ticket version from the login ticket status record and generates a WebSocket connection credential based on the login ticket identifier, current ticket version, client instance identifier, and target WebSocket service identifier. This WebSocket connection credential is used for one WebSocket handshake process; its initial usage state is unused, and it is configured with a validity period and a random number. In one implementation, the connection credential also includes integrity verification information, which is calculated by the connection credential generation module based on the connection credential identifier, login ticket identifier, ticket version, client instance identifier, target WebSocket service identifier, validity period, and random number. The integrity verification information is used by S300 to identify whether the connection credential has been tampered with during the handshake phase.

[0033] The WebSocket connection credential and the login ticket state record are associated, but they serve different purposes. The login ticket state record represents the server-side state of a login authentication, while the WebSocket connection credential represents the authorization for establishing a long-lived connection under that login state. The connection credential generation module does not directly use the original login ticket as a WebSocket handshake parameter; instead, it returns a WebSocket connection credential with a valid time and usage status to the client. Once this connection credential expires, is consumed, or the corresponding login ticket version changes, it cannot be used as the basis for a new WebSocket handshake.

[0034] The WebSocket connection credentials generated in S200 are carried by the client in the next WebSocket handshake request. The login ticket identifier, ticket version, client instance identifier, target WebSocket service identifier, validity period, random number, usage status, and integrity verification information in the connection credentials will be verified by the WebSocket server in S300. If the connection credentials fail to generate, the client maintains its HTTP login state but does not establish a corresponding WebSocket session.

[0035] S300: Receive a WebSocket handshake request carrying the WebSocket connection credential; when the WebSocket connection credential is unused, not expired, and has the same ticket version, update its usage status to "used", establish a WebSocket session and generate a connection identifier, bind the connection identifier to the login ticket status record, and generate a protocol channel binding record.

[0036] After obtaining the WebSocket connection credentials, the client sends a WebSocket handshake request to the target WebSocket server. The WebSocket connection binding module extracts the WebSocket connection credentials from the handshake request and first verifies the integrity of the connection credentials. If the integrity verification information does not match the content of the connection credentials, the WebSocket server rejects the handshake request and generates a connection credentials verification result; if the integrity verification passes, the WebSocket server queries the connection credentials record based on the connection credentials identifier, and reads the validity period, usage status, login ticket identifier, ticket version, client instance identifier, and target WebSocket service identifier.

[0037] The WebSocket server verifies connection credentials according to the order in which the connections were established. First, it compares the validity period with the current time; if the connection credential has expired, it refuses to establish a WebSocket session. Second, it checks if the usage status is unused; if the usage status is used, expired, or revoked, the handshake request is rejected. Third, it queries the login ticket status record based on the login ticket identifier, compares the ticket version in the connection credential with the current ticket version in the login ticket status record, and verifies if the ticket status is still valid. If the ticket status has been updated to expired, frozen, or expired, or if the current ticket version is inconsistent with the ticket version carried by the connection credential, the WebSocket handshake will not continue.

[0038] If the connection credential is unused, not expired, and the ticket version is consistent, the WebSocket connection binding module performs a conditional update on the usage status of the connection credential. The conditional update uses the connection credential identifier, unused status, and not expired status as update conditions, changing the usage status from unused to used. If the same connection credential is submitted repeatedly during network retries or across multiple WebSocket server nodes, only the request that satisfies the conditional update will proceed to the subsequent connection establishment process; other requests will be rejected due to the failure of the conditional update. Through this process, the connection credential, once consumed, cannot be used again to establish a new WebSocket session.

[0039] After successful consumption of connection credentials, the WebSocket server establishes a WebSocket session and assigns a connection identifier to the session. In one implementation, the connection identifier can be associated with the WebSocket server node identifier, session identifier, and establishment time to locate the corresponding connection within the WebSocket server cluster. After the session is established, the WebSocket connection binding module generates a protocol channel binding record. The protocol channel binding record includes the login ticket identifier, ticket version, HTTP access credential identifier, client instance identifier, business system identifier, WebSocket connection identifier, WebSocket server node identifier, binding status, and establishment time. The binding status is set to valid after successful connection establishment.

[0040] When establishing the protocol channel binding record, the WebSocket connection binding module also writes the login ticket identifier and ticket version into the connection state of the WebSocket session, so that subsequent WebSocket messages do not need to rely on the client repeatedly submitting the original login ticket. When a WebSocket message arrives, the WebSocket server can first obtain the connection state based on the connection identifier, and then query the login ticket status record based on the protocol channel binding record. If the protocol channel binding record writing fails, the WebSocket server closes the established WebSocket session or sets the session to an unreceiveable business message state, and records the connection credential verification result corresponding to the binding writing failure, avoiding situations where a connection has been established but the login ticket status cannot be traced.

[0041] The protocol channel binding record output by S300 forms the basis for cross-protocol authentication by S400. The HTTP side subsequently queries the login ticket status record using HTTP access credentials, while the WebSocket side queries the same login ticket status record using the connection identifier and the protocol channel binding record. Therefore, the two protocol channels do not rely on their own independent local states for authentication, but instead jointly reference the login ticket status record generated by S100.

[0042] S400. Based on the protocol channel binding record, before processing HTTP service requests and WebSocket messages, query the same login ticket status record and verify the ticket status and ticket version using the HTTP access credential and connection identifier respectively; when a ticket status change event is received, update the ticket status and ticket version, reject HTTP service requests and WebSocket messages whose associated ticket status is not valid or whose ticket version is inconsistent, close the corresponding WebSocket session, and generate a cross-protocol ticket status handling result.

[0043] After a WebSocket session is established, the HTTP application server and the WebSocket server receive HTTP business requests and WebSocket messages from the same client instance, respectively. Before processing the HTTP business request, the HTTP application server extracts the HTTP access credentials from the request, obtains the login ticket identifier and ticket version based on the HTTP access credentials, and queries the login ticket status record using the login ticket identifier. After retrieving the login ticket status record, the HTTP application server verifies whether the ticket status is valid and compares the ticket version associated with the HTTP access credentials with the current ticket version in the login ticket status record. If the ticket status is invalid, frozen, or expired, or if the ticket version is inconsistent, the HTTP application server rejects the HTTP business request and generates a cross-protocol authentication result corresponding to the request.

[0044] Before processing a WebSocket message, the WebSocket server queries the protocol channel binding record based on the connection identifier of the current WebSocket session, and obtains the login ticket identifier and the ticket version at the time of binding from that binding record. Subsequently, the WebSocket server queries the same login ticket status record based on the login ticket identifier, compares the ticket version at the time of binding with the current ticket version in the login ticket status record, and reads the binding status. If the ticket status is invalid, the ticket version is inconsistent, or the binding status is not valid, the WebSocket server does not process the WebSocket message and triggers connection disposal. This process ensures that the WebSocket session remains bound by the login ticket status after establishment, rather than completing authentication only once during the handshake phase.

[0045] Ticket status change events are triggered by the authentication server, HTTP application server, or business system. These events include ticket refresh requests, logout requests, permission change events, account freeze events, and ticket timeout events. Upon receiving a ticket status change event, the authentication server first queries the login ticket status record based on the login ticket identifier, then updates the ticket status and ticket version. In a ticket refresh scenario, the ticket version is incremented, and an access credential associated with the new version is generated. In logout, account freeze, or ticket timeout scenarios, the ticket status is updated to invalid or frozen, and the ticket version is incremented. In a permission change scenario, the business system scope can be updated based on the new permission results, in conjunction with the ticket version change. After the ticket status and ticket version are updated, this login ticket status record serves as the common basis for subsequent verification on both the HTTP and WebSocket sides.

[0046] After the ticket status changes, the cross-protocol status control module queries the protocol channel binding record based on the login ticket identifier to obtain the WebSocket connection identifier and WebSocket server node identifier associated with the login ticket. For WebSocket sessions that are still in a valid binding state, the WebSocket server can send a status change notification and perform the process of closing the WebSocket session. Closing is not a condition for ticket invalidation; once the ticket status and ticket version have been updated, even if the status change notification has not yet been delivered to the client, subsequent HTTP business requests and WebSocket messages will be rejected due to invalid ticket status or inconsistent ticket version. After the WebSocket session is closed, the binding status in the protocol channel binding record is updated to "released".

[0047] When a WebSocket session fails to close or the WebSocket server node becomes unavailable, the cross-protocol state control module maintains the ticket status in the login ticket status record as invalid and updates the binding status in the protocol channel binding record to pending closure. The WebSocket connection handling result record includes the reason for the closure failure, the corresponding connection identifier, and the WebSocket server node identifier, for use in subsequent retry processes. While the binding status is pending closure, when the WebSocket server receives a WebSocket message corresponding to that connection identifier, it still checks the ticket status and version against the records in the login ticket status record; if the check fails, the WebSocket message is rejected and does not proceed to business processing despite the physical connection not yet being closed.

[0048] When a client initiates a reconnection request due to network interruption, the cross-protocol state control module reads the login ticket identifier, current ticket version, client instance identifier, and original connection identifier from the reconnection request. The authentication server first queries the login ticket status record based on the login ticket identifier, and then queries the protocol channel binding record based on the original connection identifier. Only when the ticket status is valid, the current ticket version matches the ticket version in the login ticket status record, the client instance identifier matches, and the original connection binding status is unbound, does the authentication server generate a new WebSocket connection credential. Subsequently, the client re-executes the S300 handshake and binding process based on the new WebSocket connection credential, replacing the original connection identifier with the new connection identifier. If the ticket has expired, the ticket version is inconsistent, the client instance is inconsistent, or the original connection is still valid, the system generates a reconnection verification result and refuses to directly restore the original WebSocket session.

[0049] The cross-protocol ticket status processing result is jointly formed by status change processing, HTTP request verification, WebSocket message verification, and WebSocket connection processing. This result includes ticket status update result, HTTP service request rejection result, WebSocket message rejection result, WebSocket session closure result, and binding status update result. These results are stored in the ticket status store or connection relationship store and are queried upon the next arrival of an HTTP service request, WebSocket message, or disconnection reconnection request. Thus, the login ticket status record, HTTP access credentials, WebSocket connection credentials, protocol channel binding record, and cross-protocol ticket status processing result form a continuous data connection relationship within the same implementation process.

[0050] Example 2: Figure 2 This diagram illustrates a structural block diagram of a collaborative login ticket sharing system using HTTP and WebSocket protocols according to an embodiment of the present invention. Figure 2 As shown, the structure may include: The login ticket generation module 01 receives HTTP login requests, verifies user authentication information, and generates a login ticket status record and HTTP access credentials associated with a login ticket identifier, ticket status, and ticket version. HTTP stands for Hypertext Transfer Protocol. This module is located on the authentication server, which receives HTTP login requests from clients via a login interface and reads user authentication information, client instance identifier, and business system identifier from the requests. After successful verification of user authentication information via the authentication interface, the login ticket generation module assigns a login ticket identifier to the login, configures the initial ticket version and ticket status according to the login time and status, and associates the user identifier, client instance identifier, and business system identifier with the login ticket identifier to form a login ticket status record. The ticket status indicates whether the current login ticket is valid, invalid, frozen, or expired, and the ticket version distinguishes the authentication stages of the same login ticket before and after refresh, cancellation, or permission changes.

[0051] The login ticket generation module generates HTTP access credentials based on the login ticket status record. These HTTP access credentials are associated with the login ticket identifier, ticket version, and business system identifier. The client carries these HTTP access credentials in subsequent HTTP business requests, and the HTTP application server uses them to query the login ticket status record stored on the authentication server. If user authentication fails, the login ticket generation module terminates the current login branch and does not create a new login ticket status record. If the client instance identifier is missing or the business system identifier is not within the user's access range, the login ticket generation module returns the corresponding login authentication result and retains the original login ticket status. After the login ticket status record is successfully saved, the login ticket generation module returns the login ticket identifier, current ticket version, and HTTP access credentials to the client and provides the login ticket status record to the connection credential generation module.

[0052] The connection credential generation module 02, connected to the login ticket generation module, is used to verify the ticket status and ticket version based on the login ticket status record and the WebSocket connection authorization request, and generate a WebSocket connection credential with a one-time use status. WebSocket is a network communication protocol for bidirectional communication based on a single Transmission Control Protocol (TCP) connection. After obtaining the HTTP access credential, the client sends a WebSocket connection authorization request when a WebSocket session needs to be established. The WebSocket connection authorization request includes the login ticket identifier, the current ticket version, the client instance identifier, and the target WebSocket service identifier. The connection credential generation module calls the login ticket status record output by the login ticket generation module based on the login ticket identifier, reads the ticket status, ticket version, client instance identifier, and business system scope, and verifies the read result against the WebSocket connection authorization request.

[0053] When the ticket status is valid and the login ticket has not expired, the connection credential generation module continues to compare the client instance identifier and verify whether the target WebSocket service identifier is within the scope of the business system. If the client instance identifier is inconsistent, the target WebSocket service identifier is outside the scope of the business system, or the ticket version carried in the WebSocket connection authorization request is not the current ticket version, the connection credential generation module stops issuing connection credentials and returns a connection authorization failure result to the client. If the verification is successful, the connection credential generation module generates a WebSocket connection credential based on the login ticket identifier, the current ticket version, the client instance identifier, and the target WebSocket service identifier, and sets the validity period, random number, unused status, and integrity verification information for the WebSocket connection credential.

[0054] The WebSocket connection credential corresponds to only one WebSocket handshake process, and its credential record is associated with the login ticket status record. The connection credential generation module returns the WebSocket connection credential to the client and provides the credential record to the WebSocket connection binding module for querying. If the ticket status changes after credential generation but before the handshake is initiated, the connection credential itself does not replace the login ticket status record; the WebSocket connection binding module still needs to reread the current ticket status and current ticket version during the handshake phase.

[0055] The WebSocket connection binding module 03, connected to the connection credential generation module, receives a WebSocket handshake request carrying the WebSocket connection credential. When the WebSocket connection credential is unused, not expired, and has the same ticket version, it updates its usage status to "used," establishes a WebSocket session, generates a connection identifier, and binds the connection identifier to the login ticket status record, generating a protocol channel binding record. The WebSocket connection binding module is located on a WebSocket server or a WebSocket server node. When a client initiates a handshake to a target WebSocket service, the WebSocket connection binding module extracts the WebSocket connection credential from the WebSocket handshake request, first verifies the integrity check information, and then queries the connection credential record based on the connection credential identifier. If the integrity check fails, the credential record does not exist, or the target WebSocket service identifier does not match, the WebSocket connection binding module refuses to establish a WebSocket session and returns the connection credential verification result to the client.

[0056] After the integrity verification passes, the WebSocket connection binding module compares the validity period of the connection credential with the current time, reads the usage status of the connection credential, and queries the login ticket status record based on the login ticket identifier in the connection credential. The WebSocket connection binding module compares the ticket version in the connection credential with the current ticket version in the login ticket status record, and simultaneously verifies the ticket status and client instance identifier. If the connection credential has expired, the usage status is not unused, the ticket status is not valid, or the ticket version is inconsistent, the current handshake branch ends, and the WebSocket connection credential does not enter the consumption process.

[0057] When the connection credential meets the conditions of being unused, not expired, and having the same version, the WebSocket connection binding module updates the usage status to "used" using the connection credential identifier and the unused status as update conditions. When two WebSocket server nodes receive the same connection credential, the node that completes the condition update first continues to establish the WebSocket session; the node that has not completed the condition update generates a verification result corresponding to "credential used" and rejects the current handshake request. After the connection credential is consumed, the WebSocket connection binding module establishes a WebSocket session, assigns a connection identifier to the session, and obtains the current WebSocket server node identifier.

[0058] The WebSocket connection binding module associates the login ticket identifier, ticket version, HTTP access credential identifier, client instance identifier, business system identifier, connection identifier, and WebSocket server node identifier to form a protocol channel binding record and sets the binding status to valid. The login ticket identifier and ticket version are synchronously stored in the connection status of the WebSocket session for retrieval when WebSocket messages arrive. If saving the protocol channel binding record fails, the WebSocket connection binding module stops receiving business messages from that WebSocket session and closes the established WebSocket session; if saving succeeds, the protocol channel binding record is sent to the cross-protocol status control module as the connection basis for jointly querying the login ticket status record using the HTTP access credential and WebSocket connection identifier.

[0059] The cross-protocol state control module 04, connected to the WebSocket connection binding module, is used to query the same login ticket state record and verify the ticket state and ticket version based on the protocol channel binding record before processing HTTP business requests and WebSocket messages, using HTTP access credentials and connection identifiers respectively. Upon receiving a ticket state change event, it updates the ticket state and ticket version, rejects HTTP business requests and WebSocket messages with invalid ticket states or inconsistent ticket versions, closes the corresponding WebSocket session, and generates a cross-protocol ticket state handling result. The cross-protocol state control module interacts with the HTTP application server, authentication server, and WebSocket server respectively. After receiving an HTTP business request, the HTTP application server obtains the HTTP access credentials from the request and reads the login ticket identifier and ticket version based on the HTTP access credentials. After receiving a WebSocket message, the WebSocket server queries the protocol channel binding record based on the connection identifier of the current WebSocket session and reads the bound login ticket identifier, ticket version, and binding status.

[0060] The cross-protocol status control module queries the authentication server for the same login ticket status record based on the login ticket identifiers obtained from the two protocol channels. If the HTTP access credential carries a ticket version that matches the current ticket version and the ticket status is valid, the HTTP service request proceeds to service processing; if the versions are inconsistent or the ticket status is invalid, frozen, or expired, the HTTP application server rejects the HTTP service request. If the binding status of a WebSocket message is valid, the bound ticket version matches the current ticket version, and the ticket status is valid, the WebSocket server receives the message; if any verification result is inconsistent, the WebSocket message does not proceed to service processing, and the corresponding connection status is triggered.

[0061] Ticket status change events include ticket refresh requests, cancellation requests, permission change events, account freeze events, and ticket timeout events. Upon receiving a ticket status change event, the cross-protocol status control module first updates the ticket status and version in the login ticket status record based on the login ticket identifier, and then queries the protocol channel binding record associated with that login ticket identifier. When a ticket refresh request corresponds to a ticket version update, the original HTTP access credentials and the original WebSocket session retain the old ticket version; when a cancellation request, account freeze event, or ticket timeout event corresponds to a ticket status update, subsequent requests and messages from the original protocol channel are rejected due to status inconsistencies.

[0062] After completing the login ticket status update, the cross-protocol status control module sends connection closure control information to the corresponding WebSocket server based on the WebSocket server node identifier and connection identifier in the protocol channel binding record. After the WebSocket server closes the corresponding WebSocket session and returns the connection handling result, the cross-protocol status control module updates the binding status to "released." If the WebSocket server node is unavailable or the connection closure does not return a successful result, the binding status is updated to "pending closure," and the login ticket status remains the updated state. When the connection subsequently sends WebSocket messages, the cross-protocol status control module still rejects the message based on the ticket status and ticket version, and re-initiates the closure process based on the connection handling result.

[0063] When a client initiates a reconnection after a disconnection, the cross-protocol status control module reads the login ticket identifier, current ticket version, client instance identifier, and original connection identifier from the reconnection request, and queries the login ticket status record and protocol channel binding record respectively. If the ticket status is valid, the ticket version is consistent, the client instance identifier is consistent, and the original connection binding status is unbound, the cross-protocol status control module sends the reconnection verification result to the connection credential generation module, which generates a new WebSocket connection credential. After the new connection is established, the WebSocket connection binding module replaces the original connection identifier with the new connection identifier. If the verification results are inconsistent, the cross-protocol status control module rejects the current reconnection request and retains the processing status of the original protocol channel binding record.

Claims

1. A method for sharing login tickets using HTTP and WebSocket protocols, characterized in that, include: S100, Receive HTTP login request; Verify user identity authentication information and generate a login ticket status record and HTTP access credentials associated with the login ticket identifier, ticket status, and ticket version. S200. Based on the login ticket status record and WebSocket connection authorization request, verify the ticket status and ticket version, and generate a WebSocket connection credential with a one-time use status; S300: Receive a WebSocket handshake request carrying the WebSocket connection credential; when the WebSocket connection credential is unused, not expired, and has the same ticket version, update its usage status to used, establish a WebSocket session and generate a connection identifier, bind the connection identifier to the login ticket status record, and generate a protocol channel binding record. S400. Based on the protocol channel binding record, before processing HTTP service requests and WebSocket messages, query the same login ticket status record and verify the ticket status and ticket version using the HTTP access credential and connection identifier respectively; when a ticket status change event is received, update the ticket status and ticket version, reject HTTP service requests and WebSocket messages whose associated ticket status is not valid or whose ticket version is inconsistent, close the corresponding WebSocket session, and generate a cross-protocol ticket status handling result.

2. The method according to claim 1, characterized in that, The HTTP login request includes user authentication information, client instance identifier, and business system identifier; The login ticket status record is also associated with user identifier, client instance identifier, business system scope, generation time, and expiration time; The HTTP access credentials are associated with the login ticket identifier, ticket version, and business system identifier.

3. The method according to claim 2, characterized in that, The WebSocket connection authorization request includes the login ticket identifier, the current ticket version, the client instance identifier, and the target WebSocket service identifier; Based on the login ticket identifier, query the login ticket status record, compare the current ticket version with the ticket version in the login ticket status record, compare the client instance identifier in the WebSocket connection authorization request with the client instance identifier in the login ticket status record, and verify the target WebSocket service identifier with the business system scope; The WebSocket connection credentials include a connection credential identifier, a login ticket identifier, a ticket version, a client instance identifier, a target WebSocket service identifier, an expiration time, a random number, usage status, and integrity verification information.

4. The method according to claim 3, characterized in that, After receiving the WebSocket handshake request, verify the integrity verification information and query the validity period and usage status of the WebSocket connection credential; Compare the ticket version in the WebSocket connection credential with the ticket version in the login ticket status record; If the integrity verification passes, the current time does not exceed the validity period, the usage status is unused and the ticket version is consistent, the usage status is updated to used based on the connection credential identifier, the usage status being unused and the current time not exceeding the validity period. If the usage status update fails, a connection credential verification result is generated and the establishment of a WebSocket session is refused.

5. The method according to claim 1, characterized in that, The protocol channel binding record includes login ticket identifier, ticket version, HTTP access credential identifier, client instance identifier, business system identifier, WebSocket connection identifier, WebSocket server node identifier, binding status, and establishment time; When establishing the protocol channel binding record, the login ticket identifier and the ticket version are written into the connection state of the WebSocket session.

6. The method according to claim 5, characterized in that, Before processing the HTTP service request, obtain the login ticket identifier and ticket version based on the HTTP access credentials, and query the login ticket status record based on the login ticket identifier; Before processing the WebSocket message, query the protocol channel binding record based on the connection identifier, and obtain the login ticket identifier and ticket version based on the protocol channel binding record; The system compares the obtained ticket status with the valid status and compares the obtained ticket version with the current ticket version in the login ticket status record; if the ticket status is not valid or the ticket version is inconsistent, the HTTP service request or the WebSocket message is rejected.

7. The method according to claim 6, characterized in that, The events related to changes in the status of the invoice include invoice refresh requests, cancellation requests, permission changes, account freezes, and invoice timeouts. Upon receiving the ticket status change event, first update the ticket status and ticket version in the login ticket status record, and then query the protocol channel binding record based on the login ticket identifier; If the associated ticket status is not valid, or the version of the ticket carried or bound is inconsistent with the updated ticket version, the corresponding HTTP service request and WebSocket message are rejected, the WebSocket session corresponding to the protocol channel binding record is closed, and the binding status is updated to "released".

8. The method according to claim 5, characterized in that, Receive a disconnection reconnection request, the disconnection reconnection request including login ticket identifier, current ticket version, client instance identifier and original connection identifier; The login ticket status record is queried based on the login ticket identifier, and the protocol channel binding record is queried based on the original connection identifier; A new WebSocket connection credential is generated when the ticket status is valid, the current ticket version is consistent with the ticket version in the logged-in ticket status record, the client instance identifier is consistent, and the original connection binding status is unbound. A WebSocket session is established based on the new WebSocket connection credentials, and the original connection identifier is replaced with the new connection identifier.

9. The method according to claim 7, characterized in that, When a WebSocket session fails to close or the WebSocket server node becomes unavailable, the ticket status in the login ticket status record remains invalid, the binding status in the protocol channel binding record is updated to pending closure, and the WebSocket connection handling result is recorded. Based on the WebSocket connection handling result, the closing operation of the WebSocket session is retried; before the binding status is updated to be unbound, the corresponding WebSocket message is rejected.

10. A collaborative login ticket sharing system using HTTP and WebSocket protocols, characterized in that, include: The login ticket generation module is used to receive HTTP login requests, verify user identity authentication information, and generate login ticket status records and HTTP access credentials associated with login ticket identifier, ticket status and ticket version. The connection credential generation module, connected to the login ticket generation module, is used to verify the ticket status and ticket version based on the login ticket status record and the WebSocket connection authorization request, and generate a WebSocket connection credential with a one-time use status. The WebSocket connection binding module is connected to the connection credential generation module. It is used to receive a WebSocket handshake request carrying the WebSocket connection credential. When the WebSocket connection credential is unused, not expired, and has the same ticket version, it updates its usage status to "used", establishes a WebSocket session and generates a connection identifier, binds the connection identifier to the login ticket status record, and generates a protocol channel binding record. The cross-protocol status control module, connected to the WebSocket connection binding module, is used to query the same login ticket status record and verify the ticket status and ticket version based on the protocol channel binding record before processing HTTP business requests and WebSocket messages, respectively, using HTTP access credentials and connection identifiers; when a ticket status change event is received, the ticket status and ticket version are updated, HTTP business requests and WebSocket messages with associated ticket statuses that are not valid or have inconsistent ticket versions are rejected, the corresponding WebSocket session is closed, and a cross-protocol ticket status handling result is generated.

Images