On 
 
Source: https://juejin.im/post/5d0a298bf265da1b827aa06f
  • Preface: Multi-account login
  • 1. Initial stage of entrepreneurship
  • 2. Database design
  • 3. Introduction of third-party account solutions
  • 4. Database design
  • 5. Summary

Introduction: Multi-account login

Internet application, Our application will use multiple third-party accounts to log in, such as: NetEase, WeChat, QQ, etc., we call this multi-account unified login.
Through this article, I would like to explain the details of the technical solution of multi-account login, as well as the corresponding table design and process design. I will not have specific code implementation details here, as long as the scheme is done correctly and has ideas, the code will not be too badly written.
It comes down to the early stage of entrepreneurship because the number of users is relatively small at this time, and even has not yet accessed the account system of other third-party mentioned above, just the self-built system can be satisfied, self-built system, the current commonly used solutions are the following:
this way will be used in many early website construction, register first, Log in again, and you can find this shadow in the older CMS. The flowchart is as follows:

Process description:
    the front end sends the user name and password to the server, and the

  1. server makes a regular judgment to determine whether the user name and password length are met, whether the user name is repeated, etc., and the conditions are not directly returned to the front end by directly returning the corresponding error code. Here the password field, in order to prevent the transmission process from being truncated, it is recommended to encrypt and then upload, our transmission password will be encrypted by default MD5, and then recorded to the database for another layer of encryption, even if it is out of storage, the password should not be stored in plaintext.
  2. After the verification is passed, the user name and password are written to the database, and subsequent operations such as point issuance are carried out, which is not expanded here.
  3. Now log in, the front end will send the user name and password to the server, the server will first check whether the number of logins exceeds the set threshold, if it exceeds it, you can only continue to wait for the small black room to be closed.
  4. If it does not exceed the logic of continuing login, judge whether the user name and password are correct, and the incorrect password will be judged by the threshold, if it exceeds the small black room, remember that the small black room must set an expiration time, otherwise it will be permanently closed, which can be done with the expiration of Redis.
  5. After successful login, perform all subsequent post-logic, such as adding points.

Mobile phone number registration and login

SMS business is very mature, and it is convenient and fast to register with mobile phone number. The flow is as follows:

Process description:
    first enter the mobile phone number, and then

  1. send it to the server, the server will record the mobile phone number in our database, and then generate a random verification code, and bind the mobile phone number and verification code to a redis. Then record the expiration time, this expiration time is generally about 10 minutes, which is the validity period of our general mobile phone verification code.

    2. After the mobile phone

  2. receives the mobile phone SMS, then fill in the verification code in the interface to send to the server, and the server will query the verification code corresponding to this mobile phone number in Redis after receiving the verification code, and the error code will be returned if it fails.
  3. After success, the login operation is performed.
There seems to be no clear registration and login operation here, in fact, sending a mobile phone number can be considered a regular registration, and then the subsequent verification code input is a login operation
asks: So what do I want to do with a password?
Answer: Add a mobile phone number password supplement function in the follow-up product, which is also a very conventional method now, but now in the era of mobile Internet explosion, the password is not so important, anyway, I can never remember the password, if the mobile phone number can operate the app, absolutely do not use the password to operate.

2. Database design

table structure

description : This is just a simple description of the data that needs to be used, without expanding the specific scenario, this table structure can meet the design of the above two schemes.

3. Introducing a third-party account solution

Here is the login logic of QQ-SDK, let’s start with a wave of timing diagram:

implementation ideas:
    the

  1. client calls up the login interface by itself, enters the user name and password, here is the third party’s user name, password, after successful login, it will return access_token openid expire_in, This process will use OAuth2.0, but the built-in callback in the SDK is obtained, and later we will explain that our own implementation of OAuth2.0
  2. client gets access_token, OpenID, login_type (QQ, WeChat…) Request the application server, and after the application server gets these data, it will go to the corresponding user center for access_token and openID verification according to the corresponding login_type.

If the verification fails, the

corresponding error code
  1. after the verification is passed, it will determine whether the local login_type and openid exist, and if it does not exist, obtain the remote user name, Basic information such as avatars are used as local basic data

    2. , and if the code value

  2. already exists, it is a login operation and returns the code value.

    3. After the client gets the code value, the token value is

  3. exchanged, which is completely in accordance with the OAuth2.0 protocol, and each subsequent request must bring the token, and the token value is on the server side for a long time, because what we want to do is the kind of operation that never goes offline, so each request we will add up the token expiration time.

4. Database

designTable structureDatabase
organization User base table (users):

user

authentication association table (user _auth_rel）

local user table (user _local_auth）

third-party user table (user _third_auth）

description
    users

  1. table is only for our business side login, mainly to do their own business OAuth2.0 business

    2. ,

  2. user_local_auth do their own user name, password login, The mobile phone number login information

    3. record

  3. user_third_auth the data record of our third-party user system,
  4. user_auth_rel is used to associate our users table with user_local_auth and user_third_auth.
  5. The whole design concept is to distinguish self-built users from third parties in storage, which is also reasonable in terms of architecture evolution, at first most of the user system is self-built, and then external access.

5. To sum up

, the access technology of third-party

users is relatively simple, here is designed to have one more user_thirds is to support enough third-party access, of course, generally we just have two or three logins, too many logins not only their own maintenance costs, interface presentation is not good-looking is not.
I hope that through the above learning, you can have a better understanding of our multi-account login, the design scheme here does not include table and database, no service, is a simple and direct design, of course, the number of users and needs are different, on this basis to add a lot of things

end


 
 

 
 public number (zhisheng)  reply to  Face, ClickHouse, ES, Flink, Spring, Java, Kafka, Monitoring < keywords such as span class="js_darkmode__148"> to view more articles corresponding to keywords. 
 
 
like + Looking, less bugs 👇