CN114567475A

CN114567475A - Multi-system login method and device, electronic equipment and storage medium

Info

Publication number: CN114567475A
Application number: CN202210169227.3A
Authority: CN
Inventors: 王斌
Original assignee: Ping An International Smart City Technology Co Ltd
Current assignee: Ping An International Smart City Technology Co Ltd
Priority date: 2022-02-23
Filing date: 2022-02-23
Publication date: 2022-05-31
Anticipated expiration: 2042-02-23

Abstract

The embodiment of the application discloses a multi-system login method and device, electronic equipment and a storage medium. The method may comprise the steps of: receiving a login operation of a user; sending a request authentication to a target management system, wherein the target management system is determined according to login operation and comprises a local management system and a third-party management system; judging whether the target management system passes the request authentication; under the condition that the target management system passes the request authentication, a Code returned by the target management system is obtained; sending the Code to a gateway service module to acquire a Token returned by the gateway service module; and acquiring a subsystem list according to Token. By implementing the embodiment of the application, the multi-system is logged in a plurality of modes, so that the disaster tolerance of the multi-system login can be improved.

Description

Multi-system login method and device, electronic equipment and storage medium

Technical Field

The embodiment of the application relates to the technical field of computers, in particular to a multi-system login method, a multi-system login device, electronic equipment and a storage medium.

Background

With the development of computer technology, more and more services can be realized and completed through computer equipment. For different services, it is usually necessary to log in the corresponding service system to perform corresponding operations. And the system login, authentication and authentication methods and the like of each business system are generally executed independently by each system. Therefore, a plurality of service systems need respective account passwords to log in, which results in complex operation and low efficiency. In order to avoid this situation, in the prior art, a third-party management system is often introduced to perform unified management on multiple systems. That is, after the user logs in the third party management system by using the account password, the user logs in all the service systems, i.e., subsystems, which are interfaced with the third party management system. Therefore, the operation of logging in a plurality of systems can be reduced, and the logging efficiency is improved. However, this causes a new problem, and if the third-party management system fails, all the service systems cannot be normally logged in and used. Therefore, it is a problem to be solved to improve the disaster tolerance of multi-system login.

Disclosure of Invention

The embodiment of the application provides a method and a device for multi-system login, electronic equipment and a storage medium, which can improve disaster tolerance of multi-system login.

In a first aspect, an embodiment of the present application provides a method for multi-system login, where the method includes the following steps:

receiving a login operation of a user;

sending a request authentication to a target management system, wherein the target management system is determined according to the login operation and comprises a local management system and a third-party management system;

judging whether the target management system passes the request authentication;

under the condition that the target management system passes the request authentication, a Code returned by the target management system is obtained;

sending the Code to a gateway service module to acquire a Token returned by the gateway service module;

and acquiring a subsystem list according to the Token.

In a first aspect, an embodiment of the present application provides an apparatus for multi-system login, where the apparatus includes:

the communication module is used for receiving login operation of a user; sending a request authentication to a target management system, wherein the target management system is determined according to the login operation and comprises a local management system and a third-party management system;

the processing module is used for judging whether the target management system passes the request authentication;

the communication module is also used for acquiring a Code returned by the target management system under the condition that the target management system passes the request authentication; sending the Code to a gateway service module to acquire a Token returned by the gateway service module; and acquiring a subsystem list according to the Token.

In a third aspect, an embodiment of the present application provides an electronic device, including a processor and a memory, where the processor and the memory are connected to each other, where the memory is used to store a computer program, and the computer program includes program instructions, and the processor is configured to call the program instructions to execute the method according to the first aspect.

In a fourth aspect, the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and the computer program includes program instructions, which, when executed by a processor, cause the processor to execute the method according to the first aspect.

The embodiment of the application has the following beneficial effects:

by adopting the multi-system login method, the multi-system login device, the computer equipment and the storage medium, after the login operation of the user is received, the request authentication is sent to the target management system according to the login operation of the user, wherein the target management system is determined according to the login operation of the user. The target management system comprises a local management system and a third party management system. Then, it is determined whether the target management system passes the request authentication. And under the condition that the target management system passes the request authentication, acquiring a Code returned by the target management system. And sending the Code to the gateway service module to acquire the Token returned by the gateway service module. And then acquiring a subsystem list according to the Token. Therefore, the multi-system can be logged in through different target management systems in various modes, and the disaster tolerance of the multi-system login can be improved.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below. It is obvious that the drawings in the following description are only some embodiments of the application, and that for a person skilled in the art, other drawings can be derived on the basis of these drawings without inventive effort. Wherein:

fig. 1 is a schematic diagram of a system architecture according to an embodiment of the present application;

fig. 2 is a flowchart illustrating a method for multi-system login according to an embodiment of the present disclosure;

fig. 3 is a schematic diagram of a login interface according to an embodiment of the present application;

FIG. 4 is a block diagram of an apparatus for multi-system login according to an embodiment of the present disclosure;

fig. 5 is a schematic composition diagram of an electronic device according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some, but not all, embodiments of the present application. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

The terms "first," "second," "third," and "fourth," etc. in the description and claims of this application and in the accompanying drawings are used for distinguishing between different objects and not for describing a particular order. Furthermore, the terms "include" and "have," as well as any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to only those steps or elements listed, but may alternatively include other steps or elements not listed, or inherent to such process, method, article, or apparatus.

Reference herein to "an embodiment" means that a particular feature, result, or characteristic described in connection with the embodiment can be included in at least one embodiment of the application. The appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. It is explicitly and implicitly understood by one skilled in the art that the embodiments described herein can be combined with other embodiments.

First, terms and concepts related to the embodiments of the present application will be described.

(1)Token

Token, which is a string of characters generated by the server as a Token for requesting to the client (electronic device). A token is a special frame that can control a station to occupy the medium to distinguish data frames from other control frames. That is, Token may be understood as a secret number, and a check of the secret number is performed before some data transmission, and different secret numbers are authorized for different data operations.

(2)Code

Code is a user certificate obtained by user authorization, and is used for server to exchange to obtain a resource access certificate (Token).

(3)Springsecurity

Spring Security is a Security framework that can provide an declarative Security access control solution for Spring-based enterprise applications. The method provides a set of beans which can be configured in Spring application context, fully utilizes Spring IoC, DI (Control Inversion of Control, DI: Dependency Injection) and AOP (section-oriented programming) functions, provides an explicit security access Control function for an application system, and reduces the work of writing a large amount of repeated codes for security Control of an enterprise system.

(4) Symmetric encryption

Symmetric encryption refers to an encryption method using a single-key cryptosystem, in which the same key can be used for both encryption and decryption of information, also called single-key encryption. A key is an instruction that controls the encryption and decryption process. An algorithm is a set of rules that specify how encryption and decryption are to be performed.

The working process is as follows: the data sender processes the plaintext (original data) and the encryption key together by a special encryption algorithm, and then changes the plaintext into a complex encryption ciphertext to send out. After receiving the ciphertext, the receiving party needs to decrypt the ciphertext by using the encryption key and the inverse algorithm of the same algorithm (i.e., the special encryption algorithm) to recover the ciphertext into the readable plaintext if the receiving party wants to decode the original text.

(5) Asymmetric encryption

The asymmetric encryption algorithm requires two keys for encryption and decryption, which are a public key, for short, a public key and a private key, for short, a private key. The public key and the private key are a pair, and if the public key is used for encrypting data, only the corresponding private key can be used for decrypting the data; if the data is encrypted with a private key, it can only be decrypted with the corresponding public key.

The working process is as follows: party b generates a pair of keys (public and private) and publishes the public key to the other parties. The party A who obtains the public key uses the public key to encrypt the confidential information and then sends the confidential information to the party B. The party B decrypts the encrypted information by using another private key (private key) stored by the party B. Party b can only decrypt the information encrypted by the corresponding public key with its private key (private key).

(6)MD5

MD5 Message Digest Algorithm (MD5 Message-Digest Algorithm), a widely used cryptographic hash function, may generate a 128-bit (16-byte) hash value (hash value) to ensure the integrity of the Message transmission.

In order to better understand the technical solution of the embodiments of the present application, a system architecture to which the embodiments of the present application may relate is introduced here. Please refer to fig. 1, which is a schematic diagram of a system architecture according to an embodiment of the present disclosure. The system architecture may include: an electronic device 101 and a server 102. The electronic device 101 and the server 102 can communicate with each other through a network. Network communications may be based on any wired and wireless network, including but not limited to the Internet, wide area networks, metropolitan area networks, local area networks, Virtual Private Networks (VPNs), wireless communication networks, and the like.

The number of the electronic devices and the number of the servers are not limited in the embodiment of the application, and the servers can provide services for the electronic devices at the same time. In the embodiment of the application, the electronic device is mainly used by a user for performing multi-system login, and can be used for communicating with the server so as to obtain the subsystem list to complete multi-system login. The electronic device may be a Personal Computer (PC), a notebook computer, or a smart phone, and may also be an all-in-one machine, a palm computer, a tablet computer (pad), a smart television playing terminal, a vehicle-mounted terminal, or a portable device. The operating system of the PC-side electronic device, such as a kiosk or the like, may include, but is not limited to, operating systems such as Linux system, Unix system, Windows series system (e.g., Windows xp, Windows7, etc.), Mac OS X system (operating system of apple computer), and the like. The operating system of the electronic device at the mobile end, such as a smart phone, may include, but is not limited to, an operating system such as an android system, an IOS (operating system of an apple mobile phone), a Window system, and the like.

The server may be an independent server, or may be a cloud server that provides basic cloud computing services such as a cloud service, a cloud database, cloud computing, a cloud function, cloud storage, a network service, cloud communication, a middleware service, a domain name service, a security service, a Content Delivery Network (CDN), a big data and artificial intelligence platform, and the like. The server may alternatively be implemented as a server cluster consisting of a plurality of servers.

With the development of computer technology, more and more services can be realized and completed through computer equipment. For different services, it is usually necessary to log in the corresponding service system to perform corresponding operations. And the system login, authentication and authentication methods and the like of each business system are generally executed independently by each system. Therefore, a plurality of service systems need respective account passwords to log in, which results in complex operation and low efficiency. In order to avoid this situation, in the prior art, a third-party management system is often introduced to perform unified management on multiple systems. That is, after the user logs in the third-party management system by using the account password, the user logs in all the business systems which are in butt joint with the third-party management system. Therefore, the operation of logging in a plurality of systems can be reduced, and the logging efficiency is improved. However, this causes a new problem, and if the third-party management system fails, all the service systems cannot be normally logged in and used. Therefore, it is a problem to be solved to improve the disaster tolerance of multi-system login.

In order to solve the above problem, an embodiment of the present application provides a method for multi-system login, which may be applied to an electronic device or a server as shown in fig. 1. By implementing the method, the disaster tolerance of multi-system login can be improved.

The embodiment of the application is realized based on a Common Service Platform (CSP). The CSP is a service platform supporting upper-layer application, and comprises a gateway service module, an SDK module and a user management system. The gateway service module is responsible for authorization and authentication. The SDK module refers to an SDK package that can be referred by each subsystem (application system), and performs rights management on each application through an interceptor in SpringSecurity, and each subsystem can obtain menu list information owned by the current user through the module. And the user management system is used for login management, authority management and the like of the user.

Please refer to fig. 2, which is a flowchart illustrating a method for multi-system login according to an embodiment of the present application. The following steps S201 to S206 may be included. Wherein:

step S201: and receiving the login operation of the user.

Step S202: and sending a request authentication to a target management system, and determining by the target management system according to the login operation.

The request authentication refers to requesting authentication of user identity, and determining whether the user has operation authority and which operation authority according to the user identity.

In one possible implementation manner, the login operation includes a first login operation, the target management system is determined according to the first login operation of the user, and the target management system includes a local management system and a third-party management system. The third-party management system is a user management system other than the user management system in the CSP. Fig. 3 is a schematic view of a login interface provided in the embodiment of the present application. Button 301 indicates login using the third party management system and button 302 indicates login using the local management system. The user can quickly select a third-party management system to log in or a local management system to log in by clicking a button 301 or a button 302. It is understood that, in fig. 3, the first login operation of the user is clicking a button 301 or clicking a button 302. When a user clicks a button 301 to select to use a third-party management system for logging in, the target management system is the third-party management system; when the user selects click button 302 to log in using the local management system, the target management system is the local management system. The user can select the local management system or the third-party management system to log in by clicking the button on one interface, so that the user does not need to remember and input the address of each system to log in, the operation of the user is simplified, and the experience of the user is improved.

In a possible implementation manner, the login operation includes a second login operation, and the second login operation is used to determine a login manner, where the login manner includes a first login manner and a second login manner. As shown in fig. 3, the first login method is a login method of entering an account password for login as shown in 304, and the second login method is a login method of scan code login as shown in 303. When the user logs in using the first login method, as shown in 304, after the user inputs an account and a password and clicks a login button, the user will receive a login operation, and at this time, the user will send a request for authentication to the target management system. In the case where the user logs in using the second login method, as shown in 303, after the user scans a code using another device and clicks a button for prompting the user to confirm the login, the user's login operation is received, and at this time, a request for authentication is sent to the target management system.

Step S203: and judging whether the target management system passes the request authentication.

In a possible implementation manner, in the case that the login manner is the first login manner, determining whether the target management system passes the request authentication may include steps a 1-a 6 as follows:

a1, acquiring a first input account and a first input password according to the first login mode.

It should be noted that the first input account and the first input password are not the account and the password input by the user, but refer to the account and the password that are encrypted once for the account and the password input by the user. This is because if the front end transmits in the clear, the account number and password are at risk of being compromised. Therefore, the front end encrypts the account number and the password during transmission. Therefore, the encrypted first input account and first input password are acquired, instead of the account and password input by the user. The encryption processing mode can be symmetric encryption or asymmetric encryption. The encryption processing mode of the account number and the password can be the same or different. For example, the account entered by the user may be encrypted using a symmetric encryption process, and the password entered by the user may be encrypted using an asymmetric encryption process.

And A2, sending the first input account and the first input password to a Springsecurity framework, wherein the Springsecurity framework is used for decrypting the first input account to obtain an original input account and encrypting the first input password to obtain a second input password.

The original input account is the account input by the user, and the second input password is not the password input by the user, but the password obtained by performing secondary encryption on the password input by the user (the first encryption occurs during the aforementioned front-end transmission).

And A3, acquiring the original account and the encrypted password in the database.

It should be noted that, in order to ensure the security of the data, the original account number and the encrypted password are stored in the database. The original account refers to an account generated when the user registers or set by the user. The encrypted password is not a password set by the user, but a password obtained by secondarily encrypting the password set by the user.

In one possible implementation, the encrypted password is obtained by the MD5 algorithm. When some password information needs to be stored for identity confirmation, if the password information is directly stored in a database in a clear code mode, a system administrator can easily obtain the original password information without using any security measures, and once the information is leaked, the password is easily deciphered. In order to increase security, it is necessary to encrypt information that needs to be kept secret in the database, so that even if someone gets the entire database, the original cryptographic information cannot be obtained without a decryption algorithm. The MD5 algorithm solves this problem well because it computes an input string of arbitrary length to obtain a fixed length output, and only if the plaintext is the same, it can wait for the same ciphertext, and the algorithm is irreversible, making it impossible to back-compute the plaintext by the decryption algorithm, even if the ciphertext after encryption is obtained. Thus, the user's password can be stored in the form of MD5 value (or similar other algorithm), when the user registers, the system calculates the password input by the user into MD5 value, then compares the MD5 value with the MD5 value stored in the system, if the cipher text is the same, the password can be determined to be correct, otherwise, the password is wrong. Through such steps, the system can determine the validity of the user logging into the system without knowing the clear code of the user password. Therefore, the password of the user can be prevented from being known by the user with the authority of the system administrator, and the difficulty of cracking the password is increased to a certain extent.

And A4, encrypting the original account to obtain an encrypted account.

The encrypted account is an account obtained by encrypting an original account once.

And A5, sending the encrypted account and the encrypted password to a Springsecurity framework, wherein the Springsecurity framework is used for decrypting the encrypted account to obtain the original account and obtaining verification results of the original input account and the original account as well as the second input password and the encrypted password.

The verification result refers to whether the original input account number is successfully matched with the original account number or not, and whether the second input password is successfully matched with the encrypted password or not. And under the condition that the original input account number is successfully matched with the original account number and the second input password is successfully matched with the encrypted password, the verification result is successful. Otherwise, the verification result is unsuccessful matching.

And A6, determining whether the request authentication is passed according to the verification result.

And in the case that the verification result is that the matching is successful, determining that the request authentication is passed. And in the case that the verification result is that the matching is unsuccessful, determining not to pass the request authentication.

In an exemplary aspect, the account number input by the user is a and the password is B. The obtained account number transmitted by the head end is a1 (account number a1 is the result of encrypting account number a once), and the password is B1 (password B1 is the result of encrypting password B once). The account a1 and password B1 are then passed into the SpringSecurity framework. The SpringSecurity framework decrypts the account a1 to obtain the account a, and encrypts the password B1 again to obtain the password B2 (the password B2 is equivalent to the result of performing secondary encryption on the password B). On the other hand, the account a corresponding to the user input in the database stores an account a and a password b2. Before the SpringSecurity is transmitted, the account a is encrypted to obtain the account a1, and no processing is performed on the password b2. After the account a1 and the password B2 are transferred into a SpringSecurity framework, the SpringSecurity framework decrypts the account a1 to obtain the account a, and then determines whether the account a is matched with the account a and whether the password B2 is matched with the password B2. In the case where the account a matches the account a, and the password B2 matches the password B2, the verification result is a successful match, and the request authentication is passed. In the case where the account a does not match the account a, or the password B2 does not match the password B2, the verification result is an unsuccessful match, and the request authentication is not passed.

In a possible implementation manner, in the case that the login manner is the second login manner, determining whether the target management system passes the request authentication may include steps B1 to B7 as follows:

and B1, acquiring a Code according to the second login mode.

And the Code is generated by a third-party management system when the Code scanning is successful. The Code generated by each Code scanning may be different, but a mapping relationship exists between the Code and the user, so that the corresponding user for the Code scanning can be determined in the third-party management system according to the Code.

And B2, sending the Code to a third-party management system to acquire corresponding user information.

The gateway service module sends the Code to a third-party management system, and the third-party management system can inquire the user information in the third-party management system of the corresponding user according to the Code.

And B3, inquiring to obtain a first account and a first password in the database according to the user information.

And after the gateway service module acquires the user information in the third-party management system from the third-party management system, the gateway service module queries the local management system according to the user information in the third-party management system to obtain the user information in the local management system of the user. And inquiring in a database according to the user information in the local management system of the user to obtain a first account and a first password.

It should be noted that, because the account and the password in the database cannot be directly obtained through the user information in the third-party management system, the account and the password in the database need to be indirectly obtained by using the local management system as a medium. Therefore, the user information in the third party management system should have some or all of the corresponding user information in the local management system. That is, the local management system needs to add part or all of the user information of the user in the third-party management system, so that the corresponding user information in the local management system can be queried according to the user information in the third-party management system.

In a possible implementation manner, under the condition that the third-party management system cannot directly provide the user information to the local management system for adding the user information, that is, the third-party management system cannot provide the user information of the third-party management system through the interface, the user information for identifying the unique user can be obtained by obtaining the user characteristic information provided by the user, other information of the user is obtained by querying the third-party management system through the user characteristic information, and then the information of the user in the third-party management system is filled into the information of the user in the local management system and is stored. By acquiring the user characteristic information and automatically filling other information of the user according to the user characteristic information, user operation can be reduced, and user experience is improved.

In a possible implementation manner, in a case where a third party can provide user information in a third party management system, some or all of the user information provided by the third party management system is obtained according to a preset parameter configuration, (for example, the third party management system includes user information of the entire organization of a group a, the organization a includes the organization a1, the organization a2, the organization A3, and the organization a4, and each organization includes user information of users under its own organization, but only the organization a1 is related to the local management system, so that only the user information included under the organization a1 can be obtained by configuring the local management system in advance through parameters), and the obtained user information in the third party management system is added to the local management system. The user information is encrypted, so that the information security can be improved.

Step B4. sends the first account number and the first password to the Springsecurity framework.

In a possible implementation manner, the first account is encrypted before being sent to the Springsecurity framework, and then the Springsecurity framework decrypts the encrypted first account after receiving the encrypted first account to obtain the first account again.

Step B5. obtains a second account number and a second password in the database.

It will be appreciated that the second account number and the second password in the database are derived from user information in the local management system.

Step B6. sends the second account and the second password to the Springsecurity framework.

In a possible implementation manner, the second account is encrypted before being sent to the Springsecurity framework, and then the Springsecurity framework decrypts the encrypted second account after receiving the encrypted second account to obtain the second account again.

The Springsecurity framework is used for obtaining the verification results of the first account number and the second account number and the first password and the second password. The verification result indicates whether the first account and the second account are successfully matched and whether the first password and the second password are successfully matched. And under the condition that the first account and the second account are successfully matched and the first password and the second password are successfully matched, the verification result is successful. Otherwise, the verification result is unsuccessful matching.

Step B7. determines whether the request authentication is passed based on the verification result.

It will be appreciated that the account number and password are taken out of the database and matched twice, so that matching can be successful under normal conditions. This matching corresponds to the process of simulating the log-in.

Step S204: and under the condition that the target management system passes the authentication request, acquiring a Code returned by the target management system.

That is, the Code is generated by the target management system.

Step S205: and sending the Code to the gateway service module to acquire the Token returned by the gateway service module.

The Code has a shorter effective time than Token. The Code is used for acquiring Token, and the Token is used for determining the identity of the user so as to determine the operation authority of the user.

In a possible implementation manner, the gateway service modules used in the login process by using the local management system or the login process by using the third-party management system are the same gateway service module, namely the gateway service module in the CSP, so that the server resources can be saved. The differential processing of login by using the local management system and login by using the third-party management system in the gateway service module is determined by the characteristic data 'redirect type'. That is, there is a difference in the data carried in Token acquisition depending on the selected target management system. If the local management system is used for logging in, the data carried in the Token acquisition process comprises a Code and characteristic data 'redirect type'; if the third-party management system is used for logging in, the data carried in the Token acquisition process includes the Code, but does not include the characteristic data of the redirect type. The differentiated handling of login with the local management system and login with the third party management system in the gateway service module may be embodied as the following steps C1-C2 and steps D1-D2. Wherein, the steps C1-C2 are processing methods for the target management system being the local management system, and the steps D1-D2 are processing methods for the target management system being the third party management system.

In a possible implementation manner, in a case that the target management system is the local management system, sending the Code to a gateway service module to obtain Token returned by the gateway service module includes step C1-step C2:

step C1: and sending the Code to a gateway service module, wherein the gateway service module is used for sending the Code to a local management system.

Step C2: and receiving the Token sent by the gateway service module, wherein the Token is sent to the gateway service module by the local management system.

It can be understood that, since the local management system and the gateway service module belong to the CSP, in the case that the target management system is the local management system, the gateway service module plays a role in forwarding the Code at this time.

In a possible implementation manner, in a case that the target management system is a third-party management system, sending a Code to the gateway service module to obtain a Token returned by the gateway service module includes steps D1 to D2:

step D1: and sending the Code to a gateway service module, wherein the gateway service module is used for sending the Code to a third-party management system, and the third-party management system is used for returning corresponding user information to the gateway service module according to the received Code.

That is to say, after receiving the Code, the gateway service module uses the Code to obtain the user information in the third-party management system of the user corresponding to the Code in the third-party management system.

Step D2: and receiving the Token sent by the gateway service module, wherein the Token is generated by the gateway service module according to the received user information.

Specifically, after acquiring the user information in the third-party management system of the user, the gateway service module searches and acquires the user information in the local management system corresponding to the user in the local management system according to the user information in the third-party management system of the user. And then, generating Token according to the acquired user information in the local management system.

Step S206: and acquiring a subsystem list according to Token.

The subsystems refer to application systems integrated with the SDKs.

In a possible implementation manner, the manner of obtaining the subsystem list according to Token is as follows: the method comprises the steps that a request for obtaining a subsystem list is sent to a gateway service module, the gateway service module receives the request and then verifies the validity of Token, after the verification is successful, the gateway service module accesses the subsystem to obtain a menu, an SDK (software development kit) module on the subsystem determines the authority of a current user according to the Token, and therefore the subsystem list owned by the current user and the menu list of each subsystem in the subsystem list are returned. Therefore, the method for logging in multiple systems in multiple modes is realized.

The method according to the embodiments of the present application is explained in detail above, and the apparatus according to the embodiments of the present application is described below.

Referring to fig. 4, fig. 4 is a schematic structural diagram of a multi-system login device according to an embodiment of the present disclosure. As shown in fig. 4, the apparatus 400 for multi-system login includes:

a communication module 401, configured to receive a login operation of a user; the system is used for sending request authentication to a target management system, and the target management system determines according to the login operation;

a processing module 402, configured to determine whether the target management system passes the request authentication;

the communication module 401 is further configured to obtain a Code returned by the target management system when the target management system passes the request authentication; sending the Code to a gateway service module to acquire a Token returned by the gateway service module; and acquiring a subsystem list according to the Token.

In a possible implementation manner, the login operation includes a first login operation, the target management system is determined according to the first login operation, and the target management system includes a local management system and a third-party management system.

In a possible implementation manner, the login operation includes a second login operation, the second login operation is used to determine a login manner, and the login manner includes a first login manner and a second login manner.

In a possible implementation manner, the communication module 401 is specifically configured to: sending the Code to a gateway service module, wherein the gateway service module is used for sending the Code to the local management system; and receiving the Token sent by the gateway service module, wherein the Token is sent to the gateway service module by the local management system.

In a possible implementation manner, the communication module 401 is specifically configured to send the Code to a gateway service module, where the gateway service module is configured to send the Code to the third party management system, and the third party management system is configured to return corresponding user information to the gateway service module according to the received Code; and receiving the Token sent by the gateway service module, wherein the Token is generated by the gateway service module according to the received user information.

In a possible implementation manner, the communication module 401 is specifically configured to obtain a first input account and a first input password according to the first login manner; sending the first input account and the first input password to a Spring security framework, wherein the Spring security framework is used for decrypting the first input account to obtain an original input account and encrypting the first input password to obtain a second input password; and acquiring the original account number and the encrypted password in the database. The processing module 402 is specifically configured to encrypt the original account to obtain an encrypted account. The communication module 401 is further configured to send the encrypted account and the encrypted password to the Springsecurity framework, where the Springsecurity framework is configured to decrypt the encrypted account to obtain the original account, and obtain verification results of the original input account and the original account, and the second input password and the encrypted password. The processing module is further used for determining whether the request authentication is passed according to the verification result.

In a possible implementation manner, the communication module 401 is configured to obtain a Code according to the second login manner; sending the Code to the third-party management system to acquire corresponding user information; inquiring to obtain a first account and a first password in a database according to the user information; sending the first account and the first password to a Springsecurity framework; acquiring a second account and a second password in the database; sending the second account and the second password to the Springsecurity framework; the Springsecurity framework is used for obtaining the verification results of the first account number and the second account number and the first password and the second password. The processing module 402 is configured to determine whether the request authentication is passed according to the verification result.

For specific function implementation of the multi-system login apparatus 400, please refer to the corresponding method steps in fig. 2, which are not described herein again.

Please refer to fig. 5, which is a schematic composition diagram of an electronic device according to an embodiment of the present disclosure. Can include the following steps: a processor 110, a memory 120; wherein, the processor 110, the memory 120 and the communication interface 130 are connected by a bus 140, the memory 120 is used for storing instructions, and the processor 110 is used for executing the instructions stored in the memory 120 to implement the corresponding method steps as described above in fig. 2.

The processor 110 is configured to execute the instructions stored in the memory 120 to control the communication interface 130 to receive and transmit signals, thereby implementing the steps of the above-described method. The memory 120 may be integrated in the processor 110, or may be provided separately from the processor 110.

As an implementation manner, the function of the communication interface 130 may be realized by a transceiver circuit or a dedicated chip for transceiving. The processor 110 may be considered to be implemented by a dedicated processing chip, processing circuit, processor, or a general-purpose chip.

As another implementation manner, a computer device provided in the embodiment of the present application may be implemented by using a general-purpose computer. Program code that will implement the functions of the processor 110 and the communication interface 130 is stored in the memory 120, and a general-purpose processor implements the functions of the processor 110 and the communication interface 130 by executing the code in the memory 120.

For the concepts, explanations, details and other steps related to the technical solutions provided in the embodiments of the present application related to the computer device, reference is made to the description of the content of the method steps executed by the apparatus in the foregoing method or other embodiments, which is not described herein again.

As another implementation of the present embodiment, a computer-readable storage medium is provided, on which instructions are stored, which when executed perform the method in the above-described method embodiment.

As another implementation of the present embodiment, a computer program product is provided that contains instructions that, when executed, perform the method in the above-described method embodiments.

Those skilled in the art will appreciate that only one memory and processor are shown in fig. 5 for ease of illustration. In an actual electronic device or server, there may be multiple processors and memories. The memory may also be referred to as a storage medium or a storage device, and the like, which is not limited in this application.

It should be understood that, in the embodiment of the present Application, the processor may be a Central Processing Unit (CPU), and the processor may also be other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field-Programmable Gate arrays (FPGAs) or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components, and the like.

It will also be appreciated that the memory referred to in the embodiments of the application may be either volatile memory or nonvolatile memory, or may include both volatile and nonvolatile memory. The nonvolatile Memory may be a Read-Only Memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an Electrically Erasable PROM (EEPROM), or a flash Memory. The volatile Memory may be a Random Access Memory (RAM) which serves as an external cache. By way of example and not limitation, many forms of RAM are available, such as Static random access memory (Static RAM, SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct bus RAM (DR RAM).

It should be noted that when the processor is a general-purpose processor, a DSP, an ASIC, an FPGA or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, the memory (memory module) is integrated in the processor.

It should be noted that the memory described herein is intended to comprise, without being limited to, these and any other suitable types of memory.

The bus may include a power bus, a control bus, a status signal bus, and the like, in addition to the data bus. But for clarity of illustration the various buses are labeled as buses in the figures.

It should also be understood that reference herein to first, second, third, fourth, and various numerical designations is made only for ease of description and should not be used to limit the scope of the present application.

It should be understood that the term "and/or" herein is merely one type of association relationship that describes an associated object, meaning that three relationships may exist, e.g., a and/or B may mean: a exists alone, A and B exist simultaneously, and B exists alone. In addition, the character "/" herein generally indicates that the former and latter related objects are in an "or" relationship.

In implementation, the steps of the above method may be performed by integrated logic circuits of hardware in a processor or instructions in the form of software. The steps of a method disclosed in connection with the embodiments of the present application may be directly implemented by a hardware processor, or may be implemented by a combination of hardware and software modules in a processor. The software module may be located in ram, flash memory, rom, prom, or eprom, registers, etc. storage media as is well known in the art. The storage medium is located in a memory, and a processor reads information in the memory and completes the steps of the method in combination with hardware of the processor. To avoid repetition, it is not described in detail here.

In the embodiments of the present application, the sequence numbers of the above-mentioned processes do not mean the execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

Those of ordinary skill in the art will appreciate that the various Illustrative Logical Blocks (ILBs) and steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit.

In the above embodiments, the implementation may be wholly or partially realized by software, hardware, firmware, or any combination thereof. When implemented in software, it may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, cause the processes or functions described in accordance with the embodiments of the application to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by wire (e.g., coaxial cable, fiber optic, digital subscriber line) or wirelessly (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that incorporates one or more of the available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk), among others.

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A method for multi-system login, the method comprising:

receiving login operation of a user;

judging whether the target management system passes the request authentication;

and acquiring a subsystem list according to the Token.

2. The method according to claim 1, wherein the login operation includes a first login operation, the target management system determines according to the first login operation, and in a case that the target management system is the local management system, the sending the Code to a gateway service module to obtain the Token returned by the gateway service module includes:

sending the Code to a gateway service module, wherein the gateway service module is used for sending the Code to the local management system;

and receiving the Token sent by the gateway service module, wherein the Token is sent to the gateway service module by the local management system.

3. The method according to claim 1, wherein the login operation includes a first login operation, the target management system determines according to the first login operation, and in a case that the target management system is the third party management system, the sending the Code to a gateway service module to obtain the Token returned by the gateway service module includes:

sending the Code to a gateway service module, wherein the gateway service module is used for sending the Code to the third party management system, and the third party management system is used for returning corresponding user information to the gateway service module according to the received Code;

and receiving the Token sent by the gateway service module, wherein the Token is generated by the gateway service module according to the received user information.

4. The method according to claim 2 or 3, wherein the login operation comprises a second login operation, the second login operation is used for determining a login mode, the login mode comprises a first login mode, and the determining whether the target management system passes the request authentication comprises:

acquiring a first input account and a first input password according to the first login mode;

sending the first input account and the first input password to a Spring security framework, wherein the Spring security framework is used for decrypting the first input account to obtain an original input account and encrypting the first input password to obtain a second input password;

acquiring an original account and an encrypted password in a database;

encrypting the original account to obtain an encrypted account;

sending the encrypted account and the encrypted password to a Spring security framework, wherein the Spring security framework is used for decrypting the encrypted account to obtain the original account and obtaining verification results of the original input account and the original account as well as the second input password and the encrypted password;

and determining whether the request authentication is passed according to the verification result.

5. The method according to claim 2 or 3, wherein the login operation comprises a second login operation, the second login operation is used for determining login modes, the login modes comprise second login modes, and the determining whether the target management system passes the request authentication comprises:

acquiring a Code according to the second login mode;

sending the Code to the third-party management system to acquire corresponding user information;

inquiring to obtain a first account and a first password in a database according to the user information;

sending the first account and the first password to a Springsecurity framework;

acquiring a second account and a second password in the database;

sending the second account and the second password to the Springsecurity framework; the Springsecurity framework is used for obtaining verification results of the first account number and the second account number and the first password and the second password;

and determining whether the request authentication is passed or not according to the verification result.

6. The method of claim 1, further comprising:

acquiring user characteristic information, wherein the user characteristic information is used for identifying a unique user;

inquiring and acquiring other information of the user corresponding to the user characteristic information in the third-party management system according to the user characteristic information;

and storing other information of the user corresponding to the user characteristic information into the local management system.

7. The method of claim 1, further comprising:

acquiring user information of a third-party management system according to preset parameter configuration;

and adding the user information to the local management system.

8. An apparatus for multi-system login, the apparatus comprising:

the processing module is used for judging whether the target management system passes the request authentication or not;

the communication module is further used for acquiring a Code returned by the target management system under the condition that the target management system passes the request authentication; sending the Code to a gateway service module to acquire a Token returned by the gateway service module; and acquiring a subsystem list according to the Token.

9. An electronic device, comprising a processor and a memory, the processor and the memory being interconnected, wherein the memory is configured to store a computer program comprising program instructions, the processor being configured to invoke the program instructions to perform the method of any one of claims 1-7.

10. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program comprising program instructions that, when executed by a processor, cause the processor to carry out the method according to any one of claims 1-7.