Shulou(Shulou.com)06/02 Report--

This article mainly introduces "how to design a third-party account login". In the daily operation, I believe many people have doubts about how to design a third-party account login. The editor consulted all kinds of materials and sorted out simple and useful operation methods. I hope it will be helpful for you to answer the doubts about "how to design a third-party account login". Next, please follow the editor to study!

Name interpretation

The multi-account here is different from the system level. By multi-account system, we mean that in our Internet applications, our applications will log in using multiple third-party accounts. The APP login methods commonly used now include: NetEase, Wechat and QQ.

Content

Through this article, you can learn: multi-user technical solution details, as well as the corresponding table design, process design. No: as with other articles, I will not have specific code implementation details here, the plan is right, the code will not be too bad.

The initial stage of the evolution of architecture

It boils down to the initial stage of starting a business because the number of users is relatively small at this time, and it is not even connected to the other third-party account systems mentioned above, but the self-built system can be satisfied. if the self-built system, the commonly used ones are

User name and password registration and login

This method will be used in many early website construction, sign up first, and then log in, which can be found in the older cms.

Flow chart:

Process description:

The front end sends the user name and password to the server, and the server makes a routine judgment to determine whether the length of the user name and password is satisfied and whether the user name is repeated. The condition does not directly return the corresponding error code to the front end. Here, the password field is recommended to encrypt and upload again in order to prevent the user name and password from being truncated during transmission. Our transmission password will be encrypted by default. Then record to the database for another layer of encryption, even if it is out of the library, the password should not be stored in clear text.

After the verification is passed, the user name and password will be written to the database, and the points will be issued later, which will not be expanded here.

Now log in, and the front end sends the user name and password to the server, and the server will first check whether the number of logins exceeds the set threshold, and if so, you can only continue to wait for the dark room.

If the login logic is not exceeded, determine whether the user name and password are correct, and if the password is incorrect, then the threshold is determined. If the value is exceeded, the dark room is closed. Remember that the dark room must be set to expire, otherwise it will be closed permanently. This can be done with the expiration of redis.

After the login is successful, carry on all the subsequent post-logic, such as adding points. Wait for the operation.

Registration and login of mobile phone number

Flow chart:

Process description:

First, enter the mobile phone number, and then send it to the server. The server records the mobile phone number in our database, then generates a random verification code, binds the mobile phone number and verification code to a redis, and then records the expiration time. This expiration time is usually about 10 minutes, which is the validity period of our mobile verification code.

After the mobile phone receives the SMS message, fill in the verification code in the interface and send it to the server. After receiving the verification code, the server will query the verification code corresponding to the mobile phone number in redis. If it fails, an error code will be returned.

Log in after success.

There seems to be no clear registration and login operation here, but in fact, sending a mobile phone number can be regarded as a regular registration, and then the following CAPTCHA input is a login operation.

Q: what if I need the password?

A: it is also a common practice to add a password recording function to the follow-up product, but now in the era of the Mobile Internet Big Bang, passwords are no longer so important. Anyway, I can never remember the password. If the mobile phone number can operate app, there is absolutely no need for a password to operate.

Database design table structure self-increment id user name password mobile phone number error number 1user17fef6171469e80d32c0559f88b3772451345678901202user27fef6171469e80d32c0559f88b377245134567890130 description

Here is only a simple description of the data to be used, without extending the specific scenario, this table structure can meet the design of the above two scenarios.

Introduce a third-party account scheme

Here is the login logic of QQ-SDK, let's start with a wave of sequence diagrams.

Description:

The client itself adjusts the login interface to enter the user name and password. Here is the user name and password of the third party. If the login is successful, the user name and password will be returned to access_token openid expire_in. Oauth3.0 will be used in this process, but the built-in callback in sdk will be used to obtain it. We will explain the oauth3.0 implemented by ourselves later.

The client gets access_token, openid, login_type (qq, wechat...) to request the application server. After getting the data, the application server will go to the corresponding user center for access_token and openid verification according to the corresponding login_type. If the check fails, the corresponding error code is returned.

After the verification is passed, it will determine whether the local login_type and openid exist. If it does not exist, it will obtain the remote user name, avatar and other basic information as the local basic data, and return the code value.

If it already exists, it is a login operation that returns a code value.

After the client gets the code value, the token value is exchanged, which is in full compliance with the oauth3.0 protocol. Each subsequent request must be accompanied by a token value. The token value stays on the server for a long time, because we want to do the kind of operation that never goes offline, so we accumulate the token expiration time for each request.

Database design table structure

For the suggestion that the comment office @ can't say goodbye to 1486617502000, I would like to do some sorting out the user basic table (users) of the database.

Field remarks user_id user idtoken login tokenexpire_intoken expiration time try_times login failed

User Authentication Association Table (user_auth_rel)

Field remarks id self-increment iduser _ id user idauth_id verification table idauth_type authentication type (local, third)

Local user Table (user_local_auth)

Field remarks auth_id authentication id, add iduser _ name user unique ID password user password mobile user mobile phone

Third-party user table (user_third_auth)

Field remarks auth_id users idopenid third-party users uniquely identify login_type third-party platform identities (qq, wechat...) access_token third-party acquired access_token, verify the use of

Description

The users table is only for login on our business side, mainly for oauth3.0 business of our own business.

User_local_auth is to log in your user name and password, and log in your mobile phone number.

User_third_auth is the data record of our third-party user system

User_auth_rel is used to associate our users table with user_local_auth and user_third_auth.

The whole design concept is to distinguish self-built users from third parties in storage, which is also reasonable in the evolution of the architecture. at first, most of the user systems are self-built, and then external access.

At this point, the study on "how to design a third-party account login" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.