セッションブリッジの概要

クライアントは、コントローラー、HTTP API、またはその両方を使用して B2C Commerce プラットフォームとやり取りできます。コントローラーと API は異なる認証と認可 (authnz) メソッドを使用するため、ハイブリッド実装ではさまざまな authnz メソッドを「ブリッジ」して、買い物客のログイン、ログアウト、その他の買い物客関連のイベントで同期を維持する必要があります。

このトピックでは、SCAPI/OCAPI と B2C Commerce コントローラーのハイブリッド実装を使用した「セッションブリッジ」のアプローチについて説明します。このアプローチは、PWA Kit またはその他のヘッドレス BFF (Backend For Frontend) を使用する場合のガイドとして使用できます。ハイブリッド実装 (SiteGenesis/SFRA および PWA Kit) を使用する場合に適用される追加のセッションブリッジ手順については、段階的なヘッドレスロールアウトを参照してください。この場合、セッションブリッジでは、SLAS JWT (SCAPI の場合) とセッションdwsid (B2C Commerce コントローラーの場合) を同期します。ブラウザーはいつでもコントローラーまたは API にリクエストを送信でき、同じ買い物客として認識される必要があります。

注: SLAS トークンはすべての SCAPI および OCAPI Shopper API で使用できますが、SCAPI の使用が推奨されます。

このページの一部のリンクにアクセスできるのは、既存のお客様のみです。Commerce Cloud リポジトリにアクセスする方法については Salesforce Commerce Cloud GitHub リポジトリとアクセスを参照してください。

このセクションでは、PWA Kit とプラグイン SLAS を使用したヘッドレス実装の authnz メソッドの概要を説明し、他のヘッドレス実装のガイドを提供します。PWA Kit は認証と認可に SCAPI を使用し、B2C Commerce コントローラーはプラグイン SLAS を使用します。詳細については、プラグイン SLAS および 段階的なヘッドレスロールアウトをを参照してください。

ヘッドレス実装に含めるコンポーネントの authnz メソッドを必ず理解してください。

SCAPI と B2C Commerce コントローラーの認証と認可メカニズムの概要:

クライアントアクセスアクセスメソッド有効期限リフレッシュトークン
SCAPISLAS アクセストークンを (JWT の形式で) 取得します:JWT アクセストークンは 30 分間有効です。最大 90 日間、SLAS によって提供されるリフレッシュトークンを使用して、新しいアクセストークンを取得できます。
コントローラーdw という接頭辞が付いた HTTP Cookie によって識別されるセッションを使用します。dwsid Cookie にはセッション ID が含まれており、サーバーがセッションを見つけるために使用されます。
  • セッションは 30 分間有効で、セッション中にコントローラーにリクエストが行われると、自動的に 30 分延長されます。リクエストがない状態が 30 分間続くと、セッションは期限切れになります。
  • 重要: セッションの有効期限が切れた後にリクエストを行うと、新しいセッションが開始されます。エラーは返されません
  • セッションは最大 6 時間まで延長でき、Business Manager で 管理 > サイト > サイトの管理 > サイト名 > 設定 > セッションタイムアウト に移動して、6 時間のセッションタイムアウト値を構成できます。
該当なし

買い物カゴの有効期間はセッションの有効期間とは異なり、別個に構成されます。詳細については、買い物カゴの環境設定の構成を参照してください。

セッションブリッジは、買い物客が最初にストアフロントにアクセスしたとき、その後買い物客がログインまたはログアウトしたとき、トークンやセッションの有効期限が切れたときなど、さまざまなライフサイクルイベントに対して実行する必要があります。

次のセクションで詳しく説明する呼び出しフローは、PWA Kit とプラグイン SLAS が使用するフローです。これらのフローの目的は、同じ買い物客を参照する JWT (SLAS アクセストークン) とdwsid (セッション) を取得して、それらのリクエストが API またはコントローラーのどちらからのものかに関係なく、後続のリクエストが同期されるようにすることです。

これらのフローは、これまでストアフロントを訪れたことがない新規買い物客を対象としています。必要な一連の呼び出しは、買い物客が最初にヘッドレス/PWA サイトと B2C Commerce (SFRA) サイトのどちらにアクセスしたかによって異なります。

リフレッシュトークンは、SLAS JWT とリフレッシュトークンを BFF に保持するなど、さまざまな方法で保存するか、クライアントに送り返すかを選択できます。このアプローチで説明するすべてのフローでは、買い物客に関連付けられている SLAS リフレッシュトークンが、サーバーと JavaScript の両方からアクセスできる Cookie に保存されていることを前提としています。

この例では PWA Kit を使用していますが、次のガイダンスはすべての BFF に適用されます。

  1. SLAS から JWT を取得します。パブリッククライアントとプライベートクライアントのどちらを使用しているかによって、フローは異なります。SLAS プライベートクライアントを使用する場合は、getAccessToken を呼び出すだけで済みます。
    1. SLAS authorizeCustomer (oauth2/authorize) を呼び出します
    2. SLAS getAccessToken (oauth2/token) を呼び出します
  2. これで、API へのアクセスに使用できる JWT と、新しい JWT の取得に使用できるリフレッシュトークンを含む SLAS トークンが作成されました。
  3. OCAPI Shop/sessions を呼び出します
  4. これで、JWT に関連付けられた dwsid を含む Cookie が作成されました。

SLAS アクセストークンとセッション ID があれば、API またはコントローラーを使用してリクエストを行うことができます。

次の画像は、ヘッドレスサイトにアクセスした新規買い物客のリクエストフローを示しています。

ヘッドレスサイトの新規買い物客

このフローでは、ブラウザーが B2C Commerce にリクエストを行うと、B2C Commerce は自動的にセッションを作成し、次の条件を満たすすべてのリクエストに対して dwsid を返します。

  • DWSID Cookie が含まれていない。
  • Cookie によって参照されるセッションの有効期限が切れているか、無効である。

プラグイン SLAS を使用するか、次の手順を手動で実行します。

  1. SLAS から JWT を取得します。パブリッククライアントとプライベートクライアントのどちらを使用しているかによって、フローは異なります。SLAS プライベートクライアントを使用する場合は、トークン呼び出しのみが必要で、認可呼び出しは必要ありません。
    1. SLAS authorizeCustomer (oauth2/authorize) を呼び出します
    2. SLAS getSessionBridgeAccessToken (oauth2/session-bridge/token) を呼び出します
  2. これで、API へのアクセスに使用できる JWT と、新しい JWT の取得に使用できるリフレッシュトークンを含む SLAS トークンが作成されました。

以下の画像は、B2C Commerce サイトにアクセスした新規買い物客のリクエストフローを示しています。

B2C Commerce サイトの新規買い物客

ゲストの再訪問と登録済み買い物客の再訪問のフローは同じですが、呼び出しの順序は、買い物客が最初にヘッドレスストアフロントと B2C Commerce のどちらにアクセスしたかによって異なります。

  1. SLAS リフレッシュトークンを使用して SLASgetAccessToken (oauth2/token?refresh_token=...) を呼び出します。
  2. OCAPI Shop/sessions を呼び出して、買い物客用の新しい DW Cookie を取得します。
    1. これで、API またはコントローラーを呼び出すためのアクセストークンとセッションの両方が得られました。リピート買い物客が再びログインしたことになります。

以下の画像は、ヘッドレスサイトでのリピート買い物客のリクエストフローを示しています。

ヘッドレスサイトでのリピート買い物客

ブラウザーの Cookie jar に送信用の dwsid がない場合、または送信した dwsid が無効または期限切れの場合 (セッションの最大有効期間は 6 時間)、B2C Commerce にリクエストが行われると新しいセッションが取得されるため、セッションブリッジを実行する必要があります。* * プラグイン SLAS を使用するか、次の手順を手動で実行します。

  1. リフレッシュトークンを使用して SLASgetAccessToken (oauth2/token?refresh_token=...) を呼び出します。
  2. OCAPI Shop/sessions を呼び出して、買い物客用の新しい DW Cookie を取得します。
  3. ページを再読み込みします。これにより、新しく取得したセッションを使用してページが強制的にレンダリングされます。

以下の画像は、B2C Commerce でのリピート買い物客のリクエストフローを示しています。

B2C Commerce サイトでのリピート買い物客

ゲスト買い物客がログインした場合、必要な呼び出しの順序は、買い物客がヘッドレスストアフロントと B2C Commerce のどちらにログインするかによって異なります。

ゲスト買い物客がヘッドレスストアフロントにログインすると、次のようになります。

  1. oauth2/authorize でログインするためのユーザーの認証情報を提供します。その時点で、ログインしている買い物客の JWT が設定されます。
  2. 現在の dwsid はゲストセッションを参照しているため、古くなっています。
    1. ログインした JWT で OCAPI Shop/sessions を呼び出し、ログインしている買い物客の dwsid を取得します。

ゲスト買い物客が B2C Commerce (SFRA) にログインすると、次のようになります。

  1. oauth2/authorize でログインするためのユーザーの認証情報を提供します。その時点で、ログインしている買い物客の JWT が設定されます。
  2. ログインした JWT で OCAPI Shop/sessions を呼び出し、ログインしている買い物客の dwsid を取得します。
  3. 買い物客にリダイレクトを返して、更新されたセッションでページが再表示されるようにします。

買い物客がストアフロントからログアウトした場合、必要な呼び出しの順序は、買い物客がヘッドレスストアフロントからログアウトするか、B2C Commerce からログアウトするかによって異なります。

買い物客がヘッドレスストアフロントからログアウトした場合は、次のようになります。

  1. 現在の JWT とリフレッシュトークンを破棄します。loguoutCustomer エンドポイントを使用して、顧客をログアウトできます。
  2. getAccessToken を使用して、新しいゲスト JWT を取得します。
  3. OCAPI Shop/sessions を呼び出します。

買い物客が B2C Commerce (SFRA) からログアウトした場合は、次のようになります。

  1. 既存のセッションは自動的にクリアされます。
  2. ただし、JWT はログインしたままです。getAccessToken を使用して、新しいゲスト JWT を取得します。

SLAS アクセストークンは、付与されてから 30 分間有効です。JWT をデコードし、exp フィールドで正確なタイムスタンプを確認できます。

30 分が経過すると、トークンを使用して API リクエストを行うことはできなくなります。有効期限が切れた JWT でリクエストを行うと、エラーがスローされます。

  1. リフレッシュトークンを使用して SLASgetAccessToken (oauth2/token?grant_type=refresh_token) を呼び出し、新しいトークンを取得します。
    1. 注: パブリッククライアントからのリフレッシュトークンは 1 回しか引き換えられませんが、プライベートクライアントからのリフレッシュトークンは数日間使用できます。
    2. prd インスタンスの場合、リフレッシュトークンは 90 日間有効です。その他のインスタンスでは、リフレッシュトークンは 9 日間有効です。正確な値は TokenResponse の refresh_token_expires_in プロパティで確認できます。
  • タイムアウトによりセッションの有効期限が切れた場合、B2C Commerce への次回の呼び出しで OnSession フックがトリガーされるため、これは再訪問者のシナリオと同じになります。
  • B2C Commerce (SFRA) のリピート買い物客