最終的解決方案是：https://github.com/liuyunzhuge/php_weixin_proxy，詳細的介紹請往下閱讀。

在做項目集成微信登錄以及微信支付的時候，都需要進行用戶授權。這個授權的流程可以簡單描述為：

1. 用戶從我們的應用觸發(fā)需要授權的操作，比如點擊微信登錄；

2. 應用收到這種用戶請求后，將用戶重定向到微信提供的一個授權頁面：

或

3. 用戶通過微信掃碼（PC端授權，上邊左圖）或者點擊確認按鈕（移動端授權，上邊右圖）告知微信，授權應用訪問自己的微信賬號信息；

4. 微信收到用戶的授權許可后，生成授權碼，并把它作為參數(shù)回調(diào)至應用的某個頁面；

5. 應用的回調(diào)頁面在接收到微信的回調(diào)請求后，拿到其中的授權碼，并通過微信官方提供的access token api接口獲取access token；

6. 最后通過access token以及微信官方提供的另一個userinfo api接口就能獲取到用戶的微信賬號信息。

為了實現(xiàn)這個過程，首先要為應用申請一個微信公眾號，并將應用最終部署的域名設置到微信公眾號設置里面的授權回調(diào)頁面域名這個選項里面。微信官方對這個選項的說明如下：

關于網(wǎng)頁授權回調(diào)域名的說明

1、在微信公眾號請求用戶網(wǎng)頁授權之前，開發(fā)者需要先到公眾平臺官網(wǎng)中的“開發(fā) - 接口權限 - 網(wǎng)頁服務 - 網(wǎng)頁帳號 - 網(wǎng)頁授權獲取用戶基本信息”的配置選項中，修改授權回調(diào)域名。請注意，這里填寫的是域名（是一個字符串），而不是URL，因此請勿加 http:// 等協(xié)議頭；

2、授權回調(diào)域名配置規(guī)范為全域名，比如需要網(wǎng)頁授權的域名為：www.qq.com，配置以后此域名下面的頁面http://www.qq.com/music.html 、 http://www.qq.com/login.html 都可以進行OAuth2.0鑒權。但http://pay.qq.com 、 http://music.qq.com 、 http://qq.com無法進行OAuth2.0鑒權

3、如果公眾號登錄授權給了第三方開發(fā)者來進行管理，則不必做任何設置，由第三方代替公眾號實現(xiàn)網(wǎng)頁授權即可

由此可見，這個規(guī)則極其嚴格。如果說我們的應用最終部署的時候只有一個域名，那么這種規(guī)則不會有什么問題；但是考慮到將來應用的復雜性，我們可能在應用設計之初就會對應用做拆分，然后不同的業(yè)務采用不同的二級域名來部署。比如一個帶有交易的應用，你可能會把登錄注冊，交易管理和常規(guī)業(yè)務都獨立出來，然后采用以下的方式來部署它們：

www.your.com 部署常規(guī)業(yè)務；

trade.your.com 部署交易管理的業(yè)務；

passport.your.com 部署登錄注冊的業(yè)務；

在這種模式下，如果集成微信登錄和微信支付，前面說的授權回調(diào)頁面域名的規(guī)則就會給應用帶來問題。在這里：至少可以確認trade.your.com和passport.your.com都需要前面的介紹的用戶微信授權，但是它們是兩個不同的子域名，而且我們只有一個公眾號；根據(jù)授權回調(diào)頁面域名的原則，它只能用一個域名，并且只有回調(diào)地址的域名與該設置完全相同，才能成功發(fā)起微信授權，否則就會提示rediret_uri參數(shù)錯誤或者引發(fā)無法回調(diào)的問題。

那么這種情況該如何處理？

當下的解決方案是引入一個新的非常簡單的應用來作為微信授權的代理服務，可以這么做：

1. 把公眾號的網(wǎng)頁授權接口域名設置成另外一個子域名，如proxy.your.com；

2. 然后把php_weixin_proxy里面的index.php部署到proxy.your.com

php_weixin_proxy下的index.php是一個很簡單的php文件，你可以直接查看源碼了解它的實現(xiàn)方式。因為當前項目的環(huán)境，我采用php來完成這個代理服務實現(xiàn)，實際上，你完全可以用任意平臺語言來完成類似的功能。

當其它業(yè)務需要發(fā)起微信授權時，將授權請求先發(fā)到proxy.your.com，然后proxy.your.com會把這個請求轉(zhuǎn)發(fā)到微信；

當用戶同意授權后，proxy.your.com會收到微信的授權回調(diào)，并把回調(diào)結(jié)果（code、state參數(shù)）原封不動地再返回給最開始發(fā)起授權的業(yè)務。

唯一的區(qū)別在于，在不使用proxy.your.com的時候，你從應用發(fā)起微信授權的鏈接應該是這樣的：

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

用了proxy.your.com之后，這個授權鏈接就應該是這樣的：

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

后面這個鏈接跟上面的比：

1. 后面的鏈接中的host變成了proxy.your.com，也就是代理的授權回調(diào)域名；

2. 后面的多了一個device參數(shù)，這個是必要的。因為微信pc端跟移動端的授權地址是不一樣的，而后面的鏈接是發(fā)送個proxy.your.com的，所以需要多加個參數(shù)告訴它在轉(zhuǎn)發(fā)給授權申請給微信的時候，是用PC端還是移動端的授權地址。

整體方案思路：

小結(jié)：

這個方案我測試過，是行的通的。雖然說引入了代理服務，增加了一次重定向操作，不過由于這個授權請求并不是所有請求都需要，所以實際上也不會對用戶體驗產(chǎn)生多大的影響，但是從架構(gòu)上來說，它的好處很明顯，能夠配合著應用的拆分邏輯，集成同一個公眾號的登錄及支付功能，不必為每個子應用都單獨申請一個公眾號來開發(fā)了（這種方式從業(yè)務上來說也不合理，一個公司哪需要運營那么多公眾號）。

以上就是本文的全部內(nèi)容，希望本文的內(nèi)容對大家的學習或者工作能帶來一定的幫助，同時也希望多多支持腳本之家！

最新評論