This paper deals with the separation of front and back ends and how to develop and debug the front end of wechat web project in the local environment.

The main problem

1. How to configure the development environment of wechat public platform

2. How to configure the development environment of wechat web page project

3. How to solve the cross-domain problem when the front and back end separate development interface is called

4. How to solve the problem that the wechat server cannot access the local test environment

The first introduction about how to configure the development environment of wechat public account platform was mentioned in shuai Huajun’s previous articles. You can jump to read it after reading this article:

  • Get the basic configuration of wechat public platform developers done
  • Wechat public platform development dynamic access and update access_token
  • Wechat public platform development to obtain wechat server IP address
  • Wechat public platform development to receive messages and events and reply messages

Therefore, this article mainly introduces Shuai Huajun’s thoughts on the second, third and fourth questions above.

Wechat web page project

WeChat web development on WeChat built-in browser provides developers with rich call WeChat client interface or visit mobile system information capacity (JS – SDK), certification of subscription and services can get the user information, premise is that developers need to tell the WeChat server, the user access to current page is secure, So how does wechat determine that the page a user is currently visiting is secure? This requires the front and back end to do some simple verification, in order to get the authorization of the wechat server.

If a user accesses a third-party web page in the wechat client, the public account can obtain the user’s basic information through the wechat web page authorization mechanism, so as to realize the business logic.

For the authorization to obtain user information, you can read wechat web page authorization. Because only the wechat authentication subscription number and the wechat authentication service number have the permission to obtain user information, you can apply for a test account in the wechat background to experiment the process of obtaining user information through wechat web page authorization.

Shuai Huajun’s experiment on the webpage authorization mechanism went smoothly. He only encountered a small problem, which was immediately solved by reading the document carefully. That is, the configuration item about setting or modifying the secure domain name mentioned in the wechat authorization document.

Modify the domain name in the pop-up dialog box:

According to the usage instruction document of JS-SDK of wechat web project, if the rich API interface of wechat built-in browser needs to be used, the permission verification configuration needs to be injected through the Config interface to ensure that the page currently accessed by users is secure.

Wx. config({debug: true, // Enable debug mode, the return value of all API calls will be alert in the client, if you want to view the passed parameters, you can open it in the PC, parameter information will be printed in the log, only on the PC. Timestamp:,// Required, generate signature's timestamp nonceStr: ",// Required, generate signature's random string signature: ",// Required, signature jsApiList:" [] // Required, list of JS interfaces to use});Copy the code

After Shuai Huajun’s experiment, configuration information can be obtained dynamically by sending a request to the back end, similar to the following:

getwechatjsconfig(client => {
  wx.config({
    debug: false,
    appId: 'wxa0bb1e90533c6981',
    timestamp: client.response.timestamp,
    nonceStr: client.response.noncestr,
    signature: client.response.signature,
    jsApiList: ['chooseImage','previewImage','uploadImage','downloadImage']
  })
})
Copy the code

Shuaihuajun encapsulates a function named GetwechatjsConfig, which will send an asynchronous request to the server to obtain configuration information. After the server successfully responds to the Ajax request, the front end will execute a callback function, in which the XHR instance object is passed in. The response property of the object contains the configuration information returned by the back end. Assign these information to the corresponding attributes required by wechat respectively, and finally complete the permission verification of JS-SDK. At this time, users can use the rich and practical interface provided by wechat JS-SDK on this page.

The front and back ends were developed separately

In order to make the front-end master more initiative, it is more important to optimize the whole front-end workflow, improve the efficiency of front-end write layout style, write interaction logic, write interface specification, reduce the coupling degree of front-end and back-end work content, so that the division of responsibilities is more clear, so the development mode of front-end and back-end separation is imperative.

One advantage of the separation of the front and back ends is that the front and back ends do not need to care for the back end. The front and back ends are written separately, and the data flows like a continuous stream between the user’s visible page and the server side through a transport protocol-like API specification document.

First, HTML documents stored in the server and js, CSS, image and other resources in them flow from the back end to the front end. The user agent (browser) renders these data into the user’s pleasing interface. Then every operation of the user on the page becomes data like water flowing to the back end through Ajax. The back end processes the incoming data and pushes the new data to the front end… … This is repeated until the user jumps to a new page to start a new flow of data or until the user closes the browser.

Therefore, the primary problem to be solved in the development of the front and back end separation is how to ensure the smooth transmission of data in the process of the front and back end! This brings up the issue of cross-domain barriers.

The front end builds a local test server (such as http://localhost:8080/) on its own computer to complete a series of complicated work such as writing layout style, writing interactive logic and writing test interface. Only the last write interface (i.e., to get the data from the server http://www.example.com:80/) is the only obstacle, met problems of cross-domain, in front and back side don’t do any configuration, Ajax is unable to send the request to the remote server, the browser will warn the front-end developer!

The browser seems to have found a way for the server to add an access-Control-allow-Origin configuration to the resource requested by the front end:

Access-control-allow-origin = access-Control-allow-Origin = access-Control-allow-Origin = access-Control-allow-Origin = access-Control-allow-Origin This is used by the server to tell the browser that I allow other servers to access this address across domains.

In order to obtain the list of all articles, you must log in first. However, I found that even if the login was successful, when I sent the request to the server to obtain the list of all articles, I was told to log in first! Huh??????? Didn’t you login successfully just now? Why?? Also log in??

This is because, according to common sense, when I log in successfully, the server will save the session information of the current user in the cookie. The unique performance of the cookie ensures that the user does not need to log in again. The cookie will be carried in the request header every time the user sends a request to the server. The server authenticates whether the user logs in through cookies. Obviously, the problem is that every time the user sends a request to the server, the cookie carried by the user is a new cookie. So even if the user successfully logs in this time, the server remembers that as long as the user carrying this cookie is successfully logged in next time, The problem is that the cookie sent to the server for the next user request is not the cookie that is recorded as a successful login, so the interface that requires login will always prompt the user to log in.

So now to solve the problem is, how to keep the same user each time to send a request to the server, to ensure that the cookie carried by the request header is unique, rather than always changing!

In fact, the front end simply sets the following properties when making an Ajax request to use the same cookie information in subsequent requests:

xhr.withCredentials = true
Copy the code

The back-end code also needs to be adjusted by adding a request header that allows the front end to carry credentials in the server header. For example, Express:

res.set('Access-Control-Allow-Credentials', true)
Copy the code

The access-Control-allow-Origin header cannot be a wildcard * if it contains credential information.

Let’s change the wildcard to Express:

res.set('Access-Control-Allow-Origin', 'http://localhost:8080')
Copy the code

After the test, when the login is successful and the request is sent to the server again, the cookie value carried is exactly the same as the successful login. As long as the user does not manually clear the cookie or the server does not clear the cookie, then all subsequent requests carry the same cookie value.

However, Shuai huajun thinks that setting access-Control-allow-Origin to a local test server address like http://localhost:8080 is a dangerous operation for online servers. Because if a malicious programmer can just set up a local server and send a request to a remote server online with credentials, that would be very dangerous for the remote server online.

Therefore, it is suggested that there should be a test server that can only be accessed by the trusted IP address in the LAN during the development of the front and back ends. This test server first ensures that all Ajax requests are sent by our own front end without fear of being disturbed by outsiders. In this way, The test server for the mock online server can set the corresponding header to allow the local test server to send Ajax requests with credentials.

Wechat verification front-end local services

All those who have the development experience of wechat public platform know that wechat requires developers to configure a secure domain name, and the URL address under the secure domain name must be accessible to the wechat server, so as to pass the verification of wechat, and to use the wechat public platform or wechat web page authorization and JS-SDK verification.

Shuai huajun’s solution is to apply for a domain name address that supports Intranet penetration. Its magic lies in that the code in the local test does not need to be repeatedly deployed to the online server for debugging, and the wechat server can access the local server indirectly.

Nothing too sophisticated, you can go to natapp.cn to register and buy a domain name.

After the experiment of Intranet penetration, the verification of wechat public platform, the verification of wechat webpage authorization and the verification of URL address in jS-SDK configuration items are completely no problem.

Of course, this is only one of the solutions that need to be verified for wechat development. Shuai Huajun also hopes to know other authorization solutions for wechat public platform and wechat webpage projects under the development mode of front and back end separation.

In this paper, to the end.