微信靜默受權返回問題

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

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

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

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

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

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

 

後記:接口

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

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

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

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

2:用戶點擊菜單 打開url

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

 

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

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

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

相關文章
相關標籤/搜索