筆者由於工作需要，最近對國內外兩款知名的電商網站的使用者會話管理(User Session Management) 的實現機制做了一些調研，這裡把我學習到的一些知識分享給各位同行，希望起到拋磚引玉的作用。

我們首先看看大家日常生活中都會使用的某寶網站的使用者會話管理機制。

在電腦端訪問某寶網，輸入使用者名稱和密碼，點選登入：

![](https://img-blog.csdnimg.cn/img_convert/b68ddbbb285b97756994b453837fa24a.png)

會觀察到一個 HTTP Post 請求，login，傳送往後臺伺服器：

> https://login.taobao.com/newlogin/login.do?appName=taobao&fromSite=0

![](https://img-blog.csdnimg.cn/img_convert/1b669cc12e95f21c7f824b0b710ec576.png)

該請求的 Form Data 中包含 loginId 和 password2 兩個欄位，分別維護了使用者輸入的使用者名稱的明文，以及密碼進行 RSA 加密後的值。

下面介紹如何自行找到前端將使用者輸入的登入密碼進行 RSA 加密的準確位置。

在 Chrome 開發者工具裡找到 login 請求，在 Initiator 皮膚裡找到發起該請求的呼叫棧。稍有經驗的前端開發人員，從 onClick 和 t.loginSubmit 就能推斷出，使用者名稱和密碼的輸入框，實現在一個 Form 表單裡，點選登入按鈕後，觸發表單的 Submit.

![](https://img-blog.csdnimg.cn/img_convert/31111f43781b534258ce46e6fb8a922f.png)

開啟上圖找到的 index.js 檔案：
> https://x.alicdn.com/vip/havana-nlogin/0.5.61/index.js
直接搜尋關鍵字 password2，很快就能找到 RSA 加密的程式碼位置：

![](https://img-blog.csdnimg.cn/img_convert/4b441f8625e46165a7131a37934f9cdf.png)

設定斷點後，執行時點選登入按鈕，斷點觸發，可以進入 rsaPassword 函式，檢視 RSA 加密演算法的明細。

![](https://img-blog.csdnimg.cn/img_convert/abd97813ea153f6dd89972a8500e92f8.png)

這個 index.js 裡還能發現一些有趣的東西。比如提供了 rsaPassword 方法的模組內部，還維護了一個支援的國家列表，countryList，裡面有 168 個國家和地區：

![](https://img-blog.csdnimg.cn/img_convert/41df87204037ed14ce1ce63126d20b64.png)

但是在瀏覽器端開啟某寶網，國家和地區的下拉選單裡，只能看到十餘條記錄。這應該是前臺某處根據某種邏輯做了過濾：

![](https://img-blog.csdnimg.cn/img_convert/db7b7916f1f995e4fe116d234790f72e.png)

此外，我們在這個電商網站首頁右邊區域，能看到快速充值話費的皮膚，如下圖綠色高亮區域所示：

![](https://img-blog.csdnimg.cn/img_convert/04f50e8d9e011e2cafd62a7fb7426ea6.png)

該頁面的 HTML 原始碼，並不是靜態編寫於首頁的 HTML 檔案中，而是透過一個叫做 bianming-phone("便民"的拼音加上"手機"的英文單詞 phone) 的 HTTP 請求，從後臺讀取到前臺，然後再注入到前臺頁面中：

![](https://img-blog.csdnimg.cn/img_convert/2140de245db862dfd9b612e221fa9a85.png)

同理，還有這個旅行檢視片段(相當於 SAP UI5 裡的 View Fragment)：

![](https://img-blog.csdnimg.cn/img_convert/847baf8901dd076e345c73ca7d4ec470.png)

讀取該檢視片段的 HTTP 請求：bianming-trip

![](https://img-blog.csdnimg.cn/img_convert/90118f96c93405d34ffb56af3dddd860.png)

看到這裡，筆者不由得聯想起 SAP Commerce Cloud 前臺的 CMS 驅動設計，二者都是從電商頁面連線的後臺系統讀取部分頁面配置資訊，可謂異曲同工。

- SAP S/4HANA 的 UI 風格是 Fiori UX，實現的前端框架是 SAP UI5；
- SAP Commerce Cloud UI 實現的前端框架是 Angular；
- help.sap.com 採用 AngulaJS 實現，www.sap.com 使用的是 React.
- 某寶網首頁，採用的是阿里自研的前端框架，Kissy：

![](https://img-blog.csdnimg.cn/img_convert/79b7d7f82cc2574182dc893a9f1fcabe.png)
![](https://img-blog.csdnimg.cn/img_convert/0e158b7d330d826b966a893327282151.png)

我們在某寶網首頁看到琳琅滿目的商品圖片，都是被 Kissy 驅動，透過向 CDN 伺服器發起的資料請求而被載入的：

![](https://img-blog.csdnimg.cn/img_convert/b43d90a16490a51c6f56020964e6458f.png)

在這些頁面片段的原始碼裡還看到一些有意思的內容，比如這種“上線請刪除”的註釋。我現在瀏覽的就是上線後的程式碼呀，咋還能夠看到這些註釋 :)

![](https://img-blog.csdnimg.cn/img_convert/1c4278d3e3ee338e204af047339f0a52.png)

我們在電商網站上購物時，選擇好了自己心儀的商品，加入購物車之後，當然不希望點選結帳之後，忽然彈出要求重新登入的介面，這豈不是令人掃興。另外，當我們不小心誤操作，點選了瀏覽器重新整理按鈕，我們期望頁面重新整理後，仍然處於登入狀態，之前新增到購物車裡的商品不會丟失。這些都屬於使用者會話管理的範疇。

某寶網頁面的使用者會話管理，是透過客戶端 Cookie 和伺服器端維護的使用者會話物件來實現的。
使用者成功登入之後，伺服器建立對應的 Session 物件，返回給 login HTTP 請求的響應頭部，包含了很多 set-cookie 欄位：

![](https://img-blog.csdnimg.cn/img_convert/5ae2ae5fd0f68bec020763dc151b7d05.png)

瀏覽器解析這些響應，將伺服器頒發的 Cookie 設定到本地。下一次使用者再次操作電商網站，觸發新的發向伺服器端的請求時，瀏覽器會自動將這些 Cookie 欄位設定到請求頭部。伺服器接收到這些 Cookie 欄位，就能在記憶體中定位到之前該使用者登入後對應建立的 Session 物件，從而能夠識別出該使用者。

![](https://img-blog.csdnimg.cn/img_convert/6c981dd544b96bae29d14c3ad4d81a87.png)

這些 Cookie 在 Chrome 開發者工具裡也能檢視。
- Cookie 的 Expires 欄位存放的是過期時間，當 Expires 為 Session 時，意為該 Cookie 只在當前會話內有效，瀏覽器關閉則 Cookie 自動刪除。
- 帶有 Http Only 的 Cookie，無法被客戶端 JavaScript 程式碼讀取，提高了安全性，避免了 Cookie 透過 XSS 攻擊被竊取的可能。
- Secure 為 true 的 Cookie，無法透過 HTTP 協議傳輸到伺服器，只能透過 HTTPS 傳送。

![](https://img-blog.csdnimg.cn/img_convert/e9837bdbccd1eafe9b210fc0f297afab.png)

這個電商網站伺服器頒發的 Cookie 裡，欄位 lid 儲存的是使用者名稱經過 URL encode 之後的值，dnk 存放的是使用者名稱的 Unicode：

![](https://img-blog.csdnimg.cn/img_convert/a4b83c2a5af03c5018568a608ea7ccfb.png)
![](https://img-blog.csdnimg.cn/img_convert/7ac441c24569c950deddbf680525a6c6.png)

下面再看另一款來自國外的電商網站，SAP Commerce Cloud 的使用者會話管理機制的設計和實現。

SAP Commerce Cloud UI，基於 100% API 驅動的無頭電商架構，Commerce 後臺將 Commerce 核心業務透過 OCC(Omni Commerce Connect) API 的方式暴露出來。藉助這些 API 和開源的 SAP Spartacus 庫，客戶可以自行開發具備個性化 UX 的電商網站。

![](https://img-blog.csdnimg.cn/img_convert/31e1eb8676949b7e4f1b42993c568294.png)

SAP Commerce Cloud 有個名為 Oauth2 的 extension，基於 OAuth 2.0 協議實現了使用者認證和令牌頒發/功能,支援 OAuth 2.0 協議定義的包括 Resource Owner Password Flow 在內的全部四種認證流。

![](https://img-blog.csdnimg.cn/img_convert/222a5cb49d8c9df500828e180bd7cf41.png)

SAP Commerce Cloud UI 扮演了 OAuth 2.0 認證框架中的客戶端 (Client) 角色，透過消費 SAP Commerce Oauth2 擴充套件提供的 OAuth 系列 API，實現使用者會話管理。

讓我們從最初始的使用者登入場景說起。
輸入使用者名稱和密碼：

![](https://img-blog.csdnimg.cn/img_convert/05b4c21ac66089142276288cb4383144.png)

SAP Commerce Cloud UI 呼叫 Commerce OAuth2 API，endpoint 為 /authorizationserver/oauth/token, 將使用者名稱，密碼，client_id 和 client_secret 去換取訪問令牌(Access Token)和重新整理令牌(Refresh Token).

![](https://img-blog.csdnimg.cn/img_convert/2c299634bf8388d50cb7727787640579.png)

這裡的 SAP Commerce Cloud UI 作為 OAuth 認證體系裡的客戶端，其 client_id 和 client_secret 在 Commerce Backoffice 裡配置：

![](https://img-blog.csdnimg.cn/img_convert/9a103cf7aba2c52c5bb0bf203477bb24.png)

伺服器端驗證透過後，會頒發訪問令牌和重新整理令牌，如下圖 access_token 和 refresh_token 欄位所示：

![](https://img-blog.csdnimg.cn/img_convert/3dbeb6fa20d90e7d74c98ea8636e25c3.png)

SAP Commerce Cloud UI 在 OAuth 體系中扮演的角色是客戶端，透過訪問令牌，獲得訪問 Commerce 後臺伺服器上的業務資料的許可。而重新整理令牌，用於當訪問令牌過期時，由客戶端憑藉其換取新的訪問令牌。重新整理令牌本身是一個憑證，表明持有其的客戶端，曾經透過 OAuth 認證，獲得了訪問受保護資源的許可，當透過重新整理令牌再次請求新的訪問令牌時，客戶端不用再從頭開始走一遍 OAuth 認證的完整流程。

SAP Commerce Cloud 的訪問令牌和重新整理令牌都有過期時間，有時也稱為 TTL(Time-to-Live，存活時間)，預設值分別為12小時和30天。

![](https://img-blog.csdnimg.cn/img_convert/4ad22dac10d2a750ad5e9c1e16c1c2dd.png)

而我們團隊的開發人員，在開發 SAP Commerce Cloud UI 使用者會話管理功能，進行各種邊界條件的測試時，為了方便起見，通常將自己本地搭建的 Commerce 伺服器上令牌的過期時間進行了調整。比如下圖的例子，二者分別調整為30秒和60秒之後過期：

![](https://img-blog.csdnimg.cn/img_convert/d3f419c9f5c6ecda93af2209881fd08c.png)

訪問令牌獲取之後，在接下來 Commerce Cloud UI 消費後臺 OCC API 時，會將其附加在 HTTP 請求的頭部欄位裡：

![](https://img-blog.csdnimg.cn/img_convert/7694b3ad52f890364aa7583ba9ff59a6.png)

如果此時訪問令牌已經過期，則該請求會收到伺服器 401 錯誤的應答：

![](https://img-blog.csdnimg.cn/img_convert/168275ccd67806837466eed8fde9943c.png)

以及錯誤詳情 InvalidTokenError:Access token expired: IqQ-8cYzHV1gjQOpnYytHTFPt30

![](https://img-blog.csdnimg.cn/img_convert/e4ee872ae0bd115d37c954a3661fedc1.png)

顯然這種偏技術的錯誤訊息不應該顯示給使用者，幸運的是我們還有重新整理令牌。此時，SAP Commerce Cloud UI 會將過期的訪問令牌，連同重新整理令牌一齊傳送給 Commerce 後臺，申請一個新的訪問令牌：

![](https://img-blog.csdnimg.cn/img_convert/15e400a113fdd35e2ca0216fb599ca7b.png)

SAP Commerce Cloud UI 初次登入申請令牌時，grant_type 的值為 password；而訪問令牌過期，使用重新整理令牌重新申請時，grant_type 的值應該填充為 refresh_token.

如果重新整理令牌的過期時間也到達了，該怎麼辦？沒有重新整理令牌，也就無從獲取新的訪問令牌。因此，我們會將使用者重定向到登入頁面，顯示一條“Session expired”的提示資訊，讓其登入之後，重新獲取訪問令牌和重新整理令牌。

![](https://img-blog.csdnimg.cn/img_convert/12c9ac6c7dc4474d060faaf8fb9e070c.png)

本文前一章節，從某寶首頁登入說起曾經提到，我們在電商網站上購物，如果不小心重新整理了瀏覽器，只要客戶端儲存的 Cookie 尚未過期，就可仍然保持登入狀態。這樣，客戶重新整理之前的會話，比如新增商品到購物車，或者正在進行結帳的某一步，仍然處於有效狀態。

SAP Commerce Cloud UI 透過將訪問令牌持久化到瀏覽器的 Local Storage 中來實現上述場景。
每當使用者成功登入後，我們將 Commerce 後臺伺服器頒發的訪問令牌進行持久化儲存，儲存到瀏覽器 Local Storage 中。

![](https://img-blog.csdnimg.cn/img_convert/39a4bae282716d341e74ae79a88a9ab7.png)

每次 SAP Commerce Cloud UI 初始化時，透過 Angular APP_INITIALIZER 這個注入令牌，我們開發了 AuthStatePersistenceService 服務，將瀏覽器本地儲存中的令牌同步到記憶體中。

![](https://img-blog.csdnimg.cn/img_convert/c9fb0b7ab42067c296283ec453f767be.png)
![](https://img-blog.csdnimg.cn/img_convert/754be371994ec9b5f029fe65658a82b2.png)

採取這種設計後，即使使用者在購物過程中重新整理了瀏覽器，SAP Commerce Cloud UI 重新載入後，從 Local Storage 中取出訪問令牌同步到記憶體中，接下來的使用者操作，繼續使用該令牌呼叫 Commerce OCC API，不會因瀏覽器重新整理而中斷。

總結起來，SAP Commerce Cloud UI 有關訪問令牌和重新整理令牌的使用場景如下：

(1) 使用者登入後，SAP Commerce Cloud UI 將伺服器頒發的訪問令牌儲存於記憶體中，並持久化到瀏覽器 Local Storage.
對於重新整理令牌，出於安全性考慮，我們團隊實現時，僅將其維護在應用記憶體中，並不進行持久化操作。

(2) 當使用者操作 UI，觸發 API 呼叫後收到伺服器返回的訪問令牌過期的錯誤之後，SAP Commerce Cloud UI 自動利用重新整理令牌，申請新的訪問令牌；待拿到新的訪問令牌之後，使用該令牌重新呼叫之前因為舊的訪問令牌過期而失敗的 API；這一系列機制對於使用者來說完全透明，使用者在介面上的操作不會受到任何影響。

(3) 如果使用者操作觸發的 API 呼叫收到的伺服器返回為重新整理令牌過期，SAP Commerce Cloud UI 會暫存當前使用者瀏覽頁面的 URL，並將使用者重定向到登入頁面；使用者重新登入後，獲取到新的訪問令牌和重新整理令牌，再被 SAP Commerce Cloud 重定向到重新整理令牌過期時正在操作的頁面。

# 總結

本文選擇了國內外兩款最具代表性的電商購物網站，使用 Chrome 開發者工具進行探究，分析了這兩款電商網站使用者會話管理機制的設計原理，並從前端實現原始碼層面進行了剖析，分享了使用者會話管理的各種 Boundary Condition(邊界情況)下實現的注意事項。

淺談電商網站開發中使用者會話管理機制的設計和實現原理

相關文章