Single-user login detection method and device, electronic equipment and storage medium

Abstract

This application discloses a method, apparatus, electronic device, and storage medium for detecting single-user login. The method includes: when a target front-end page establishes a connection with a target service node through a target account, retrieving a first connection message from a message queue storing connection messages sent by multiple service nodes. The connection message includes the account used to log in to the service node and a channel identifier for the connection channel between the service node and the front-end page; matching the first connection message with target channel objects in a target channel set to obtain a matching result. The target channel set stores channel objects generated after the front-end page connects with the target service node, and each target channel object includes at least the target channel identifier of the connection channel and the target account; and determining whether to generate a connection closing command based on the matching result. The solution provided in this application reduces the performance overhead of both the front-end web interface and the back-end service nodes while achieving single-user login.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and in particular relates to a method, apparatus, electronic device and storage medium for detecting single-user login. Background Technology

[0002] In a distributed system, the same account may be logged in from multiple locations at the same time, posing a security risk. Related technologies typically employ single-user login to ensure user account security; that is, only one user is allowed to log in to the same account at a time. For example, if user A logs in with the same account, and then user B tries to log in with the same account, user A's account will be automatically logged out.

[0003] In related technologies, a common approach is to use periodic polling on the front-end web interface to detect whether the same account is logged in elsewhere. This method requires back-end service nodes to set up filters or interceptors, and the front-end web interface to periodically request relevant interfaces to implement the polling, which incurs performance overhead for both the front-end web interface and the back-end service nodes. Summary of the Invention

[0004] This application provides a method, apparatus, electronic device, and storage medium for detecting single-user login, which can reduce the performance loss of the front-end web and back-end service nodes while realizing single-user login.

[0005] In a first aspect, embodiments of this application provide a single-user login detection method applied to a target service node. The method includes: upon detecting that a target front-end page has established a connection with a target service node through a target account, obtaining a first connection message from a message queue, wherein the message queue stores connection messages sent by multiple service nodes, and the connection message includes at least the account logged into the service node and a channel identifier for the connection channel between the service node and the front-end page; matching the first connection message with target channel objects in a target channel set to obtain a matching result, wherein the target channel set stores channel objects generated after at least one front-end page connects with the target service node, and the target channel object includes at least the target channel identifier of the connection channel between the target front-end page and the target service node and the target account; and determining whether to generate a connection closure instruction based on the matching result, wherein the connection closure instruction instructs the target front-end page to generate a prompt message indicating that the target account has logged into another service node.

[0006] Secondly, embodiments of this application provide a single-user login detection device applied to a target service node. The device includes: a message acquisition module, used to acquire a first connection message from a message queue when a target front-end page establishes a connection with a target service node through a target account. The message queue stores connection messages sent by multiple service nodes, and the connection message includes at least the account used to log in to the service node and a channel identifier for the connection channel between the service node and the front-end page; a message matching module, used to match the first connection message with target channel objects in a target channel set to obtain a matching result. The target channel set stores channel objects generated after at least one front-end page connects with a target service node, and the target channel object includes at least the target channel identifier for the connection channel between the target front-end page and the target service node, and the target account; and an instruction generation module, used to determine whether to generate a connection closure instruction based on the matching result. The connection closure instruction instructs the target front-end page to generate a prompt message indicating that the target account has logged into another service node.

[0007] Thirdly, embodiments of this application provide an electronic device, which includes: a processor and a memory storing computer program instructions; the processor executes the computer program instructions to implement the single-user login detection method as described in the first aspect.

[0008] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the single-user login detection method as described in the first aspect.

[0009] Fifthly, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform the single-user login detection method as described in the first aspect.

[0010] As described above, in this embodiment, since the same account logs in from different locations, the service nodes providing the service are different. Each service node also locally stores all accounts logged into that service node and the corresponding channel identifier for each account. Therefore, the service node can retrieve the first connection message at the head of the message queue and match it with the locally stored account and its corresponding channel identifier to determine whether the account has logged into other service nodes. This process eliminates the need for service nodes to provide filters or interceptors, and also eliminates the need for periodic polling by the front-end web server, thereby reducing performance overhead for both the front-end web server and the back-end service nodes. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a diagram illustrating single-user login in related technologies;

[0013] Figure 2 This is a system architecture diagram of a single-user login detection method provided in one embodiment of this application;

[0014] Figure 3 This is a flowchart illustrating a single-user login detection method provided in one embodiment of this application;

[0015] Figure 4 This is a single-user login detection interaction diagram provided in one embodiment of this application;

[0016] Figure 5 This is a schematic diagram of the structure of a single-user login detection device provided in another embodiment of this application;

[0017] Figure 6 This is a schematic diagram of the structure of an electronic device provided in another embodiment of this application. Detailed Implementation

[0018] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0019] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0020] To facilitate understanding, before explaining the solution provided in this application, the background of the solution provided in this application will be explained first.

[0021] Single-user login means that only one user is allowed to log in to the same account at the same time. For example, in Figure 1 In the single-user login diagram shown, user A logs into a service node in the distributed system using the same account, and then user B logs into the distributed system using the same account. After user B successfully logs in, user A is automatically logged out.

[0022] It should be noted that, in Figure 1 In this context, User A and User B represent users who log in to the distributed system using the same account on different devices.

[0023] To implement single-user login, related technologies involve the backend service node generating an authorization token after successful login and storing the user information (e.g., account) and the authorization token in a key-value database (Redis). The backend service node adds a filter (or interceptor) to the corresponding routing message. The frontend web application uses a timer to request the relevant interface at fixed intervals, and the backend service node performs filtering. If the authorization token passed to the backend service node's filter does not match the corresponding user's authorization token in the Redis database, a message is displayed indicating that the account is already logged in elsewhere, prompting the user to log in again. Simultaneously, the frontend web application redirects to the login page, automatically logging the account out.

[0024] Alternatively, in related technologies, instead of using authorization tokens, single-user login can be achieved by combining a key-value database like Redis with session sharing in a distributed system. This approach typically requires backend service nodes to add filters or interceptors, and the frontend web application to periodically request the relevant API to enable single-user login.

[0025] Both of the above methods for implementing single-user login require the front-end web server to periodically poll, and the back-end service nodes need to provide filters or interceptors, which increases the performance overhead of the front-end and back-end.

[0026] Furthermore, in related technologies, single-user login solutions typically target a single device, not a single user. This means that while the same account can be automatically logged out when logged in simultaneously on different devices, it cannot be automatically logged out when the same account is logged in simultaneously on the same device. For example, on the same terminal device, if a user logs in to an account using browser 1 and simultaneously logs in to the same account using browser 2 (different from browser 1), the account associated with browser 1 will not automatically log out.

[0027] To address the aforementioned shortcomings, this application provides a method, apparatus, electronic device, and storage medium for detecting single-user login. Specifically, the method, based on token-based Redis single-user login, utilizes Netty WebSocket and RabbitMQ to enable real-time detection of logged-in accounts by the web front-end of a distributed system. In this solution, a custom NioSocketChannel class object is defined on the service node of the WebSocket communication protocol in the Netty network application framework and stored in the local ChannelGroup and RabbitMQ message queue. This enables the establishment and closure of WebSocket connections across multiple nodes, and combined with the connection status monitored by the front-end web interface, real-time detection of account logout is achieved.

[0028] As an example, Figure 2 The system architecture diagram of the method provided in the embodiments of this application is shown. Figure 2 As can be seen, the system architecture mainly includes three layers: the front-end interaction layer, the back-end service layer, and the component layer. The front-end web layer is deployed in the front-end interaction layer, used for interacting with users, obtaining user login accounts, and displaying login notifications. The back-end service layer deploys a gateway service that communicates with the front-end web layer, as well as a back-end microservice cluster. The back-end microservice cluster provides Netty WebSocket services and other business services. The component layer provides the RabbitMQ cluster, Redis cluster, and other components required for single-user login.

[0029] exist Figure 2 In this system, single-user login is implemented using Netty's WebSocket service and RabbitMQ message queue. After the front-end Web listens for the connection closing command of the back-end service node, it generates a prompt message to inform the user that the account has been logged in elsewhere. After a period of time (e.g., a few seconds), the front-end Web redirects to the corresponding login page. The entire process can achieve automatic account logout without the front-end Web using timers to call the interface, reducing the performance loss between the front-end and back-end.

[0030] The single-user login detection method provided in the embodiments of this application is described below. The method provided in the embodiments of this application is explained from the perspective of the target service node, wherein the target service node is any service node deployed in the Web distributed system.

[0031] Figure 3 A flowchart illustrating a single-user login detection method according to an embodiment of this application is shown. Figure 3 As shown, the method includes the following steps:

[0032] Step S301: If it is detected that the target front-end page has established a connection with the target service node through the target account, the first connection message is obtained from the message queue.

[0033] In step S301, the target front-end page is the web page used by the user to log in to the target service node; for example, the target front-end page can be a web browser. Correspondingly, the target account is the account used by the user to log in to the target service node.

[0034] In step S301, the message queue is stored in the message server. Both the message server and the service nodes are deployed in the Web distributed system. In this embodiment, the message queue can be a queue in a RabbitMQ server, which acts as a message broker and queue server, allowing data sharing between different applications via communication protocols. All service nodes deployed in the Web distributed system can access the message queue in the message server. This message queue stores connection messages sent by multiple service nodes. Each connection message includes at least the account used to log in to the service node and a channel identifier for connecting the service node to the front-end page. The first connection message is the first connection message at the head of the message queue. Multiple service nodes retrieve the first connection message from the message queue at a certain frequency, or the message server sends the first connection message to multiple service nodes at a preset period. These service nodes can then query their local channel sets for a channel object matching the first connection message.

[0035] It should be noted that when the front-end web logs into the target service node through different accounts, a connection channel is established between the front-end web and the target service node, and the channel identifier of the connection channel is stored locally on the target service node. That is, what the target service node stores locally is the channel identifier of the connection channel connecting to the target service node. When the same account logs into different service nodes, the channel identifier of the account is different on different service nodes.

[0036] In this embodiment of the application, the connection channel can be implemented through a channel object, wherein the channel object can be a NioSocketChannel class object defined by the server side of Nettyd WebSocket.

[0037] As an example, after the target service node establishes a communication connection with the target front-end page, such as through a WebSocket connection, the target service node retrieves the first connection message from the head of the message queue, or the message server retrieves the first connection message from the head of the message queue and broadcasts the first connection message to all service nodes deployed in the Web distributed system, so that all service nodes can receive the first connection message.

[0038] Step S302: Match the first connection message with the target channel objects in the target channel set to obtain the matching result.

[0039] In step S302, each service node locally stores a channel set. The channel set corresponding to the target service node is called the target channel set. The target channel set stores the channel objects generated after at least one front-end page connects to the target service node. Since each front-end page corresponds to an account, the target channel set essentially stores the channel objects corresponding to the account that logs into the target service node. In this embodiment, the target channel object includes at least the target channel identifier and the target account of the connection channel between the target front-end page and the target service node. For example, the target front-end page logs into the target service node using account 1, and the target service node establishes a connection channel to realize communication between the target front-end page and the target service node. The channel identifier and account 1 of this connection channel are written into the channel object, and the target channel object is stored in the target channel set of the target service node.

[0040] As an example, the process of matching the first connection message with the channel objects in the target channel set essentially involves comparing the account and channel identifier in the first connection message with the account and target channel identifier in the target channel object corresponding to the target account in the target channel set, respectively, to obtain the matching result. This matching result mainly includes three types: the account in the first connection message is the same as the account in the target channel object, but the channel identifier is different; the account in the first connection message is the same as the account in the target channel object, and the channel identifier is also the same; the channel identifier in the first connection message is different from the account in the target channel object.

[0041] Step S303: Determine whether to generate a connection closure command based on the matching result.

[0042] In step S303, the connection closure command is used to instruct the target front-end page to generate a prompt message, which indicates that the target account has logged into other service nodes.

[0043] As an example, if the account in the first connection message is the same as the target account, but the channel identifier is different, it is determined that the target account has already logged into another service node. In this case, to achieve single-user login for the same account, in this embodiment, the target service node calls the `close` method to close the connection between the target front-end page and the target service node, generates a connection close instruction, and sends the instruction to the target front-end page. When the target front-end page hears the connection close instruction, it generates a prompt message to inform the user that the account has already logged in elsewhere; after waiting for a period of time (e.g., a few seconds), the target front-end page redirects to the login page, thus achieving the offline status of the target account, i.e., single-user login.

[0044] Based on the scheme defined in steps S301 to S303 above, it can be understood that in this embodiment, since the same account logs in from different locations, the service nodes providing the service are different. Each service node also locally stores all accounts logged into that service node and the channel identifier corresponding to each account. Therefore, the service node can retrieve the first connection message at the head of the message queue and determine whether the account has logged into other service nodes by matching the first connection message with the locally stored account and its corresponding channel identifier. This process does not require service nodes to provide filters or interceptors, nor does it require periodic polling by the front-end web server, thus reducing the performance overhead of both the front-end web server and the back-end service nodes.

[0045] The implementation process of steps S301 to S303 above will be explained below.

[0046] Before retrieving the first connection message from the message queue, a communication connection needs to be established between the target front-end page and the target service node.

[0047] Specifically, the target service node receives a login request from the target front-end page containing at least the target account; then, it generates an authorization token based on the login request and returns the authorization token to the target front-end page, causing the target front-end page to generate and send a communication connection request containing at least the target account; next, it receives the communication connection request, generates a target channel object based on the communication connection request, writes the target account into the target channel object, and stores the target channel object in the target channel set corresponding to the target service node; finally, it establishes a communication connection between the target front-end page and the target service node based on the target channel object.

[0048] In one example, a user sends a login request via a front-end web application (i.e., the target front-end page), and the target service node controls single-user login through a key-value database, Redis. When the user initiates the login request via the front-end web application, they enter the target account's userID. Upon receiving the login request, the target service node obtains the target account, generates an authorization token based on the target account, caches the target account's userID and the authorization token in the key-value database Redis, and then returns the authorization token to the front-end web application.

[0049] After receiving the authorization token from the target service node, the front-end web application initiates a WebSock communication connection request, passing the target account's userID during the handshake. The target service node sets the target account's userID into the userID field of the Netty-customized NioSocketChannel class object (i.e., the target channel object), and saves the NioSocketChannel class object to the target service node's local ChannelGroup object (i.e., the target channel collection). Thus, the front-end web application can communicate with the target service node through the NioSocketChannel class object, thereby establishing a communication connection between the front-end web application and the target service node.

[0050] It should be noted that in the above example, Netty can support extending custom classes by inheriting the NioSocketChannel class. The userID in this class is a member variable that can be used to store the target account.

[0051] In addition, it should be noted that since the target front-end page and the target service node establish a communication connection through the target channel object, the corresponding channel object is different when the same account logs into different target service nodes. Therefore, it is possible to determine whether to log the account offline based on the target channel identifier of the target channel object, without the need for the target front-end page to poll periodically, thus reducing the performance consumption of the front-end page.

[0052] Furthermore, after establishing a communication connection between the target front-end page and the target service node, it is also necessary to check whether the communication connection was established successfully. If the communication connection fails to establish, the target service node removes the target channel object from the target channel set. That is, when the WebSocket connection fails to establish, the target service node removes the custom NioSocketChannel class object from the ChannelGroup object; simultaneously, the front-end web server will also clear the information related to the authorization token from its local storage and prompt the user that login failed.

[0053] Once the communication connection is successfully established, the target service node generates a second connection message based on the target channel identifier and the target account of the target channel object, and sends the second connection message to the message queue of the message server. The second connection message includes at least the target channel identifier and the target account. That is, after the WebSocket connection is successfully established, the front-end web interface prompts the user that login was successful, and simultaneously, the target service node publishes the target channel identifier (channelID) and member variable (userID) of the custom NioSocketChannel class object to the RabbitMQ message queue.

[0054] It should be noted that in this embodiment, the message queue can be a sequential queue that follows the first-in-first-out principle. Therefore, the message server places the second connection message corresponding to the target channel identifier channelID and the member variable userID at the tail of the message queue RabbitMq. When retrieving a connection message from the message queue RabbitMq, the connection message is retrieved from the head of the message queue RabbitMq.

[0055] Furthermore, it's important to note that since all connection messages from service nodes deployed in the Web distributed system are sent to a message queue, and this message queue is a sequential queue, the order of connection messages for all service nodes is guaranteed. To ensure reliable delivery of connection messages, the target service node retryes on failures during the process of sending the connection message to the message server. This is further enhanced by the use of a key-value database like Redis to ensure the reliability of connection messages containing the channel identifier and target account, while maintaining good performance.

[0056] Specifically, the target service node determines the message identifier corresponding to the second connection message and stores the message identifier and the second connection message in the key-value database. If the second connection message fails to be sent, the number of times it is sent in the key-value database is updated, and if the number of times it is sent is less than or equal to a preset threshold, the second connection message and the message identifier corresponding to the second connection message are sent to the message queue of the message server.

[0057] In the above embodiments, the key-value database can be a Redis database. Each piece of data in the key-value database includes at least a key and a hash map. The key includes at least a message identifier, and the hash map includes at least the target account, the account and channel identifier in the second connection message, the sending status of the second connection message, and the number of times the second connection message has been sent.

[0058] As an example, after generating the second connection message, the target service node generates a globally unique message identifier (msgID) for the second connection message and stores it in a key-value database (Redis) using AOF (Append Only File) persistence. In the Redis database, the message identifier (msgID) serves as the key, and the account and channel identifiers from the second connection message, along with the message's sending status and number of sends, form a hash map. The sending status of the second connection message includes both successful and failed sending states.

[0059] To ensure the reliability of connection message delivery, the target service node also monitors the sending status and number of times connection messages are sent in real time. If the number of times the messages are sent is less than or equal to a preset threshold, and the second connection message and its corresponding message identifier are successfully sent to the message queue, the target service node updates the sending status in the key-value database to a successful status; if the number of times the messages are sent exceeds the preset threshold, the target service node updates the sending status in the key-value database to a failed status.

[0060] In the event of a connection message sending failure, the message server returns a notification of connection message sending failure to the target service node. Upon receiving this notification, the target service node checks the key-value database to see if the number of times the connection message has been sent has reached a preset threshold. If the threshold has not been reached, the target service node resends the connection message to the message server, updates the sending status of the corresponding connection message in the key-value database to a sending failure status, and increments the sending count by 1. This process continues until the sending count reaches the preset threshold, at which point the target service node stops sending connection messages to the message server. If the target service node successfully sends the connection message to the message server, it receives a sending success notification from the message server and updates the sending status of the corresponding connection message in the key-value database to a sending success status.

[0061] As can be seen, the key-value database is used to record the sending status and number of times the connection message is sent. As long as the number of times the connection message is sent does not exceed the preset threshold, the target service node can keep sending the connection message to the message server until the connection message is successfully sent to the message server, thus ensuring the reliability of the connection message delivery.

[0062] Furthermore, after the target front-end page establishes a connection with the target service node through the target account, the target service node matches the first connection message with the target channel object in the target channel set to obtain the matching result.

[0063] Specifically, the target service node compares the account in the first connection message with the target account, and the channel identifier in the first connection message with the target channel identifier. If the account in the first connection message is the same as the target account, but the channel identifier in the first connection message is different from the target channel identifier, a first matching result is obtained. If the account in the first connection message is the same as the target account, and the channel identifier in the first connection message is the same as the target channel identifier, a second matching result is obtained. If the account in the first connection message is different from the target account, a third matching result is obtained.

[0064] It's important to note that connection messages are cached in a message queue. If connection messages in the message queue are not processed promptly, false offline detections may occur. For example, user A logs into the first service node using the target account. After successful login, the first service node stores the connection message for user A at the tail of the message queue. User B then logs into the second service node using the same target account. After successful login, the second service node stores the connection message for user B at the tail of the message queue and retrieves the connection message from the head of the queue. If connection messages in the message queue are not processed promptly, the second service node might retrieve the connection message for user A. Since user A uses the same account as user B but uses different connection channels, the second service node might log user B offline, while user A's account remains online.

[0065] To address the aforementioned issues, in this embodiment, when the matching result is the first matching result, it is also necessary to compare the generation time of the first connection message with the generation time of the target channel object, and then determine whether to generate a connection closure instruction based on the comparison result; wherein, if the generation time of the first connection message is later than the generation time of the target channel object, it is determined to generate a connection closure instruction; if the generation time of the first connection message is earlier than the generation time of the target channel object, it is prohibited to generate a connection closure instruction.

[0066] Taking the example of the second service node detecting a connection message corresponding to user A after logging in, when the second service node detects a connection message with the same account but a different channel identifier, the second service node continues to check whether the generation time of the connection message is later than the generation time of the channel object corresponding to the second service node. If so, it means that the account corresponding to the connection message logged in after user B, and at this time, the second service node performs a logout operation on user B's account; if not, it means that the account corresponding to the connection message logged in before user B, and at this time, the second service node does not perform any operation on user B's account, maintaining the login status of user B's account.

[0067] Furthermore, if the matching result is the second or third match result, the target service node is prohibited from generating a connection close command. That is, if the matching result is the second or third match result, the target service node will continue to maintain the login status of the target account.

[0068] As an example, Figure 4 The diagram illustrates the interaction process for single-user login detection. This interaction mainly involves the user, the front-end web interface, the service node, and the message server. Figure 4 As shown, the interaction process mainly includes the following steps:

[0069] Step S401: User A logs in using the target account userID;

[0070] Step S402: The front-end Web sends a login request to the service node S1;

[0071] In step S403, service node S1 obtains the target account userID, generates an authorization token, and caches the userID and token in the key-value database Redis;

[0072] Step S404: Service node S1 returns a token to the front-end Web;

[0073] Step S405: The front-end Web initiates a WebSocket connection request, and enters the target account userID during the handshake process;

[0074] Step S406: Service node S1 sets the userID to the userID variable of the NioSocketChannel class object, and then saves the NioSocketChannel class object to the local ChannelGroup object;

[0075] Step S407: Service node S1 sends a message indicating that the WebSocket connection has been successfully established to the front-end Web server.

[0076] Step S408: The front-end web interface prompts the user that login was successful;

[0077] Step S409: The front-end Web sends a ping to the service node S1 to maintain the link;

[0078] Step S410: Service node S1 publishes the message to the message queue of the message server;

[0079] Step S411: User B logs in using the target account userID;

[0080] Step S412: The front-end Web sends a login request to the service node S2;

[0081] In step S413, service node S2 obtains the target account userID, generates an authorization token, and caches the userID and token in the key-value database Redis;

[0082] Step S414: Service node S2 returns a token to the front-end Web;

[0083] Step S415: The front-end Web initiates a WebSocket connection request, and enters the target account userID during the handshake process;

[0084] Step S416: Service node S2 sets the userID to the userID variable of the NioSocketChannel class object, and then saves the NioSocketChannel class object to the local ChannelGroup object;

[0085] Step S417: Service node S2 sends a message indicating that the WebSocket connection has been successfully established to the front-end Web server.

[0086] Step S418: The front-end web interface prompts the user that login was successful;

[0087] Step S419: The front-end Web sends a ping to the service node S2 to maintain the link;

[0088] In step S420, service node S2 publishes the message to the message queue of the message server;

[0089] Step S421: Service node S1 listens to the message queue, consumes messages in the message queue, and when it detects a message with the same account but a different NioSocketChannel object, it calls the close method to close the connection and removes the NioSocketChannel object from the local ChannelGroup object of service node S1.

[0090] Step S422: Service node S1 closes the WebSocket connection established by user A upon login;

[0091] In step S423, the front-end Web detects that the WebSocket connection is closed, generates a prompt message indicating that the account has been logged in elsewhere, and automatically redirects to the login page after a period of time;

[0092] Step S424: The front-end web displays a prompt message to the user;

[0093] In step S425, service node S2 continues to listen to the message queue, consume messages, and compare the account and channel identifier in the message with the NioSocketChannel class object in the local ChannelGroup object of service node S2. Since the userID is the same and the channel identifier of the custom NioSocketChannel class object is the same, service node S2 does not perform any processing.

[0094] It should be noted that, in Figure 4 In this context, User A and User B are used only to represent the same account logging into different service nodes. User A and User B can be the same user. For example, if a user logs in on Browser 1 using the target account and simultaneously logs in on Browser 2 using the same target account, Browser 1 and Browser 2 can be on the same terminal device.

[0095] Based on the above, compared with related technologies, in the solution provided by the embodiments of this application, the front-end Web can detect in real time whether the same account logs into other service nodes at the same time, without the need for the front-end Web to poll periodically, thereby solving the problem of front-end and back-end performance loss caused by front-end Web periodic polling and reducing the back-end performance loss in single user login.

[0096] This application also provides a single-user login detection device, applied to a target service node, such as... Figure 5 As shown, the device 500 includes: a message acquisition module 501, a message matching module 502, and an instruction generation module 503.

[0097] The message acquisition module 501 is used to acquire a first connection message from a message queue when it is detected that the target front-end page has established a connection with the target service node through the target account. The message queue is used to store connection messages sent by multiple service nodes. The connection message includes at least the account that logs into the service node and the channel identifier of the connection channel used to connect the service node and the front-end page.

[0098] The message matching module 502 is used to match the first connection message with the target channel object in the target channel set to obtain the matching result. The target channel set is used to store the channel object generated after at least one front-end page connects with the target service node. The target channel object includes at least the target channel identifier and the target account of the connection channel between the target front-end page and the target service node.

[0099] The instruction generation module 503 is used to determine whether to generate a connection closure instruction based on the matching result. The connection closure instruction is used to instruct the target front-end page to generate a prompt message, which indicates that the target account has logged into other service nodes.

[0100] In one example, the message matching module is specifically used to compare the account in the first connection message with the target account, and the channel identifier in the first connection message with the target channel identifier, respectively; if the account in the first connection message is the same as the target account, but the channel identifier in the first connection message is different from the target channel identifier, a first matching result is obtained; if the account in the first connection message is the same as the target account, and the channel identifier in the first connection message is the same as the target channel identifier, a second matching result is obtained; if the account in the first connection message is different from the target account, a third matching result is obtained.

[0101] In one example, the instruction generation module includes a time comparison module and a first generation module. The time comparison module is used to compare the generation time of the first connection message with the generation time of the target channel object when the matching result is a first matching result, and determine whether to generate a connection closure instruction based on the comparison result. The first generation module is used to prevent the generation of a connection closure instruction when the matching result is a second or third matching result.

[0102] In one example, the time comparison module is specifically used to determine whether to generate a connection closure instruction if the generation time of the first connection message is later than the generation time of the target channel object; and to prevent the generation of a connection closure instruction if the generation time of the first connection message is earlier than the generation time of the target channel object.

[0103] In one example, the single-user login detection device further includes: a connection establishment module, used to receive a login request sent by a target front-end page before obtaining a first connection message from a message queue, wherein the login request includes at least a target account; generate an authorization token based on the login request and return the authorization token to the target front-end page so that the target front-end page generates and sends a communication connection request, wherein the communication connection request includes at least a target account; receive the communication connection request and generate a target channel object based on the communication connection request; write the target account into the target channel object and store the target channel object in the target channel set corresponding to the target service node; and establish a communication connection between the target front-end page and the target service node based on the target channel object.

[0104] In one example, the single-user login detection device also includes an object removal module and a message sending module. The object removal module is used to remove the target channel object from the target channel set if the communication connection fails to be established. The message sending module is used to generate a second connection message based on the target channel identifier and target account of the target channel object if the communication connection is successfully established, and send the second connection message to the message queue of the message server.

[0105] In one example, the message sending module is specifically used to determine the message identifier corresponding to the second connection message; store the message identifier corresponding to the second connection message and the second connection message in a key-value database, wherein each piece of data in the key-value database includes at least a key and a hash map, the key includes at least the message identifier, the hash map includes at least the target account and the account and channel identifier in the second connection message, the sending status of the second connection message, and the number of times the second connection message has been sent; if the second connection message fails to be sent, update the number of times it has been sent in the key-value database, and if the number of times it has been sent is less than or equal to a preset threshold, send the second connection message and the message identifier corresponding to the second connection message to the message queue of the message server.

[0106] In one example, the message sending module is also used to update the sending status in the key-value database to a successful status when the number of sending attempts is less than or equal to a preset threshold and the second connection message and the message identifier corresponding to the second connection message are successfully sent to the message queue; and to update the sending status in the key-value database to a failed status when the number of sending attempts exceeds the preset threshold.

[0107] The single-user login detection device provided in this application embodiment can implement all the processes implemented in the aforementioned method embodiments, and will not be repeated here to avoid repetition.

[0108] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0109] Figure 6 A schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application is shown.

[0110] The electronic device may include a processor 601 and a memory 602 storing computer program instructions.

[0111] Specifically, the processor 601 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0112] Memory 602 may include mass storage for data or instructions. For example, and not limitingly, memory 602 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 602 may include removable or non-removable (or fixed) media. Where appropriate, memory 602 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 602 is non-volatile solid-state memory.

[0113] Memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the methods according to one aspect of this disclosure.

[0114] The processor 601 reads and executes computer program instructions stored in the memory 602 to implement any of the single-user login detection methods in the above embodiments.

[0115] In one example, the electronic device may also include a communication interface 603 and a bus 610. For example, Figure 6 As shown, the processor 601, memory 602, and communication interface 603 are connected through bus 610 and complete communication with each other.

[0116] The communication interface 603 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0117] Bus 610 includes hardware, software, or both, that couples components of an electronic device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 610 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, any suitable bus or interconnect is contemplated herein.

[0118] Furthermore, in conjunction with the single-user login detection method in the above embodiments, this application embodiment can provide a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when executed by a processor, these computer program instructions implement any of the single-user login detection methods in the above embodiments.

[0119] Furthermore, in conjunction with the single-user login detection method in the above embodiments, this application embodiment can provide a computer program product for implementation. When the instructions in this computer program product are executed by the processor of an electronic device, the electronic device performs any of the single-user login detection methods described in the above embodiments.

[0120] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0121] The functional modules shown in the above-described block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0122] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0123] The foregoing flowcharts and / or block diagrams describing single-user login detection methods, apparatuses, electronic devices, and storage media according to embodiments of this disclosure have described various aspects of the present disclosure. It should be understood that each block in the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to create a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowcharts and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by dedicated hardware performing the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0124] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A method for detecting single-user login, characterized in that, Applied to the target service node, including: When it is detected that the target front-end page has established a connection with the target service node through the target account, the first connection message is obtained from the message queue. The message queue is used to store connection messages sent by multiple service nodes. The connection message includes at least the account that logs into the service node and the channel identifier of the connection channel used to connect the service node and the front-end page. The first connection message is the first connection message located at the head of the message queue. The first connection message is matched with the target channel object in the target channel set to obtain a matching result. The target channel set is used to store the channel object generated after at least one front-end page is connected to the target service node. The target channel object includes at least the target channel identifier of the connection channel between the target front-end page and the target service node and the target account. Based on the matching result, it is determined whether to generate a connection closure instruction, wherein the connection closure instruction is used to instruct the target front-end page to generate a prompt message, and the prompt message is used to indicate that the target account has logged into other service nodes; If the matching result indicates that the account in the first connection message is the same as the target account, but the channel identifier in the first connection message is different from the target channel identifier, the generation time of the first connection message is compared with the generation time of the target channel object; if the generation time of the first connection message is later than the generation time of the target channel object, the connection closing instruction is determined to be generated; if the generation time of the first connection message is earlier than the generation time of the target channel object, the generation of the connection closing instruction is prohibited.

2. The method according to claim 1, characterized in that, The first connection message is matched with the target channel objects in the target channel set to obtain matching results, including: The account in the first connection message is compared with the target account, and the channel identifier in the first connection message is compared with the target channel identifier. If the account in the first connection message is the same as the target account, but the channel identifier in the first connection message is different from the target channel identifier, a first matching result is obtained; If the account in the first connection message is the same as the target account, and the channel identifier in the first connection message is the same as the target channel identifier, a second matching result is obtained; If the account in the first connection message is different from the target account, a third matching result is obtained.

3. The method according to claim 2, characterized in that, Determining whether to generate a connection closure command based on the matching results includes: If the matching result is the first matching result, the generation time of the first connection message is compared with the generation time of the target channel object, and it is determined whether to generate the connection closing instruction based on the comparison result; If the matching result is the second matching result or the third matching result, the generation of the connection closing command is prohibited.

4. The method according to claim 3, characterized in that, Compare the generation time of the first connection message with the generation time of the target channel object, and determine whether to generate the connection closing instruction based on the comparison result, including: If the generation time of the first connection message is later than the generation time of the target channel object, the connection closing instruction is determined to be generated; If the generation time of the first connection message is earlier than the generation time of the target channel object, the generation of the connection closure command is prohibited.

5. The method according to claim 1, characterized in that, Before retrieving the first connection message from the message queue, the method further includes: Receive a login request sent by the target front-end page, wherein the login request includes at least the target account; An authorization token is generated based on the login request, and the authorization token is returned to the target front-end page so that the target front-end page generates and sends a communication connection request, wherein the communication connection request includes at least the target account; Receive the communication connection request, and generate the target channel object based on the communication connection request; Write the target account into the target channel object, and store the target channel object into the target channel set corresponding to the target service node; A communication connection is established between the target front-end page and the target service node based on the target channel object.

6. The method according to claim 5, characterized in that, After establishing a communication connection between the target front-end page and the target service node based on the target channel object, the method further includes: If the communication connection fails to be established, the target channel object is removed from the target channel set; If the communication connection is successfully established, a second connection message is generated based on the target channel identifier of the target channel object and the target account, and the second connection message is sent to the message queue of the message server.

7. The method according to claim 6, characterized in that, Sending the second connection message to the message queue of the message server includes: Determine the message identifier corresponding to the second connection message; The message identifier corresponding to the second connection message and the second connection message are stored in a key-value database. Each piece of data in the key-value database includes at least a key and a hash map. The key includes at least a message identifier, and the hash map includes at least the target account, the account and channel identifier in the second connection message, the sending status of the second connection message, and the number of times the second connection message has been sent. If the second connection message fails to be sent, the number of times it is sent in the key-value database is updated, and if the number of times it is sent is less than or equal to a preset threshold, the second connection message and the message identifier corresponding to the second connection message are sent to the message queue of the message server.

8. The method according to claim 7, characterized in that, The method further includes: If the number of transmissions is less than or equal to the preset threshold, and the second connection message and the message identifier corresponding to the second connection message are successfully sent to the message queue, the transmission status in the key-value database is updated to a success status. If the number of transmissions exceeds the preset threshold, the transmission status in the key-value database will be updated to a failure status.

9. A single-user login detection device, characterized in that, Applied to the target service node, including: The message acquisition module is used to acquire a first connection message from a message queue when it is detected that the target front-end page has established a connection with the target service node through the target account. The message queue is used to store connection messages sent by multiple service nodes. The connection message includes at least the account of logging into the service node and the channel identifier of the connection channel used to connect the service node and the front-end page. The first connection message is the first connection message located at the head of the message queue. The message matching module is used to match the first connection message with the target channel objects in the target channel set to obtain a matching result. The target channel set is used to store channel objects generated after at least one front-end page connects with the target service node. The target channel object includes at least the target channel identifier of the connection channel between the target front-end page and the target service node and the target account. The instruction generation module is used to determine whether to generate a connection closure instruction based on the matching result, wherein the connection closure instruction is used to instruct the target front-end page to generate a prompt message, and the prompt message is used to indicate that the target account has logged into other service nodes; The instruction generation module is configured to, when the matching result indicates that the account in the first connection message is the same as the target account, but the channel identifier in the first connection message is different from the target channel identifier, compare the generation time of the first connection message with the generation time of the target channel object; if the generation time of the first connection message is later than the generation time of the target channel object, determine to generate the connection closing instruction; if the generation time of the first connection message is earlier than the generation time of the target channel object, prohibit the generation of the connection closing instruction.

10. An electronic device, characterized in that, Electronic devices include: processors and memory storing computer program instructions; When the processor executes the computer program instructions, it implements the single-user login detection method as described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, A computer-readable storage medium stores computer program instructions that, when executed by a processor, implement the single-user login detection method as described in any one of claims 1-8.

Images