微信靜默受權返回問題

微信中須要獲取openid，爲了安全起見，採用服務器端靜默受權方式，最終過程是：

前端頁面(獲取openid) -> 指定服務器端地址 -> 服務器端跳轉到微信受權頁 -> 微信受權頁跳回服務器端 -> 服務器端跳回前端頁面

在這裏會存在一個問題，即微信受權返回死循環問題，由於這邊前端跳轉所有都是使用replace跳轉，因此不會在history上再增長1一個頁面，後來覺得是咱們服務器的問題，而後撇開微信直接讓服務器端返回一個假的openid發現是能夠返回的，因此問題出在微信的受權問題上，即：不管前端跳轉是否採用replace,使用微信受權，微信自動會在瀏覽器增長一條頁面，即跳轉微信受權前的一個頁面，這樣的話，當用戶點擊返回按鈕的時候，天然是返回到沒有受權頁，而後沒有受權頁根據業務邏輯再繼續發起受權請求，就這樣陷入了無線循環之中。

也思考過一些解決方式，好比使用iframe來獲取openid,好比使用XMLHttpRequest來代替服務器端跳轉，這些所有都行不通，因此只能在請求受權頁作手腳，即判斷 是否應該去獲取受權頁，若是是由於返回進入該頁面的 則執行history.back(),不然則進入微信受權模式，可是這種方式仍是存在一個問題，即若是請求受權頁自己就是首頁怎麼辦，執行history.back()也不會讓微信瀏覽器自動關閉，這個時候就會卡在這裏，固然是可使用微信JSSDK的closeWindow()方法，可是這種方式須要等待wx.config()完成，這裏涉及到從服務器端獲取簽名等流程，具備明顯的延時狀況，形成一種很糟糕的用戶體驗，因此最終的解決方式是：

1：若是請求受權頁是首頁，當用戶點擊返回按鈕的時候，仍是走受權頁，即陷入無限循環套路，

2：若是請求受權頁不是首頁，則執行higtory.back() 返回上一頁

 

後記：

可是我在調查公衆號返回狀況的時候，依然看到不少公衆號在獲取到openid後能夠實現完美返回，最終獲得結果以下：

微信靜默受權分爲客戶端靜默受權和服務器端靜默受權，客戶端靜默受權是指首先打開一個網頁，而後在網頁內部調用微信靜默受權獲取到微信openid，服務器端靜默受權是指點擊微信菜單按鈕，而後按鈕事件爲click，這個時候會通知到對應分服務器端，服務器端在使用靜默受權方式拿到openid後，在返回真正的客戶端頁面，這個時候客戶端頁面已經拿到了openid，

在微信的菜單中博包含click和view事件，其中click是與用戶交互的，好比接收用戶文本消息 返回模板消息等等，而view是綁定一個url地址，click與view的不一樣之處在於，點擊click按鈕是調用服務器端接口與服務器端進行通訊的，同時服務器端必須返回指定格式信息，而view則是直接打開綁定在菜單上的url,因此這個時候會存在三種狀況打開頁面

1：用戶在輸入框輸入地址，而後點擊發送，而後點擊對話框裏的地址打開

2：用戶點擊菜單 打開url

3：用戶點擊模板消息裏的詳情打開url

 

第二種狀況，用戶點擊菜單，這個時候若是菜單綁定的是服務器端接口，則服務器端接口在使用靜默受權方式拿到openid後，而後跳轉到真正的客戶端頁面同時帶上openid

第三種狀況，用戶點擊模板消息，由於模板消息屬於交互，因此模板消息裏面的url應該是帶上openid的

第一種狀況，這種狀況屬於非正常進入，應該給與友情提示，同時若是但願更加友好，則可使用客戶端靜默受權模式獲取到用戶openid,而後便可正常顯示頁面，這個時候會存在返回循環問題，能夠先跳轉到首頁，而後首頁有進入指定頁面入口，而後在指定頁面會進行客戶端靜默受權，而後在返回的時候，判斷一下，若是是返回進入的請求受權頁 則執行hsitory.back()。