SAP Spartacus 的會話管理 Session Management

官網

從一開始，Spartacus 就包含了用戶端身份驗證和使用者身份驗證。 盡管這對于 Web 應用程式來說并不常見，但對于 Spartacus 來說是必須的，因為後者需要使用 OCC API。

用戶端身份驗證涉及代表已登出使用者工作的 endpoint，例如注冊、重置密碼、以訪客身份下訂單和驗證位址。這些 endpoint 需要随請求一起發送通路令牌，并且需要按照 OAuth 規範定義的用戶端憑據流來檢索此通路令牌。換句話說，某些 OCC 請求需要用戶端憑據流 - Client Credentials Flow，是以您需要在 OAuth 用戶端中啟用此流。

注意：在 OAuth 用戶端中啟用用戶端憑據流時，應始終将 ROLE_CLIENT 與 Spartacus OAuth 用戶端一起使用。永遠不要将 ROLE_TRUSTED_CLIENT 與 Spartacus 一起使用，因為它會顯着危害應用程式的安全性。

同時，使用者認證 - user authentication, 用于代表特定使用者資源發送的請求。例如，如果您想更新您的個人資料，您需要登入。當您登入時，伺服器會确認您的憑據 - credentials, 并向應用程式傳回通路令牌。然後，此令牌将用于您帳戶上的所有請求，例如更新您的個人資料、修改購物車和結帳。

在 Spartacus 3.0 之前，用戶端身份驗證和使用者身份驗證的代碼都在 AuthModule 中，其中包括混合在一起的攔截器、服務和外觀方法。在 Spartacus 3.0 中，AuthModule 仍然包含用戶端和使用者身份驗證，但現在這是導入 UserAuthModule 和 ClientAuthModule 兩個子產品的結果。每個子產品負責一種類型的身份驗證。

此更改很重要，因為 Spartacus 預設建構為支援 OCC，但 Spartacus 不限于使用 OCC。 OCC API 需要為其接收的某些請求提供用戶端憑據，但這對于其他 API 并不常見，是以，用戶端和使用者身份驗證已分離，以便更輕松地與其他 API 一起使用。例如，如果您使用不需要用戶端身份驗證的其他 API，則可以隻導入 UserAuthModule，而不是使用 AuthModule，并通過不包含 ClientAuthModule 來減小最終包的大小。

Authentication Flow

對使用者進行身份驗證是該子產品的主要職責。 先前版本的 Spartacus 使用自定義代碼來提供對資源所有者密碼流的支援，但 OAuth 指定了可在 Web 應用程式中使用的其他流。 為了支援這些額外的流程，Spartacus 3.0 不再将其自定義代碼用于資源所有者密碼流程，而是依賴于為此目的建構的第三方 angular-oauth2-oidc 庫，該庫也經過了良好的測試和認證。

身份驗證從 AuthService facade 開始，您可以在其中通過調用以下登入方法之一來初始化流程：

• Resource Owner Password Flow 的 loginWithCredentials
• loginWithRedirect 用于隐式流或授權代碼流 - Implicit Flow or the Authorization Code Flow

然後 login 方法與 angular-oauth2-oidc 庫互動。 但是，這種互動始終通過 OAuthLibWrapperService，這是一個用于将外部庫與 Spartacus 代碼隔離的層。

Storing Tokens and User Identifiers

身份驗證後，從庫方法收到的令牌需要存儲在某個地方。 以前，這些代币儲存在 NgRx Store 中，但在 Spartacus 3.0 中，有專門的服務來儲存資料。 該庫需要一個帶有類似于 localStorage 或 sessionStorage 的 API 的存儲機制，這是從 NgRx 切換到帶有流的服務來儲存資料的主要原因。

對于身份驗證，通常僅存儲令牌及其中繼資料（例如到期時間和範圍）就足夠了。 但是，對于 OCC，還需要在登入或登出後設定緊密耦合的使用者 ID，以及在使用輔助服務子產品 (ASM) 時進行使用者模拟所需的使用者 ID。 在 Spartacus 3.0 之前，使用者 ID 與 NgRx 中的令牌儲存在同一位置，并且由于之前的關聯，使用者 ID 仍保留在 UserAuthModule 中。 但是，令牌現在已與此子產品中的使用者辨別符分開。 令牌及其中繼資料現在與 AuthStorageService 一起存儲，而使用者 ID 則擁有自己的專用 UserIdService。

Access Tokens in API Calls and Error Recovery

登入使用者并存儲他們的通路令牌和使用者 ID 後，就可以請求使用者的一些資源。為此，有必要在請求中将通路令牌作為标頭傳遞。 在 Spartacus 中，這是通過 HTTP 攔截器實作的。

要使用通路令牌豐富請求，您無需以任何方式标記請求。 AuthInterceptor 根據 URL 識别對 API 的請求。如果請求沒有 Authorization 标頭，并且比對 API 路徑，則攔截器将标頭添加到請求中。為了更容易擴充攔截器，Spartacus 有自己的 AuthHttpHeaderService 幫助服務。在大多數情況下，擴充這一項服務就足夠了。

除了注入令牌之外，該攔截器還負責處理與授權相關的錯誤。在這種情況下，它首先嘗試恢複并重試請求，如果不可能，它完成登出過程并将使用者重定向到登入頁面。當請求因通路令牌過期而失敗時，攔截器使用重新整理令牌（如果存在）請求新的通路令牌，然後使用新令牌重試失敗的請求。

Persisting Authentication Data in the Browser Storage