The name of the interpretation
The multi-account system is different from the system-level system. The multi-account system we talk about means that in our Internet applications, our applications will use multiple third-party accounts to log in, and the commonly used LOGIN methods of APP (netease Cloud Music) include netease, wechat and QQ
content
Through this article, you can learn: multi-user technical scheme details below, as well as the corresponding table design, flow design. Don’t: As in other articles, I won’t have the code implementation details here, the solution is done right, the code is not too bad. PNG
Evolution of architecture
In those early days
It comes down to the initial stage of entrepreneurship because the number of users at this time is relatively small, and there is not even access to the account system of other third parties mentioned above. The self-built system can be satisfied
User name and password for login
This way in many early site construction will be used, first register, and then log in, in the old CMS can find this shadow.
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 meets the conditions such as whether the user name is repeated. The conditions do not directly return the corresponding error code to the front end. In order to prevent interception during transmission, it is recommended that the password field be encrypted before uploading. Our transmission password will be encrypted by MD5 by default, and then recorded to the database for another layer of encryption, even if it is out of the database, it is ok, the password should not be stored in plain text.
- After passing the verification, the user name and password will be written into the database, and subsequent operations such as credit issuance will be carried out, which will not be expanded here.
- Log in now, and the front end sends the user name and password to the server. The server will verify whether the number of login times exceeds the set threshold. If so, it can only wait for the black room to be closed.
- If the login logic is not exceeded, determine whether the user name and password are correct. If the password is incorrect, determine the threshold. If the password exceeds the threshold, close the small black room.
- After successful login, all subsequent post-logic, such as add integral… Such operations.
Register with your mobile number
Flow chart:
- Enter a phone number first, and then sent to the server, the server will phone number recorded in our database, and then generate random authentication code, phone number and verification code is bound to a redis, expiration time, and then records the expiration time is 10 minutes or so commonly, this is our general mobile phone verification code will be valid.
- After receiving the SMS, the mobile phone will fill in the verification code on the interface and send to the server. After receiving the verification code, the server will query the verification code corresponding to the mobile phone number in Redis, and return the error code if it fails.
- Once successful, log in.
It seems that there is no clear registration and login operation. In fact, sending the mobile phone number can be considered as a routine registration, and then the verification code input behind is a login operation.
Q: What should I do if I need a password?
Answer: in the follow-up products to increase the function of a mobile phone number password collection, which is now very regular, but now the mobile Internet era, the big bang password already seems not so important, anyway, I could never remember password, if the phone number is able to operate the app, absolutely no password to operate.
Database design
Table structure
| On the id | The user name | password | Mobile phone no. | Wrong number |
|---|---|---|---|---|
| 1 | user1 | 7fef6171469e80d32c0559f88b377245 | 13456789012 | 0 |
| 2 | user2 | 7fef6171469e80d32c0559f88b377245 | 13456789013 | 0 |
instructions
- This table structure can satisfy the design of the above two schemes.
Introduce third-party account schemes
Here is the login logic of QQ-SDK. Let’s start with a sequence diagram
Description:
- After login, access_token openID expire_in will be returned. Oauth2.0 will be used for this process, but the built-in callback in SDK will be obtained. We’ll explain our own implementation of OAuth2.0 later
- The client gets access_token, OpenID, login_type (QQ, wechat…) Request the application server. After receiving 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 verification fails, an error code is returned
- After the verification passes, the system checks whether the login_type and openID exist locally. If they do not, the system obtains basic information such as the remote user name and profile picture as the local basic data, and returns the code value
- If it already exists, log in and return code.
- After the client gets the code value, it exchanges the token value, which is completely in accordance with the protocol of OAuth2.0. Each subsequent request must bring the token value, and the token value takes a long time on the server side, because we want to do the operation that never goes offline, so each request we will add the token expiration time.
Database design
Table structure
For comments @can not say goodbye to 1486617502000 suggestion, HERE I do database collation user base table (users)
| field | note |
|---|---|
| user_id | The user id |
| token | User login token |
| expire_in | Token Expiration Time |
| try_times | Number of login failures |
User authentication correlation table (user_auth_rel)
| field | note |
|---|---|
| id | On the id |
| user_id | The user id |
| auth_id | Verify the table id |
| auth_type | Validation type (local, third) |
Local User table (user_local_auth)
| field | note |
|---|---|
| auth_id | Authentication ID. The id is automatically added |
| user_name | Unique user identification |
| password | The user password |
| mobile | User’s phone |
Third Party User table (user_third_auth)
| field | note |
|---|---|
| auth_id | The user id |
| openid | Unique identifier of a third-party user |
| login_type | Third-party platform identification (QQ, wechat…) |
| access_token | Access_token Obtained by a third party and used for verification |
instructions
- The Users table is only for our business side login, mainly to do their own business oauth2.0 business,
- User_local_auth is used to record user name, password, 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 between self-built users and third-party storage, which makes sense in the evolution of the architecture. At first, the user system is mostly self-built, and then external access.
conclusion
- In general, third party access is technically fairly simple, and the addition of user_Thirds allows for as many third party access as possible. Of course, we usually only have two or three logins, because too many logins cost maintenance and the interface layout is not very attractive.
- I hope you can through the above learning, can have a better understanding of our multi-account login, here the design does not contain sub-table sub-library, no service, is a simple and direct design, of course, the number of users and needs are not the same, on this basis to add a lot of things, thank you for reading!! !