這是 Jerry 2021 年的第 51 篇文章，也是汪子熙公眾號總共第 328 篇原創文章。

如無特殊說明，本公眾號介紹的 SAP Commerce Cloud UI，均指新一代基于 Spartacus 開源項目開發的 UI，而非傳統的基于 JSP 技術，同 Commerce 平臺耦合在一起的 Accelerator UI.

前文?從淘寶首頁登錄說起?提到過，淘寶網的用戶會話管理，通過瀏覽器的 Cookie 和服務器端的用戶會話對象來實現。

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

關于 SAP Commerce Cloud Headless 架構的更多介紹，請參考我之前的文章：Jerry在2020 SAP全球技術大會的分享：SAP Spartacus技術介紹的文字版。

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

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

讓我們從最初始的用戶登錄場景說起。

輸入用戶名和密碼：

SAP Commerce Cloud UI 調用 Commerce OAuth2 API，endpoint 為 /authorizationserver/oauth/token, 將用戶名，密碼，client_id 和 client_secret 去換取訪問令牌(Access Token)和刷新令牌(Refresh Token).

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

服務器端驗證通過后，會頒發訪問令牌和刷新令牌，如下圖 access_token 和 refresh_token 字段所示：

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

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

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

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

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

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

顯然這種偏技術的錯誤消息不應該顯示給用戶，幸運的是我們還有刷新令牌。此時，SAP Commerce Cloud UI 會將過期的訪問令牌，連同刷新令牌一齊發送給 Commerce 后臺，申請一個新的訪問令牌：

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

如果刷新令牌的過期時間也到達了，該怎么辦？沒有刷新令牌，也就無從獲取新的訪問令牌。因此，我們會將用戶重定向到登錄頁面，顯示一條“Session expired”的提示信息，讓其登錄之后，重新獲取訪問令牌和刷新令牌。

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

SAP Commerce Cloud UI 通過將訪問令牌持久化到瀏覽器的 Local Storage 中來實現上述場景。

每當用戶成功登錄后，我們將 Commerce 后臺服務器頒發的訪問令牌進行持久化存儲，保存到瀏覽器 Local Storage 中。

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

采取這種設計后，即使用戶在購物過程中刷新了瀏覽器，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 重定向到刷新令牌過期時正在操作的頁面。

本文簡單介紹了 SAP Commerce Cloud UI 用戶會話管理的基本實現原理和支持的場景。對其技術實現感興趣的朋友，可以查閱我們團隊發布在 Github 上的文檔，感謝閱讀。

https://sap.github.io/spartacus-docs/session-management

更多閱讀

• 從產品展示頁面談談Hybris的特有概念和設計結構

• 從產品展示頁面談談Hybris系列之二: DTO, Converter和Populator

• Hybris Enterprise Commerce Platform 服務層的設計與實現

• 從一個實際的例子出發，談談SAP Commerce Cloud電商云的UI自定義開發

• SAP Commerce Cloud (電商云) UI 的懶加載功能

• SAP CRM Fiori 應用和 SAP Commerce Cloud (電商云) UI 如何通過調整CSS來改變UI顯示風格

• SAP 產品一脈相承的 UI 增強思路，在 SAP Commerce Cloud (電商云) UI 增強實現中的體現

• Jerry在2020 SAP全球技術大會的分享：SAP Spartacus技術介紹的文字版

• 一小時內在本地搭建SAP Commerce Cloud(電商云)的前后臺運行環境

• SAP Commerce Cloud ( 電商云 ) 路由路徑的自定義配置與開發

更多Jerry的原創文章，盡在：“汪子熙”:

總結

以上是生活随笔為你收集整理的SAP Commerce Cloud UI 的用户会话管理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。