A login control system and method for a microservice gateway

Abstract

This application provides a login control system and method based on a microservice gateway. In this system, a first client sends a first login request to the microservice gateway via an Nginx server; the first client is the client to be logged in. The microservice gateway responds to the first login request and determines whether the first client's login behavior conforms to a preset login policy based on a ticket list. The preset login policy limits the maximum number of simultaneous logins by the same user, with the same login type, or different login types. Login types include mobile application login and PC login. The microservice gateway also kicks out a second client if the first client's login behavior does not conform to the preset login policy. The second client is a client already logged into the business system, and the username of the second client is the same as that of the first client. This allows for user kickout and control of the login status of the same user in a clustered environment.

Description

Technical Field

[0001] This application relates to the field of Internet operation and maintenance management, and in particular to a login control system and method for a microservice gateway. Background Technology

[0002] In a multi-device login system, users are allowed to access the same account on multiple devices. In practice, this typically involves verifying user login on different devices (such as desktop and mobile), and implementing functions like user kickout and login restrictions based on business logic to control and manage user login status, ensuring security and a good user experience.

[0003] While Spring Security can be used to kick out users from business systems, it doesn't support this feature in clustered environments. Therefore, building a business system based on Spring Security doesn't meet actual user needs and results in a poor user experience. Summary of the Invention

[0004] This application provides a login control system and method for a microservice gateway to solve the problem that traditional login control methods do not meet the actual needs of users.

[0005] In a first aspect, embodiments of this application provide a login control system based on a microservice gateway, including: a client, an Nginx server, a microservice gateway, and a microservice cluster. The microservice cluster is formed by splitting a business system into multiple microservices based on a microservice architecture and deploying the multiple microservices on different servers. The client includes a mobile application and a PC.

[0006] The first client is used to send the first login request to the microservice gateway through the Nginx server. The first client is the client to be logged in. The first login request carries ticket information, which includes at least the username and login type identifier.

[0007] The microservice gateway responds to the first login request and determines whether the first client's login behavior conforms to the preset login policy based on a ticket list. The ticket list is formed based on ticket information, and the preset login policy limits the maximum number of simultaneous logins by the same user, the same login type, or different login types. Login types include login via mobile application, login via desktop application, and login via web application. The microservice gateway also kicks out a second client if the first client's login behavior does not conform to the preset login policy. The second client is a client already logged into the business system, and the username of the second client is the same as the first client's. Furthermore, the microservice gateway forwards the first login request to the microservice cluster if the first client's login behavior conforms to the preset login policy, or after kicking out a second client, so that the first client can log in and access the business system.

[0008] In one possible implementation, before sending the first login request to the microservice gateway via the Nginx server, the first client is further configured to send a second login request to the microservice gateway via the Nginx server. The second login request carries at least user information, including at least a username and password. The microservice gateway is further configured to authenticate the first client based on the second login request, and generate ticket information after successful authentication. The microservice gateway is further configured to send the ticket information to the first client via the Nginx server, and add the first client's username and login type identifier to the end of the ticket list. The ticket list includes a first entry and a second entry, where the first entry corresponds to the username and the second entry corresponds to the login type identifier. The first client is further configured to save the ticket information as cookie information.

[0009] In one possible implementation, the preset login policy is pre-configured based on a configuration page. The preset login policy includes at least a login type conflict policy and / or a login count conflict policy. The login type conflict policy includes situations where a first login type and a second login type are conflicting types. When the first client's login type is the first login type, the total login count of the second client with both the first and second login types is less than a first threshold. The login count conflict policy includes situations where the total login count of the second client with the same login type is less than a second threshold corresponding to that type. The first threshold is equal to the maximum value among the second thresholds corresponding to the first and second login types. In the step of determining whether the first client's login behavior conforms to the preset login policy based on the ticket list, the microservice gateway is specifically used to: retrieve a ticket list from a preset database; determine the login types of the first and second clients based on the ticket list; determine whether the login type conflict policy is effective; and, if the login type conflict policy is effective, determine whether the first client's login type is the first login type; if the first client's login type is the first login type... For each second client, iterate through the login types and determine if the total number of logins for second clients with login types of both the first and second login types is less than a first threshold. If the total number of logins for second clients with login types of both the first and second login types is less than the first threshold, the login behavior of the first client is determined to conform to the preset login policy. If the total number of logins for second clients with login types of both the first and second login types is not less than the first threshold, the login behavior of the first client is determined to not conform to the preset login policy. If the login type of the first client is not the first login type, and / or, in the case that the login type conflict policy is not in effect, determine if the total number of logins for second clients with the same login type as the first client is less than the second threshold corresponding to the type. If the total number of logins for second clients with the same login type as the first client is not less than the second threshold, the login behavior of the first client is determined to not conform to the preset login policy. If the total number of logins for second clients with the same login type as the first client is less than the second threshold, the login behavior of the first client is determined to conform to the preset login policy.

[0010] In one feasible approach, in the step of kicking out a second client when the login behavior of the first client does not conform to the preset login policy, the microservice gateway specifically performs the following: if the total number of logins of the second client with login types of both the first and second login types is not less than a first threshold, based on the order of the ticket list, determine the top N+1 second clients as kickable clients, where N equals the difference between the total number of logins of the second clients with login types of both the first and second login types and the first threshold; or, if the total number of logins of the second clients with the same login type as the first client is not less than a second threshold, according to the order of the ticket list, determine the top M+1 second clients with the same login type as the first client as kickable clients, where M equals the difference between the total number of logins of the second clients with the same login type as the first client and the second threshold corresponding to the type; and delete the username and login type identifier of the kickable client from the ticket list.

[0011] In one possible implementation, the kickout client is also used to send an access request to the microservice gateway via the Nginx server, the access request carrying ticket information; the microservice gateway is also used to respond to the access request, retrieve a ticket list from a preset database, and determine that the login type identifier of the kickout client is not in the ticket list; and the microservice gateway is also used to send a re-login notification to the kickout client via the Nginx server.

[0012] In one feasible approach, the client runs on a terminal device. When the client runs on a mobile terminal, the client is a mobile application, which includes iOS and Android applications.

[0013] In one possible implementation, the second client is also used to send a logout request to the microservice gateway via the Nginx server; the microservice gateway is also used to respond to the logout request by retrieving a ticket list from a preset database and deleting the second client's username and login type identifier from the ticket list.

[0014] In one possible implementation, the configuration page includes settings for a second threshold and whether the login type conflict policy is in effect.

[0015] In one feasible approach, the default database is a Redis database; the ticket information is in JWT lightweight format.

[0016] Secondly, this application provides a login control method based on a microservice gateway, applied to a login control system. The login control system includes: a client, an Nginx server, a microservice gateway, and a microservice cluster. The microservice cluster is formed by splitting a business system into multiple microservices based on a microservice architecture and deploying these microservices on different servers. The client includes a mobile application and a PC. The method includes: sending a first login request to the microservice gateway through the Nginx server; wherein the first login request is sent by a first client, which is the client to be logged in; the first login request carries ticket information, which includes at least a username and a login type identifier; responding to the first login request, based on the ticket list... The table determines whether the login behavior of the first client conforms to the preset login policy. The ticket list is formed based on ticket information. The preset login policy limits the maximum number of simultaneous logins by the same user, the same login type, or different login types. Login types include login via mobile application and login via PC. If the login behavior of the first client does not conform to the preset login policy, a second client is kicked out. The second client is a client already logged into the business system, and the username of the second client is the same as that of the first client. If the login behavior of the first client conforms to the preset login policy, or after kicking out a second client, the first login request is forwarded to the microservice cluster to allow the first client to log in and access the business system.

[0017] As can be seen from the above, this application provides a login control system and method based on a microservice gateway. The system includes: a client, an Nginx server, a microservice gateway, and a microservice cluster. The microservice cluster is formed by splitting a business system into multiple microservices based on a microservice architecture and deploying these microservices on different servers. The client includes a mobile application and a PC. A first client is used to send a first login request to the microservice gateway through the Nginx server. The first client is the client to be logged in. The first login request carries ticket information, which includes at least a username and a login type identifier. The microservice gateway responds to the first login request and determines whether the first client meets the preset criteria based on the ticket list. The system employs a login strategy. The ticket list is formed based on ticket information. A preset login strategy limits the maximum number of simultaneous logins by the same user, using the same login type, or different login types. Login types include login via mobile application and login via PC. The microservice gateway also kicks out a second client if the login behavior of the first client does not conform to the preset login strategy. The second client is a client already logged into the business system, and its username is the same as the first client's. Furthermore, the microservice gateway forwards the first login request to the microservice cluster if the first client's login behavior conforms to the preset login strategy, or after kicking out a second client, so that the first client can log in and access the business system. Thus, the system provided in this application embodiment can implement user kickout in a cluster environment, supporting access control for multiple clients (terminals), and especially controlling the login status of the same user. Moreover, this application embodiment can implement user kickout based on the gateway, achieving functional reuse without modifying the business system. Attached Figure Description

[0018] Figure 1 A schematic diagram of a first architecture of a login control system based on a microservice gateway provided in an embodiment of this application;

[0019] Figure 2 A schematic diagram of a second architecture of a login control system based on a microservice gateway provided in an embodiment of this application;

[0020] Figure 3 This is a schematic diagram illustrating a first interaction between a first client and a microservice gateway, provided in an embodiment of this application.

[0021] Figure 4 This is a schematic diagram illustrating a second interaction between a first client and a microservice gateway, provided in an embodiment of this application.

[0022] Figure 5 This is a schematic diagram of client state transitions provided in an embodiment of this application;

[0023] Figure 6A first schematic diagram of a configuration page for a preset login strategy provided in an embodiment of this application;

[0024] Figure 7 A flowchart illustrating the process of verifying whether a first client conforms to a preset login policy, provided in an embodiment of this application;

[0025] Figure 8 A second schematic diagram of the configuration page for the preset login strategy provided in the embodiments of this application;

[0026] Figure 9 This application provides an embodiment of the interaction diagram between the kickout client and the microservice gateway;

[0027] Figure 10 A schematic diagram illustrating the interaction between the second client and the microservice gateway provided in an embodiment of this application;

[0028] Figure 11 This is a flowchart illustrating the login control method based on a microservice gateway provided in an embodiment of this application. Detailed Implementation

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

[0030] Before introducing the technical solutions of the embodiments of this application, the terminology involved in the embodiments of this application will be introduced by way of example.

[0031] Microservice architecture is an architectural concept that breaks down a large, single application or service into several or even dozens of small, independent microservices. Each microservice can be developed, deployed, and scaled independently, typically communicating via APIs. Microservice architecture is characterized by flexibility, scalability, ease of maintenance, and technical diversity.

[0032] A microservice architecture mainly includes several key components such as the client, backend servers / microservices (microservices), and the microservices gateway.

[0033] (1) Client: The entry point for users to interact with the microservice architecture. Clients include, for example, web browsers and mobile applications. Specifically, the client provides the user interface, facilitating user input of commands and viewing of information. The client also sends HTTP requests to the microservice gateway or backend server in the microservice architecture based on user actions to obtain the required data or services. Furthermore, the client receives the corresponding data returned by the microservice gateway and displays it to the user in the user interface.

[0034] (2) Backend Servers (Microservices): Backend servers are the actual business logic processing units in a microservice architecture. Each microservice typically corresponds to one or more backend server instances. Backend servers are used to execute corresponding business logic processing based on client requests, such as database queries and data calculations. Backend servers are also used to store the processing results in the database for later use and querying. Furthermore, backend servers are used to encapsulate the processing results into response data and return it to the microservice gateway.

[0035] (3) Microservice gateway: A middleware layer used to manage communication between different services in a microservice architecture. The microservice gateway forwards client requests to the corresponding backend servers according to routing rules, receives response data from the backend servers, and then returns it to the client.

[0036] The use of microservice gateways can significantly improve the flexibility, maintainability, and security of microservice architectures. Common microservice gateway tools include Nginx, Kong, Zuul, and Spring Cloud Gateway.

[0037] A multi-device login system refers to a system that allows users to log in and use the same account (username) simultaneously on multiple devices (such as mobile phones, tablets, and computers). This type of system is becoming increasingly common in modern applications, especially in areas such as social media, online shopping, financial services, and enterprise management. Its main purpose is to improve user experience, enabling users to easily access the same services and data across different environments and devices.

[0038] As can be seen, a multi-device login system allows users to access the same account on multiple devices. In practical applications, this typically includes user login verification on different devices (such as desktop and mobile devices), and implementing functions such as user kickout and login restrictions based on business logic to control and manage user login status, ensuring security and a good user experience.

[0039] While Spring Security can be used to kick out users from business systems, it doesn't support this feature in clustered environments. Therefore, building a business system based on Spring Security doesn't meet actual user needs and results in a poor user experience.

[0040] In addition, there are other methods to implement user removal. For example, one method uses session management, creating a session and storing login information when a user logs in, then checking the consistency between the old and new sessions to remove the previous user. However, this method requires replicating sessions across nodes in a clustered environment, increasing memory overhead and limiting the number of concurrent logins per account. Another method is using a global Map variable. When a user logs in, their information and session are stored in this Map. If the user logs in again, the current session is compared with the session stored in the Map. If they don't match, it's considered a remote login, and the previous user can be removed one by one. However, this solution also doesn't support clustering.

[0041] Figure 1 This is a schematic diagram of a first structure of a login control system based on a microservice gateway provided in an embodiment of this application.

[0042] Figure 2 This is a schematic diagram of a second structure of a login control system based on a microservice gateway provided in an embodiment of this application.

[0043] like Figure 1 and Figure 2 As shown in the figure, this application provides a login control system based on a microservice gateway, including: a client 100, an Nginx server 200, a microservice gateway 300, and a microservice cluster 400.

[0044] The microservice cluster 400 is formed by splitting a business system into multiple microservices based on a microservice architecture and deploying these microservices on different servers. Business systems may include, for example, enterprise information management systems, financial service systems, and Internet of Things (IoT) platforms; this application embodiment does not specifically limit the types of systems described.

[0045] Continue to see Figure 1The microservice cluster 400 can be built based on the Apollo-Eureka-Config unified registry center and the Apollo-admin unified configuration center. Spring Boot Service A, Spring Boot Service B, and Spring Boot Service C represent different microservices. See also... Figure 2 Microservices may specifically include a configuration management database (CMDB) and knowledge management (KM). In practical applications, business systems may also include other microservices, but this application does not specifically limit this.

[0046] Client 100 may include a mobile application and a PC. When client 100 runs on a mobile terminal, client 100 is specifically a mobile application. When the mobile terminal is an iOS terminal, client 100 can be an iOS terminal, and the login type is iOS login. When the mobile terminal is an Android terminal, client 100 can be an Android terminal, and the login type is Android login.

[0047] In some implementations, the PC client may include a desktop application and a web application (Web App). When client 100 runs on a PC, client 100 can specifically be a web application, and the login type is login via the web application. It is understood that a web application refers to an application accessed or used through a browser, which does not require local installation; it only needs to connect to the server (microservice cluster 400) via the network to obtain services. When client 100 runs on a PC, client 100 can also be a desktop application, and the login type is login via the desktop application. It is understood that a desktop application refers to an application that needs to be installed locally on the PC. In this embodiment, the web application and the desktop application can run simultaneously on the same PC and can log in simultaneously.

[0048] In other words, users can log in from multiple devices, including native applications on iOS devices, native applications on Android devices, desktop applications on PCs, web browsers on PCs, or web browsers on both iOS and Android devices.

[0049] Nginx Server 200 is a high-performance HTTP and reverse proxy server used to handle tasks such as request forwarding, load balancing, and SSL encryption from client 100 to microservice gateway 300.

[0050] Microservice Gateway 300 can be a Spring Cloud gateway, acting as an intermediary between client 100 and microservice cluster 400. Microservice Gateway 300 can handle all incoming requests, including authentication, authorization, routing, rate limiting, monitoring, and logging. The specific working steps of Microservice Gateway 300 will be detailed below.

[0051] In some implementations, the client 100 and the Nginx server 200 can communicate via protocols such as HTTP / HTTPS, WebSocket, and TCP / IP, and the Nginx server 200 and the microservice gateway 300 can communicate via protocols such as HTTP / RESTful API and gRPC. This application embodiment does not specifically limit this.

[0052] In this embodiment, client 100 can be either a first client 101 or a second client 102. First client 101 is the client 100 waiting to log into the business system, and second client 102 is the client 100 already logged into the business system. The username (admin / user / id) used by second client 102 is the same as that used by first client 101, i.e., the account is the same. For example, the usernames of first client 101 and second client 102 are both admin1, user1, or id1.

[0053] Figure 3 This is a schematic diagram illustrating a first interaction between a first client and a microservice gateway, as provided in an embodiment of this application.

[0054] Further, such as Figure 3 As shown, the first client 101 performs the following step S101: It sends a second login request to the microservice gateway 300 through the Nginx server 200. The second login request carries at least user information, including at least a username and password, used to verify the user's identity. This step can be understood as the first client 101 actively accessing the microservice application interface.

[0055] Continue to see Figure 3 The microservice gateway 300 is used to perform the following steps S102: authenticate the first client 101 based on the second login request, and generate a token after successful authentication; wherein, a token is a data structure used to prove the user's identity or session state in network communication.

[0056] In this embodiment, the ticket information includes at least a username and a login type identifier. The format of the ticket information can be lightweight JWT (JSON Web Token), and this embodiment does not specifically limit this. Furthermore, the microservice gateway 300 can determine the login type by analyzing the request header of the second login request or by using a URL path, and this embodiment does not specifically limit this.

[0057] It is understandable that the microservice gateway 300 does not directly forward login requests to the backend server (microservice cluster 400). Instead, it first intercepts login requests and verifies the username and password. For example, the microservice gateway 300 can extract the username and password and compare them with the user database preset by the business system to verify whether the user's identity is genuine and valid. The microservice gateway 300 can also check the user's status, such as whether it is locked, expired, or has permission to access the corresponding service. This application embodiment does not specifically limit this aspect.

[0058] For example, the ticket information in a JWT structure can be as follows:

[0059] JWT Decoder.17Z7KGglUYp7MYYuJLSIdc6mNm nEPVcDf7zKiUemc try an exampletoken|JWT RFC

[0060] {

[0061] Typ:JWT",

[0062] alg:"HS256"

[0063] }

[0064] {

[0065] type:"user,

[0066] id:"root",

[0067] name: "Super Administrator"

[0068] consumer:"BIT-MSA",

[0069] tenantId:"admin",

[0070] secret_id:"D64D12C5E8F84A25B916AE0C927CDB23",

[0071] iss:"BIT_MASA"

[0072] iat:1725413464,

[0073] nbf:1725413464,

[0074] exp:1725420964,

[0075] }

[0076] [signature]

[0077] The JWT is defined as follows: "type": "user": indicates the JWT type is user. "id": "root": indicates the user's unique identifier is "root". "name": "super administrator": indicates the user's name is "super administrator". "consumer": "BIT-MSA": indicates the consumer or system name associated with the user. "tenantId": "admin": indicates the tenant ID associated with the user. "secret_id": "D64D12C5E8F84A25B916AE0C927CDB23": indicates a key or identifier associated with this user. "iss": "BIT_MASA": indicates the issuer of this JWT, specifically "BIT_MASA". "iat": 1725413464: indicates the JWT's issue time, expressed as a Unix timestamp. "nbf":1725413464: Indicates that this JWT is not available before the specified time (Not Before), expressed as a Unix timestamp. "exp":1725420964: Indicates the expiration time of this JWT (Expiration), expressed as a Unix timestamp.

[0078] In this embodiment, the microservice gateway 300 can also sign the ticket information with a key to ensure the authenticity and integrity of the ticket information. After the microservice gateway 300 sends the ticket information to the client 100, the client 100 can carry the ticket information when accessing the microservice gateway 300 subsequently. In this way, the microservice gateway 300 can use the key to verify the signature of the ticket information, i.e., signature verification. If the signature verification is successful, it means that the ticket information was issued by the microservice gateway 300, that is, the ticket information is authentic and valid.

[0079] The microservice gateway 300 is also used to perform the following steps S103: sending ticket information to the first client 101 through the Nginx server 200, and adding the username and login type identifier of the first client 101 to the end of the ticket list.

[0080] It is worth noting that the ticket list is a data structure that records all active sessions. A session refers to an interaction process established between the client 100 and the microservice gateway 300, used to store user status information and data. The ticket list may include a first entry and a second entry. The first entry records the username, and the second entry records the login type identifier. For example, the username can be use1, use2, etc., and the login type identifier can be web1, web2, IOS1, PC1, Android1, Android2, etc., or the login type identifier can be IOS client, Web browser 1, desktop application, Android client, Web browser 2, etc. This application embodiment does not specifically limit this. In this way, ticket information management can be realized.

[0081] In this embodiment, the list of tickets can be stored in a preset database, such as a Redis database, a Cassandra database, or a MySQL database. This embodiment does not specifically limit the database to this type.

[0082] The first client 101 is also used to perform the following step S104: save the ticket information as cookie information.

[0083] In some implementations, the first client 101 may also save the ticket information as local storage or session storage, but this application embodiment does not specifically limit this.

[0084] Figure 4 This is a schematic diagram illustrating a second interaction between a first client and a microservice gateway, as provided in an embodiment of this application.

[0085] Further, such as Figure 4 As shown, after authentication is complete, the first client 101 can also perform the following step S201: send a first login request to the microservice gateway 300 through the Nginx server 200. The first login request carries ticket information, i.e., carries a cookie. This step can also be understood as the first client 101 actively accessing the microservice application interface.

[0086] For further details, please refer to [link / reference]. Figure 4 The microservice gateway 300 is also used to perform the following steps S202: respond to the first login request and determine whether the first client 101 conforms to the preset login policy based on the ticket list; wherein, the ticket list is formed based on ticket information, and the preset login policy is used to limit the maximum number of logins of the same user, the same login type or different login types at the same time. The specific preset login policy will be detailed below and will not be repeated here.

[0087] Understandably, the microservice gateway 300 can check ticket information, verify that an account is bound to N tickets, and then determine the kick-out policy.

[0088] Furthermore, the microservice gateway 300 is also used to perform the following step S203: if the login behavior of the first client 101 does not conform to the preset login policy, a second client 102 is kicked out. In this way, the number of concurrent logins of the same user, the same login type or different login types can be limited. The same user can refer to the same account, that is, the username used for login is the same.

[0089] Furthermore, the microservice gateway 300 is also used to perform the following steps S204: if the login behavior of the first client 101 conforms to the preset login policy, or after kicking out a second client 102, the first login request is forwarded to the microservice cluster 400 so that the first client 101 can log in and access the business system.

[0090] Figure 5 This is a schematic diagram of client state transitions provided in an embodiment of this application.

[0091] It is understandable that, such as Figure 5 As shown, after the first client 101 logs into the business system, it can be referred to as the second client 102.

[0092] It is worth noting that kicking out includes at least the step of terminating the session between the second client 102 and the microservice cluster 400.

[0093] In this way, the system can flexibly manage user login behavior while ensuring the security and stability of the business system.

[0094] It's worth noting that forwarding the first login request to microservice cluster 400, enabling the first client 101 to log in and access the business system, can be accomplished by having the microservice gateway 300 include ticket information in its header when accessing microservice cluster 400. In other words, when forwarding the request, microservice gateway 300 places ticket information containing the user's identity in the HTTP request header to ensure that microservice cluster 300 can recognize and verify the legitimacy of the request.

[0095] As can be seen from the above, this application provides a login control system based on a microservice gateway. The system includes: a client 100, an Nginx server 200, a microservice gateway 300, and a microservice cluster 400. The microservice cluster 400 is formed by splitting a business system into multiple microservices based on a microservice architecture and deploying these microservices on different servers. The client 100 includes a mobile application and a PC client. A first client 101 is used to send a first login request to the microservice gateway 300 through the Nginx server 200. The first client 101 is the client 100 to be logged in. The first login request carries ticket information, which includes at least a username and a login type identifier. The microservice gateway 300 responds to the first login request and determines whether the first client 101 meets the pre-defined login requirements based on the ticket list. A login policy is established; the ticket list is formed based on ticket information. The preset login policy is used to limit the maximum number of logins by the same user, the same login type, or different login types simultaneously. Login types include login via mobile application and login via PC. The microservice gateway 300 is also used to kick out a second client 102 if the login behavior of the first client 101 does not conform to the preset login policy. The second client 102 is a client already logged into the business system, and the username of the second client 102 is the same as that of the first client 101. The microservice gateway 300 is also used to forward the first login request to the microservice cluster 400 if the login behavior of the first client 101 conforms to the preset login policy, or after kicking out a second client 102, so that the first client 101 can log in and access the business system. In this way, the system provided in this application embodiment can realize user kickout in a cluster environment, support access control of multiple clients (terminals), and especially control the login status of the same user. Furthermore, this application embodiment can realize user kickout based on the gateway, and achieve function reuse without modifying the business system.

[0096] The following section, with reference to the accompanying diagram, details the steps for verifying whether the first client 101 conforms to the preset login strategy.

[0097] The preset login policy is pre-configured based on the configuration page, which can be the user interface provided by the client 100. After the preset login policy is configured on the management side, the client 100 can store the preset login policy locally and send the preset login policy to the microservice gateway 300 through the Nginx server 200 so that the microservice gateway 300 can retain the preset login policy.

[0098] Example 1:

[0099] The preset login strategy includes at least a login type conflict strategy and / or a login count conflict strategy. The login type conflict strategy includes a first login type and a second login type being conflicting types. When the login type of the first client 101 is the first login type, the total number of logins of the second client 102 with login types of both the first and second login types is less than a first threshold. The login count conflict strategy includes a second client 102 with the same login type having a total number of logins less than a second threshold corresponding to the type. The first threshold is equal to the maximum value among the second thresholds corresponding to the first and second login types.

[0100] Figure 6 This is a first schematic diagram of the configuration page for the preset login strategy provided in the embodiments of this application.

[0101] like Figure 6 As shown, the configuration interface includes settings for the second threshold and whether the login type conflict policy is effective. Users can determine whether the login type conflict policy is effective by checking the checkboxes in the configuration interface (user interaction interface). When any checkbox is checked, the login type conflict policy is effective; when all checkboxes are unchecked, the login type conflict policy is not effective.

[0102] For example, when the "iOS cross-login" checkbox is checked, the default login type conflict policy takes effect. A cross-login relationship exists between clients logged in via iOS and clients logged in via PC. When an iOS client needs to log in as the first client, it needs to be checked whether the total number of logins for the second client logged in via iOS and PC is less than a first threshold. Similarly, when a PC client needs to log in, it also needs to be checked whether the total number of logins for the second client logged in via iOS and PC is less than the first threshold. It's important to understand that the first and second login types are not fixed but change according to user configuration. When the "Android cross-login" checkbox is checked, the default login type conflict policy takes effect, and a cross-login relationship exists between clients logged in via Android and clients logged in via PC.

[0103] Furthermore, if neither the "iOS cross-login" nor the "Android cross-login" checkboxes are selected, it indicates that the login type conflict policy is not in effect.

[0104] In some implementations, if both the "iOS cross-login" and "Android cross-login" checkboxes are selected, then there is a cross-login relationship between clients logging in via iOS and clients logging in via PC, and at the same time, there is a cross-login relationship between clients logging in via Android and clients logging in via PC. When the first client 101 on iOS needs to log in, it is necessary to determine whether the total number of logins of the second client 102 (login via iOS, Android, and PC) is less than a first threshold. In this case, the first login type is login via iOS, and the second login type is login via Android and login via PC.

[0105] Furthermore, in this embodiment, the second threshold corresponding to the login type via iOS can be 1, the second threshold corresponding to the login type via Android can be 1, and the second threshold corresponding to the login type via PC can be 3. In this case, when the iOS option is selected, or when the Android option is selected, the first threshold can be equal to the maximum value of the second thresholds corresponding to each type, that is, equal to the second threshold 3 corresponding to the login type via PC. The specific values ​​of the first and second thresholds can be determined based on actual circumstances, and this embodiment does not impose specific limitations on them.

[0106] In the step of determining whether the login behavior of the first client 101 conforms to the preset login policy based on the ticket list, the microservice gateway 300 is specifically used to execute the following steps S200-1 to S200-8.

[0107] S200-1: Retrieve a list of tickets from a preset database, and determine the login type of the first client 101 and the second client 102 based on the list of tickets.

[0108] This step can determine the login type of the first client 101 and the second client 102 based on the login type identifier. It is understood that different login types correspond to different login type identifiers.

[0109] S200-2: Determine whether the login type conflict policy is in effect, and if the login type conflict policy is in effect, determine whether the login type of the first client 101 is the first login type.

[0110] It is understood that whether the first login type and the second login type are conflicting types can be pre-configured based on the configuration page, and this application embodiment does not specifically limit this.

[0111] S200-3: If the login type of the first client 101 is the first login type, iterate through each second client 102 and determine whether the total number of logins of the second clients 102 with login types of the first login type and the second login type is less than the first threshold.

[0112] For example, if the login type of the first client 101 can be login via iOS, then it is necessary to determine the total number of logins of the second client 102 (login type via PC) and the second client 102 (login type via iOS) to determine whether it is less than the first threshold.

[0113] It is worth noting that in this embodiment, the login type via PC can only correspond to login via desktop application. In this case, when login via PC is the second login type, the number of logins via desktop application can be counted. Alternatively, the login type via PC can only correspond to login via web, in which case the number of logins via web can be counted. In some implementations, the login type via PC can include both login via desktop application and login via web. In this case, when login via PC is the second login type, the number of logins via desktop application and login via web can be counted. Based on this, the login count of the second client 102 of the first login type is then counted to obtain the total number of logins.

[0114] S200-4: If the total number of logins of the second client 102 with login types of the first login type and the second login type is less than the first threshold, it is determined that the login behavior of the first client 101 conforms to the preset login strategy.

[0115] For example, if the first threshold is 3, and the first login type is login via iOS, the total number of logins of the second client 102 via iOS and PC is 2, which is less than the first threshold. Therefore, the login behavior of the first client 101 conforms to the preset login policy, and there is no need to kick out the second client 102.

[0116] S200-5: If the total number of logins of the second client 102 with login types of the first login type and the second login type is not less than the first threshold, it is determined that the login behavior of the first client 101 does not conform to the preset login policy.

[0117] For example, if the first threshold is 3, and the first login type is login via iOS, the total number of logins of the second client 102 via iOS and PC is 3, which is not less than the first threshold. Therefore, the login behavior of the first client 101 does not conform to the preset login policy, and one of the second clients 102 needs to be kicked out.

[0118] S200-6: If the login type of the first client 101 is not the first login type, and / or, if the login type conflict policy is not effective, determine whether the total number of logins of the second client 102 with the same login type as the first client 101 is less than the second threshold corresponding to the type.

[0119] Understandably, when the login type of the first client 101 is not the first login type, or when the login type conflict policy is not in effect, it can be determined whether the login count of the second client 102, which has the same login type as the first client 1014, is less than the second threshold. For example, if the first client 101 logs in via iOS, the second threshold for the login type via iOS is equal to 1, and the "Android cross-login" checkbox is checked and the "iOS cross-login" checkbox is not checked in the configuration page, then it can be determined that the first client 101 is not the first login type. At this time, it can be further determined whether the total login count of the second client 102, whose login type is via iOS, exceeds 1.

[0120] Understandably, if the login type conflict policy does not take effect after step S200-2, you can proceed to step S200-6.

[0121] S200-7: If the total number of logins of the second client 102 with the same login type as the first client 101 is not less than the second threshold, it is determined that the login behavior of the first client 101 does not conform to the preset login policy.

[0122] For example, if the first client 101 logs in via iOS and the second threshold corresponding to the login type via iOS is equal to 1, then when the number of logins of the second client 102 via iOS is 1, which is not less than the second threshold, then one of the second clients 102 needs to be kicked out.

[0123] S200-8: If the total number of logins of the second client 102 with the same login type as the first client 101 is less than the second threshold, it is determined that the login behavior of the first client 101 conforms to the preset login strategy.

[0124] Furthermore, in the step of kicking out a second client 102 when the login behavior of the first client 101 does not conform to the preset login policy, the microservice gateway 300 can specifically be used to execute the following steps S300-1.

[0125] S300-1: If the total number of logins of the second client 102 with login types of the first login type and the second login type is not less than the first threshold, based on the sorting order of the ticket list, determine the top N+1 second clients 102 as clients that can be kicked out, where N is equal to the difference between the total number of logins of the second client 102 with login types of the first login type and the second login type and the first threshold.

[0126] In other words, the first N second clients to log in can be kicked out.

[0127] For example, if the first threshold is 3, and the first login type is login via iOS, the total number of logins for the second client 102 (login via iOS and login via PC) is 4. In this case, N equals 1, and the first N+1 logins of the second client 102 need to be kicked out, i.e., 2 second clients 102 need to be kicked out. For instance, if the first 2 logins of the second client 102 are from iOS and PC respectively, then these two second clients can be kicked out.

[0128] Alternatively, the microservice gateway 300 can also be used to perform the following steps S300-2.

[0129] S300-2: If the total number of logins of the second client 102 with the same login type as the first client 101 is not less than the second threshold, the top M+1 second clients 102 with the same login type as the first client 101 are determined as kick-out clients 103 according to the order of the ticket list. M is equal to the difference between the total number of logins of the second clients with the same login type as the first client and the second threshold corresponding to the type.

[0130] In other words, the second client 102, which logged in first and has the same login type as the first client 101, can be kicked out.

[0131] For example, when the login type of the first client 101 is login via Android and the second threshold corresponding to the login type via Android is equal to 1, the total number of logins of the second client 102 via Android is 3. At this time, M equals 2, and the first login of M+1 second clients 102 with the login type of login via Android needs to be kicked out, that is, 3 second clients 102 need to be kicked out.

[0132] Furthermore, the microservice gateway 300 can also be used to perform the following steps S300-3.

[0133] S300-3: Remove the username and login type identifier of the client 103 that can be kicked out from the ticket list.

[0134] This serves to maintain the list of invoices.

[0135] As can be seen, the method provided in the embodiments of this application can realize simultaneous login from multiple devices and mutual kicking between clients.

[0136] Example 2:

[0137] The preset login strategy includes at least a login count conflict strategy and a login type conflict strategy. The login count conflict strategy includes a situation where the total number of logins of the second client 102 of the same login type is less than the first preset threshold corresponding to the type. The login type conflict strategy includes a situation where the first client 101 of the first login type and the second client 102 of the second login type have a login conflict and cannot log in at the same time, or a situation where the first client 101 of the first login type and the second client 102 of the third login type do not have a login conflict and can log in at the same time.

[0138] For example, the first preset threshold for logging in via a desktop application or a web application can be 3. Similarly, the first preset threshold for logging in via an Android device can be 1, and the first preset threshold for logging in via an iOS device can be 1. The specific first preset threshold can be set based on the actual situation, and this application embodiment does not impose any specific limitations on it.

[0139] Furthermore, in this embodiment, a login type conflict strategy can be used to enable mutual disconnection between the desktop application and the web application. In this case, the desktop application is used as the first login type, and its corresponding second login type is login via the web application. In other words, if login via the web application is the first login type, its corresponding second login type is login via the desktop application. The login type conflict strategy can also be used to enable mutual disconnection between the web application and mobile applications (Android and / or iOS). In this case, the web application is used as the first login type, and its corresponding second login type is login via the mobile application. In other words, if login via the mobile application is the first login type, its corresponding second login type is login via the web application. The login type conflict strategy can also be used to enable mutual disconnection between Android and iOS. In this case, if login via Android is the first login type, its corresponding second login type includes login via iOS. In other words, if login via iOS is the first login type, its corresponding second login type includes login via Android.

[0140] Furthermore, embodiments of this application can enable simultaneous login via desktop application and mobile application (Android and / or iOS) based on a login type conflict strategy. In this case, login via desktop application is the first login type, and the corresponding third login type is login via mobile application (Android and / or iOS). In other words, login via mobile application is the first login type, and the corresponding third login type is login via desktop application.

[0141] It is worth noting that the login count conflict policy and login type conflict policy are set according to actual needs, and do not mean that the desktop application and the web application cannot log in at the same time.

[0142] Furthermore, in the step of determining whether the login behavior of the first client 101 conforms to the preset login policy, the microservice gateway 300 is specifically used to execute the following steps S221-S226.

[0143] S221: Retrieve a list of tickets from a preset database, and determine the login type of the first client 101 and the second client 102 based on the list of tickets.

[0144] This step can be determined based on the login type identifier corresponding to the first client 101. It is understood that different login types correspond to different login type identifiers.

[0145] S222: Using the login type of the first client 101 as the first login type, iterate through the login types of each second client 102 to determine whether there exists a second client 102 with the login type as the second login type.

[0146] In some implementations, S222 can also determine whether there is only a second client 102 with the third login type. If there is only a second client 102 with the third login type, it also means that there is no second client 102 with the second login type.

[0147] For example, when the login type of the first client 101 is login via desktop application, the second login type can be login via mobile application, and the third login type can be login via mobile application.

[0148] S223: If there is a second client 102 with a login type of the second login type, determine that the login behavior of the first client 101 does not conform to the preset login policy.

[0149] Understandably, based on the login type conflict policy, it can be determined that a client of the first login type and a client of the second login type cannot log in at the same time. Therefore, when a second client 102 of the second login type exists, the login behavior of the first client 101 of the first login type is illegal, and its login behavior does not comply with the login type conflict policy.

[0150] S224: If there is no second client 102 with the second login type, based on the ticket list, determine whether the total number of logins of the second client 102 with the same login type as the first client 101 is less than the first preset threshold corresponding to the type.

[0151] For example, if the login type of the first client 101 is login via iOS, then the total number of logins is equal to the number of second clients 102 that log in via iOS.

[0152] S225: If the value is not less than the first preset threshold, it is determined that the login behavior of the first client 101 does not conform to the preset login policy.

[0153] For example, if the first preset threshold for the login type via iOS is equal to 1, then when the login type of the first client 101 is login via iOS and the number of second clients 102 that log in via iOS is equal to 1, the total number of logins is equal to 1, which is not less than the first preset threshold and does not conform to the preset login strategy.

[0154] S226: If it is less than the first preset threshold, determine that the login behavior of the first client 101 conforms to the preset login policy.

[0155] For example, when there is no second client 102 that conflicts with the login type of the first client 101, and the number of second clients 102 with the same login type as the first client 101 is less than the first preset threshold corresponding to the type, it means that login can continue to be performed with that login type. Therefore, the login behavior of the first client 101 conforms to the preset login policy.

[0156] Furthermore, in step S203, the microservice gateway 300 is specifically used to execute the following steps S231-S233.

[0157] S231: If there is a second client with login type 2 login type, determine that the second client with login type 2 login type is a client that can be kicked out 103.

[0158] Since the first login type conflicts with the second login type, a login conflict will occur regardless of whether the total number of logins of the second client 102, which is of the same login type as the first client 101, is less than the first preset threshold. In this case, the conflicting client should be kicked out.

[0159] For example, when logging in via a desktop application, the web application can be kicked out.

[0160] S232: If there is no second client with the second login type, and the number of clients is not less than the first preset threshold, the first second client 102 with the same login type as the first client 101 is determined as the client 103 that can be kicked out, according to the order of the ticket list.

[0161] For example, when the login type of the first client 101 is login via desktop application, the first preset threshold can be equal to 3. If three second clients 102 have already successfully logged in via desktop application, then the first second client 102 in the ticket list with the same login type as the first client 101 can be kicked out.

[0162] S233: Remove the username and login type identifier of the client 103 that can be kicked out from the ticket list.

[0163] This serves to maintain the list of invoices.

[0164] Example 3:

[0165] The preset login policy includes at least the following: the total number of logins by the second client 102 of the same login type is less than the first preset threshold corresponding to that type. It's worth noting that the first preset threshold for different login types can be the same or different, not the same value. For example, the first preset threshold for the login type via iOS can be 2. Suppose a user logs into the system using account A (username a) on two devices (device 1 and device 2), both of which are iOS devices. When the user wants to log in using account A on device 3, which is also an iOS device, the microservice gateway 300 checks the ticket list and determines that the number of logins via iOS is 2, meaning the total number of logins by the second client of the same login type is not less than the first preset threshold. This violates the preset login policy, so either device 1 or device 2 can be kicked out. Which device to kick out will be detailed below. The preset login policy also includes the following: the total number of logins by all second clients is less than the second preset threshold, and the second preset threshold is greater than the first preset threshold.

[0166] For example, the second preset threshold can be 5. After a user logs in on 5 devices using account A, if the user tries to log in on device 6, the microservice gateway 300 determines by checking the ticket list that all clients 100 logged in with account A are not less than the second preset threshold. This violates the preset login policy, so it can choose to kick out a device. Which device to kick out will be detailed below.

[0167] This effectively controls user login behavior while improving the security of the business system and the user experience.

[0168] It is understood that the management system can design preset login policies based on actual needs, and is not limited to the two cases mentioned above. The first preset threshold can also be 1 or 3, and the second preset threshold can also be 3, 4 or 6, which can be adjusted based on actual conditions. This application embodiment does not specifically limit this. Furthermore, this application embodiment can set different first preset thresholds based on different login types of the first client 101.

[0169] Figure 7 This is a flowchart illustrating the process of verifying whether a first client conforms to a preset login policy, as provided in an embodiment of this application.

[0170] like Figure 7 As shown, in step S202, the microservice gateway 300 is specifically used to execute the following steps S2021-S2025.

[0171] S2021: Obtain a list of tickets from a preset database. Based on the list of tickets and the ticket information of the first client 101, determine whether the total number of logins of the second client 102, which is of the same login type as the first client 101, is less than a first preset threshold.

[0172] For example, the list of invoices is as follows:

[0173]

[0174]

[0175] It can be seen that for the second client 102 with user ID 001, the total number of logins is 5, the number of logins via iOS is 1, the number of logins via Android is 1, the number of logins via desktop application is 1, and the number of logins via web browser (web application) is 2.

[0176] S2022: If it is not less than the first preset threshold, it is determined that the first client 101 does not conform to the preset login strategy.

[0177] For example, when the first preset threshold is 2 and the login type of the first client 101 is login via web browser, the total number of logins of the second client 102 with the same login type as the first client 101 is 2, which is not less than the first preset threshold. Therefore, the first client 101 does not meet the preset login strategy.

[0178] S2023: If it is less than the first preset threshold, based on the ticket list and the ticket information of the first client 101, determine whether the total number of logins of the second client 102 is less than the second preset threshold.

[0179] For example, when the first preset threshold is 2 and the login type of the first client 101 is login via iOS, the total number of logins of the second client 102 with the same login type as the first client 101 with user ID 001 is 1, which is less than the first preset threshold. Therefore, the total number of logins of the second client 102 can continue to be compared.

[0180] S2024: If it is not less than the second preset threshold, it is determined that the first client 101 does not conform to the preset login strategy.

[0181] For example, when the second preset threshold is 5, the total number of logins of the second client 102 with user ID 001 is 5, which is not less than the second preset threshold. Therefore, it can be determined that the first client 101 does not meet the preset login policy.

[0182] S2025: If it is less than the second preset threshold, determine that the first client 101 conforms to the preset login strategy.

[0183] For example, when the second preset threshold is 6, the total number of logins of the second client 102 with user ID 001 is 5, which is less than the second preset threshold. Therefore, it can be determined that the first client 101 conforms to the preset login policy.

[0184] For example, when a user logs into the same account through multiple web applications (such as different browsers or tabs), the microservice gateway 300 can identify each independent login session. In the ticket list, it can also distinguish between M web applications with the same username; for example, the login type identifiers of the M web applications can be determined as Web Browser 1, Web Browser 2, ..., Web Browser M, respectively.

[0185] Furthermore, after determining that the first client 101 does not meet the preset login policy, in order to ensure that the first client 101 logs in smoothly, this embodiment of the application may choose to kick out a second client 102.

[0186] Specifically, the preset login strategy also includes the login type of the second client 102 that the first client 101 can kick out. For example, the desktop application can kick out the web application, and the Android application can kick out the iOS application. The specific design can be based on actual needs, and this application embodiment does not impose any specific limitations on this.

[0187] Furthermore, in step S203, the microservice gateway 300 can be used to perform the following step S2031.

[0188] S2031: If it is not less than the first preset threshold, the first second client 102 with the same login type as the first client 101 is determined as the client 103 that can be kicked out, according to the order of the ticket list.

[0189] It is understandable that the order of the ticket list is the same as the order in which the first client 101 sends the second login request.

[0190] For example, when the first preset threshold is 2, and the login type of the first client 101 is login via a web browser, the total number of logins of the second client 102 with the same login type as the first client 101 is 2, which is not less than the first preset threshold. At this time, the first second client 102 with the same login type as the first client 101 is the client with the login type identifier of Web browser 1, as shown in the example. Figure 5 The second client 102 can be identified as the client 103 that can be kicked out.

[0191] Alternatively, the microservice gateway 300 can also be used to perform the following steps S2032.

[0192] S2032: If it is not less than the second preset threshold, the second client 102 that can be kicked out by the first client 101 is determined as the kick-out client 103 according to the order of the ticket list.

[0193] For example, when the second preset threshold is 5, the total number of logins of the second client 102 with user ID 001 is 5, which is not less than the second preset threshold. When the login type that the first client 101 can be kicked out is login via desktop application, it can be determined that the first second client 102 that can be kicked out by the first client 101 is a client with user ID 001 and login type identified as a web browser. Therefore, this second client 102 can be identified as the client 103 that can be kicked out.

[0194] As can be seen, the method provided in this application embodiment can first determine whether the number of logins of a second client 102 with the same login type as the first client 101 is less than a first preset threshold. If it is not less than the first preset threshold, a second client 102 with the same login type as the first client 101 is kicked out. In this way, the number of simultaneous online logins for each login type can be constrained. Further, if it is less than the first preset threshold, it can be determined whether the total number of logins of the second client 102 is less than a second preset threshold. If it is not less than the second preset threshold, a second client 102 with a login type conflicting with the first client 101 is kicked out. In this way, a maximum of N clients can be online, while simultaneously constraining the number of simultaneous online logins for each login type.

[0195] Furthermore, the microservice gateway 300 can also be used to perform the following steps S2033.

[0196] S2033: Remove the username and login type identifier of the client 103 that can be kicked out from the ticket list.

[0197] This serves to maintain the list of invoices.

[0198] Figure 8 This is a second schematic diagram of the configuration page for the preset login strategy provided in the embodiments of this application.

[0199] like Figure 8 As shown, based on Embodiments 2 and 3, the configuration page of the preset login strategy provided in this application embodiment may include cells consisting of a row header indicating the login type of the first client 101 and a column header indicating the login type of the second client 102, and the cells include an option for whether or not the user can be kicked out.

[0200] For example, when the login type of the first client 101 is login via a desktop application, it can kick out the second client 102, whose login type is Android. When the login type of the first client 101 is login via iOS, it can kick out the second client 102, whose login types are both desktop application and iOS.

[0201] Furthermore, the configuration page may also include settings for a first preset threshold, a second preset threshold, a first login type, a second login type, and / or a third login type. The first preset threshold is used to limit the total number of logins for the second client 102 of the same login type, and the second preset threshold is used to limit the total number of logins for all second clients 102. The first login type, the second login type, and the third login type are used to limit whether there is a login type conflict between the first client 101 and the second client 102.

[0202] By configuring the settings page, you can control, for example, how many times the same account can log in and how many devices (endpoints) can be online at the same time.

[0203] Based on Embodiments 1, 2 and 3, this application may also provide the following embodiments.

[0204] In some implementations, the microservice gateway 100 can also publish an event to the relevant services in the microservice cluster 400, indicating that the kickout client 103 has been kicked out, to trigger the services in the microservice cluster 400 to perform corresponding state updates and resource reallocation. For example, after receiving the notification, each service in the microservice cluster 400 can update its internal session management information to ensure that all services can obtain the latest client state.

[0205] In some implementations, the microservice gateway 100 can also send a login success notification to the first client 101 through the Nginx server 200.

[0206] It is understandable that indiscriminately kicking out devices may result in a poor user experience. This application embodiment can make the kick-out operation more in line with user habits by selecting logged-in clients.

[0207] Figure 9 This is a schematic diagram illustrating the interaction between a kickout client and a microservice gateway, provided as an embodiment of this application.

[0208] like Figure 9 As shown in the embodiment of this application, the kickout client 103 can also be used to perform step S301: send an access request to the microservice gateway 300 through the Nginx server 200, the access request carrying ticket information, that is, carrying a cookie.

[0209] This step can also be understood as the first client 101 actively accessing the microservice application interface.

[0210] The microservice gateway 300 is also used to perform the following steps S302: in response to an access request, retrieve a ticket list from a preset database and determine that the login type identifier of the client 103 that can be kicked out is not in the ticket list.

[0211] If the login type identifier of client 103 is not in the ticket list, it may indicate that the client's session has expired.

[0212] It is worth noting that when any client accesses the microservice application interface, it includes the steps of verifying the correctness of the cookie and the validity of the session. Verifying the correctness of the cookie can be reflected in the signature verification step, and verifying the validity of the session can be reflected in the step of verifying whether the login type identifier is in the ticket list.

[0213] In addition, the microservice gateway 300 is also used to perform step S303: send a re-login notification to the kick-out client 103 via the Nginx server 200.

[0214] At this point, the user interface of client 103 can be redirected to the login screen.

[0215] Figure 10 This is a schematic diagram illustrating the interaction between the second client and the microservice gateway provided in an embodiment of this application.

[0216] like Figure 10As shown, the second client 102 can also be used to execute step S401: sending a logout request to the microservice gateway 300 through the Nginx server 200. The logout request may carry ticket information.

[0217] In this embodiment, the logout request is triggered by the user performing the "Logout" operation in the client user interface. In some implementations, the user's "Close" operation in the client user interface may not trigger a logout request; this can be designed based on actual circumstances, and this embodiment does not impose specific limitations on it.

[0218] The microservice gateway 300 is also used to perform step S402: in response to the logout request, retrieve the ticket list from the preset database and delete the username and login type identifier of the second client 102 from the ticket list.

[0219] This serves to maintain the list of invoices.

[0220] The microservice gateway 300 is also used to perform step S403: send a re-login notification to the second client 102 via the Nginx server 200.

[0221] In response to the re-login notification, the user interface of the second client 102 can be redirected to the login screen. See also... Figure 5 When the second client 102 logs out of the business system, it can be referred to as the first client 101.

[0222] The microservice gateway 100 can also publish an event to the relevant services of the microservice cluster 400, indicating that the second client 102 has logged out.

[0223] As can be seen from the above, the login control system based on a microservice gateway provided in this application embodiment can implement user kick-out functionality under a microservice architecture based on Spring Cloud Gateway and Redis technologies. It supports access control for multiple terminals, and the login ticket uses lightweight JWT. Users can configure login policies according to their usage needs to achieve highly flexible kick-out functionality, thereby improving the user experience.

[0224] Figure 11 This is a flowchart illustrating the login control method based on a microservice gateway provided in an embodiment of this application.

[0225] like Figure 11As shown in the figure, this application embodiment also provides a login control method based on a microservice gateway, applied to a login control system. The login control system includes: a client 100, an Nginx server 200, a microservice gateway 300, and a microservice cluster 400. The microservice cluster 400 is formed by splitting the business system into multiple microservices based on a microservice architecture and deploying the multiple microservices on different servers. The client 100 includes a mobile application terminal and a PC terminal.

[0226] The methods include:

[0227] S501: Send a first login request to the microservice gateway through the Nginx server; wherein, the first login request is sent by the first client 101, and the first client 101 is the client to be logged in; the first login request carries ticket information, and the ticket information includes at least the username and login type identifier.

[0228] S502: Responding to the first login request, determine whether the login behavior of the first client 101 conforms to the preset login policy based on the ticket list; wherein, the ticket list is formed based on ticket information, and the preset login policy is used to limit the maximum number of logins by the same user, the same login type or different login types at the same time, and the login types include login via mobile application terminal and login via PC terminal;

[0229] S503: If the login behavior of the first client 101 does not conform to the preset login policy, a second client 102 is kicked out. The second client 102 is a client that has already logged into the business system, and the username of the second client 102 is the same as that of the first client 101.

[0230] S504: If the login behavior of the first client 101 conforms to the preset login policy, or after kicking out a second client 102, the first login request is forwarded to the microservice cluster 400 so that the first client 101 can log in and access the business system.

[0231] In some implementations, before S501, there is also S601: sending a second login request to the microservice gateway 300 through the Nginx server 200; wherein the second login request is sent by the first client 101, and the second login request carries at least user information, including at least the username and password.

[0232] Following S601 are:

[0233] S602: Authentication of the first client 101 is performed based on the second login request, and ticket information is generated after successful authentication.

[0234] S603: The ticket information is sent to the first client 101 through the Nginx server 200, and the username and login type identifier of the first client 101 are added to the end of the ticket list. The ticket list includes a first entry and a second entry, the first entry corresponds to the username, and the second entry corresponds to the login type identifier.

[0235] S604: Save the ticket information as a cookie.

[0236] In some implementations, the preset login strategy is based on pre-configuration on the configuration page. The preset login strategy includes at least a login type conflict strategy and / or a login count conflict strategy. The login type conflict strategy includes situations where the first login type and the second login type are conflicting types. When the login type of the first client 101 is the first login type, the total login count of the second client 102 with login types of both the first and second login types is less than a first threshold. The login count conflict strategy includes situations where the total login count of the second client 102 with the same login type is less than the second threshold corresponding to the type. The first threshold is equal to the maximum value among the second thresholds corresponding to the first login type and the second login type. Step S502 specifically includes:

[0237] S5021: Obtain a ticket list from the preset database, and determine the login type of the first client 101 and the second client 102 based on the ticket list;

[0238] S5022: Determine whether the login type conflict policy is in effect, and if the login type conflict policy is in effect, determine whether the login type of the first client 101 is the first login type;

[0239] S5023: If the login type of the first client 101 is the first login type, iterate through each second client 102 and determine whether the total number of logins of the second clients 102 with login types of the first login type and the second login type is less than the first threshold;

[0240] S5024: If the total number of logins of the second client 102 with login types of the first login type and the second login type is less than the first threshold, it is determined that the login behavior of the first client 101 conforms to the preset login strategy;

[0241] S5025: If the total number of logins of the second client 102 with login types of the first login type and the second login type is not less than the first threshold, it is determined that the login behavior of the first client 101 does not conform to the preset login strategy;

[0242] S5026: If the login type of the first client 101 is not the first login type, and / or, if the login type conflict policy does not take effect, determine whether the total number of logins of the second client 102 with the same login type as the first client 101 is less than the second threshold corresponding to the type;

[0243] S5027: If the total number of logins of the second client 102 with the same login type as the first client 101 is not less than the second threshold, it is determined that the login behavior of the first client 101 does not conform to the preset login policy;

[0244] S5028: If the total number of logins of the second client 102 with the same login type as the first client 101 is less than the second threshold, it is determined that the login behavior of the first client conforms to the preset login strategy.

[0245] In some implementations, the client runs on a terminal device. When the client runs on a mobile terminal, the client is a mobile application, which includes iOS and Android clients.

[0246] In some implementations, the default login policy also includes the login type of the second client 102 that can be kicked out by the first client 101;

[0247] Step S503 specifically includes:

[0248] S5031: If the total number of logins of the second client 102 with login types of the first login type and the second login type is not less than the first threshold, based on the sorting order of the ticket list, determine the top N+1 second clients 102 as clients that can be kicked out, where N is equal to the difference between the total number of logins of the second clients 102 with login types of the first login type and the second login type and the first threshold.

[0249] Alternatively, step S5032 is included: if the total number of logins of the second client 102 with the same login type as the first client 101 is not less than the second threshold, the top M+1 second clients 102 with the same login type as the first client 101 are determined as kick-out clients 103 according to the order of the ticket list, where M is equal to the difference between the total number of logins of the second clients 102 with the same login type as the first client 101 and the second threshold corresponding to the type;

[0250] And, including step S5033: removing the username and login type identifier of the client 103 that can be kicked out from the ticket list.

[0251] In some implementations, the following steps S601-S603 are also included.

[0252] S601: An access request is sent from Nginx server 200 to microservice gateway 300, and the access request carries ticket information;

[0253] S602: In response to the access request, retrieve the ticket list from the preset database and determine that the login type identifier of the client 103 that can be kicked out is not in the ticket list.

[0254] And S603: Send a re-login notification to kickout client 103 via Nginx server 200.

[0255] In some implementations, the following steps S701-S702 are also included.

[0256] S701: Send a logout request to the microservice gateway 300 via Nginx server 200;

[0257] S702: In response to the logout request, retrieve the ticket list from the preset database and delete the username and login type identifier of the second client 102 from the ticket list.

[0258] In some implementations, the configuration page includes settings for a second threshold and whether login type conflict policies are effective.

[0259] In some implementations, the default database is a Redis database; the ticket information is in JWT lightweight format.

[0260] In a specific implementation, the present invention also provides a computer storage medium, wherein the computer storage medium may store a program, and when the program is executed, it may include some or all of the steps of the various embodiments of the login control system and method based on a microservice gateway provided by the present invention. The storage medium may be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0261] It is readily understood that, based on the several embodiments provided in this application, those skilled in the art can combine, split, or reorganize the embodiments of this application to obtain other embodiments, none of which exceed the protection scope of this application.

[0262] The above detailed embodiments further illustrate the purpose, technical solution, and beneficial effects of the embodiments of this application. It should be understood that the above are merely specific embodiments of the embodiments of this application and are not intended to limit the protection scope of the embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solutions of the embodiments of this application should be included within the protection scope of the embodiments of this application.

Claims

1. A login control system based on a microservice gateway, characterized in that, include: The system comprises a client, an Nginx server, a microservice gateway, and a microservice cluster. The microservice cluster is formed by splitting the business system into multiple microservices based on a microservice architecture and deploying the multiple microservices on different servers. The client includes mobile applications and PC clients; The first client is used to send a first login request to the microservice gateway through the Nginx server, and the first client is the client to be logged in; The first login request carries ticket information, which includes at least the username and login type identifier; The microservice gateway is used to respond to the first login request and determine whether the login behavior of the first client conforms to the preset login policy based on the ticket list; wherein, the ticket list is formed based on the ticket information, and the preset login policy is used to limit the maximum number of logins by the same user, the same login type, or different login types at the same time, and the login types include login through the mobile application terminal and login through the PC terminal; The microservice gateway is also used to kick out a second client if the login behavior of the first client does not conform to the preset login policy. The second client is the client that has already logged into the business system, and the username of the second client is the same as that of the first client. The microservice gateway is also used to forward the first login request to the microservice cluster when the login behavior of the first client conforms to the preset login policy, or after kicking out a second client, so that the first client can log in and access the business system.

2. The login control system based on a microservice gateway according to claim 1, characterized in that, Before sending the first login request to the microservice gateway through the Nginx server, the first client is also used to send a second login request to the microservice gateway through the Nginx server. The second login request carries at least user information, which includes at least the username and password. The microservice gateway is also used to authenticate the first client based on the second login request, and generate the ticket information after successful authentication; The microservice gateway is also used to send the ticket information to the first client through the Nginx server, and to add the username and login type identifier of the first client to the end of the ticket list. The ticket list includes a first entry and a second entry, the first entry corresponding to the username and the second entry corresponding to the login type identifier. The first client is also used to save the ticket information as cookie information.

3. The login control system based on a microservice gateway according to claim 2, characterized in that, The preset login strategy is based on the configuration page and includes at least a login type conflict strategy and / or a login count conflict strategy. The login type conflict strategy includes a first login type and a second login type being conflicting types. When the login type of the first client is the first login type, the total number of logins of the second client with login types of both the first and second login types is less than a first threshold. The login count conflict strategy includes the total number of logins of the second client with the same login type being less than a second threshold corresponding to the type. The first threshold is equal to the maximum value among the first login type and the second threshold corresponding to the second login type. In the step of determining whether the login behavior of the first client conforms to the preset login policy based on the ticket list, the microservice gateway is specifically used for: The ticket list is retrieved from a preset database, and the login types of the first client and the second client are determined based on the ticket list; Determine whether the login type conflict policy is in effect, and if the login type conflict policy is in effect, determine whether the login type of the first client is the first login type; If the login type of the first client is the first login type, iterate through each second client and determine whether the total number of logins of the second clients with login types of the first login type and the second login type is less than the first threshold; If the total number of logins of the second client with login types of the first login type and the second login type is less than the first threshold, it is determined that the login behavior of the first client conforms to the preset login strategy; If the total number of logins of the second client with login types of the first login type and the second login type is not less than the first threshold, it is determined that the login behavior of the first client does not conform to the preset login strategy; If the login type of the first client is not the first login type, and / or, if the login type conflict policy is not effective, determine whether the total number of logins of the second client with the same login type as the first client is less than the second threshold corresponding to the type; If the total number of logins of the second client with the same login type as the first client is not less than the second threshold, it is determined that the login behavior of the first client does not conform to the preset login policy; If the total number of logins of the second client with the same login type as the first client is less than the second threshold, it is determined that the login behavior of the first client conforms to the preset login policy.

4. The login control system based on a microservice gateway according to claim 3, characterized in that, In the step of kicking out a second client when the login behavior of the first client does not conform to the preset login policy, the microservice gateway is specifically used for: If the total number of logins of the second client with login types of the first login type and the second login type is not less than the first threshold, based on the sorting order of the ticket list, the top N+1 second clients are determined as kick-out clients, where N is equal to the difference between the total number of logins of the second clients with the first login type and the second login type and the first threshold. Alternatively, if the total number of logins of the second client with the same login type as the first client is not less than the second threshold, the top M+1 second clients with the same login type as the first client are determined as the kick-out clients according to the order of the ticket list, where M is equal to the difference between the total number of logins of the second client with the same login type as the first client and the second threshold corresponding to the type. Remove the username and login type identifier of the client that can be kicked out from the ticket list.

5. The login control system based on a microservice gateway according to claim 4, characterized in that, The kickout client is also used to send an access request to the microservice gateway through the Nginx server, the access request carrying the ticket information; The microservice gateway is also configured to respond to the access request by retrieving the ticket list from the preset database and determining that the login type identifier of the client that can be kicked out is not in the ticket list; Furthermore, the microservice gateway is also used to send a re-login notification to the kick-out client via the Nginx server.

6. The login control system based on a microservice gateway according to claim 3, characterized in that, The client runs on a terminal device. When the client runs on a mobile terminal, the client is the mobile application client, which includes iOS and Android clients.

7. The login control system based on a microservice gateway according to claim 3, characterized in that, The second client is also used to send a logout request to the microservice gateway through the Nginx server; The microservice gateway is also configured to, in response to the logout request, retrieve the ticket list from the preset database and delete the username and login type identifier of the second client from the ticket list.

8. The login control system based on a microservice gateway according to claim 3, characterized in that, The configuration page includes settings for the second threshold and whether the login type conflict policy is effective.

9. The login control system based on a microservice gateway according to claim 3, characterized in that, The preset database is a Redis database; the ticket information is in JWT lightweight format.

10. A login control method based on a microservice gateway, characterized in that, This system is applied to a login control system, which includes: a client, an Nginx server, a microservice gateway, and a microservice cluster. The microservice cluster is formed by splitting the business system into multiple microservices based on a microservice architecture and deploying the multiple microservices on different servers. The client includes a mobile application and a PC client. The method includes: The Nginx server sends a first login request to the microservice gateway; wherein the first login request is sent by a first client, which is the client to be logged in; the first login request carries ticket information, which includes at least a username and a login type identifier; In response to the first login request, the system determines whether the login behavior of the first client conforms to a preset login policy based on the ticket list; wherein, the ticket list is formed based on the ticket information, and the preset login policy is used to limit the maximum number of logins by the same user, the same login type, or different login types at the same time, and the login types include login via the mobile application terminal and login via the PC terminal; If the login behavior of the first client does not conform to the preset login policy, a second client is kicked out. The second client is the client that has already logged into the business system, and the username of the second client is the same as that of the first client. If the login behavior of the first client conforms to the preset login policy, or after kicking out a second client, the first login request is forwarded to the microservice cluster so that the first client can log in and access the business system.

Images