The following section will describe the corresponding debugging strategy under different conditions, of course, may not be the optimal solution
preface
What are “Secure Domain name Restrictions”?
Take the use of wechat JS-SDK as an example, each public account is limited to three secure domain names, which must be verified by Tencent server (this means that the domain name must be bound to a server that can be accessed by external networks). Then you can only use jS-SDK under these domain names, which is the secure domain name restriction.
This policy is relatively widely used, and is probably equivalent to the APIS provided by three parties that require you to configure IP whitelists.
The following figure roughly describes the process of JS-SDK domain name verification, where
- WeixinWebview is the browser in wechat client;
- BuServer is our own business server;
- WeixinClient is the wechat App;
Ensure that BuServer has access_Token and JSAPi_ticket information required for signature.
On this basis, we want to bypass this security policy, there are roughly two solutions:
- Regular operation, a fixed domain name as a test dedicated, fill in the security domain name list, occupy a hole “here of course can apply for a test account”, and then solve the internal network penetration of “ngrok, peanut shell flow” can be achieved;
- Unconventional operations, implemented by modifying DNS resolution to override requests for specific resources “or all resources” to local development services;
Normal operation
- Through the Ngrok/peanut shell network penetration, the general tool will give you a temporary domain name, fixed domain name need to pay;
- Fill the domain name into the wechat secure domain name list, and put the verification file into the Web container for verification;
- Once you’ve done the above two steps, you’re ready to debug happily.
Unconventional operation
It can be seen from the above flow chart that the JS-SDK config information is obtained by the CURRENT request page URL + jsapi_ticket + appID +…… The config is obtained by signing according to certain rules, and then passed into wechat client for verification.
Throughout the validation process, what we can hack is to forward the requested resource to the development server so that we can debug the local code.
Around “forwarding the requested resource to the development server”, the following two scenarios can be thought of:
- Intercepting the request and forwarding it to the development server;
- Using DNS resolution, secure domain name resolution to the development server “commonly known as DNS hijacking”;
Scheme 1 Packet capture tool forwarding
In this article, you can use Charles, Fiddler and other packet capture tools to forward the specified request.
Scheme 2 DNS hijacking
DNS resolution process:
To implement DNS hijacking, the most realistic solution is to modify the hosts file of the development machine to resolve the secure domain name to the IP address of the local development environment.
Hijacking of HTTP requests
If your site provides HTTP services, just modify the hosts file on your development machine and point the secure domain name to the development service. See here is almost enough, you can go to practice.
HTTPs request hijacking
However, most commercial web sites are HYPERtext transfer protocol Secure (HTTPs), so it is not possible to simply use DNS hijacking to forward requests to local HTTP services.
If your secure domain name is an HTTPs service, that might be a bit of a hassle. First let’s take a look at a timeline like an HTTPs Server request:
As you can see in the figure above, when an HTTP request is made by an HTTPs Server, it will be permanently redirected to an HTTPs request, and then the response header will have a special “strict-transport-security” header. This header tells the browser that all requests under this domain will be accessed using HTTPs. So if a subsequent HTTP request is made, the browser will internally redirect to the HTTPs request.
The above description of HTTPs requests is intended to introduce the following problems when your secure domain name corresponds to HTTPs services:
- After the secure domain name DNS is hijacked to the local HTTP service, access to the browser is still an HTTPs request.
- Based on 1, we thought of clear browser cache, but wechat developer tools cannot enter Chrome ://net-internals/# HSTS clean;
Q1: Take Chrome as an example. Enter Chrome ://net-internals/# HSTS to clear security policies.
Q2: In the wechat developer tool, we don’t have access to this page, which means that if the secure domain name has a security policy cache in the tool, you can’t hijack it into an HTTP service. “Let me know if there’s a solution here.”
To solve this problem, we can only introduce the ultimate solution, through an HTTPs Server to do a forward request, the process is as follows:
ProxyServer does two things:
- An SSL certificate corresponding to the security domain name is configured to support HTTPs requests.
- Forward requests under secure domain names to corresponding development services;
If the ProxyServer exists as a generic service, you need to consider how to proxy to development services started by different developers.
Originally we planned to use QueryString to specify the address of the development service to be brokered to. The reality is that all requests in a page that depend on the domain are forwarded, so queryString methods can’t easily do this.
So finally through the cookie to achieve this requirement, through the cookie to specify the development server address, so that all resource requests under the domain will carry the cookie, can achieve custom forwarding to the upstream service.
Finally using this scheme to debug wechat JS-SDK requires the following two steps:
- Change the hosts file to hijack the secure domain name to the proxy service;
- Set cookies to specify the upstream service to be proxy to;
In this way, the proxy service can exist as a generic service that can be used by any developer who wants to do some debugging around secure domain name restrictions.
FAQ
Q1. Advantages and disadvantages of routine operation?
Pros:
- Fewer steps, easy to do, suitable for occasional debugging;
Cons:
- Fixed domain name wants money 💰, do not fix domain name to often change again, but a month only revises opportunity 3 times;
- Wechat security domain name pool did not pit how to do ah… “It is not impossible to apply for a test account, but the interfaces related to the back-end access_token and JSAPi_ticket must be modified.”
- It is not general enough. The secure domain name is set for other three logins and cannot be reused.
For Cons 1, there is a better solution: you can combine DNS hijacking, and use the peanut shell to verify the domain name when binding the secure domain name in wechat background. Then you don’t need to use the peanut shell anymore, you can modify hosts, and hijack the verified domain name to the local development service, so you don’t need to worry about HTTPs or pay for the fixed domain name. If you are interested, you can try it.
Q2. What are the advantages of unconventional operations?
Pros:
- No additional domain name is required, which means no change to the secure domain name configuration and no change to the server code.
- Generic, a three-party service with a similar secure domain name policy;
- For ordinary developers, the cost of daily development and debugging is very low, and no special permissions are required;
Cons:
- The construction process is relatively complex and requires server resources.
Q3. How to debug the real phone in wechat?
If it is HTTPs, you also need to configure the certificate trust. This step is not described in this article, you can Google yourself.
Q4. How to apply for a test account?
Mp.weixin.qq.com/debug/cgi-b…
summary
On the solution, the additional cost of the conventional solution is low, but in the case of multiple developers collaborative development of the public account, the overall cost is high; Unconventional solutions are more suitable for multiple developers who need to debug wechat JS-SDK, once and for all.
In the process, you can actually learn the concept of DNS hijacking, practical application, and further understanding of HTTPs.
Finally, if you like, you can follow the public account “Teacup lid”.
