|
這是 Jerry 2021 年的第 51 篇文章,，也是汪子熙公眾號總共第 328 篇原創(chuàng)文章。 如無特殊說明,，本公眾號介紹的 SAP Commerce Cloud UI,，均指新一代基于 Spartacus 開源項目開發(fā)的 UI，而非傳統(tǒng)的基于 JSP 技術(shù),，同 Commerce 平臺耦合在一起的 Accelerator UI. 前文 從淘寶首頁登錄說起 提到過,，淘寶網(wǎng)的用戶會話管理，通過瀏覽器的 Cookie 和服務(wù)器端的用戶會話對象來實現(xiàn),。 而 SAP Commerce Cloud UI,，基于 100% API 驅(qū)動的無頭電商架構(gòu)，Commerce 后臺將 Commerce 核心業(yè)務(wù)通過 OCC(Omni Commerce Connect) API 的方式暴露出來,。借助這些 API 和開源的 SAP Spartacus 庫,，客戶可以自行開發(fā)具備個性化 UX 的電商網(wǎng)站。 關(guān)于 SAP Commerce Cloud Headless 架構(gòu)的更多介紹,，請參考我之前的文章：Jerry在2020 SAP全球技術(shù)大會的分享：SAP Spartacus技術(shù)介紹的文字版,。 SAP Commerce Cloud 有個名為 Oauth2 的 extension，基于 OAuth 2.0 協(xié)議實現(xiàn)了用戶認(rèn)證和令牌頒發(fā)/功能,支持 OAuth 2.0 協(xié)議定義的包括 Resource Owner Password Flow 在內(nèi)的全部四種認(rèn)證流,。 SAP Commerce Cloud UI 扮演了 OAuth 2.0 認(rèn)證框架中的客戶端 (Client) 角色,，通過消費 SAP Commerce Oauth2 擴展提供的 OAuth 系列 API，實現(xiàn)用戶會話管理,。 讓我們從最初始的用戶登錄場景說起,。 輸入用戶名和密碼： SAP Commerce Cloud UI 調(diào)用 Commerce OAuth2 API，endpoint 為 /authorizationserver/oauth/token, 將用戶名,，密碼,，client_id 和 client_secret 去換取訪問令牌(Access Token)和刷新令牌(Refresh Token). 這里的 SAP Commerce Cloud UI 作為 OAuth 認(rèn)證體系里的客戶端，其 client_id 和 client_secret 在 Commerce Backoffice 里配置： 服務(wù)器端驗證通過后,，會頒發(fā)訪問令牌和刷新令牌,，如下圖 access_token 和 refresh_token 字段所示： SAP Commerce Cloud UI 在 OAuth 體系中扮演的角色是客戶端，通過訪問令牌,，獲得訪問 Commerce 后臺服務(wù)器上的業(yè)務(wù)數(shù)據(jù)的許可,。而刷新令牌，用于當(dāng)訪問令牌過期時,，由客戶端憑借其換取新的訪問令牌,。刷新令牌本身是一個憑證，表明持有其的客戶端,，曾經(jīng)通過 OAuth 認(rèn)證,，獲得了訪問受保護資源的許可,，當(dāng)通過刷新令牌再次請求新的訪問令牌時，客戶端不用再從頭開始走一遍 OAuth 認(rèn)證的完整流程,。 SAP Commerce Cloud 的訪問令牌和刷新令牌都有過期時間,，有時也稱為 TTL(Time-to-Live，存活時間),，默認(rèn)值分別為12小時和30天,。 而我們團隊的開發(fā)人員，在開發(fā) SAP Commerce Cloud UI 用戶會話管理功能,，進行各種邊界條件的測試時,，為了方便起見，通常將自己本地搭建的 Commerce 服務(wù)器上令牌的過期時間進行了調(diào)整,。比如下圖的例子，二者分別調(diào)整為30秒和60秒之后過期： 訪問令牌獲取之后,，在接下來 Commerce Cloud UI 消費后臺 OCC API 時,，會將其附加在 HTTP 請求的頭部字段里： 如果此時訪問令牌已經(jīng)過期，則該請求會收到服務(wù)器 401 錯誤的應(yīng)答：
以及錯誤詳情 InvalidTokenError:Access token expired: IqQ-8cYzHV1gjQOpnYytHTFPt30
顯然這種偏技術(shù)的錯誤消息不應(yīng)該顯示給用戶,，幸運的是我們還有刷新令牌,。此時，SAP Commerce Cloud UI 會將過期的訪問令牌,，連同刷新令牌一齊發(fā)送給 Commerce 后臺,，申請一個新的訪問令牌：
SAP Commerce Cloud UI 初次登錄申請令牌時，grant_type 的值為 password,；而訪問令牌過期,，使用刷新令牌重新申請時，grant_type 的值應(yīng)該填充為 refresh_token. 如果刷新令牌的過期時間也到達了,，該怎么辦,？沒有刷新令牌，也就無從獲取新的訪問令牌,。因此,，我們會將用戶重定向到登錄頁面，顯示一條“Session expired”的提示信息,，讓其登錄之后,，重新獲取訪問令牌和刷新令牌。
前文 從淘寶首頁登錄說起 曾經(jīng)提到,，我們在淘寶網(wǎng)上購物,，如果不小心刷新了瀏覽器，只要客戶端存儲的 Cookie 尚未過期,，就可仍然保持登錄狀態(tài),。這樣,，客戶刷新之前的會話，比如添加商品到購物車,，或者正在進行結(jié)帳的某一步,，仍然處于有效狀態(tài)。 SAP Commerce Cloud UI 通過將訪問令牌持久化到瀏覽器的 Local Storage 中來實現(xiàn)上述場景,。 每當(dāng)用戶成功登錄后,，我們將 Commerce 后臺服務(wù)器頒發(fā)的訪問令牌進行持久化存儲，保存到瀏覽器 Local Storage 中,。
每次 SAP Commerce Cloud UI 初始化時,，通過 Angular APP_INITIALIZER 這個注入令牌，我們開發(fā)了 AuthStatePersistenceService 服務(wù),，將瀏覽器本地存儲中的令牌同步到內(nèi)存中,。
采取這種設(shè)計后，即使用戶在購物過程中刷新了瀏覽器,，SAP Commerce Cloud UI 重新加載后,，從 Local Storage 中取出訪問令牌同步到內(nèi)存中，接下來的用戶操作,，繼續(xù)使用該令牌調(diào)用 Commerce OCC API,，不會因瀏覽器刷新而中斷。 總結(jié)起來,，SAP Commerce Cloud UI 有關(guān)訪問令牌和刷新令牌的使用場景如下： (1) 用戶登錄后,，SAP Commerce Cloud UI 將服務(wù)器頒發(fā)的訪問令牌存儲于內(nèi)存中，并持久化到瀏覽器 Local Storage. 對于刷新令牌,，出于安全性考慮,，我們團隊實現(xiàn)時，僅將其維護在應(yīng)用內(nèi)存中,，并不進行持久化操作,。 (2) 當(dāng)用戶操作 UI，觸發(fā) API 調(diào)用后收到服務(wù)器返回的訪問令牌過期的錯誤之后,，SAP Commerce Cloud UI 自動利用刷新令牌,，申請新的訪問令牌；待拿到新的訪問令牌之后,，使用該令牌重新調(diào)用之前因為舊的訪問令牌過期而失敗的 API,；這一系列機制對于用戶來說完全透明，用戶在界面上的操作不會受到任何影響,。 (3) 如果用戶操作觸發(fā)的 API 調(diào)用收到的服務(wù)器返回為刷新令牌過期,，SAP Commerce Cloud UI 會暫存當(dāng)前用戶瀏覽頁面的 URL，并將用戶重定向到登錄頁面；用戶重新登錄后,，獲取到新的訪問令牌和刷新令牌,，再被 SAP Commerce Cloud 重定向到刷新令牌過期時正在操作的頁面。
本文簡單介紹了 SAP Commerce Cloud UI 用戶會話管理的基本實現(xiàn)原理和支持的場景,。對其技術(shù)實現(xiàn)感興趣的朋友,，可以查閱我們團隊發(fā)布在 Github 上的文檔，感謝閱讀,。 https://sap./spartacus-docs/session-management
更多閱讀 |
|
|
