[技術博客] 小程序掃碼登陸網頁端原理

目錄

• 1、問題引入
• 2、幾個難題
  • 1. 網頁端是怎麼知道哪一個用戶掃描的二維碼？
  • 2. 小程序掃碼，掃出來的是什麼東西？
  • 3. 小程序掃到二維碼之後，作了什麼事情，怎麼和網頁端通信的？
• 3、解決方案
  • 1. 相當重要的uuid
  • 2. 用戶信息與uuid的綁定
  • 3. 網頁端輪詢uuid，直至獲取到用戶身份信息
• 4、一些技術細節

做者：雨飛

1、問題引入

在設計用於管理社團信息的網頁端時，咱們須要解決的一個問題是怎樣讓社團管理員很方便地登陸到管理平臺中去。出於提升用戶體驗角度的考慮，咱們的小程序在用戶第一次登陸時，只須要微信受權得到身份信息，就能夠自動完成註冊和登陸流程，用戶無需手動輸入密碼或建立新的帳號，一切都是與微信綁定的。這種作法當然方便，但缺點在於登陸流程和微信環境高度綁定，脫離微信環境以後再想獲取並驗證用戶的身份信息就比較困難。

最後咱們選擇了在網頁端設置小程序掃碼登陸，用戶只須要打開咱們的小程序，在「個人」頁面中點擊「掃描二維碼」，即可以自動登陸到網頁端社團數據管理平臺。在實現這個功能的過程當中，咱們遇到了一些問題，這些問題在經歷了一段時間的學習研究以後得以解決，咱們以爲有必要在此把解決問題的過程記錄下來，做爲技術博客。所以有了這篇文章。

2、幾個難題

1. 網頁端是怎麼知道哪一個用戶掃描的二維碼？

這是不少人在第一次看到」掃碼登陸「這種登陸方式時的第一反應。的確，這個過程看起來有點神奇，網頁上只是顯示了一個二維碼而已，爲何小程序掃碼以後，網頁端就知道是哪一個用戶掃描的二維碼呢？若是咱們要本身去實現這個功能的話，也必然面臨着一樣的問題。

2. 小程序掃碼，掃出來的是什麼東西？

第二個問題其實是由第一個問題引出的。既然網頁端不須要任何額外信息就能知道是哪一個用戶掃描的二維碼，那麼二維碼裏就必然包含着對識別用戶身份相當重要的信息。這裏面的信息具體有哪些內容？這也是咱們着重要解決的事情。

3. 小程序掃到二維碼之後，作了什麼事情，怎麼和網頁端通信的？

從用戶體驗的角度來看，小程序掃碼登陸是一件十分天然的事情：網頁端顯示二維碼，小程序掃碼，網頁端即可以正常登陸。然而小程序掃碼以後，網頁端怎麼知道小程序已經掃碼了？小程序是如何把自身存儲的用戶信息發送給網頁端的？只有解決這些問題，掃碼登陸的流程才能夠說是被真正打通。

3、解決方案

1. 相當重要的uuid

uuid（通用惟一識別碼）是解決以上難題的關鍵。其實掃碼登陸的根本難題在於如何在小程序和網頁端之間共享用戶的身份信息，所以勢必須要一個識別碼來進行網頁端和小程序的通訊綁定。

後端服務器對外提供一個接口，網頁端每次訪問這個接口，都會得到一個全局惟一的uuid。網頁端獲取uuid以後，將其轉換爲二維碼展現在頁面上，二維碼包含且只包含這個uuid。

咱們使用了qrcode.react做爲網頁端生成二維碼的組件。

2. 用戶信息與uuid的綁定

後端服務器生成uuid以後，便會將這個uuid存入redis緩存中。小程序掃描到帶有uuid信息的二維碼，得到用戶身份信息以後，訪問服務器的另外一個接口，將用戶信息和uuid一塊兒發送給後端。後端把身份信息與剛剛存入redis的uuid綁定在一塊兒，由此完成用戶信息和uuid（也即二維碼）的綁定。

3. 網頁端輪詢uuid，直至獲取到用戶身份信息

網頁端知道，在將來的某一時刻，小程序會把當前登陸用戶的身份信息和uuid綁定在一塊兒，所以網頁端只須要不斷輪詢後端服務器，並把本身的uuid做爲參數，就能夠知道uuid是否已經綁定了用戶信息。若是還未綁定，則等待直至uuid失效；若是已綁定，就使用該身份信息登陸。至此，掃碼登陸的流程所有打通。

4、一些技術細節

1. redis在存儲uuid時，出於安全考慮，必須設置過時時間
2. 網頁端輪詢時，須要注意輪詢時間間隔，避免對服務器形成過大壓力
3. uuid一旦與用戶身份信息綁定，一次使用後則需失效，不然會帶來安全隱患