《微信小程序七日談》- 第五天：你可能要在登錄功能上花費大力氣 ...
前幾篇文章的內容主要集中于小程序開發框架中的一些機制細節，基本上都是客戶端層面的知識。隨著小程序項目的不斷深入，我們不得不面對一些需要客戶端與服務端協同完成的需求，比如用戶登錄功能。
大多數的小程序都會有自身的用戶體系，然而小程序必須要經過微信賬戶的驗證授權，然后再與第三方服務器（也就是公司自己的服務器）通信實現用戶的登錄。這里面就涉及到微信賬戶信息與自身用戶信息的耦合。下面就簡單介紹一下我們項目目前實現用戶登錄的技術細節。
瀏覽器環境下登錄的實現方案
在制定具體實現方案之前，我們首先思考一下用戶登錄功能需要注意哪些細節。通常來講，實現用戶登錄功能需要注意以下兩點：
- 登錄狀態保存；
- 安全驗證。
登錄狀態保存就是登錄成功后請求站內數據接口時無需再次登錄，客戶端與服務器按照既定的規則進行用戶有效性驗證。瀏覽器環境下的登錄狀態保存通常使用cookie實現，這種方案的實現原理是瀏覽器發出的http請求header中會攜帶客戶端的cookie。如下圖：
安全驗證是為了應對流量劫持，防止中間人攻擊，在我們的頁面中插入亂七八糟的內容。大家可能會想到使用https來防止流量劫持。https可以應對絕大部分的應用場景，有效的防止流量劫持。但其實市場上有一些“黑科技”軟件可以捕獲并且解密https加密信息的，比如Fiddler。所以在https的基礎上，再進行一層安全驗證是還有必要的。
大家可以參考這篇文章了解fiddler解密https的知識。
自定義安全驗證通常的方案是客戶端與服務器約定好一個驗證簽名，客戶端在發出http請求之前按照約定好的算法計算出一個簽名字符串，并且在http請求中將計算簽名的參數傳遞給服務器。服務器接收到請求之后，解析出簽名字符串和客戶端傳遞的計算參數，然后按照同樣的算法計算出簽名字符串，并將其與客戶端的簽名進行對比，完全一致則驗證通過，否則返回驗證未通過的數據。如下圖：
上述流程成立的前提條件是：
- 瀏覽器可以獲取到UA信息；
- 瀏覽器發出的http請求header中會攜帶UA信息，服務器可以獲取。
那么這套方案在小程序平臺上是否可以復用呢？答案是否定的。
小程序的限制
目前我們所知的小程序存在以下限制：
- 不支持cookie，所以使用cookie儲存登錄狀態的方案不可行；
- http請求header不攜帶設備信息，服務器無法獲取。
但是我們在吐槽小程序重重限制的同時得到了一個好消息：http請求可以自定義header。我們仿佛看到了解決問題的銀彈。
使用自定義header傳遞敏感信息
登錄識別信息在無法使用cookie傳遞的限制下只有兩種傳輸途徑：
- url query
- http header
小程序提供了獲取設備信息的API，提供了在客戶端計算簽名字符串的參數。按前文提到的驗證規則，客戶端計算簽名的參數必須傳遞給服務器才能保證兩端計算的一致性。所以我們又面臨了之前的抉擇，是query還是header？
其實使用任何一種途徑都可以完成需求，但是url query（通常稱為data）的語義應該是與接口功能緊密相關的數據，并且http請求的header比url query數據更保密，所以我們團隊最終采用header傳遞登錄識別信息和設備信息的方案。
登錄實現方案
確定信息的傳遞方式只是第一步，在小程序平臺下實現自己的用戶登錄仍然有很多細節需要琢磨。我們首先看一下官方文檔給出的第三方登錄流程圖：
官方文檔給出的流程是實現第三方登錄的基本流程，但是具體的登錄功能中仍然有一些細節上的不同，比如：
- 手機驗證碼登錄；
- 3rd_session和openId不能明文暴露給客戶端，需要進行加密；
- 登錄狀態保存的有效期；
- 用戶登錄的服務器與基礎服務的服務器并不是同一臺。
在小程序登錄機制的基礎上，我們團隊在制定安全登錄功能時最終采用了如下方案：
對比微信官方的登錄流程圖，有以下幾個細節：
- 3rd_session和openId不直接暴露給客戶端，而是通過可逆的加密算法進行加密后，組合成token暴露給客戶端；
- 第一次請求基礎功能服務器時并不驗證簽名，此次請求的目的是從微信服務器獲取3rd_session和openId并且加密后返回客戶端，以便后續請求使用；
- 第二次請求的目標是用戶服務器，攜帶token的sign。用戶服務器首先會進行簽名驗證和手機驗證碼校驗；
- 驗證通過后解析token獲取3rd_session和openId，然后與uid結合重新計算token。最后將uid和token一并返回給客戶端。
用戶登錄成功后，客戶端將uid和token儲存在本地，以便后續請求數據接口使用。
客戶端儲存token和uid的方式可以采用storage或者app.globalData。
數據接口的請求驗證方案
數據接口是在用戶登錄成功之后才可以進行請求，相比較登錄功能，數據接口的請求驗證方案要簡單很多。如下圖：
接口請求只需驗證sign以及token即可，如果token錯誤或者已過期，則返回客戶端重新登錄的標識。
總結
想在微信小程序中實現自己的用戶體系需要花費一些力氣，每個公司都有自身的用戶登錄驗證體系，同時還要考慮安全性和狀態保存問題。在小程序不支持cookie、http請求header不攜帶設備信息等限制下，實現登錄功能的各種細節都需要采用一些折中的手段。而且往往這些方案顯得有些臃腫并且難以維護，非常考驗開發者的抽象能力。
本篇文章闡述的是筆者團隊目前采用的登錄實現方案，并非最佳實踐，許多細節仍需打磨。希望可以給大家一些參考。
