讓使用者登入，標識使用者和獲取使用者資訊，以使用者為核心提供服務，是大部分小程式都會做的事情。我們今天就來了解下在小程式中，如何做使用者登入，以及如何去維護這個登入後的會話（Session）狀態。

在微信小程式中，我們大致會涉及到以下三類登入方式：

• 自有的賬號註冊和登入；
• 使用其他第三方平臺賬號登入；
• 使用微信賬號登入（即直接使用當前已登入的微信賬號來作為小程式的使用者進行登入）。

第一和第二種方式是目前Web應用中最常見的兩種方式，在微信小程式中同樣可以使用，但是需要值的注意的是，小程式中沒有Cookie的機制，所以在使用這2種方式前，請確認你們或第三方的API是否需要依賴Cookie

我們今天主要來討論一下第三種方式，即如何使用微信賬號進行登入，因為這種方式和微信平臺結合最緊密，使用者體驗比較好。

登入流程

引用小程式官方文件的登入流程圖，整個登入流程基本如下圖所示：

該圖中，“小程式”指的就是我們使用小程式框架寫的程式碼部分，“第三方伺服器”一般就是我們自己的後臺服務程式，“微信伺服器”是微信官方的API伺服器。

下面我們來逐步分解一下這個流程圖。

步驟一：在客戶端獲取當前登入微信使用者的登入憑證(code)

在小程式中登入的第一步，就是先獲取登入憑證。我們可以使用wx.login()

我們可以在小程式的App程式碼中發起登入憑證請求，也可以在其他任何Page頁面程式碼中發起登入憑證請求，主要根據你小程式的實際需要。

步驟二：將登入憑證發往你的服務端，並在你的服務端使用該憑證向微信伺服器換取該微信使用者的唯一標識(openid)和會話金鑰(session_key)

首先，我們使用wx.request()方法，請求我們自己實現的一個後臺API，並將登入憑證（code）攜帶過去，例如在我們前面程式碼的基礎上增加：

你的後臺服務接著需要使用這個傳遞過來的登入憑證，去呼叫微信介面換取openid和session_key

我們先來介紹下openid，用過公眾號的童鞋應該對這個標識都不陌生了，在公眾平臺裡，用來標識每個使用者在訂閱號、服務號、小程式這三種不同應用的唯一標識，也就是說每個使用者在每個應用的openid都是不一致的，所以在小程式裡，我們可以用openid來標識使用者的唯一性。

那麼session_key是用來幹嘛的呢？有了使用者標識，我們就需要讓該使用者進行登入，那麼 session_key 就保證了當前使用者進行會話操作的有效性，這個session_key是微信服務端給我們派發的。也就是說，我們可以用這個標識來間接地維護我們小程式使用者的登入態，那麼這個session_key是怎麼拿到的呢？我們需要在自己的服務端請求微信提供的第三方介面 https://api.weixin.qq.com/sns/jscode2session

從這幾個引數，我們可以看出，要請求這個介面必須先呼叫wx.login()來獲取到使用者當前會話的code。那麼為什麼我們要在服務端來請求這個介面呢？其實是出於安全性的考量，如果我們在前端通過request呼叫此介面，就不可避免的需要將我們小程式的appid和小程式的secret暴露在外部，同時也將微信服務端下發的session_key暴露給“有心之人”，這就給我們的業務安全帶來極大的風險。除了需要在服務端進行session_key的獲取，我們還需要注意兩點：

• session_key和微信派發的code是一一對應的，同一code只能換取一次session_key。每次呼叫wx.login()，都會下發一個新的code和對應的session_key，為了保證使用者體驗和登入態的有效性，開發者需要清楚使用者需要重新登入時才去呼叫wx.login()
• session_key是有失效性的，即便是不呼叫wx.login，session_key也會過期，過期時間跟使用者使用小程式的頻率成正相關，但具體的時間長短開發者和使用者都是獲取不到的

步驟三：生成3rd_session

前面說過通過 session_key 來“間接”地維護登入態，所謂間接，也就是我們需要 自己維護使用者的登入態資訊 ，這裡也是考慮到安全性因素，如果直接使用微信服務端派發的session_key來作為業務方的登入態使用，會被“有心之人”用來獲取使用者的敏感資訊，比如wx.getUserInfo()這個介面呢，就需要session_key來配合解密微信使用者的敏感資訊。

那麼我們如果生成自己的登入態標識呢，這裡可以使用幾種常見的不可逆的雜湊演算法，比如md5、sha1等，將生成後的登入態標識（這裡我們統稱為'skey'）返回給前端，並在前端維護這份登入態標識(一般是存入storage)。而在服務端呢，我們會把生成的skey存在使用者對應的資料表中，前端通過傳遞skey來存取使用者的資訊。

步驟四：在客戶端儲存Session ID

開發Web應用的時候，在客戶端（瀏覽器）中，我們通常將Session ID存放在cookie中，但是小程式沒有cookie機制，所以不能採用cookie了，但是小程式有本地的storage，所以我們可以使用storage來儲存Session ID，以供後續的後臺API呼叫所使用。

在之後，呼叫那些需要登入後才有許可權訪問的後臺服務時，你可以將儲存在storage中的Session ID取出並攜帶在請求中（可以放在header中攜帶，也可以放在querystring中，或是放在body中，根據你自己的需要來使用），傳遞到後臺服務，後臺程式碼中獲取到該Session ID後，從redis中查詢是否有該Session ID存在，存在的話，即確認該session是有效的，繼續後續的程式碼執行，否則進行錯誤處理。

前面我們將skey存入前端的storage裡，每次進行使用者資料請求時會帶上skey，那麼如果此時session_key過期呢？所以我們需要呼叫到wx.checkSession()這個API來校驗當前session_key是否已經過期，這個API並不需要傳入任何有關session_key的資訊引數，而是微信小程式自己去調自己的服務來查詢使用者最近一次生成的session_key是否過期。如果當前session_key過期，就讓使用者來重新登入，更新session_key，並將最新的skey存入使用者資料表中。

步驟五：支援emoji表情儲存

如果需要將使用者微信名存入資料表中，那麼就確認資料表及資料列的編碼格式。因為使用者微信名可能會包含emoji圖示，而常用的UTF8編碼只支援1-3個位元組，emoji圖示剛好是4個位元組的編碼進行儲存。

這裡有兩種方式(以mysql為例)：

1.設定儲存字符集

在mysql5.5.3版本後，支援將資料庫及資料表和資料列的字符集設定為 utf8mb4 ，因此可在 /etc/my.cnf 設定預設字符集編碼及服務端編碼格式

[client]
default-character-set=utf8mb4
[mysql]
default-character-set=utf8mb4
[mysqld]
character-set-client-handshake = FALSE
character-set-server=utf8mb4
collation-server=utf8mb4_unicode_ci

設定完預設字符集編碼及服務端字符集編碼，如果是對已經存在的表和欄位進行編碼轉換，需要執行下面幾個步驟：

設定資料庫字符集為 utf8mb4

ALTER DATABASE 資料庫名稱 CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;

設定資料表字符集為 utf8mb4

ALTER TABLE 資料表名稱 CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

設定資料列欄位字符集為 utf8mb4

ALTER TABLE 資料表名稱 CHANGE 欄位列名稱 VARCHAR(n) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

這裡的 COLLATE 指的是排序字符集，也就是用來對儲存的字元進行排序和比較的， utf8mb4 常用的collation有兩種： utf8mb4_unicode_ci 和 utf8mb4_general_ci ，一般建議使用 utf8mb4_unicode_ci ，因為它是基於標準的 Unicode Collation Algorithm(UCA) 來排序的，可以在各種語言進行精確排序。這兩種排序方式的具體區別可以參考：What's the difference between utf8_general_ci and utf8_unicode_ci

2.通過使用sequelize對emoji字元進行編碼入庫，使用時再進行解碼

這裡是sequelize的配置，可參考Sequelize文件

{
 dialect: 'mysql',// 資料庫型別
 dialectOptions: { 
 charset: 'utf8mb4',collate: "utf8mb4_unicode_ci"
 },}

附：後臺程式碼（tp5）

到此這篇關於微信小程式使用者登入和登入態維護的實現的文章就介紹到這了,更多相關小程式使用者登入和登入態維護內容請搜尋我們以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援我們！