前幾篇文章的內容主要集中于小程序開發(fā)框架中的一些機制細節(jié)，基本上都是客戶端層面的知識。隨著小程序項目的不斷深入，我們不得不面對一些需要客戶端與服務端協(xié)同完成的需求，比如用戶登錄功能。

大多數(shù)的小程序都會有自身的用戶體系，然而小程序必須要經(jīng)過微信賬戶的驗證授權，然后再與第三方服務器（也就是公司自己的服務器）通信實現(xiàn)用戶的登錄。這里面就涉及到微信賬戶信息與自身用戶信息的耦合。下面就簡單介紹一下我們項目目前實現(xiàn)用戶登錄的技術細節(jié)。

瀏覽器環(huán)境下登錄的實現(xiàn)方案

在制定具體實現(xiàn)方案之前，我們首先思考一下用戶登錄功能需要注意哪些細節(jié)。通常來講，實現(xiàn)用戶登錄功能需要注意以下兩點：

1. 登錄狀態(tài)保存；
2. 安全驗證。

登錄狀態(tài)保存就是登錄成功后請求站內數(shù)據(jù)接口時無需再次登錄，客戶端與服務器按照既定的規(guī)則進行用戶有效性驗證。瀏覽器環(huán)境下的登錄狀態(tài)保存通常使用cookie實現(xiàn)，這種方案的實現(xiàn)原理是瀏覽器發(fā)出的http請求header中會攜帶客戶端的cookie。如下圖：

安全驗證是為了應對流量劫持，防止中間人攻擊，在我們的頁面中插入亂七八糟的內容。大家可能會想到使用https來防止流量劫持。https可以應對絕大部分的應用場景，有效的防止流量劫持。但其實市場上有一些“黑科技”軟件可以捕獲并且解密https加密信息的，比如Fiddler。所以在https的基礎上，再進行一層安全驗證是還有必要的。

大家可以參考這篇文章了解fiddler解密https的知識。

自定義安全驗證通常的方案是客戶端與服務器約定好一個驗證簽名，客戶端在發(fā)出http請求之前按照約定好的算法計算出一個簽名字符串，并且在http請求中將計算簽名的參數(shù)傳遞給服務器。服務器接收到請求之后，解析出簽名字符串和客戶端傳遞的計算參數(shù)，然后按照同樣的算法計算出簽名字符串，并將其與客戶端的簽名進行對比，完全一致則驗證通過，否則返回驗證未通過的數(shù)據(jù)。如下圖：

上述流程成立的前提條件是：

1. 瀏覽器可以獲取到UA信息；
2. 瀏覽器發(fā)出的http請求header中會攜帶UA信息，服務器可以獲取。

那么這套方案在小程序平臺上是否可以復用呢？答案是否定的。

小程序的限制

目前我們所知的小程序存在以下限制：

• 不支持cookie，所以使用cookie儲存登錄狀態(tài)的方案不可行；
• http請求header不攜帶設備信息，服務器無法獲取。

但是我們在吐槽小程序重重限制的同時得到了一個好消息：http請求可以自定義header。我們仿佛看到了解決問題的銀彈。

使用自定義header傳遞敏感信息

登錄識別信息在無法使用cookie傳遞的限制下只有兩種傳輸途徑：

1. url query
2. http header

小程序提供了獲取設備信息的API，提供了在客戶端計算簽名字符串的參數(shù)。按前文提到的驗證規(guī)則，客戶端計算簽名的參數(shù)必須傳遞給服務器才能保證兩端計算的一致性。所以我們又面臨了之前的抉擇，是query還是header？

其實使用任何一種途徑都可以完成需求，但是url query（通常稱為data）的語義應該是與接口功能緊密相關的數(shù)據(jù)，并且http請求的header比url query數(shù)據(jù)更保密，所以我們團隊最終采用header傳遞登錄識別信息和設備信息的方案。

登錄實現(xiàn)方案

確定信息的傳遞方式只是第一步，在小程序平臺下實現(xiàn)自己的用戶登錄仍然有很多細節(jié)需要琢磨。我們首先看一下官方文檔給出的第三方登錄流程圖：

官方文檔給出的流程是實現(xiàn)第三方登錄的基本流程，但是具體的登錄功能中仍然有一些細節(jié)上的不同，比如：

• 手機驗證碼登錄；
• 3rd_session和openId不能明文暴露給客戶端，需要進行加密；
• 登錄狀態(tài)保存的有效期；
• 用戶登錄的服務器與基礎服務的服務器并不是同一臺。

在小程序登錄機制的基礎上，我們團隊在制定安全登錄功能時最終采用了如下方案：

對比微信官方的登錄流程圖，有以下幾個細節(jié)：

1. 3rd_session和openId不直接暴露給客戶端，而是通過可逆的加密算法進行加密后，組合成token暴露給客戶端；
2. 第一次請求基礎功能服務器時并不驗證簽名，此次請求的目的是從微信服務器獲取3rd_session和openId并且加密后返回客戶端，以便后續(xù)請求使用；
3. 第二次請求的目標是用戶服務器，攜帶token的sign。用戶服務器首先會進行簽名驗證和手機驗證碼校驗；
4. 驗證通過后解析token獲取3rd_session和openId，然后與uid結合重新計算token。最后將uid和token一并返回給客戶端。

用戶登錄成功后，客戶端將uid和token儲存在本地，以便后續(xù)請求數(shù)據(jù)接口使用。

客戶端儲存token和uid的方式可以采用storage或者app.globalData。

數(shù)據(jù)接口的請求驗證方案

數(shù)據(jù)接口是在用戶登錄成功之后才可以進行請求，相比較登錄功能，數(shù)據(jù)接口的請求驗證方案要簡單很多。如下圖：

接口請求只需驗證sign以及token即可，如果token錯誤或者已過期，則返回客戶端重新登錄的標識。

總結

想在微信小程序中實現(xiàn)自己的用戶體系需要花費一些力氣，每個公司都有自身的用戶登錄驗證體系，同時還要考慮安全性和狀態(tài)保存問題。在小程序不支持cookie、http請求header不攜帶設備信息等限制下，實現(xiàn)登錄功能的各種細節(jié)都需要采用一些折中的手段。而且往往這些方案顯得有些臃腫并且難以維護，非常考驗開發(fā)者的抽象能力。

本篇文章闡述的是筆者團隊目前采用的登錄實現(xiàn)方案，并非最佳實踐，許多細節(jié)仍需打磨。希望可以給大家一些參考。