Resolution of a micro-letter authorization callback page domain name can only be set one problem _php tips

The Final Solution is: Https://github.com/liuyunzhuge/php_weixin_proxy, detailed introduction please read down.

User authorization is required for Project integration micro-letter login and micro-credit payment. This authorization process can be described briefly as:

1. Users from our application triggers the need to authorize the operation, such as Click on the micro-letter login;

2. After the application receives this user request, redirects the user to an authorization page provided by the micro-letter:

Or

3. The user through the micro-letter scanning code (PC-side authorization, the left image above) or click the Confirmation button (mobile end authorization, the top right) to inform the micro-letter, authorized application access to their own micro-letter account information;

4. After receiving the user's authorization, the micro-letter generates the authorization code and recalls it as a parameter to a page of the application;

5. The application callback page receives the micro-mail callback request, takes the authorization code, and obtains access token through the access token API interface provided by the microblogging official.

6. Finally, the user's micro-credit account information can be obtained through access token and another UserInfo API interface provided by the micro-credit official.

In order to achieve this process, first of all to apply for the application of a micro-public number, and the application of the final deployment of the domain name to the micro-public number settings inside the authorization callback page domain name this option. The micro-credit official's description of this option is as follows:

A description of the Web page authorization callback domain name

1, before the micro-trust public number to request the user page authorization, the developer needs to first to the public platform in the "Development-interface permissions-Web services-Web account-Web authorization to obtain user information" configuration options, modify the authorization callback domain name. Please note that here is the domain name (is a string), 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 authorized domain name: www.qq.com, after the configuration of this domain Name page http://www.qq.com/music.html, http://www.qq.com/login.html Can carry out OAuth2.0 authentication. But http://pay.qq.com, http://music.qq.com, http://qq.com can't carry out OAuth2.0 authentication.

3, if the public sign is authorized to the third party developers to manage, you do not have to do any setting, the third party in lieu of public number to implement the Web page authorization can be

This shows that the rule is extremely strict. If there is only one domain name in the final deployment of our application, then there is no problem with this rule, but given the complexity of the application in the future, we may be able to split the application at the beginning of the application design, and then different businesses will be deployed with different two-level domain names. For example, with a trading application, you might be able to separate login, transaction management, and regular business, and then deploy them in the following ways:

Www.your.com deployment of regular operations;

Trade.your.com the business of deploying transaction management;

Passport.your.com deployment login registered business;

In this mode, if the integration of micro-letter login and micro-credit payment, the previous authorization callback page domain rules will bring problems to the application. Here: At the very least, you can confirm that trade.your.com and passport.your.com need the user's micro-credit authorization described earlier, but they are two different subdomains, and we have only one public number; According to the authorization callback page domain name principle, it only uses one domain name, and only the callback address domain name and the To successfully initiate a micro-credit authorization, or you will be prompted to Rediret_uri parameter errors or raise an issue that cannot be recalled.

So how do you deal with this situation?

The immediate solution is to introduce a new, very simple application as a proxy service for micro-trust, and you can do this:

1. The public number of the Web page authorized interface domain name set to another subdomain, such as proxy.your.com;

2. Then deploy the index.php inside the php_weixin_proxy to proxy.your.com.

Php_weixin_proxy under the index.php is a very simple PHP file, you can directly view the source code to understand how it is implemented. Because of the current project environment, I use PHP to complete this proxy service implementation, in fact, you can use any platform language to complete similar functions.

When other business needs to initiate a micro-letter authorization, the authorization request is first sent to proxy.your.com, then proxy.your.com will forward the request to the micro-letter;

When the user agrees to authorize, the proxy.your.com receives the micro-letter authorization callback and returns the callback result (code, state parameter) back to the business that initiated the authorization.

The only difference is that when you do not use proxy.your.com, you should initiate a micro-letter authorization link from the application:

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

After using the proxy.your.com, the authorization link should be this:

http://proxy.your.com/?appid=xxxxx&redirect_uri=http%3a%2f%2fpassport.your.com%2flogin%2fnotify& Response_type=code&scope=snsapi_base&state=584bc87e11ff37492&device=pc

The link in the back is compared to the above:

1. The following link in the host into the proxy.your.com, that is, the authorization of the proxy callback domain name;

2. After a device parameter, this is necessary. Because the PC end of the micro-credit and the mobile end of the authorized address is not the same, and the following link is sent a proxy.your.com, so need to add a parameter to tell it to the authorization to apply to the micro-letter, the PC or mobile end of the authorized address.

Overall plan idea:

Summary:

I have tested this scheme, it is OK. Although the introduction of the proxy service, added a redirect operation, however, since this authorization request is not required for all requests, it will not actually have much impact on the user experience, but architecturally, it has the advantage of being able to integrate the same public number login and payment functions with the application split logic , there is no need to apply for a single public number for each child application (this approach is not reasonable in business and a company needs to run so many public numbers).

The above is the entire content of this article, I hope the content of this article for everyone's study or work can bring some help, but also hope that a lot of support cloud Habitat community!