CN111865938B - Login method and device - Google Patents
Login method and device Download PDFInfo
- Publication number
- CN111865938B CN111865938B CN202010623072.7A CN202010623072A CN111865938B CN 111865938 B CN111865938 B CN 111865938B CN 202010623072 A CN202010623072 A CN 202010623072A CN 111865938 B CN111865938 B CN 111865938B
- Authority
- CN
- China
- Prior art keywords
- authorization
- user
- data
- self
- login
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/102—Entity profiles
Landscapes
- Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Power Engineering (AREA)
- Telephonic Communication Services (AREA)
- Information Transfer Between Computers (AREA)
Abstract
The application discloses a login method and a login device, electronic equipment and a computer readable storage medium, wherein the method comprises the following steps: acquiring uniform authorization data and self-built authorization data, wherein the uniform authorization data is used for verifying a user with a uniform authorization type in a login process, and the self-built authorization data is used for verifying a user with a self-built authorization type in the login process; receiving login data to be verified of a first user; using the unified authorization data or the self-built authorization data to verify login data to be verified of the first user; and if the verification is passed, allowing the first user to log in. The unified authorization data and the self-established authorization data are obtained in a data importing or data inputting mode, the registration step of a user is omitted, the login data to be verified of the first user are verified through the unified authorization data or the self-established authorization data, if the verification is passed, the first user is allowed to login, and therefore interfaces and processes are kept consistent when the user logs in under different account authorization systems.
Description
Technical Field
The present application relates to the field of information processing technologies, and in particular, to a login method and apparatus, an electronic device, and a computer-readable storage medium.
Background
The registration login function is the most basic function of the system, and a common registration login has only one account authorization system, but when accounts with different permissions of multiple business departments in a company need to use the same business system (such as a CRM system) at the same time, different account authorization systems may be involved, such as a unified authorization system and a self-established authorization system. Therefore, front-end experience consistency of login and registration of different account numbers of multiple departments needs to be considered as much as possible during process design.
The prior art generally adopts the following login method: under the same account authorization system, the user data is managed by using a unified database and a table, the interfaces and the flows of the users with different authorities during registration and login are kept consistent, and various interfaces and flows of registration and login are not needed. The method has the defect that the problem that the interfaces and the flows can not be kept consistent when the user registers and logs in under different account authorization systems is not solved.
Disclosure of Invention
The application aims to provide a login method and device, electronic equipment and a computer readable storage medium, and solve the problem that interfaces and processes cannot be kept consistent when users register and login under different account authorization systems.
The purpose of the application is realized by adopting the following technical scheme:
in a first aspect, the present application provides a login method, including: acquiring uniform authorization data and self-built authorization data, wherein the uniform authorization data is used for verifying a user with a uniform authorization type in a login process, and the self-built authorization data is used for verifying a user with a self-built authorization type in the login process; receiving login data to be verified of a first user; using the unified authorization data or the self-built authorization data to verify login data to be verified of the first user; and if the verification is passed, allowing the first user to log in. The technical scheme has the advantages that the unified authorization data and the self-built authorization data are obtained in a data importing or data inputting mode, the registration step of a user is omitted, the login data to be verified of the first user are verified through the unified authorization data or the self-built authorization data, if the login data to be verified pass the verification, the first user is allowed to log in, and therefore interfaces and processes of the user during login under different account authorization systems are kept consistent.
In some possible implementations, the verifying the login data to be verified of the first user by using the unified authorization data or the self-established authorization data includes: using the unified authorization data to verify login data to be verified of the first user; and if the verification is not passed, the login data to be verified of the first user is verified by using the self-built authorization data. The technical scheme has the advantages that the unified authorization data generally cannot be frequently called or changed, the unified authorization data is preferentially used for verifying the login data to be verified of the user, and the verification efficiency can be improved.
In some possible implementations, the obtaining the unified authorization data and the self-established authorization data includes: acquiring the uniform authorization data and storing the uniform authorization data into a uniform authorization table, and acquiring the self-built authorization data and storing the self-built authorization data into a self-built authorization table; the verifying the login data to be verified of the first user by using the unified authorization data or the self-built authorization data includes: and checking the login data to be checked of the first user by using the data in the unified authorization table or the data in the self-established authorization table. The technical scheme has the beneficial effects that the authorization data of the user are stored in different data tables, and the pressure of a single data table is shared.
In some possible implementations, the verifying the login data to be verified of the first user by using the data in the unified authorization table or the data in the self-established authorization table includes: obtaining the authorization type of the first user according to the login data to be verified of the first user; if the authorization type of the first user is a uniform authorization type, verifying the login data to be verified of the first user by using the data in the uniform authorization table; and if the authorization type of the first user is the self-established authorization type, verifying the login data to be verified of the first user by using the data in the self-established authorization table. The technical scheme has the advantages that the login data to be verified of the user is verified by using the corresponding authorization data according to the authorization type of the user, and the verification efficiency is improved.
In some possible implementations, the login data to be verified of the first user includes identification information of the first user; the method further comprises the following steps: setting identification information corresponding to the authorization type of the user for each user; the obtaining the authorization type of the first user according to the login data to be verified of the first user comprises: and obtaining the authorization type of the first user according to the identification information of the first user. The technical scheme has the advantages that the identification information corresponding to the authorization type of each user is set for each user, so that the authorization type of the user can be obtained according to the identification information of the user when the login data to be verified of the user is received, and the verification efficiency is further improved by utilizing the corresponding relation between the identification information and the authorization type.
In some possible implementations, if the authorization type of the first user is a self-established authorization type, the method further includes: receiving identity information to be verified of the first user; checking the identity information to be checked of the first user by using the data in the self-established authorization table; if the verification is passed, allowing the first user to register; and receiving registration data input by the first user and storing the registration data in the self-built authorization table. The technical scheme has the advantages that the user with the self-established authorization type in the self-established authorization table can be configured to be started by registration, and a consistent registration interface and a consistent registration flow are provided for the user with the self-established authorization type.
In some possible implementations, the method further includes: acquiring the authority type of the first user; and if the authority type of the first user is the first authority type, receiving sub-account authorization data sent by the first user and storing the sub-account authorization data to the self-built authorization table. The technical scheme has the advantages that the user with the first permission type has the permission of independently creating the sub-account, receives the sub-account authorization data sent by the user with the first permission type and stores the sub-account authorization data into the self-created authorization table, and the function of independently creating the sub-account by the user is achieved.
In some possible implementations, the method further includes: receiving identity information to be verified of a second user; checking the identity information to be checked of the second user by using the sub-account authorization data sent by the first user; and if the verification is passed, allowing the second user to be registered as the sub-account of the first user. The technical scheme has the beneficial effects that the sub-account number created by the user independently can use the data in the self-established authorization table to check the registration data of the sub-account number so as to realize the registration of the sub-account number.
In some possible implementation manners, the unified authorization data and the self-built authorization data both include at least one of account password information, a name and a mobile phone number of a user, and the account password information includes an account and a password corresponding to the account; the checking the login data to be checked of the first user by using the unified authorization data or the self-established authorization data comprises the following steps: and verifying the login data to be verified of the first user by using the unified authorization data or the account password information, the name or the mobile phone number in the self-built authorization data. The technical scheme has the beneficial effects that the account number and the password, the name or the mobile phone number are used for verifying in the login process.
In some possible implementations, the method further includes: receiving a code scanning login request sent by first equipment, wherein a first user is in a logged-in state on the first equipment; and allowing the first user to log in response to the code scanning login request. The technical scheme has the beneficial effect that the login function is realized in a code scanning mode.
In a second aspect, the present application provides a login device, the device comprising: the system comprises an acquisition module, a storage module and a processing module, wherein the acquisition module is used for acquiring unified authorization data and self-established authorization data, the unified authorization data is used for verifying a user with a unified authorization type in a login process, and the self-established authorization data is used for verifying the user with the self-established authorization type in the login process; the receiving module is used for receiving login data to be verified of a first user; the verification module is used for verifying the login data to be verified of the first user by using the unified authorization data or the self-built authorization data; and the login module is used for allowing the first user to log in if the verification is passed.
In some possible implementations, the check module is to: using the unified authorization data to verify login data to be verified of the first user; and if the verification is not passed, the login data to be verified of the first user is verified by using the self-built authorization data.
In some possible implementation manners, the obtaining module is configured to obtain the unified authorization data and store the unified authorization data in a unified authorization table, and obtain the self-established authorization data and store the self-established authorization data in a self-established authorization table; the verification module is used for verifying the login data to be verified of the first user by using the data in the unified authorization table or the data in the self-built authorization table.
In some possible implementations, the check module is to: obtaining the authorization type of the first user according to the login data to be verified of the first user; if the authorization type of the first user is a uniform authorization type, verifying login data to be verified of the first user by using data in the uniform authorization table; and if the authorization type of the first user is the self-established authorization type, verifying the login data to be verified of the first user by using the data in the self-established authorization table.
In some possible implementations, the login data to be verified of the first user includes identification information of the first user; the device also comprises a setting module used for setting identification information corresponding to the authorization type of the user for each user; the checking module is further used for obtaining the authorization type of the first user according to the identification information of the first user.
In some possible implementations, if the authorization type of the first user is a self-established authorization type, the apparatus further includes a registration module, where the registration module is configured to: receiving identity information to be verified of the first user; checking the identity information to be checked of the first user by using the data in the self-established authorization table; if the verification is passed, allowing the first user to register; and receiving registration data input by the first user and storing the registration data in the self-built authorization table.
In some possible implementations, the apparatus further includes a sub-account module, the sub-account module is configured to: acquiring the authority type of the first user; and if the authority type of the first user is the first authority type, receiving sub-account authorization data sent by the first user and storing the sub-account authorization data to the self-built authorization table.
In some possible implementations, the sub-account module is further configured to: receiving identity information to be verified of a second user; checking the identity information to be checked of the second user by using the sub-account authorization data sent by the first user; and if the verification is passed, allowing the second user to be registered as the sub-account of the first user.
In some possible implementation manners, the unified authorization data and the self-built authorization data both include at least one of account password information, a name and a mobile phone number of a user, and the account password information includes an account and a password corresponding to the account; the verification module is used for verifying the login data to be verified of the first user by using account number and password information, a name or a mobile phone number in the unified authorization data or the self-built authorization data.
In some possible implementations, the login module is further configured to: receiving a code scanning login request sent by first equipment, wherein a first user is in a logged-in state on the first equipment; and allowing the first user to log in response to the code scanning login request.
In a third aspect, the present application further provides an electronic device, including a memory and a processor, where the memory stores a computer program, and the processor implements the steps of any one of the above methods when executing the computer program.
In a fourth aspect, the present application also provides a computer-readable storage medium storing a computer program which, when executed by a processor, implements the steps of any of the methods described above.
Compared with the prior art, the beneficial effect of this application includes:
the application discloses a login method and device, electronic equipment and a computer readable storage medium, unified authorization data and self-built authorization data are obtained in a data importing or data inputting mode, the registration step of a user is omitted, login data to be verified of a first user are verified through the unified authorization data or the self-built authorization data, if the login data to be verified pass the verification, the first user is allowed to login, and therefore interfaces and processes are kept consistent when the user logs in under different account authorization systems.
Drawings
The present application is further described below with reference to the drawings and examples.
Fig. 1 is a schematic flowchart of a login method according to an embodiment of the present application;
fig. 2 is a schematic flowchart of a login verification process according to an embodiment of the present disclosure;
fig. 3 is a schematic flowchart of a login verification process according to an embodiment of the present application;
fig. 4 is a schematic flowchart of creating a sub-account according to an embodiment of the present disclosure;
fig. 5 is a schematic flowchart of a process of registering and logging in a seed account according to an embodiment of the present disclosure;
FIG. 6 is a flowchart illustrating a code scanning registration process provided by an embodiment of the present application;
fig. 7 is a schematic flowchart of a login method according to an embodiment of the present application;
fig. 8 is a schematic structural diagram of a login apparatus according to an embodiment of the present application;
fig. 9 is a schematic structural diagram of an electronic device according to an embodiment of the present application;
fig. 10 is a schematic structural diagram of a program product for implementing a login method according to an embodiment of the present application.
Detailed Description
The present application is further described with reference to the accompanying drawings and the detailed description, and it should be noted that, in the case of no conflict, any combination between the embodiments or technical features described below may form a new embodiment.
Referring to fig. 1, an embodiment of the present application provides a login method, which is applied to an occasion where different account numbers in the same service system relate to different account authorization systems, and the method includes steps S101 to S104.
Step S101: acquiring unified authorization data and self-established authorization data, wherein the unified authorization data is used for verifying a user with a unified authorization type in a login process, and the self-established authorization data is used for verifying a user with a self-established authorization type in the login process. The unified authorization data and the self-established authorization data are authorization data, the authorization data may include registration data, creation data, and/or other data used for verifying the identity of the user, the registration data of the user refers to data input by the user when the user registers an account, the creation data of the user refers to data input by a department administrator when the sub-account user is created, and the other data used for verifying the identity of the user is, for example, an identity card number, a job number, or a passport number. The registration data and the creation data of the user can include the name and the mobile phone number of the user, the user identity is verified in a mode such as account number password verification and mobile phone number verification, the user is allowed to log in if the verification is passed, the user can also realize code scanning login through logged-in equipment, the verification mode and the code scanning login mode can adopt modes in the prior art, and repeated description is omitted in the application. The user with the unified authorization type refers to a user defined by a system administrator in the service system, and the user with the self-established authorization type refers to a user defined by a department administrator in the service system. The department administrator may be a business department administrator or an administrator of a network site, branch.
Step S102: and receiving login data to be verified of the first user. The login data to be verified is at least one of account password information, name and mobile phone number, wherein the account password information refers to an account and a password corresponding to the account.
Step S103: and using the unified authorization data or the self-built authorization data to verify the login data to be verified of the first user. In some possible implementations, the check-up during the login process may be performed using an account password, a name, or a mobile phone number. Specifically, the unified authorization data and the self-built authorization data may both include at least one of account password information, a name, and a mobile phone number of the user, where the account password information includes an account and a password corresponding to the account. The step S103 may include: and verifying the login data to be verified of the first user by using the account number and password information, the name or the mobile phone number in the unified authorization data or the self-built authorization data.
Step S104: and if the verification is passed, allowing the first user to log in. This step may allow the user to log into a system or application involving a different account authorization hierarchy, the system being, for example, a CRM system, and the application being, for example, kyushutong.
The unified authorization data and the self-established authorization data are obtained in a data importing or data inputting mode, the registration step of a user is omitted, the login data to be verified of the first user are verified through the unified authorization data or the self-established authorization data, if the verification is passed, the first user is allowed to login, and therefore interfaces and processes are kept consistent when the user logs in under different account authorization systems.
In some possible implementation manners, the unified authorization data is generally not frequently called or changed, and the unified authorization data is preferentially used for verifying the login data to be verified of the user, so that the verification efficiency can be improved. Specifically, referring to fig. 2, the step S103 may include steps S1031 to S1032.
Step S1031: using the unified authorization data to verify login data to be verified of the first user; if the verification passes, step S104 is executed.
Step S1032: if the verification is not passed, the login data to be verified of the first user is verified by using the self-built authorization data; if the verification is passed, executing step S104; and if the verification is not passed, not allowing the first user to log in.
In some possible implementations, the authorization data of the user may be stored in different data tables, sharing the pressure of a single data table. Specifically, the step S101 may include: and acquiring the uniform authorization data and storing the uniform authorization data in a uniform authorization table, and acquiring the self-built authorization data and storing the self-built authorization data in a self-built authorization table.
The step S103 may include: and checking the login data to be checked of the first user by using the data in the unified authorization table or the data in the self-established authorization table.
In some possible implementation manners, the login data to be verified of the user can be verified by using the corresponding authorization data according to the authorization type of the user, so that the verification efficiency is improved. Specifically, referring to fig. 3, the step S103 may include steps S1033 to S1035.
Step S1033: and obtaining the authorization type of the first user according to the login data to be verified of the first user.
Step S1034: and if the authorization type of the first user is the uniform authorization type, verifying the login data to be verified of the first user by using the data in the uniform authorization table.
Step S1035: and if the authorization type of the first user is the self-established authorization type, verifying the login data to be verified of the first user by using the data in the self-established authorization table.
In some possible implementation manners, identification information corresponding to the authorization type of each user can be set for each user, so that the authorization type of the user can be obtained according to the identification information of the user when login data to be verified of the user is received, and the verification efficiency is further improved by using the corresponding relation between the identification information and the authorization type. Specifically, the login data to be verified of the first user may include identification information of the first user. The identification information is, for example, an account name such as "unified authorization zhang" or "self-created authorization zhu si", or a keyword identification in an account ID such as "01 × × and" 02 × ", and distinguishes users of the unified authorization type from users of the self-created authorization type in a similar manner.
The method may further comprise the steps of: and setting identification information corresponding to the authorization type of the user for each user.
The step S1033 may include: and obtaining the authorization type of the first user according to the identification information of the first user.
In some possible implementation manners, a user with a first permission type has the permission to autonomously create a sub-account, and receives sub-account authorization data sent by the user with the first permission type and stores the sub-account authorization data into an autonomous authorization table, so that the function of autonomously creating the sub-account by the user is realized. Specifically, referring to fig. 4, the method may further include steps S105 to S106.
Step S105: and acquiring the authority type of the first user. The types of permissions may include, for example, system administrators, department administrators, and general employees.
Step S106: and if the authority type of the first user is the first authority type, receiving sub-account authorization data sent by the first user and storing the sub-account authorization data to the self-built authorization table.
The first permission type is, for example, a department administrator. The authority type of the administrator of the business department can be set as a department administrator, and the authority type of the administrator of the network site or the branch can also be set as a department administrator. The administrator of the business department may be a department administrator in a self-established authorization system independent of the unified authorization system, created autonomously or by a system administrator. The administrator of the network site or branch may be created by a system administrator, affiliated with a department administrator in the unified authorization hierarchy. As long as the authority type of the user is a department administrator, the sub-account can be created autonomously, that is, both the department administrator in the self-established authorization system and the department administrator in the unified authorization system can create the sub-account autonomously. And the sub-account numbers independently created by the two belong to a self-built authorization system, and the sub-account number authorization data belong to self-built authorization data and are stored in a self-built authorization table. The sub-account authorization data may be at least one of account password information, name, and phone number.
In some possible implementation manners, the user of the self-established authorization type in the self-established authorization table needs to be enabled through registration, and a consistent registration interface and a consistent registration flow are provided for the user of the self-established authorization type. Specifically, if the authorization type of the first user is a self-established authorization type, the method may further include: receiving identity information to be verified of the first user; verifying the identity information to be verified of the first user by using the data in the self-built authorization table; and if the verification is passed, allowing the first user to register. The identity information to be verified is, for example, a name, an identification number, a passport number, a mobile phone number, or other identification. The method may further comprise: and receiving registration data input by the first user and storing the registration data in the self-built authorization table. The identity information to be verified may only be a name, an identity card number or a mobile phone number, and other identity identification information needs to be supplemented when the user registers for verification in a subsequent login process.
In some possible implementations, the sub-account created by the user himself may use the data in the self-created authorization table to check its registration data to enable registration of the sub-account. Specifically, referring to fig. 5, the method may further include steps S107 to S109.
Step S107: and receiving identity information to be verified of the second user.
Step S108: and checking the identity information to be checked of the second user by using the sub-account authorization data sent by the first user.
Step S109: and if the verification is passed, allowing the second user to register as the sub account of the first user.
Further, the method may further include step S110: and receiving registration data input by the second user and storing the registration data in the self-built authorization table.
With continued reference to FIG. 5, the method may further include steps S111-S113.
Step S111: and receiving login data to be verified of a second user.
Step S112: and checking the login data to be checked of the second user by using the data in the self-established authorization table.
Step S113: and if the verification is passed, allowing the second user to log in.
It can be seen that, regardless of the sub-accounts created by the department administrator in the self-established authorization system or the department administrator in the unified authorization system, the flow during registration and login is consistent, and the front-end experience is consistent.
In some possible implementation manners, a user who has logged in to the client may implement the login function of the computer by scanning a code. Specifically, referring to fig. 6, the method may further include steps S114 to S115.
Step S114: receiving a code scanning login request sent by first equipment, wherein the first user is in a logged-in state on the first equipment.
Step S115: and allowing the first user to log in response to the code scanning login request.
Referring to fig. 7, an embodiment of the present application further provides a login method, where the method includes steps S201 to S207, and the method may further include steps S301 to S310, and steps S401 to S413. Steps S201 to S207 are login methods of users of uniform authorization type under the uniform authorization system, steps S301 to S310 are login methods of users of self-established authorization type under the self-established authorization system, and steps S401 to S413 are login methods of users of semi-uniform semi-self-established authorization type under the semi-uniform semi-self-established authorization system. The semi-uniform semi-self-built authorization type user refers to the fact that a user account is an account distributed by a uniform authorization table, a sub-account is a sub-account which is created by the user independently, and the sub-account is generally a mobile phone number and can also be an identity card number or other identity identification information.
Step S201: the unified authorization table allocates a unified authorization account for the user, and account registration data of the user is stored in the unified authorization table, and the account registration data may generally include a name, a role (permission type), a mobile phone number, and the like of the user.
Step S202: and (3) logging in by the user, executing the step S203 if the user logs in by using the account password, executing the step S205 if the user logs in by using the mobile phone number, and executing the step S207 if the user logs in by scanning the code.
Step S203: and if the user logs in by using the account password, the account password of the user in the unified authorization table is used for verifying the account password to be verified input by the user.
Step S204: if the account password passes the verification, allowing the user to log in the account; if the verification code input by the user is correct, allowing the user to log in an account corresponding to the mobile phone number; and if the equipment for sending the code scanning login request by the user logs in a certain account, allowing the user to log in the account.
Step S205: and if the user logs in by using the mobile phone number, the mobile phone number of the user in the unified authorization table is used for verifying the mobile phone number to be verified input by the user.
Step S206: and if the verification is passed, sending a verification code to the mobile phone number, and executing the step S204.
Step S207: if the user is in the logged-on state on the device and logs in by using the device scan code, step S204 is executed.
Step S301: the self-built authorization table is used for distributing self-built authorization account numbers for users, account number registration data of the users are stored in the self-built authorization table, and the account number registration data can generally comprise names, roles (authority types), mobile phone numbers and the like of the users.
Step S302: and (4) registering the user.
Step S303: the user inputs a name and a mobile phone number to call the short message interface.
Step S304: and checking the name and the mobile phone number input by the user by using the data in the self-built authorization table, and if at least one piece of self-built authorization data is consistent with the name and the mobile phone number input by the user, sending an authentication code to the mobile phone number input by the user.
Step S305: the user completes the registration.
Step S306: and (4) logging in by the user, executing the step S307 if the user logs in by using the mobile phone number, and executing the step S310 if the user scans the code to log in.
Step S307: and if the user logs in by using the mobile phone number, the mobile phone number of the user in the self-built authorization table is used for verifying the mobile phone number to be verified input by the user.
Step S308: and if the verification is passed, sending a verification code to the mobile phone number, and executing step S309.
Step S309: if the verification code input by the user is correct, allowing the user to log in an account corresponding to the mobile phone number; and if the equipment of the code scanning login request sent by the user logs in a certain account, allowing the user to log in the account.
Step S310: if the user is in the logged-on state on the device and logs in by scanning the code with the device, step S309 is executed.
Step S401: the unified authorization table allocates a unified authorization account for a user with an authority type of a department administrator, account registration data of the user is stored in the unified authorization table, and the account registration data can generally include the name, the role (the authority type), the mobile phone number and the like of the user.
Step S402: and (4) logging in by the department administrator, executing the step S403 if the department administrator logs in by using the account password, executing the step S405 if the department administrator logs in by using the mobile phone number, and executing the step S407 if the department administrator scans the code for logging in.
Step S403: and if the department administrator logs in by using the account password, the account password of the department administrator in the unified authorization table is used for verifying the account password to be verified, which is input by the department administrator.
Step S404: if the account password passes the verification, allowing a department administrator to log in the account; if the verification code input by the department administrator is correct, allowing the department administrator to log in an account corresponding to the mobile phone number; if the equipment of the department administrator sending the code scanning login request has already logged in a certain account, the department administrator is allowed to log in the account
Step S405: and if the department administrator logs in by using the mobile phone number, the mobile phone number to be verified input by the department administrator is verified by using the mobile phone number of the department administrator in the unified authorization table.
Step S406: and if the verification is passed, sending a verification code to the mobile phone number, and executing the step S404.
Step S407: if the department administrator is in the logged-on state on the device and logs in by scanning the code with the device, step S404 is executed.
Step S408: the department administrator creates a sub-account.
Step S409: and (4) logging in by the self-established sub-account, executing the step S410 if the self-established sub-account uses the mobile phone number for logging in, and executing the step S413 if the self-established sub-account scans the code for logging in.
Step S410: and if the self-established sub-account is logged in by using the mobile phone number, verifying the mobile phone number to be verified input by the self-established sub-account by using the mobile phone number in the account number establishing information of the self-established sub-account in the self-established authorization table.
Step S411: and if the verification is passed, sending a verification code to the mobile phone number, and executing the step S412.
Step S412: if the verification code input by the self-built sub-account number is correct, allowing the self-built sub-account number to log in an account number corresponding to the mobile phone number; and if the equipment for sending the code scanning login request by the self-built sub-account number already logs in an account, allowing the self-built sub-account number to log in the account.
Step S413: if the self-established sub-account is in the logged-in state on the device and is logged in by using the device scan code, step S412 is executed.
Referring to fig. 8, an embodiment of the present application further provides a login apparatus, where the apparatus includes modules 201 to 204.
The obtaining module 201 is configured to obtain unified authorization data and self-established authorization data, where the unified authorization data is used to check a user with a unified authorization type in a login process, and the self-established authorization data is used to check a user with a self-established authorization type in a login process.
The receiving module 202 is configured to receive login data to be verified of a first user.
A checking module 203, configured to check the login data to be checked of the first user using the unified authorization data or the self-established authorization data.
And the login module 204 is configured to allow the first user to log in if the verification passes.
In some possible implementations, the checking module 203 is configured to: using the unified authorization data to verify login data to be verified of the first user; and if the verification is not passed, the login data to be verified of the first user is verified by using the self-built authorization data.
In some possible implementation manners, the obtaining module 201 is configured to obtain the uniform authorization data and store the uniform authorization data in a uniform authorization table, and obtain the self-established authorization data and store the self-established authorization data in a self-established authorization table; the checking module 203 is configured to check the login data to be checked of the first user by using the data in the unified authorization table or the data in the self-established authorization table.
In some possible implementations, the checking module 203 is configured to: obtaining the authorization type of the first user according to the login data to be verified of the first user; if the authorization type of the first user is a uniform authorization type, verifying the login data to be verified of the first user by using the data in the uniform authorization table; and if the authorization type of the first user is the self-established authorization type, verifying the login data to be verified of the first user by using the data in the self-established authorization table.
In some possible implementations, the login data to be verified of the first user includes identification information of the first user; the device further comprises a setting module 205 for setting identification information corresponding to the authorization type of the user for each user; the checking module 203 is further configured to obtain an authorization type of the first user according to the identification information of the first user.
In some possible implementations, if the authorization type of the first user is a self-established authorization type, the apparatus further includes a registration module 206, where the registration module 206 is configured to: receiving identity information to be verified of the first user; verifying the identity information to be verified of the first user by using the data in the self-built authorization table; if the verification is passed, allowing the first user to register; and receiving registration data input by the first user and storing the registration data in the self-built authorization table.
In some possible implementations, the apparatus further includes a sub-account module 207, where the sub-account module 207 is configured to: acquiring the authority type of the first user; and if the authority type of the first user is the first authority type, receiving sub-account authorization data sent by the first user and storing the sub-account authorization data to the self-built authorization table.
In some possible implementations, the sub-account module 207 is further configured to: receiving identity information to be verified of a second user; checking the identity information to be checked of the second user by using the sub-account authorization data sent by the first user; and if the verification is passed, allowing the second user to register as the sub account of the first user.
In some possible implementation manners, the unified authorization data and the self-built authorization data both include at least one of account password information, a name and a mobile phone number of a user, and the account password information includes an account and a password corresponding to the account; the verification module 203 is configured to verify login data to be verified of the first user by using account password information, a name, or a mobile phone number in the unified authorization data or the self-established authorization data.
In some possible implementations, the login module 204 is further configured to: receiving a code scanning login request sent by first equipment, wherein a first user is in a logged-in state on the first equipment; and allowing the first user to log in response to the code scanning login request.
Referring to fig. 9, an embodiment of the present application further provides an electronic device 3, where the electronic device 3 includes at least one memory 31, at least one processor 32, and a bus 33 connecting different platform systems.
The memory 31 may include readable media in the form of volatile memory, such as Random Access Memory (RAM) 311 and/or cache memory 312, and may further include Read Only Memory (ROM) 313.
In which the memory 31 further stores a computer program, which program product 4 can be executed by the processor 32, so that the processor 32 executes the steps of the login method in the embodiment of the present application (as shown in fig. 1). Memory 31 may also include a program/utility 314 having a set (at least one) of program modules 315, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which or some combination thereof may comprise an implementation of a network environment.
Accordingly, the processor 32 may execute the program product 4 described above, as well as execute the program/utility 314.
The electronic device 3 may also communicate with one or more external devices 34, such as a keyboard, pointing device, bluetooth device, etc., and may also communicate with one or more devices capable of interacting with the electronic device 3, and/or with any device (e.g., router, modem, etc.) that enables the electronic device 3 to communicate with one or more other computing devices. Such communication may be through input/output (I/O) interfaces 35. Also, the electronic device 3 may communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network, such as the internet) via the network adapter 36. The network adapter 36 may communicate with other modules of the electronic device 3 via the bus 33. It should be appreciated that although not shown in FIG. 9, other hardware and/or software modules may be used in conjunction with the electronic device 3, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage platforms, to name a few.
Referring to fig. 10, an embodiment of the present application further provides a computer-readable storage medium for storing a computer program, where the computer program is executed to implement the steps of the login method in the embodiment of the present application (as shown in fig. 1). Fig. 10 shows a program product 4 provided by the present embodiment for implementing the above method, which may employ a portable compact disc read only memory (CD-ROM) and include program codes, and may be run on a terminal device, such as a personal computer. However, the program product 4 of the present invention is not limited thereto, and in this document, a readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. Program product 4 may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium include: an electrical connection having one or more wires, a portable disk, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
A computer readable storage medium may include a propagated data signal with readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A readable storage medium may also be any readable medium that is not a readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a readable storage medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing. Program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computing device, partly on the user's device, as a stand-alone software package, partly on the user's computing device and partly on a remote computing device, or entirely on the remote computing device or server. In situations involving remote computing devices, the remote computing devices may be connected to the user computing device through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to external computing devices (e.g., through the internet using an internet service provider).
The foregoing description and drawings are only for purposes of illustrating the preferred embodiments of the present application and are not intended to limit the present application, which is, therefore, to the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present application.
Claims (7)
1. A login method is characterized in that the login method is applied to the same service system, different account numbers under the same service system relate to different account authorization systems, and the method comprises the following steps:
acquiring uniform authorization data and self-built authorization data, wherein the uniform authorization data is used for verifying a user with a uniform authorization type in a login process, and the self-built authorization data is used for verifying a user with a self-built authorization type in the login process;
receiving login data to be verified of a first user;
using the unified authorization data or the self-built authorization data to verify login data to be verified of the first user;
if the verification is passed, allowing the first user to log in;
the acquiring of the unified authorization data and the self-established authorization data includes:
acquiring the uniform authorization data and storing the uniform authorization data into a uniform authorization table, and acquiring the self-built authorization data and storing the self-built authorization data into a self-built authorization table;
the verifying the login data to be verified of the first user by using the unified authorization data or the self-built authorization data includes:
using the data in the unified authorization table or the data in the self-built authorization table to verify the login data to be verified of the first user;
the method further comprises the following steps:
acquiring the authority type of the first user; the authority types comprise a system administrator, a department administrator and common staff;
if the authority type of the first user is the first authority type, receiving sub-account authorization data sent by the first user and storing the sub-account authorization data into the self-established authorization table;
wherein the first permission type is a department administrator; the authority type of the administrator of the business department is a department administrator, and the authority type of the administrator of the network site or the branch is a department administrator; the administrator of the business department is independently established or established by a system administrator, and is independent of the department administrator in the self-established authorization system of the unified authorization system; the administrator of the network point or the branch is created by a system administrator and is affiliated to a department administrator in the unified authorization system; a department administrator in the self-built authorization system and a department administrator in the unified authorization system are used for independently creating sub-accounts, the sub-accounts created by the self-built authorization system and the unified authorization system belong to the self-built authorization system, and the authorization data of the sub-accounts belong to the self-built authorization data and are stored in a self-built authorization table;
the method further comprises the following steps:
receiving identity information to be verified of a second user;
checking the identity information to be checked of the second user by using the sub-account authorization data sent by the first user;
and if the verification is passed, allowing the second user to be registered as the sub-account of the first user.
2. The login method according to claim 1, wherein the verifying the login data to be verified of the first user by using the unified authorization data or the self-established authorization data comprises:
using the unified authorization data to verify login data to be verified of the first user;
and if the verification is not passed, the login data to be verified of the first user is verified by using the self-built authorization data.
3. The login method according to claim 1, wherein the verifying the login data to be verified of the first user by using the data in the unified authorization table or the data in the self-established authorization table comprises:
obtaining the authorization type of the first user according to the login data to be verified of the first user;
if the authorization type of the first user is a uniform authorization type, verifying login data to be verified of the first user by using data in the uniform authorization table;
and if the authorization type of the first user is the self-established authorization type, verifying the login data to be verified of the first user by using the data in the self-established authorization table.
4. The login method according to claim 3, wherein the login data to be verified of the first user comprises identification information of the first user;
the method further comprises the following steps:
setting identification information corresponding to the authorization type of the user for each user;
the obtaining the authorization type of the first user according to the login data to be verified of the first user comprises:
and obtaining the authorization type of the first user according to the identification information of the first user.
5. The login method of claim 3, wherein if the authorization type of the first user is a self-established authorization type, the method further comprises:
receiving identity information to be verified of the first user;
checking the identity information to be checked of the first user by using the data in the self-established authorization table;
if the verification is passed, allowing the first user to register;
and receiving registration data input by the first user and storing the registration data in the self-built authorization table.
6. The login method according to claim 1, wherein the method further comprises:
receiving a code scanning login request sent by first equipment, wherein a first user is in a logged-in state on the first equipment;
and allowing the first user to log in response to the code scanning login request.
7. A login device is applied to the same service system, different account numbers under the same service system relate to different account authorization systems, and the device comprises:
the system comprises an acquisition module, a storage module and a processing module, wherein the acquisition module is used for acquiring uniform authorization data and self-built authorization data, the uniform authorization data is used for verifying a user with a uniform authorization type in a login process, and the self-built authorization data is used for verifying a user with a self-built authorization type in the login process;
the receiving module is used for receiving login data to be verified of a first user;
the verification module is used for verifying the login data to be verified of the first user by using the unified authorization data or the self-built authorization data;
the login module is used for allowing the first user to log in if the verification is passed;
the acquisition module is used for acquiring the unified authorization data and storing the unified authorization data into a unified authorization table, and acquiring the self-built authorization data and storing the self-built authorization data into a self-built authorization table;
the verification module is used for verifying the login data to be verified of the first user by using the data in the unified authorization table or the data in the self-built authorization table;
the device also comprises a sub-account module, wherein the sub-account module is used for: acquiring the authority type of the first user; the authority types comprise a system administrator, a department administrator and a common employee; if the authority type of the first user is the first authority type, receiving sub-account authorization data sent by the first user and storing the sub-account authorization data into the self-established authorization table; wherein the first permission type is a department administrator; the authority type of the administrator of the business department is a department administrator, and the authority type of the administrator of the network site or the branch is a department administrator; the administrator of the business department is independently established or established by a system administrator, and is independent of the department administrator in the self-established authorization system of the unified authorization system; the administrator of the network point or the branch is created by a system administrator and is affiliated to a department administrator in the unified authorization system; a department administrator in the self-built authorization system and a department administrator in the unified authorization system are used for independently creating sub-accounts, the sub-accounts created by the self-built authorization system and the unified authorization system belong to the self-built authorization system, and the authorization data of the sub-accounts belong to the self-built authorization data and are stored in a self-built authorization table;
the sub-account module is further configured to: receiving identity information to be verified of a second user; checking the identity information to be checked of the second user by using the sub-account authorization data sent by the first user; and if the verification is passed, allowing the second user to register as the sub account of the first user.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010623072.7A CN111865938B (en) | 2020-06-30 | 2020-06-30 | Login method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010623072.7A CN111865938B (en) | 2020-06-30 | 2020-06-30 | Login method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111865938A CN111865938A (en) | 2020-10-30 |
| CN111865938B true CN111865938B (en) | 2023-04-07 |
Family
ID=72989475
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010623072.7A Active CN111865938B (en) | 2020-06-30 | 2020-06-30 | Login method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111865938B (en) |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106685977A (en) * | 2017-01-03 | 2017-05-17 | 武汉虹信技术服务有限责任公司 | Account system construction method based on intelligent community cloud platform |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104348777B (en) * | 2013-07-24 | 2019-04-09 | 腾讯科技（深圳）有限公司 | The access control method and system of a kind of mobile terminal to third-party server |
| CN106487760B (en) * | 2015-08-28 | 2019-05-10 | 百度在线网络技术（北京）有限公司 | The interoperability methods and device of more system of account |
| CN107508835B (en) * | 2017-09-25 | 2020-07-10 | 咪咕文化科技有限公司 | Account verification method and device and computer readable storage medium |
| CN109274685B (en) * | 2018-11-02 | 2021-09-17 | 深圳壹账通智能科技有限公司 | Multi-system login method and device, computer equipment and storage medium |
| CN110830463B (en) * | 2019-10-30 | 2021-08-31 | 腾讯科技（深圳）有限公司 | Third party authorized login method and device |
-
2020
- 2020-06-30 CN CN202010623072.7A patent/CN111865938B/en active Active
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106685977A (en) * | 2017-01-03 | 2017-05-17 | 武汉虹信技术服务有限责任公司 | Account system construction method based on intelligent community cloud platform |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111865938A (en) | 2020-10-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8055904B1 (en) | Systems and methods for software application security management | |
| US8108907B2 (en) | Authentication of user database access | |
| CN112039826B (en) | Login method and device applied to applet end, electronic equipment and readable medium | |
| US9998439B2 (en) | Mobile device identify factor for access control policies | |
| US11082813B2 (en) | Message-based management service enrollment | |
| US7404085B2 (en) | Authentication of handheld devices for access to applications | |
| CN112528262A (en) | Application program access method, device, medium and electronic equipment based on token | |
| CN111176794A (en) | Container management method and device and readable storage medium | |
| US7748026B1 (en) | Transparent interceptors for privacy policy implementation | |
| CN106713315B (en) | Login method and device of plug-in application program | |
| US11075918B2 (en) | Cognitive user credential authorization advisor | |
| US9531725B2 (en) | Optimizing infrastructure support based on authenticated access, validation and context related information retrieval | |
| CN113572763B (en) | Data processing method and device, electronic equipment and storage medium | |
| KR102388919B1 (en) | User information processing system and method through interworking with authentication device and cloud server | |
| KR20200000578A (en) | Patent management system | |
| CN111865938B (en) | Login method and device | |
| CN117172786A (en) | Identity authentication method, device, equipment, medium and program product | |
| JP2020166601A (en) | Mediation server, program, and information processing method | |
| CN110245473A (en) | Service management system and non-transitory computer-readable medium | |
| CN114493901A (en) | Data access application processing method and device, computer equipment and storage medium | |
| CN110796021B (en) | Identity authentication method and device applied to self-service equipment | |
| CN112965821A (en) | Service request processing method and device and electronic equipment | |
| CN113111328B (en) | User identity authentication method, system, terminal and computer readable storage medium | |
| CN113641966B (en) | Application integration method, system, equipment and medium | |
| CN116702108A (en) | Authentication method, device and system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |