マイライブラリドキュメント

マルチルートサイドバー

flex-layout

  • Getting Started

  • Guides

  • Reference

typed-rx-http

  • Getting Started

  • Guides

  • Reference

global-rx-state

  • Getting Started

  • Guides

  • Reference

webflux-fe-dev-assistant

reactive-mongo-dsl

ヘッダー & セッション認証

認証がないプロジェクトではcreateHttpClientのみを使用し、必要な場合にのみHeaderStoreとセッション認証を付けます。


このページの commonService.ts コードは全体ファイルの一部です。

以下の HeaderStore、headersProvider、sessionAuth コードは、互いに独立したファイルの例ではなく、プロジェクト共通 HTTP アダプター (rxjsHttpService.ts/commonService.ts) の各部分を分けて説明するものです。全体ファイル構造を最初に見たい場合は、HTTP クライアントの最小完成形/拡張形全体コードを確認した後にこのページを読んでください。

ブラウザで共有するヘッダー

ログイン後に受け取ったアクセストークンのように複数のサービスが一緒に使用する必要があるヘッダーはHeaderStoreに保管できます。

commonService.ts
ts
Next.jsではブラウザとサーバーヘッダーを分ける

クライアントコンポーネントではHeaderStoreを読み取り、サーバーコンポーネントではクッキーを読み取るように headersProviderを作成できます。この関数ではCSRとSSRのヘッダー取得方法を一箇所で分離できます。

commonService.ts
ts
401リフレッシュが必要な場合はcallApiで一度ラップする

自動生成サービスを一つずつ修正せずに、共通callApiにセッションオペレーターを付けます。これによりすべての生成サービスが同じトークン取得とリフレッシュルールを使用します。

commonService.ts
ts

Authorizationがない場合はトークンエンドポイントを最初に確認し、元のリクエストが401の場合はリフレッシュ後にもう一度リクエストします。リフレッシュも失敗した場合はログアウトエンドポイントを呼び出し元のエラーを伝えます。

refresh/retry なしでトークン同期だけが必要な場合

401 refresh/retry を使用せず、リクエスト前にトークンだけを同期するには withEnsureToken() を使用します。

ts
認証が必要ない場合は
ts

公開APIや簡単なプロジェクトではこれで十分です。HeaderStoreとセッション認証は必須構造ではありません。

© 2026 Byeolnaerim. 無断転載を禁じます。紹介プライバシーポリシー