Only the backend is involved, see the top column for all directories, codes, documents, and interface paths are:
[Lilishop Mall] Record the study notes of the B2B2C mall system~
The whole article will combine the business introduction to focus on the design logic, which includes the interface class and business class, and the specific source code analysis, the source code is not complicated to read~
Caution: Some comments in the source code are wrong, some comments have completely opposite meanings, and some comments are not correct. I updated them during the reading process and added new comments where I did not know. So be careful when reading the source code!
Table of contents
B1. Log in according to the third-party user ID (for example: unionID, openid)
According to the title, you can know that the third method is relatively simple for the backend, and it is very similar to the first method: the development of the WeChat applet login interface. The information for obtaining user authorization is handed over to the frontend, and the backend only The user is responsible for obtaining the unique ID of the user, and then performs subsequent business operations~
The front-end of the shop corresponding to this method is developed with uniapp, so the uni.login method used on the front-end invokes the third-party client, and the user will get the user's unique ID after authorization, and then the front-end calls the platform back-end request interface To realize the follow-up business~~
Front-end main implementation page: /lilishop-uniapp-master/pages/passport/login.vue
Of course, there is more than one way of third-party login on the APP side.
A1. Member joint login module
B1. Log in according to the third-party user ID (for example: unionID, openid)
Business logic:
- The front end performs the authorization operation, and the interface is called after the user authorization is successful, and carries the parameter user information (openid, type third-party type QQ/WECHAT, etc., nickname, etc.);
- The backend receives the parameters, and checks whether there is an account corresponding to type and openid in the joint login association table information li_connect. If it is found, it indicates that it has been bound, and directly creates a Token based on the account and returns it; if it does not find this, it means that it has not been bound, so first Create an account based on the user information, and then return the login token of the account;
very simple~
Off topic note:
Seeing this makes it clearer that the shop project I mentioned earlier will generate multiple accounts for the same user logging in in different ways! Because the user does not carry the user's unique ID when logging in with a third-party authorization, this does not refer to the openid unionid, but the unique identifier that the platform can determine!
The user name and mobile phone number specified by the platform, but when the user logs in with a third party, he does not enter the user name or mobile phone number for binding detection! ! ! That's the only difference! ! ! Even if the unionid of various WeChat products is unique, can you guarantee that the unionid of QQ is the same as that of WeChat? No, so the essence is that there is no binding with the unique identifier of the platform! ! !
Like CSDN and Code Cloud, you can specify account binding! ! !
Code logic:
We have said that the business logic of this login method 2. It is very similar to the business in the callback in the previous article, especially the logic after getting the user information through ConnectUtil is the same~ So, we can completely put the latter logic in Together, the code is to abstract the common code~~~
This article ended very quickly, hahahahaha~~~~~~~~
Let's enter the analysis of the commodity module later, there are so many things to record, let's make the storm more violent! ! ! ! !