Solve the problem that only one domain name can be set on the WeChat authorization callback page [php], callback php

Solve the problem that only one domain name can be set for the authorization callback page [php], callback php

   
The final solution is: https://github.com/liuyunzhuge/php_weixin_proxy. For more information, see the following.
 

User authorization is required for project integration login and payment. The authorization process can be described as follows:
1. the user triggers authorization operations from our application, such as clicking log on;
2. After receiving such a user request, the application redirects the user to an authorization page provided:
Or
3. the user can scan the Code (PC-side authorization, as shown in the upper left figure) or click the OK button (mobile-side authorization, as shown in the upper right figure) to authorize the application to access its account information;
4. After receiving the user's authorization, generate the authorization code and call it back to a page of the application as a parameter;
5. After receiving the callback request, the app's callback page obtains the authorization code and obtains the access token through the official access token api interface;
6. Finally, the user's account information can be obtained through access token and another officially provided userinfo api.

To achieve this, you must first apply for a public account for the application and set the domain name to the authorization callback page domain name option in the public account settings. The official description of this option is as follows:

   
Webpage authorization callback Domain Name Description
    
1. Before the public account requests the user's webpage authorization, the developer must modify the authorization callback domain name in the configuration option "development-interface permission-webpage service-webpage account-webpage authorization to obtain basic user information" on the official website of the public platform. Please note that the domain name (a string) is entered here, rather than the URL, so do not add http: // and other protocol headers;
    
2, authorization callback domain name configuration specification for the full domain name, such as the need for web page authorization Domain Name: www.qq.com, after the configuration of the domain name under the page http://www.qq.com/music.html, http://www.qq.com/login.html can be OAuth2.0 authentication. But http://pay.qq.com, http://music.qq.com, http://qq.com cannot perform OAuth2.0 Authentication
    
3. If a third-party developer is authorized to log on to the public account for management, no setup is required. A third party can authorize a webpage instead of the public account.
 

It can be seen that this rule is extremely strict. If our application is deployed with only one domain name, this rule will not be a problem. However, considering the complexity of future applications, we may split the application at the beginning of the application design, then different services are deployed using different second-level domain names. For example, for an application with transactions, you may separate login registration, transaction management, and regular business, and then deploy them in the following ways:
Www.your.com;
Trade.your.com deploy the transaction management business;
Passport.your.com deploy the login registration service;
In this mode, if logon and payment are integrated, the domain name rules on the Authorization callback page mentioned above will cause problems to the application. Here: At least we can confirm that both trade.your.com and passport.your.com require the user authorization described above, but they are two different subdomain names, and we only have one public account; according to the authorization callback page domain name principle, it can only use one domain name. Only when the Domain Name of the callback address is exactly the same as the setting can authorization be initiated successfully, otherwise, the system prompts a rediret_uri parameter error or a callback failure.

So what should we do?

The current solution is to introduce a new very simple application as an authorized proxy service. You can do this:
1. Set the webpage authorization interface Domain Name of the public account to another subdomain name, such as proxy.your.com;
2. Deploy index. php In php_weixin_proxy to proxy.your.com.

   
Index. php under php_weixin_proxy is a very simple php file. You can view the source code to understand its implementation method. Because of the current project environment, I use php to implement this proxy service. In fact, you can use any platform language to complete similar functions.
 

When other services need to initiate authorization, send the authorization request to proxy.your.com, and then proxy.your.com forwards the request;
After the user agrees to the authorization, proxy.your.com receives the authorization callback and returns the callback result (the code and state parameters) intact to the business that initiated the authorization.

The only difference is that when proxy.your.com is not used, the link from which you initiate authorization should be as follows:
Https://open.weixin.qq.com/connect/qrconnect? Appid = xxxxx & redirect_uri = http % 3A % 2F % 2Fpassport.your.com % 2F & response_type = code & scope = snsapi_login & state = 584bc87e11ff37492 # wechat_redirect
After proxy.your.com is used, the authorization link should be like this:
Http://proxy.your.com /? Appid = xxxxx & redirect_uri = http % 3A % 2F % 2Fpassport.your.com % 2 Flogin % 2 Fnotify & response_type = code & scope = snsapi_base & state = 584bc87e11ff37492 & device = pc

The following link keeps up with the following comparison:
1. The host in the link is changed to proxy.your.com, that is, the authorized callback Domain Name of the proxy;
2. A device parameter is added later, which is necessary. Because the authorization addresses on the pc and mobile terminals are different, and the following link sends a proxy.your.com, you need to add more parameters to tell it when forwarding the authorization request to the mobile terminal, whether to use an authorized address on the PC or mobile end.

Overall solution ideas:

Summary:

I have tested this solution and it works. Although a proxy service is introduced and a redirection operation is added, this authorization request is not required by all requests, so it does not actually affect the user experience, however, in terms of architecture, it has obvious advantages. It can work with the application's split logic to integrate the login and payment functions of the same public account, you don't have to apply for a public number for each sub-application. (This method is not reasonable in terms of business. Which company needs to operate so many public accounts ).