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

What this article shares with you is about the design and implementation of Wechat authorization interface. The editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article. Let's take a look at it with the editor.

Today to show you the implementation of Wechat authorized interface, first of all, there are many ways to implement this interface, so it is necessary for us to design according to the requirements, the interface design will be universal and flexible.

Wechat authorization and authentication is based on Auth3.0.

Wechat license is based on Auth3.0, but it is simpler than Auth3.0. Some PC sites are based on QQ or Weibo and require users to log in when implementing authentication, that is, entering an account and password, but not in Wechat, because Wechat APP has already logged in.

I don't know if you have such an experience. When you visit a web page in Wechat, clicking a button or clicking a link in moments will pop up a web page where there is a button that you need to click to confirm authorization, as shown below:

This shows that this web page uses an interface authorized by Wechat users.

Next, let's take a look at the document:

Learned from the document, in the use of Wechat authorization, you should first set up Wechat authorized domain name, how to set it? The document reads as follows:

Before the official Wechat account requests a user's web page authorization, the developer needs to go to the configuration option of "Development-Interface permission-Web Service-Web account-Web license to obtain basic user information" on the official website of the public platform. Modify the authorization callback domain name. Please note that the domain name (a string) is entered here, not URL, so do not add protocol headers such as http://. As shown in the figure:

Because my official account here is not certified, so there is no corresponding interface permission, so it can not be set, but we can use the test number to set up, take the test number to do development. As shown in the figure:

Click modify and a window will pop up:

Note: the authorized callback domain name can only be entered in the domain name, not url. The domain name is only a string, and the url is with protocol. You should distinguish it here.

Next, let's look at the document and see a paragraph like this:

1. Guide the user to the authorization page to agree to the authorization and obtain the code

2. Exchange for web page authorization access_token through code (different from access_token in basic support)

3. If necessary, developers can refresh the web license access_token to avoid expiration.

4. Get the basic information of users through web authorization access_token and openid (support UnionID mechanism

The first step is to guide the user to the authorization page to agree to the authorization and obtain the code. There are two problems:

1. Guide the user to the authorization page. What is the authorization page and what is the address of the authorization page?

2. What is code?

Reading the document with questions, according to the content of the document, is actually asking the user to click on a spliced url. This url is called authorization url. The authorization url contains the following five parameters:

Appid 、 redirect_uri 、 response_type 、 scope 、 state .

The first parameter appid needless to say

The second parameter, redirect_uri, is the callback address (remember this name). The domain name in this redirect_uri must be the same as the authorized callback domain name entered above, as long as the domain name is the same, and you can set other parts except the domain name at will.

The third parameter is the fixed value response_type=code

The fourth parameter is divided into two cases: snsapi_base and snsapi_userinfo. Here we only consider the second case.

The fifth parameter state is an identification bit that can be omitted with some custom parameters, such as where the user entered your page: state= "Wechat scan code".

The stitched url is as follows:

Put this url in the a tag of the page:

Guide the user to click on this link (change the name of the button to start the game and click to start the lottery). After the user clicks, a page will pop up as follows:

Simplify the flowchart:

When the user clicks the confirm login (whether authorized or not) page, it will jump to redirect_url (callback address), which is the redirect_url parameter passed when concatenating url above, and the code parameter and state parameter will be taken with the jump back.

Some students will ask, why jump to redirect_url (callback address) and have parameters on url? Because this is the OAuth3.0 authentication mechanism, everyone follows this authentication mechanism. The returned url is as follows:

Redirect_url?code= "skhdsaddkasj" & state= "Custom parameters"

Because the interface we designed is separated from the front and rear ends, we need the front-end staff to get the code and state (state can be omitted), and then send them to the back-end interface in exchange for user information.

At this point, we define the data exchange of an interface, the front-end engineer sends code, and the back-end interface returns user information.

Now the question arises, what do the back-end engineers do after they get the code? Continue to read the documentation:

It can be seen from the document that after getting the code, the backend personnel need to request an interface of Wechat to obtain the access_token and OpenID values. Caching is not considered for the time being (it doesn't make much sense for each person to get a different access_token).

The third step is to refresh the token, which can also be omitted because the above access_token does not use caching. Go straight to the next step.

Step 4: pull the user information and look at the document:

As you can see, you have to request the interface of Wechat again. This request needs to use the access_token and openid obtained last time, as well as another lang parameter, which is set to zh_CN (Chinese). This parameter is set to the language of the returned information.

The implementation code is as follows:

Here we use a npm package called superagent. The backend service of this package sends requests, which is easier to use than the native http module of nodejs. If you are interested, you can go to the npm official website to have a look at the official documentation. It is relatively simple, and I will not repeat it here.

You can clearly see from the above code that we use callback nesting because the second request relies on the return value of the first request and first receives the code put from the front end to the back end at the beginning of this route.

The first request is to get the access_token, and the second request is to get the user information and return it to the front-end staff. At this point, we have completed the interface of exchanging the user information with code.

The advantage of this development is that the front-end developer splices the authorization address and specifies the callback address during the stitching process. The callback address displays the final activity page, which does two things:

1. Intercept code from url.

2. Send code to the backend interface in exchange for user information.

The code is as follows:

The flow chart of the program is as follows:

The above is the design and implementation of Wechat authorization interface. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

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.