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

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

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

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

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

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

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

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

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

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

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

那么這套方案在小程序平臺(tái)上是否可以復(fù)用呢？答案是否定的。

小程序的限制

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

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

但是我們?cè)谕虏坌〕绦蛑刂叵拗频耐瑫r(shí)得到了一個(gè)好消息：http請(qǐng)求可以自定義header。我們仿佛看到了解決問題的銀彈。

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

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

1. url query
2. http header

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

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

登錄實(shí)現(xiàn)方案

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

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

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

在小程序登錄機(jī)制的基礎(chǔ)上，我們團(tuán)隊(duì)在制定安全登錄功能時(shí)最終采用了如下方案：

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

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

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

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

數(shù)據(jù)接口的請(qǐng)求驗(yàn)證方案

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

接口請(qǐng)求只需驗(yàn)證sign以及token即可，如果token錯(cuò)誤或者已過期，則返回客戶端重新登錄的標(biāo)識(shí)。

總結(jié)

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

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