[Lilishop Mall] No4-4. Code development of business logic, involving: development of third-party login on member B side - development of third-party authorization joint login interface on web side

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

A1. Member joint login module

B1.Development of the third-party authorized joint login interface on the web side

Business logic:

Code logic:

        1. AuthRequest, a small module that handles third-party Auth login requests (you can first look at the relationship diagram inside)

        2. A tool class ConnectUtil that specifically handles third-party login on the web side

        3. Joint login business class ConnectService

        4. The relationship diagram from interface to business (you can see it first)

         5. Key code pictures (the source code is not included, it is too many and inconvenient)

                ConnectBuyerWebController interface: 

                ConnectUtil :

                ConnectServiceImpl :

---

A1. Member joint login module

B1.Development of the third-party authorized joint login interface on the web side

The web-side third-party authorized joint login module refers to   JustAuth, which is a third-party authorized login tool library JustAuth  . The shop project builds its own joint login tool based on this tool class library, but it does not fully refer to and build it. There is a difference , but it is enough for the current use, and it is also a kind of learning for me~~~

So after we understand the business logic clearly, we analyze the code logic~~~

Before we start, let me explain that the third-party login logic involved in web federated login is mostly consistent, and it uses the OAuth2.0 Authorization code authorization mode [this mode is mostly used in conjunction with ordinary server-side applications (commonly used on the web side) Authorization method)], so there are many businesses that can be imagined, and can be viewed in the code logic~

The federated login involves three interfaces. Let's take the WeChat code scanning authorization login on the PC as an example:

1. First, the user clicks the WeChat login button on the front end of the PC. At this time, the platform's interface for obtaining third-party trusted login authorization path will be called, and the input parameter login method (WeChat PC, WeChat applet, QQ, etc.) will be passed. This interface will obtain the corresponding third-party authorization api according to the third-party login method, as well as the input parameters (such as: appid, scope, etc.) required by the authorization api. Among them, there must be redirect_uri and state input parameters, and redirect_uri is the callback address of the platform. api (that is, the interface in 2.), the state is carried when the third-party calls back, and is used for effective verification by both parties, so it needs to be unique and stored in the cache. Then splice it into an authorized url based on the above information, and return it to the front end for redirection.
2. After the PC front end receives it, it will be redirected to the authorization url page. This page is provided by the third party. At this time, the user scans the code/login account. After the third party is successfully authorized, the third party will call the callback interface of the platform, which is 1 The redirect_uri api address in ., and there will be input parameters code and state, the code is defined by the third party, and the state is defined by the platform. In this interface, accessToken is obtained through code, and then user information (openid, etc.) is obtained through accessToken. Then obtain the bound account according to the openid, and if the account can be obtained, create a login token based on the account. If no account is associated, create a new account based on openid and associate the third party, and then create a login token based on the account. Then use the state as the key to cache the Token for 3.. Finally, return to the login page of the platform PC to redirect to the front end, and pass the parameter state. [At this time, the front end is a third party, and the third party will call back the platform page] 
3. The third party calls back the login page on the PC side of the platform, judges whether there is a state parameter in the page, and calls the third-party trusted login response result acquisition interface, and obtains the Token information cached in 2. according to the state, and returns it to the front end. 

The above process is also completed by means of redirection.

In a word:

Get the third-party user information (that is, the unique identifier), and then judge whether there is an account bound according to the user information. If not, register and then cache the login token of this account. To get the cached login token, and then the login is successful!

Business logic:

The business logic can be seen above, which is very clearly described~

In fact, there is no particularly complicated logic, but it is a bit convoluted.

So here comes the question, the QQ authorization on the PC side, Alipay authorization, Weibo authorization, etc. are all such logic, so do we need to correspond to each re-development interface? Of course not, only one set of similar code is needed, we should not write the code to death, but improve the maintainability of the code by improving the reusability of the code.

Then you need to design the code well, see the code logic~~~

Code logic:

1. AuthRequest, a small module that handles third-party Auth login requests (you can first look at the relationship diagram inside)

We know that the processes of various third parties are similar, so the special thing is that the configuration information of the third parties is different, such as appid, appSecret, authorization url, etc. Some of them have different contents, and some even have different fields. Then we need to store different third-party information and use it according to different third parties.

From the above aspects, we can abstract a small module that specifically handles third-party Auth login requests. In order to meet the business. This module needs to contain the storage and transmission of the following information:

1. Third-party authorization configuration, such as appKey, appSecret, redirectUri, etc., is for all third parties , some are shared, and some are used by a third party. The configuration here is stored in the setting.
2. Third-party authorization APIs, authorized APIs, APIs for obtaining accessToken, APIs for obtaining user information, etc., are for all third parties , some are shared, and some are used by a third party.

and the processing of the following businesses:

1. According to the information in 1. 2. above, splice the required request url, that is, add parameters to the api, such as authorization url, user information url
2. Set a unified login logic, first get the accesstoken through the code, and then get the user information according to the accesstoken;

 Therefore, based on the above conclusions, combined with business logic, we can get the relationship diagram of the classes in the following modules, and the thinking instructions are all in the diagram~~~

2. A tool class ConnectUtil that specifically handles third-party login on the web side

What is the difference between it and the above small module that specifically handles third-party Auth login requests?

The ConnectUtil tool class is a tool class that undertakes the joint login request interface and the joint login business class. It mainly obtains configuration information through the Auth login request module, and then calls the joint login business class ConnectService to process specific platform services according to the business.

I understand, it is an intermediate tool~~~

The main methods are:

1. AuthRequest getAuthRequest(String type) Returns the corresponding third-party authorization request object through login
2. void callback(String type, AuthCallback callback, ...) login callback method
3. ResultMessage<Object> getResult(String state) Get federated login response result

1 only needs the cooperation of AuthRequest, 3 only needs the cooperation of Cache, then 2 will involve the following joint login business class ConnectService.

3. Joint login business class ConnectService

This class appeared in the last article when it dealt with the authorized login of the WeChat applet, so the logic here is very simple, it is the final business class that specializes in joint login! ! !

Since it involves member operations, this class needs to be injected into the member business class MemberService

It can be seen that the main idea of ​​this class is to operate the joint login service according to the user information of the third party.

4. The relationship diagram from interface to business (you can see it first)

 5. Key code pictures (the source code is not included, it is too many and inconvenient)

ConnectBuyerWebController interface: 

ConnectUtil :

 

Note here above that the redirection is to redirect to a certain page of the platform, preferably the login page, and pass the state parameter, which corresponds to the key of the saved token~~~ Just use a unique value, and take it directly here The third-party temporary login authorization code, but the name is the state that calls the authorization url, so pay attention anyway~~~

ConnectServiceImpl :