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
Description of the code development phase of No4 business logic
A1. Third-party platform authorization login logic (need to understand)
B1. WeChat authorization method
C3. WeChat AppID, openid, unionid (must know)
C1. Application development platform
AppID, openid, UnionID of C3.QQ (must know)
The actual logic of B4.shop platform B-side member login (need to understand)
C1. Actual third party and account login results
C2. Actual third party and account login logic
B2. WeChat applet login interface
B3. Third-party authorized joint login on the web side
Description of the code development phase of No4 business logic
The detailed design of the third part is basically almost the same (the rest is not difficult to understand, I will add it later), and now I start to develop the code according to the business logic. It is easy to write code, but the premise is to combine business logic and write beautiful code. It is necessary to consider not only the code specification, but also whether the call is appropriate, whether the dependency is strict, whether the logic is reasonable, and whether the design is environmentally friendly and concise.
So we first learn the development idea of the shop project, analyze its advantages, and ponder whether there are shortcomings. Of course, our own understanding may not be completely correct, but if we don’t think about it, we will never know the correct solution!
At the same time, it is necessary to distinguish the key points. Not everything needs to be analyzed in detail. Just like the common addition, deletion, modification and query logic, it is good to explain it clearly. If it is complicated, it needs to be carefully considered. Some logic is often needed as code development, such as Login logic, payment logic, etc.
Since it needs to be comprehensively analyzed, start from the basic and less relevant analysis, and follow the logic of the NO3-2 interface analysis for the general direction.
The general direction is as follows:
1. First solve the system settings, because the overall needs; [For example: logistics, zoning, configuration, etc., mostly on the operation side or system]
2. Then solve the basic management of members and the basic management of stores; [such as member login, registration, modification, store application, management, etc., all involve three terminals]
3. Then start to solve product management, shopping cart management, and promotion management; [These three parts are quite complicated, and they involve a lot of business, and the three parts are also related to each other, so they should be considered together]
4. Finally, solve the remaining small modules. After all, most modules are related to the first three modules [for example, member evaluation, news, delivery, etc., are also related to the three terminals]
The content of the analysis generally includes:
- Business analysis [you must first analyze the business to be solved, and then think about how to write code according to the business]
- The relationship between business classes [Analyze the relationship between the key classes involved, which is conducive to understanding the business and clearing the code design architecture ~]
- Code writing [select key descriptions of key method logic and absorb coding ideas]
- Third-party tools [Record tools used and why they are used]
The above analysis is not divided into front and back. After all, we want to analyze the shop system, which is definitely different from the normal development process. We have analyzed most of the business analysis before, so if it is not necessary, we will skip it later. The relationship between business categories must be analyzed. We have also briefly analyzed some of them before, such as promotion. Code writing is to implement the idea of the relationship between business classes into the code, and some third-party tools affect the business, and some are simple shortcut tools, such as third-party login, payment, hutool tools, and so on.
OK, all thinking is over, why don't we start with member login~~~~~~~~~~~~~~
A1. Third-party platform authorization login logic (need to understand)
Since we need to use third-party tools for authorized login, we need to understand their usage guidelines before adding them to our system.
To put it bluntly, it is to get the information of the user in the third-party platform (there must be a unique user ID), and then bind this information with the user of our shop platform, so that you can log in to the shop platform through the third party.
So the key point is to know how to obtain authorized user information from a third party.
Before understanding, let's sort out which third-party login methods are needed, and then understand the actual use according to the required login methods~
- On the PC side, user name and password login, mobile phone number login, these two are registered, so put them together
- PC terminal, mobile app/small program scan code to log in
- PC terminal, QQ authorized login
- On the PC side, WeChat scan code to authorize login
- WeChat applet terminal, WeChat authorization + mobile phone number authorization login
- WeChat browser, WeChat authorized login
- Mobile browser, username and password login, mobile phone number login
- Mobile browser, QQ authorized login
- APP terminal, username and password login, mobile phone number login
- APP side, QQ authorized login
- APP side, WeChat authorized login
The green one above is the login method that requires a third-party authorization, and the rest are the login methods of the platform.
B1. WeChat authorization method
For WeChat, it has a WeChat development platform and provides authorization guides for many products: Mini Programs, Official Accounts, Open Platforms, Mini Games, etc. We need to understand Mini Programs and Open Platforms.
The small program method is needed because we have a small program terminal, so we can directly use the API of the small program to obtain the user information or mobile phone number we want;
The need for an open platform is because we have the WeChat code scanning authorization on the PC side, and the WeChat client authorization on the APP side/WeChat browser side. We need the appid and secret authorized by the open platform to call the API interface provided by him, and finally get what we want. The required user information; and the open platform is divided into website applications, mobile applications, third-party platforms, etc. We only need to use website applications and third-party platforms.
C1. WeChat applet
The authorization logic of the WeChat applet is based on the API of the WeChat applet component, that is to say, the authorized user information is obtained at the front end of the applet, such as the mobile phone number. The authorization information obtained at this time is encrypted, and the WeChat party needs to be called. The interface gets the code value and decrypts it to get the phone number.
It is easy to understand by reading the document, BUT , it should be noted that the following method of obtaining the mobile phone number document is a new method! And the shop project is using the old version of the method! ! !
New version logic:
Obtain the dynamic token code for obtaining the mobile phone number through the component, and then call the HTTPS getPhoneNumber interface through the access_token and code, and the interface response returns the mobile phone number information. very convenient.
Old version logic:
Get the encrypted data encryptedData and the initial vector iv of the encryption algorithm, and decrypt it according to the encrypted data decryption algorithm provided by WeChat, and get the mobile phone number information. Inconvenient, decryption needs to get the user's sessionKey first, and also use the decryption algorithm provided by WeChat.
The following figure shows the new version of the document and the document address:
WeChat Mini Program Authorized Mobile Number Login: Get Mobile Number | WeChat Open Documentation
Obtain mobile phone number interface | WeChat open document
Documents and addresses of the old version: get the phone number in the old version | WeChat Open Documentation
C2. WeChat open platform
The authorization logic of the open platform only refers to website applications and third-party platforms. Their authorization logic is based on OAuth2, and both support the Authorization code authorization mode, so the steps are similar:
1. 获取code
2. 通过 code 换取 accesstoken
3. 然后根据 accesstoken 进行接口调用，获取用户基本数据资源或帮助用户实现基本操作。WeChat website application authorization login: website application website application WeChat login development guide | WeChat open document
WeChat third-party platform authorization login: a third-party application initiates web page authorization on behalf of the official account | WeChat Open Documentation
C3. WeChat AppID, openid, unionid (must know)
One of the key points for us to use WeChat authorization is that we need to obtain the authorized user information in WeChat. The user information must have a unique user identifier and cannot be changed. It must be ensured that the user information is consistent each time the user authorizes, so that Our shop platform can find the bound member information through the user ID~~~
Then openid and unionid are the unique identifiers of users, but there are differences, just look at the picture below to understand~~
Introduction to Basic Concepts of Different Types of ID | WeChat Open Documentation
Through the above figure, we can understand the difference between openid and unionid.
We can use it differently according to different businesses, for example:
Business 1: The project has multiple applications, and it is necessary to ensure that the authorized login of each terminal points to the same account on this platform.
Design 1: (1) We can use a third-party platform to associate multiple terminals, and then get the unionid authorized by WeChat users on any terminal and bind him to a user of the platform, then no matter which terminal The login will eventually find the associated account through unionid; (2) We can also use openid directly. When the user authorizes for the first time on which end, he must be bound to a user of the platform. After binding once at a certain end , the user can be located after authorization again, but it needs to be bound once when each terminal logs in for the first time.
Business 2: The project has only APP-side applications, and the platform does not need to be registered, only WeChat authorization is required to log in.
Design 2: (1) We directly use openid, the user logs in directly when the app is authorized for the first time, and then authorizes directly every time he logs in, and there is no need to bind user information at all~
B2.QQ authorization method
For QQ, it also has a Tencent open platform , and there are also a variety of service platforms, application development platform, content development platform, QQ development platform, etc. We just need to understand the application development platform.
C1. Application development platform
The access methods in the application development platform are further divided into: mobile applications, mobile games, PC applications, and website access. The focus is on website access, and QQ login is also based on OAuth2.0. QQ login OAuth2.0 supports website access and mobile application access .
These two access methods can use the SDK provided by QQ, and can also be independently developed according to the OAuth2.0 protocol. The shop platform is the second one that is independently developed according to the protocol. In other words, these two access methods are equivalent to the same one (again, it’s too convenient~~~)
QQ also supports the Authorization code authorization mode, so the steps are similar:
Step1：获取Authorization Code
Step2：通过Authorization Code获取Access Token
Step3：（可选）权限自动续期，获取Access Token
Step4：使用Access Token来获取用户的OpenIDThe following picture and document address:
QQ website, mobile application authorization login: development strategy_Server-side Tencent Open Platform
AppID, openid, UnionID of C3.QQ (must know)
Of course, the user information authorized by QQ must also have a unique user ID, which is also openid. For details, please refer to the documentation.
One thing, QQ also provides appids of different applications to obtain a unique UnionID, which needs to be applied for.
Tencent Open Platform Concepts and Terminology
QQ Interconnection UnionID Open Business Self-service Handling Guide—QQ Interconnection WIKI
B3. Thinking about logical integration of third-party platform authorized login and own platform login (can be skipped)
C1. Logical thinking
Make a note of this logical thinking and keep your mind clear.
First of all, if the platform does not need to integrate third-party login, the platform must record and save the user's account information, the most basic is the account number and password. The account number can be a user name or a mobile phone number, and must be unique. Only in this way can we ensure that the user opens the same account and the data associated with the account every time he logs in.
But if we use a third-party platform to log in and authorize, does the platform still need to record and save user account information? This is to be developed according to the specific business. There are two options at this point:
Solution 1. After the platform uses a third-party application to log in and authorize, it will save the record as account information according to the third-party user information, so that when logging in through the third-party authorization next time, it will search for the account based on the user information and then log in.
[In this solution, if the third-party user information does not contain the platform's unique account identifier (such as user name or mobile phone number), a new account will be created based on the third-party user identifier, and the user can also pass the username/mobile phone number Number to register a member account, which will generate two accounts, and eventually the same person may have multiple accounts! ! 】
Solution 2. After the platform uses a third-party application to log in and authorize, bind the third-party user ID with the existing account on the platform, then the next time the user logs in through the third-party authorization, the associated account will be searched , and log in.
[In this solution, when the third-party platform authorizes the user to log in, it must be bound to the account of the platform, so that the same user will only get one account no matter which method is used to log in. In the end, the same user will only have one account. account! ! 】
Back to our question, does the platform still need to record and save user account information? Let's look at the specific business. The above two solutions are not the most absolute. They are just the two solutions used by the public. They can be subdivided according to the business and actual development.
Generally speaking, option 2 is more reasonable, and the same user should not generate multiple accounts, so that users themselves will be confused~~~~~~~~ For example, on a certain website, you use your mobile phone number to register an account and then purchase VIP, I logged in with WeChat authorization the next day, I opened the account and found that the account is not a VIP, at this time you: emmmmmmm
C2. Examples
At present, many large websites will add third-party platforms to authorize login, such as CSDN, Code Cloud, etc., all of which use scheme 2.
Example 1, the code cloud website is using the solution 2, the code cloud can log in through multiple login methods, you must bind the code cloud's own account when authorizing the login, and then use this login authorization method later, you will get the same account information.
Example 2, the CSDN website also uses scheme 2, and you can also log in through multiple login methods, but when you log in with third-party authorization, it will determine whether the account has been bound, and if it is not bound, the login cannot be successful! You can log in to the csdn account and actively bind a third-party application, and then use this login authorization method later, you will be able to log in successfully and get the same account information.
Note: Except for WeChat third-party login , after WeChat login, you can directly locate and bind the account, or directly register and bind the account. why?
First of all, the account registration of csdn requires a mobile phone number. After the registration is successful, you can add an email address and a user name to log in.
Secondly, the third-party authorized login method of the WeChat applet can obtain the mobile phone number of the user's WeChat!
Therefore, it is obvious that this method can directly locate the account~~~~
The actual logic of B4.shop platform B-side member login (need to understand)
The development logic of the project is designed according to the business and actual situation, but we are learning the shop project after all (and the shop project does not provide specific business requirements, we have no way of knowing), so the actual development logic must be On the contrary, so we need to know the final development results of the shop project first, then analyze the actual development logic, and finally we can choose to analyze the business requirements to get the design. [The main ideas are roughly: requirements design, development design, code development]
C1. Actual third party and account login results
Just look at the results of the demo address I provided in the shop.
Yes, different authorization login methods will generate six accounts. If you don’t believe me, you can test it in the demo address yourself.
C2. Actual third party and account login logic
This is all based on the source and demo addresses of the master branch.
First, list how many authorized login methods there are:
The green shading is the authorized login method.
- On the PC side, user name and password login, mobile phone number login, these two are registered, so put them together
- PC terminal, mobile app/small program scan code to log in
- PC terminal, QQ authorized login
- On the PC side, WeChat scan code to authorize login
- WeChat applet terminal, WeChat authorization + mobile phone number authorization login
- WeChat browser, WeChat authorized login
- Mobile browser, username and password login, mobile phone number login
- Mobile browser, QQ authorized login
- APP terminal, username and password login, mobile phone number login
- APP side, QQ authorized login
- APP side, WeChat authorized login
First extract the logic of 2. scan code registration, because this logic is based on the login account, and no new account will be generated. 1.7.9. They all use the same platform account login method (because the codes all use the same one).
Among them, the QQ login of 3. and 8. generates an account (because the code uses the same one), and the login of 5. and 1. generates an account (because the logic is the same).
So for the logic of the login method (not code development!!! For code development, see c3), in the end we can only pay attention to:
- PC terminal, username and password login, mobile phone number login, WeChat applet terminal, WeChat authorization + mobile phone number authorization login
- PC terminal, mobile browser terminal, QQ authorized login
- On the PC side, WeChat scan code to authorize login
- WeChat browser, WeChat authorized login
- APP side, QQ authorized login
- APP side, WeChat authorized login
Let's analyze one by one.
For 1., the member account of the shop platform determines the user's unique identifier through the user name and mobile phone number, and the mobile phone number can be used to register directly when logging in with the mobile phone number. When the WeChat applet terminal authorizes login, the mobile phone number of the WeChat user is finally obtained, so the member information is finally obtained through the mobile phone number, so the final operation of these two methods is the same account~
For 2., the operation codes of the mobile browser and the PC are exactly the same, that is to say, the appid they operate is the same, so the openid of the user they get is also the same, so the account that is finally associated is also the same one~
So why are 5. and 2. different? Because the two login methods ultimately operate different applications, so the appid is not the same, and the openid of the user finally obtained must not be the same, so what about the unionid? We definitely don’t know whether these two applications are bound to the same development account, but the source code contains the unionid and openid binding logic, but the demonstration address shows two accounts, so unionid is not Consistent, so the final associated account is not the same~
For 3. 4. 6., let’s first explain that the three login methods ultimately operate on different applications, so the appid is not the same, and the openid of the user finally obtained must not be the same, so what about the unionid? Same as the above logic, it should not be under the same development account, so the final linked account is not the same~
The above is all logic, so what about the specific development code? Is it a login method to develop a code interface? That's definitely not the case. If there is a similar process, we will definitely develop it with the least code logic~
C3. Actual third-party and account login code development logic (mainly analyze similar development logic to reduce low-quality code)
Let's first list the development logic of the login method of the source code, and then analyze it in detail
According to the code development logic, the member side of the shop project can be divided into:
- PC side
- WeChat Mini Program
- WeChat H5 terminal
- Mobile H5 terminal
- APP side
Among them, the pc end is a front-end code, using the vue framework, and the remaining four are a front-end code, using the uni - app framework, which distinguishes different login methods for different ends in the code.
The backend is all the same set of code.
According to the code development logic, the development code of each end can be divided into several types (mainly distinguishing the back end, because the final front end calls the interface to realize the login logic, and I put the pages involved in the front end at the end):
- Login with username and password [the back-end codes of each end are the same]
- Mobile phone number login [the back-end code of each end is the same]
- PC-side mobile app/small program scan code to log in
- In the WeChat applet, WeChat authorized mobile phone number to log in
- WeChat H5 end WeChat authorized login, mobile H5 end QQ authorized login, PC end WeChat scan code login, PC end QQ scan code login
- APP-side WeChat authorized login, APP-side QQ authorized login
Therefore, the interfaces finally developed by shop are these six types:
For the application interface of 1. 2. 3. see: cn.lili.controller.passport.MemberBuyerController【Member Interface】
4. For the application interface, see: cn.lili.controller.passport.connect.MiniProgramBuyerController【Mini Program Login Interface】
5. For the application interface of 6., see: cn.lili.controller.passport.connect.ConnectBuyerWebController [Third-party authorized joint login on the web side]
The specific development details will be recorded in detail in the next article, and the application interface and logic will be recorded below~~~~~
C4. The small pit of the current shop code (to some extent it is a small pit)
In the WeChat applet, the final use is to log in with a WeChat authorized mobile phone number, that is, first get the mobile phone number to judge whether there is an account, and if not, create an account, and bind the openid and unionid to this account, pay attention to openid and unionid here Is respectively and account binding! That is, there are two associations.
However, if the user uses APP/H5/WeChat H5 to log in with WeChat authorization, the accesstoken and user information can be obtained after the WeChat callback interface, but the user association is finally judged according to the openid! ! !
I feel that this logical project will not do this. Which platform users want to use different methods to log in and have a new account? Wouldn’t the data be scattered? Who would consistently remember what data was manipulated by which account? Anyway, I don't understand. . .
So this piece cannot be used directly~~~~~ This piece of source code analysis is over, I will write the modified logic, and modify the code when I have time! ! !
A2. Member login interface
B1. Member interface
The SMS login interface needs to be combined with the SMS verification code interface. The SMS verification code interface can be found at: cn.lili.controller.common.SmsController. We will combine the detailed business introduction later~~~
- Registered user (username, mobile phone number)
- Username and password login interface
- SMS login interface (this logic needs to be combined with the SMS verification code interface)
- web-get mobile app/mini-program login QR code, web-QR code long-rotation training verification login, app/mini-program scan code, app scan code-login confirmation: agree/deny
- Account logout interface
APP, mobile H5 terminal
APP, WeChat Mini Program, scan the code in the upper right corner to log in
B2. WeChat applet login interface
The front-end code of the WeChat applet will get the mobile phone number and user information authorized by the user, and then call the back-end interface as an input parameter. If it succeeds, it will directly return the token. Since the mobile phone number of the applet needs to be decrypted, the interface is singled out.
So this one is not very complicated.
- Mini Program Login/Auto Registration
WeChat Mini Program
B3. Third-party authorized joint login
There are two types of login methods. The first is the third-party joint login method. The third-party mainly uses the Authorization code authorization mode of oauth2.0, so when integrated together, the third-party will call back the platform interface, and then re-enter the interface. Direct the front-end page of the platform, and then call the platform result interface to get the response result token. The second is to log in according to the third-party user ID, which is similar to the logic of the applet, but the development is different, so it is also a single-out interface.
Joint login with third-party authorization on the web
Most of these are OAuth2 Authorization Code modes, which are used in combination with ordinary server-side applications (commonly used authorization methods on the web side)
- WEB obtains third-party trust login authorization path, third-party trust login unified callback address, third-party trust login response result acquisition
Joint login with third-party authorization on the mobile terminal
This class is mostly used in conjunction with mobile applications or Web Apps
- Login based on third-party user ID (for example: unionID, openid)
PC side
Mobile H5 terminal, APP terminal, WeChat H5 terminal
