无码人妻精一区二区三区,eeuss影院www在线观看,无码精品久久久久久人妻中字,日韩av高清在线看片

流程概述

以開發(fā)者的角度，整個流程為：

大致的步驟是：

1. 小程序調用“獲取登錄憑證”接口，獲取由微信返回的 code 。
2. 小程序端將 code 傳送給開發(fā)者服務端，由服務端將獲取的 code 以及 AppID 和 AppSecret ，發(fā)送給微信服務端。
3. 開發(fā)者服務端獲取微信服務端返回的 OpenID 和會話密鑰等信息。

 

圖上后續(xù)的流程為獲取 OpenID 后以及之后開發(fā)者服務端與小程序端和微信服務端交互的流程，不在本文敘述范圍內。

獲取登錄憑證

用戶打開小程序后，小程序端調用 wx.login() 方法，之后直接獲取返回的 code （用戶登錄憑證），我們來看看，這個過程中，微信做了什么。

 

這個過程中需要的一張數(shù)據(jù)表我們標記為“用戶登錄憑證表”。

 

備注說明：事實上，存儲該類信息的數(shù)據(jù)庫大概率使用的是NoSQL數(shù)據(jù)庫，在本文敘述中，將不再區(qū)分NoSQL數(shù)據(jù)庫和關系型數(shù)據(jù)庫，僅認為兩者只是存儲方式的不同，統(tǒng)一以關系型數(shù)據(jù)庫的“表”、“記錄”、“字段”的概念進行描述。

當小程序端調用 wx.login() 方法后，微信App攜帶以下信息向微信服務端發(fā)送請求：

1. wx_id：微信用戶的全局唯一識別碼
2. AppID：小程序的唯一識別碼

 

微信服務端獲取請求并識別請求為有效請求之后，向“用戶登錄憑證表”新增一條記錄，相應的有效字段及內容分別是：

1. 創(chuàng)建時間：即該條記錄的新增時間。
2. 失效時間：當前文檔中說明 code 的有效期為5分鐘，該字段內容只需由創(chuàng)建時間累加5分鐘，得出結果即可。
3. AppID：記錄發(fā)送請求的小程序。
4. wx_id：記錄訪問者用戶。
5. code：即用戶登錄憑證，由特定規(guī)則生成即可，只需保證在有效時間內同一AppID下不重復即可。
6. 是否使用：創(chuàng)建記錄時默認為“否”，后續(xù)該 code 被使用后，變更為“是”。

 

完成以上步驟后，微信服務端向客戶端返回 code ，以下是微信返回內容的一個示例：

 

到達這一步，小程序端已獲取 code （用戶登錄憑證）。

發(fā)送登錄憑證

發(fā)送 code （用戶登錄憑證）的過程分為2步：

1. 第1步：小程序端向開發(fā)者服務端發(fā)送。
2. 第2步：開發(fā)者服務端向微信服務端發(fā)送。

 

在這個過程中，很多人會有疑問：開發(fā)者服務端實際上充當了一個中轉站的用途，為什么不改成由小程序端直接向微信服務端發(fā)送？

 

這里的原因，筆者分析主要有2個。一是發(fā)送 code 的過程中，需要同時攜帶小程序對應的 AppID 和 AppSecret 以便驗證請求者的身份，這些敏感信息在前端存儲極易泄漏。二是使用 OpenID 的過程，都在開發(fā)者服務端，即便由小程序端獲取，最終還是需要由小程序端發(fā)送給開發(fā)者服務端。

 

筆者也自己做了一個測試，嘗試從小程序端直接發(fā)送請求，發(fā)現(xiàn)微信已經從流程上杜絕了此類操作。

 

第一步，從小程序端向微信服務端發(fā)起請求。提示內容為：

 

即要請求的 https://api.weixin.qq.com 域名不在后臺配置的合法域名中，后面考慮如果把這個域名加入合法域名會怎么樣？

 

第二步，登錄小程序管理后臺，添加該域名，提示內容為：

 

即該域名不允許被加入到合法域名中。對此微信官方文檔也給出了詳細解釋（對應上述提到的原因一）：

 

因此，指定的這兩步只能按照流程進行，沒有辦法繞過。

返回OpenID

在微信服務端收到由開發(fā)者服務端發(fā)送的 code 及相關信息后，將會向開發(fā)者服務端返回 OpenID 、 session_key 和 UnionID 等信息，我們這里僅說明 OpenID ，這是一個涉及判斷條件較多的環(huán)節(jié)。

第一步：判斷 code 有效性

只有同時滿足以下條件，才認為這個 code 是有效的：

1. code 在有效期內
2. code 與 AppID 對應
3. AppSecret 與 AppID 對應

 

前兩者只需將請求的內容與“用戶登錄憑證表”進行比較即可得出，第3項需查詢對應的小程序賬戶信息表。

 

測試中發(fā)現(xiàn)過期的 code 和無效的 code 給出的提示都是 invalid code ，猜測可能對于 code 存在定時清空機制，對于超時的 code 直接做了刪除處理。在判斷達到以上條件后，就進入第2步。

第二步：生成OpenID

每一個用戶的 OpenID 需要在指定的小程序下保持全局唯一，而生成的 OpenID 是定長的（指長度在指定字符數(shù)內），那么無論按照任何算法，都必然存在“可能出現(xiàn)2個用戶初次生成的OpenID重復”的情況，所以對于OpenID信息，最好的策略不是實時生成，而是采用以下策略：

 

按照規(guī)則生成后，判斷該小程序下是否重復，如不重復，則存表，如重復，則加干擾項，重新生成，直到不重復為止。

 

微信實際采取的策略不得而知，但無非是以上規(guī)則的加強版。一個最為簡單的規(guī)則就是，將用戶的 wx_id 和 AppID 直接轉換成數(shù)字，然后將相乘的結果再轉換成字符串。如重復，則將結果數(shù)字加1即可。

 

對于一個有效的 code ，根據(jù)篩選 wx_id 和 AppID ，有記錄則直接返回該值，如果無，則按照規(guī)則生成。

第三步：返回OpenID

生成 OpenID 之后，就由微信服務端向開發(fā)者服務端返回結果。

 

至此，開發(fā)者服務端獲取訪問者的 OpenID 信息，即完成“靜默登錄”動作，這一套流程的優(yōu)點是，在小程序上，無需用戶輸入賬號密碼，即可完成登錄。在完成登錄之后，后續(xù)的小程序端和開發(fā)者服務端之間的交互可直接依照常規(guī)的完成登錄的方式進行，例如向小程序端發(fā)送 access_token 等，以此作為身份憑證。

總結

微信小程序的這套“靜默登錄”機制給開發(fā)者提供了很大的方便，也方便了用戶的操作，開發(fā)者在設計產品時，要充分利用這套“靜默登錄”機制，除非是存在多類型客戶端情況，否則就沒有必要讓用戶進行相應的注冊登錄操作，在這一點上一定要改變思維。