Interesting facts about WeChat JSSDK docking

Food Guide: If you like to get straight to the point, you can read directly from 4

1. There is no smoke without fire.

People come and go, a solid company, and smooth employees. Recently, the project team recruited a backend Java developer from a large company. Other Java colleagues said that he worked very quickly.

I am responsible for connecting with him to invoke the app’s functions from the web page embedded in the WeChat official account. When I was about to prepare for docking, I happened to be called to a meeting. Before the meeting was over, he said that he had finished the interface (returning the signed interface of WeChat jssdk). I said I would look at the documentation before joint debugging, but he said there was no need to look at it, as he had done it before. He said I would just give him the url, and he would just return me the appid, signature, timestamp and other parameters.

2. Weird bug

Later I found out that the code to generate the jssdk signature existed before, but after I logged out, he opened the comment directly. But this is all for another day. When I was debugging, I found that WeChat kept prompting invalid signature .

I tentatively asked the backend if there was a problem with the signature. After all, I just passed a url as a parameter in this interface. He said that as long as it returned 200, there would be no problem . He also kindly helped me troubleshoot the URL problem.

I said your appid seems to be different from the appid we authorized with WeChat at that time. He said the official account is different, of course the appid is different (he seemed to say something but didn’t say anything. Because I have always been responsible for this one) No public). He also seemed too lazy to argue with me about the appid issue, and would ask me from time to time how the debugging was going.

3. Many detours

Because it is normal to use a signature tool to verify the signature. So after that, I followed the direction of invalid signature to find my own problem. While checking the information, I found some interesting remarks.

Image source
Insert image description here
Image source
Insert image description here
Image source
Insert image description here
Image source
Insert image description here
Image source
Insert image description here
These interesting remarks remind me of the time when WeChat payment was made - WeChat JSAPI payment pitfall summary : read the document carefully and don’t completely believe in the background parameters.

4. Generate signatures yourself

4.1 Differences between WeChat platforms

Because the official account’s embedded webpage to evoke the app only involves 2 platforms. So I only talk about these 2 platforms:

① The public platform is used to manage public accounts (such as subscription accounts, service accounts, etc.):
On this platform, we have 1 public account and 1 service account. So there are 2 appids here , such as WeChat authorization, WeChat binding, payment, etc. We all use the appid of the service account.

② The open platform is related to app applications (it has nothing to do with subscription accounts, service accounts and other public accounts).
Insert image description here
On this platform we have 3 applications: ios, android, ipad. So here we have 3 appids again

③ That is, we have at least 5 appids in total, and unfortunately, the appid of the open platform ios is used to generate the jssdk signature in the background. From the WeChat jssdk document, we can see that the appid that generates the jssdk signature should use the appid of the public platform .
Insert image description here
I plan not to use the signature returned by the background interface, but use the WeChat interface to generate signature tests myself. Regarding the choice of service account appid and subscription account appid, I chose the appid of the service account because I have never used the appid of a subscription account for development before.

4.2 Front-end generates temporary signature

After determining the appid, I found another old Java colleague I had worked with before. Let him set me as a long-term developer of the service account. With the account, we can know the secret of the appid.

As for appid + secret + WeChat interface + postman + WeChat signature verification tool, we generate the jssdk signature ourselves for testing. (Only for testing, not for production)

The specific process is as follows:
JS-SDK uses permission signature algorithm
to obtain Access token

① Use this interface to obtain access_token

https请求方式: GET https://api.weixin.qq.com/cgi-bin/token?grant_type=client_credential&appid=APPID&secret=APPSECRET

② Take access_token to generate ticket (also called jsapi_ticket)

https://api.weixin.qq.com/cgi-bin/ticket/getticket?access_token=ACCESS_TOKEN&type=jsapi

③ Use the WeChat JS interface signature verification tool to generate a signature
Insert image description here
④ During debugging, I found that if the appid is written incorrectly, such as using the appid of the open platform, a normal signature can also be generated. But it will always prompt invalid signature . This tip is actually not correct, because the appid of the open platform cannot be used on WeChat jssdk

4.3 invalid url domain

Take the obtained parameters and wx.config again. This time I finally found another prompt: invalid url domain

Later, I found that I still didn’t read it carefully. The document was actually written very clearly: the js interface security domain name needs to be configured (note that it is not a web page authorized domain name)
Insert image description here
Insert image description here

4.4 errMsg:config:ok

Later, config:ok finally appeared, which proved that the configuration passed.
Insert image description here
I don't understand why the success information is placed in errMsg.

5. Follow-up pull

The formal process is, after all, generating signatures in the background. I found my backend colleague and explained to him the problem of different appids. He interrupted me directly and said that I could just replace it. I told him that after the replacement was completed, he could generate a set of parameters locally and send them to me to try, without going online directly.

After a while, he went directly online. Moreover, there are three load balancing machines, and only one is connected. Later, I found that the signature generated by the interface still prompted invalid signature .

Later, I used the appid + noncestr + timestamp + url parameters returned by its interface, and paired it with the jsapi_ticket I generated using 4. The signature obtained was normal, so he went back and changed it again.

Before leaving, I told him not to go online. Although the signature was passed, the first step, the subsequent use of the development tag, may cause the appid to change. Because I looked at the development tag document before and found that some things need to be configured, so I feel that there may be changes. . After a while he was online again

6. Open label configuration

① To jump to the app in the WeChat webpage, you need to go to the WeChat open platform according to the jump APP: wx-open-launch-app to configure it ② However, in the configuration document , there is one item that we do not comply with: the company has some special common Reason, so there are several company names (company entities). Therefore, the certification subjects of public account platforms and open platforms are different.
Insert image description here
Insert image description here

Insert image description here

7. End without illness

Because service accounts, subscription accounts, and open platforms involve many things. Therefore, it is inconvenient to modify the main body, and in the end it can only end in vain.

Guess you like

Origin blog.csdn.net/weixin_44050791/article/details/123771129