Azure Static Web Apps を構成する

[アーティクル]
03/11/2023

Azure Static Web Apps の構成は、次の設定を制御する staticwebapp.config.json ファイルで定義できます。

ルーティング
認証
承認
フォールバック規則
HTTP 応答のオーバーライド
グローバル HTTP ヘッダーの定義
カスタムの MIME の種類
ネットワーク

Note

ルーティングを構成するのに以前使用されていた routes.json は非推奨となっています。この記事の説明のとおりに staticwebapp.config.json を使用して、静的 Web アプリのルーティングやその他の設定を構成してください。

このドキュメントでは、スタンドアロン製品であり、Azure Storage の静的 Web サイトホスティング機能とは別の、Azure Static Web Apps を構成する方法について説明します。

ファイルの場所

staticwebapp.config.json の推奨される場所は、ワークフローファイルで app_location として設定されたフォルダー内です。しかし、app_location として設定されたフォルダー内の任意のサブフォルダーにファイルを配置できます。さらに、ビルドステップがある場合は、ビルドステップによってファイルが output_location のルートに出力されることを確かめる必要があります。

詳細については、「構成ファイルの例」を参照してください。

重要

staticwebapp.config.json がある場合、非推奨の routers.json ファイルは無視されます。

Routes

静的 web アプリ内の1つ以上のルートに対して規則を定義できます。ルートルールを使用すると、特定のロールのユーザーへのアクセスを制限したり、リダイレクトや書き換えなどのアクションを実行したりできます。ルートは、ルーティング規則の配列として定義します。使用例については、「構成ファイルの例」を参照してください。

規則は、ルートが 1 つしかない場合でも routes 配列で定義します。
規則は、routes 配列に出現する順序で評価されます。
最初に一致した時点で、規則の評価は停止します。一致は、 route プロパティと配列内の値 methods (指定されている場合) が要求と一致した場合に発生します。各要求は、1つのルールに一致することができます。

ルーティングの懸念事項は、認証 (ユーザーの識別) および承認 (ユーザーへの機能の割り当て) の概念とかなり重複しています。この記事と共に、認証と承認に関するガイドをお読みください。

ルートの定義

各規則は、ルートパターンと、1 つまたは複数のオプションの規則プロパティで構成されます。ルート規則は routes 配列で定義します。使用例については、「構成ファイルの例」を参照してください。

重要

ルールが要求と一致するかどうかを判断するために、routeおよび methods(指定されている場合) プロパティのみが使用されます。

規則のプロパティ	必須	規定値	Comment
`route`	はい	該当なし	呼び出し元によって要求されるルートパターン。ルートパスの末尾には、ワイルドカードを使用できます。たとえば、ルート /admin* は、/admin で始まるすべてのルートと一致します。
`methods`	いいえ	すべてのメソッド	ルートに一致する要求メソッドの配列を定義します。使用可能なメソッドには、`GET`、`HEAD`、`POST`、`PUT`、`DELETE`、`CONNECT`、`OPTIONS`、`TRACE`、`PATCH` があります。
`rewrite`	いいえ	該当なし	要求から返されるファイルまたはパスを定義します。 `redirect` 規則に対して相互に排他的です。書き換え規則では、ブラウザーの場所は変更されません。値は、アプリのルートを基準にする必要があります
`redirect`	いいえ	該当なし	要求のファイルまたはパスのリダイレクト先を定義します。 `rewrite` 規則に対して相互に排他的です。リダイレクト規則では、ブラウザーの場所が変更されます。既定の応答コードは `302` (一時的なリダイレクト) ですが、`301` (永続的なリダイレクト) でオーバーライドできます。
`statusCode`	いいえ	`301`または`302`リダイレクトの場合	応答の HTTP 状態コード。
`headers`	いいえ	該当なし	応答に追加される HTTP ヘッダーのセット。ルート固有のヘッダーが応答内のグローバルヘッダーと同じ場合、`globalHeaders` はルート固有のヘッダーによってオーバーライドされます。ヘッダーを削除するには、値を空の文字列に設定します。
`allowedRoles`	いいえ	anonymous	ルートにアクセスするために必要なロール名の配列を定義します。有効な文字は、`a-z`、`A-Z`、`0-9`、`_` です。組み込みのロールは、 `anonymous`、すべてのユーザーに適用されます。組み込みロール `authenticated` は、ログインしている任意のユーザーに適用されます。ユーザーは、少なくとも 1 つのロールに属している必要があります。ロールは、OR に基づいて照合されます。ユーザーが一覧にあるいずれかのロールに属している場合は、アクセス権が付与されます。個々のユーザーは、招待によってロールに関連付けられます。

各プロパティは、要求または応答パイプラインで特定の目的があります。

目的	プロパティ
ルートと一致させる	`route`、`methods`
規則が一致して承認された後に処理する	`rewrite` (要求を変更する) `redirect`、`headers`、`statusCode` (応答を変更する)
ルートが一致した後に承認する	`allowedRoles`

ルートパターンを指定する

routeプロパティは、正確なルートまたはワイルドカードパターンにすることができます。

正確なルート

正確なルートを定義するには、ファイルの完全なパスをrouteプロパティに配置します。

{
  "route": "/profile/index.html",
  "allowedRoles": ["authenticated"]
}

このルールは、ファイル/ /profile/index.htmlの要求と一致します。 index.htmlが既定のファイルであるため、このルールはフォルダー (/profileまたは/profile/) の要求とも一致します。

重要

routeプロパティでフォルダーパス (/profileまたは/profile/) を使用する場合は、ファイル/ /profile/index.htmlの要求と一致しません。ファイルを提供するルートを保護する場合は、ファイルの完全なパス (/profile/index.htmlなど) を常に使用します。

ワイルドカードパターン

ワイルドカード規則はルートパターン内のすべての要求と一致し、パスの末尾でのみサポートされます。使用例については、「構成ファイルの例」を参照してください。

たとえば、カレンダーアプリケーションに対するルートを実装するには、1 つのファイルを提供するように、calendar ルートに該当するすべての URL を書き換えることができます。

{
  "route": "/calendar*",
  "rewrite": "/calendar.html"
}

その場合、calendar.html ファイルでは、クライアント側ルーティングを使用して、/calendar/january/1、/calendar/2020、/calendar/overview などの URL のバリエーションに対して異なるビューを提供できます。

Note

/calendar/*のルートパターンは、 /calendar/パスの下にあるすべての要求と一致します。ただし、パス /calendar または /calendar.html の要求とは一致しません。 /calendarで始まるすべての要求を照合するには、/calendar*を使用します。

ワイルドカードの一致をファイル拡張子でフィルター処理できます。たとえば、指定したパスの HTML ファイルのみに一致する規則を追加する場合は、次の規則を作成できます。

{
  "route": "/articles/*.html",
  "headers": {
    "Cache-Control": "public, max-age=604800, immutable"
  }
}

複数のファイル拡張子に基づいてフィルター処理するには、この例に示すように、オプションを中かっこで囲みます。

{
  "route": "/images/thumbnails/*.{png,jpg,gif}",
  "headers": {
    "Cache-Control": "public, max-age=604800, immutable"
  }
}

ワイルドカードルートの一般的なユースケースには、以下が含まれます。

パスパターン全体に対して特定のファイルを提供する
認証と承認の規則を適用する
特殊なキャッシュ規則を実装する

ロールを使用してルートをセキュリティで保護する

ルートをセキュリティで保護するには、1 つまたは複数のロール名を規則の allowedRoles 配列に追加します。使用例については、「構成ファイルの例」を参照してください。

重要

ルーティング規則では、HTTP 要求をセキュリティで保護できるのは、クライアントから提供されるルートStatic Web Appsのみです。多くのフロントエンドフレームワークでは、Static Web Appsへの要求を発行せずに、ブラウザ上でルートを変更するクライアント側のルーティングを採用しています。ルーティング規則では、クライアント側のルートはセキュリティで保護されません。クライアントは、機密データを取得するために HTTP API を呼び出す必要があります。 API がデータを返す前に、ユーザーのID を検証します。

既定では、すべてのユーザーが組み込みの anonymous ロールに属し、ログインしているすべてのユーザーが authenticated ロールのメンバーになります。必要に応じて、状態を介してユーザーをカスタムロールに関連付けることができます。

たとえば、認証されたユーザーのみにルートを制限するには、組み込みの authenticated ロールを allowedRoles 配列に追加します。

{
  "route": "/profile*",
  "allowedRoles": ["authenticated"]
}

必要に応じて、allowedRoles 配列に新しいロールを作成できます。ルートを管理者のみに制限するには、allowedRoles 配列に administrator という名前の独自のロールを定義できます。

{
  "route": "/admin*",
  "allowedRoles": ["administrator"]
}

ロールの名前は完全に制御できます。ロールが従う必要のあるリストはありません。
個々のユーザーは、招待によってロールに関連付けられます。

重要

コンテンツをセキュリティで保護する場合は、可能な限り正確なファイルを指定します。保護するファイルが多数ある場合は、共有プレフィックスの後にワイルドカードを使用します。例：/profile を含む、 /profileで始まる可能性のあるすべてのルートをセキュリティで保護します。

アプリケーション全体へのアクセスを制限する

多くの場合、アプリケーション内のすべてのルートに対して認証を要求する必要があります。ルートをロックするには、すべてのルートに一致する規則を追加し、組み込みの authenticated ロールを allowedRoles 配列に含めます。

次の構成例では匿名アクセスをブロックし、認証済みでないすべてのユーザーを Microsoft Entra のサインインページにリダイレクトします。

{
  "routes": [
    {
      "route": "/*",
      "allowedRoles": ["authenticated"]
    }
  ],
  "responseOverrides": {
    "401": {
      "statusCode": 302,
      "redirect": "/.auth/login/aad"
    }
  }
}

Note

既定では、構成済みのすべての ID プロバイダーが有効になっています。認証プロバイダーをブロックするには、認証と承認に関するページを参照してください。

フォールバックルート

シングルページアプリケーションは、多くの場合、クライアント側のルーティングに依存します。これらのクライアント側ルーティング規則では、要求をサーバーに返さずに、ブラウザーのウィンドウの場所が更新されます。ページを更新する場合、またはクライアント側ルーティング規則によって生成された URL に直接移動する場合は、適切な HTML ページを提供するために、サーバー側フォールバックルートが必要です。フォールバックページは、多くの場合、クライアント側アプリの index.html として指定されます。

navigationFallback セクションを追加して、フォールバックルールを定義できます。次の例は、デプロイされたファイルに一致しないすべての静的ファイルの要求に対して /index.html を返します。

{
  "navigationFallback": {
    "rewrite": "/index.html"
  }
}

フィルターを定義すると、どの要求でフォールバックファイルを返すかを制御できます。次の例では、/images フォルダーの特定のルートと /css フォルダーのすべてのファイルに対する要求が、フォールバックファイルを返す対象から除外されます。

{
  "navigationFallback": {
    "rewrite": "/index.html",
    "exclude": ["/images/*.{png,jpg,gif}", "/css/*"]
  }
}

たとえば、次のディレクトリ構造では、上記のナビゲーションフォールバック規則によって、次の表で詳しく説明した結果が得られます。

├── images
│   ├── logo.png
│   ├── headshot.jpg
│   └── screenshot.gif
│
├── css
│   └── global.css
│
└── index.html

要求先	返されるもの	状態
/about/	index.html ファイル。	`200`
/images/logo.png	画像ファイル。	`200`
/images/icon.svg	/index.html ファイル (svg ファイル拡張子が `/images/*.{png,jpg,gif}` フィルターに含まれていないため)。	`200`
/images/unknown.png	"ファイルが見つかりませんでした" エラー。	`404`
/css/unknown.css	"ファイルが見つかりませんでした" エラー。	`404`
/css/global.css	スタイルシートファイル。	`200`
/images または /css フォルダー外にあるその他のファイル	index.html ファイル。	`200`

重要

非推奨の routes.json ファイルから移行する場合は、routing rules にレガシフォールバックルート ("route": "/*") を含めないでください。

グローバルヘッダー

globalHeaders セクションでは、ルートヘッダー規則によってオーバーライドされない限り、各応答に適用される一連の HTTP ヘッダーが提供されます。それ以外の場合は、ルートからのヘッダーとグローバルヘッダーの両方の和集合が返されます。

使用例については、「構成ファイルの例」を参照してください。

ヘッダーを削除するには、値を空の文字列 ("") に設定します。

グローバルヘッダーの一般的なユースケースには、以下が含まれます。

カスタムキャッシュルール
セキュリティポリシー
エンコードの設定
クロスオリジンリソース共有 (CORS) の構成

次の例では、カスタム CORS 構成を実装します。

{
  "globalHeaders": {
    "Access-Control-Allow-Origin": "https://example.com",
    "Access-Control-Allow-Methods": "POST, GET, OPTIONS"
  }
}

Note

グローバルヘッダーは、API の応答には影響を与えません。 API 応答内のヘッダーは、保持されて、クライアントに返されます。

応答のオーバーライド

responseOverrides セクションでは、サーバーからエラーコードが返される場合のカスタム応答を定義できます。使用例については、「構成ファイルの例」を参照してください。

次の HTTP コードをオーバーライドできます。

状態コード	意味	考えられる原因
400	Bad request	無効な招待リンク
401	権限がありません	認証されていない状態での制限されたページへの要求
403	許可されていません	ユーザーはログインしているが、ページを表示するために必要なロールがない。ユーザーはログインしていますが、ランタイムが ID 要求からユーザーの詳細を取得できません。カスタムロールを使用してサイトにログインしているユーザーが多すぎるため、ランタイムでユーザーをサインインさせることができません。
404	見つかりません	ファイルが見つかりません

次の構成例は、エラーコードをオーバーライドする方法を示しています。

{
  "responseOverrides": {
    "400": {
      "rewrite": "/invalid-invitation-error.html"
    },
    "401": {
      "statusCode": 302,
      "redirect": "/login"
    },
    "403": {
      "rewrite": "/custom-forbidden-page.html"
    },
    "404": {
      "rewrite": "/custom-404.html"
    }
  }
}

プラットフォーム

platform セクションでは、API 言語ランタイムのバージョンなど、プラットフォーム固有の設定を制御します。

API 言語ランタイムのバージョンの選択

API 言語ランタイムのバージョンを構成するには、platform セクションの apiRuntime プロパティを、サポートされている次の値のいずれかに設定します。

言語ランタイムのバージョン	オペレーティングシステム	Azure Functions バージョン	`apiRuntime` 値	サポート終了日
.NET Core 3.1	Windows	3.x	`dotnet:3.1`	2022 年 12 月 3 日
.NET 6.0 インプロセス	Windows	4.x	`dotnet:6.0`	-
.NET 6.0 分離	Windows	4.x	`dotnet-isolated:6.0`	-
.NET 7.0 isolated	Windows	4.x	`dotnet-isolated:7.0`	-
.NET 8.0 分離	Windows	4.x	`dotnet-isolated:8.0`	-
Node.js 12.x	Linux	3.x	`node:12`	2022 年 12 月 3 日
Node.js 14.x	Linux	4.x	`node:14`	-
Node.js 16.x	Linux	4.x	`node:16`	-
Node.js 18.x (パブリックプレビュー)	Linux	4.x	`node:18`	-
Python 3.8	Linux	4.x	`python:3.8`	-
Python 3.9	Linux	4.x	`python:3.9`	-
Python 3.10	Linux	4.x	`python:3.10`	-

.NET

.NET アプリのランタイムバージョンを変更するには、csproj ファイルの TargetFramework 値を変更します。省略可能ですが、staticwebapp.config.json ファイルに apiRuntime 値を設定する場合は、その値が csproj ファイルで定義したものと一致するようにしてください。

次の例では、csproj ファイルの TargetFramework 要素を更新して、API 言語ランタイムバージョンとして NET 8.0 を設定する方法を示します。

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    ...
  </PropertyGroup>
...

Node.js

次の構成例では、apiRuntime プロパティを使用して、staticwebapp.config.json ファイルの API 言語ランタイムバージョンとして Node.js 16 を選択する方法を示します。

{
  ...
  "platform": {
    "apiRuntime": "node:16"
  }
  ...
}

Python

次の構成例では、apiRuntime プロパティを使用して、staticwebapp.config.json ファイルの API 言語ランタイムバージョンとして Python 3.8 を選択する方法を示します。

{
  ...
  "platform": {
    "apiRuntime": "python:3.8"
  }
  ...
}

ネットワーク

networking セクションは、静的 Web アプリのネットワーク構成を制御します。アプリへのアクセスを制限するには、allowedIpRanges で許可される IP アドレスブロックの一覧を指定します。許可される IP アドレスブロックの数に関する詳細については、「Azure Static Web Apps のクォータ」を参照してください。

Note

ネットワーク構成は、Azure Static Web Apps Standard プランでのみ使用できます。

クラスレスドメイン間ルーティング (CIDR) 表記で IPv4 アドレスブロックを定義します。 CIDR 表記の詳細については、「クラスレスドメイン間ルーティング」を参照してください。各 IPv4 アドレスブロックは、パブリックアドレス空間またはプライベートアドレス空間を表します。 1 つの IP アドレスからのアクセスのみを許可したい場合は、/32CIDR ブロックを使用できます。

{
  "networking": {
    "allowedIpRanges": [
      "10.0.0.0/24",
      "100.0.0.0/32",
      "192.168.100.0/22"
    ]
  }
}

1 つ以上の IP アドレスブロックが指定されている場合、allowedIpRanges の値と一致しない IP アドレスからの要求はアクセスを拒否されます。

IP アドレスブロックに加えて、allowedIpRanges 配列でサービスタグを指定して、特定の Azure サービスにトラフィックを制限することもできます。

"networking": {
  "allowedIpRanges": ["AzureFrontDoor.Backend"]
}

認証

既定の認証プロバイダーには、構成ファイル内の設定が必要ありません。
カスタム認証プロバイダーでは、設定ファイルの auth セクションが使用されます。

認証されたユーザーにルートを制限する方法の詳細については、「ロールを使用したルートのセキュリティ保護」を参照してください。

認証されたパスのキャッシュを無効にする

Azure Front Door との手動統合を設定している場合は、セキュリティで保護されたルートのキャッシュを無効にすることをお勧めします。エンタープライズレベルエッジが有効になっていると、セキュリティで保護されたルートのキャッシュは既に無効になっています。

セキュリティで保護されたルートに対する Azure Front Door のキャッシュを無効にするには、ルートヘッダーの定義に "Cache-Control": "no-store" を追加します。

次に例を示します。

{
    "route": "/members",
    "allowedRoles": ["authenticated, members"],
    "headers": {
        "Cache-Control": "no-store"
    }
}

転送ゲートウェイ

forwardingGateway セクションでは、Content Delivery Network (CDN) や Azure Front Door などの転送ゲートウェイから静的 Web アプリにアクセスする方法を構成します。

Note

転送ゲートウェイの構成は、Azure Static Web Apps Standard プランでのみ使用できます。

許可された転送先ホスト

allowedForwardedHosts リストでは、X-Forwarded-Host ヘッダーで受け入れるホスト名を指定します。一致するドメインがリストにある場合は、サインインが成功した後などのリダイレクト URL の作成時に Static Web Apps が X-Forwarded-Host の値を使用します。

転送ゲートウェイの内側にある Static Web Apps が正しく機能するには、ゲートウェイからの要求の X-Forwarded-Host ヘッダーに正しいホスト名が含まれ、同じホスト名が allowedForwardedHosts のリストに存在する必要があります。

"forwardingGateway": {
  "allowedForwardedHosts": [
    "example.org",
    "www.example.org",
    "staging.example.org"
  ]
}

X-Forwarded-Host ヘッダーがリストの値と一致しない場合でも、要求は成功しますが、ヘッダーは応答で使用されません。

必須ヘッダー

必須ヘッダーは、サイトへの要求ごとに送信される必要のある HTTP ヘッダーです。必須ヘッダーの用途の 1 つは、すべての必須ヘッダーが各要求に存在しない場合、サイトへのアクセスを拒否することです。

たとえば、次の構成は、サイトへのアクセスを特定の Azure Front Door インスタンスに制限する Azure Front Door 用の一意の識別子を追加する方法を示したものです。詳細については、Azure Front Door の構成に関するチュートリアルの記事を参照してください。

"forwardingGateway": {
  "requiredHeaders": {
    "X-Azure-FDID" : "692a448c-2b5d-4e4d-9fcc-2bc4a6e2335f"
  }
}

キーと値のペアは、どのような文字列のセットでもかまいません
キーは、大文字と小文字が区別されません
値は、大文字と小文字が区別されます

末尾のスラッシュ

末尾のスラッシュは、URL の最後の / です。従来、末尾のスラッシュ付き URL は Web サーバー上のディレクトリを指し、末尾のスラッシュなしのものはファイルを示します。

検索エンジンは、ファイルかディレクトリかに関係なく、2 つの URL を個別に扱います。これらの両方の URL で同じコンテンツがレンダリングされると、Web サイトは重複するコンテンツを提供するため、検索エンジンの最適化 (SEO) に悪影響を与えることがあります。明示的に構成されている場合、Azure Static Web Apps は、Web サイトのパフォーマンスと SEO の向上に役立つ一連の URL 正規化とリダイレクトルールを適用します。

使用可能な構成ごとに、次の正規化とリダイレクトルールが適用されます。

常時

trailingSlash を always に設定すると、末尾のスラッシュを含まないすべての要求が末尾のスラッシュ付き URL にリダイレクトされます。たとえば、/contact は /contact/ にリダイレクトされます。

"trailingSlash": "always"

要求先	返されるもの	状態	パス
/about	/about/index.html ファイル	`301`	/about/
/about/	/about/index.html ファイル	`200`	/about/
/about/index.html	/about/index.html ファイル	`301`	/about/
/contact	/contact.html ファイル	`301`	/contact/
/contact/	/contact.html ファイル	`200`	/contact/
/contact.html	/contact.html ファイル	`301`	/contact/

なし

trailingSlash を never に設定すると、末尾のスラッシュ付きのすべての要求が末尾のスラッシュなしの URL にリダイレクトされます。たとえば、/contact/ は /contact にリダイレクトされます。

"trailingSlash": "never"

要求先	返されるもの	状態	パス
/about	/about/index.html ファイル	`200`	/about
/about/	/about/index.html ファイル	`301`	/about
/about/index.html	/about/index.html ファイル	`301`	/about
/contact	/contact.html ファイル	`200`	/contact
/contact/	/contact.html ファイル	`301`	/contact
/contact.html	/contact.html ファイル	`301`	/contact

Auto

trailingSlash を auto に設定すると、フォルダーへのすべての要求が末尾のスラッシュを含む URL にリダイレクトされます。ファイルに対するすべての要求は、末尾のスラッシュなしの URL にリダイレクトされます。

"trailingSlash": "auto"

要求先	返されるもの	状態	パス
/about	/about/index.html ファイル	`301`	/about/
/about/	/about/index.html ファイル	`200`	/about/
/about/index.html	/about/index.html ファイル	`301`	/about/
/contact	/contact.html ファイル	`200`	/contact
/contact/	/contact.html ファイル	`301`	/contact
/contact.html	/contact.html ファイル	`301`	/contact

Web サイトのパフォーマンスを最適にするには、always、never、auto のいずれかのモードを使用して末尾のスラッシュの戦略を設定します。

既定では、trailingSlash の設定を省略すると、Azure Static Web Apps は次の規則を適用します。

要求先	返されるもの	状態	パス
/about	/about/index.html ファイル	`200`	/about
/about/	/about/index.html ファイル	`200`	/about/
/about/index.html	/about/index.html ファイル	`200`	/about/index.html
/contact	/contact.html ファイル	`200`	/contact
/contact/	/contact.html ファイル	`301`	/contact
/contact.html	/contact.html ファイル	`200`	/contact.html

構成ファイルの例

{
  "trailingSlash": "auto",
  "routes": [
    {
      "route": "/profile*",
      "allowedRoles": ["authenticated"]
    },
    {
      "route": "/admin/index.html",
      "allowedRoles": ["administrator"]
    },
    {
      "route": "/images/*",
      "headers": {
        "cache-control": "must-revalidate, max-age=15770000"
      }
    },
    {
      "route": "/api/*",
      "methods": ["GET"],
      "allowedRoles": ["registeredusers"]
    },
    {
      "route": "/api/*",
      "methods": ["PUT", "POST", "PATCH", "DELETE"],
      "allowedRoles": ["administrator"]
    },
    {
      "route": "/api/*",
      "allowedRoles": ["authenticated"]
    },
    {
      "route": "/customers/contoso*",
      "allowedRoles": ["administrator", "customers_contoso"]
    },
    {
      "route": "/login",
      "rewrite": "/.auth/login/github"
    },
    {
      "route": "/.auth/login/twitter",
      "statusCode": 404
    },
    {
      "route": "/logout",
      "redirect": "/.auth/logout"
    },
    {
      "route": "/calendar*",
      "rewrite": "/calendar.html"
    },
    {
      "route": "/specials",
      "redirect": "/deals",
      "statusCode": 301
    }
  ],
  "navigationFallback": {
    "rewrite": "index.html",
    "exclude": ["/images/*.{png,jpg,gif}", "/css/*"]
  },
  "responseOverrides": {
    "400": {
      "rewrite": "/invalid-invitation-error.html"
    },
    "401": {
      "redirect": "/login",
      "statusCode": 302
    },
    "403": {
      "rewrite": "/custom-forbidden-page.html"
    },
    "404": {
      "rewrite": "/404.html"
    }
  },
  "globalHeaders": {
    "content-security-policy": "default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none'"
  },
  "mimeTypes": {
    ".json": "text/json"
  }
}

上記の構成に基づいて、次のシナリオを確認します。

要求先	結果
/profile	認証されたユーザーには、/profile/index.html ファイルが提供されます。認証されていないユーザーは`401` 応答の上書き規則によって /login にリダイレクトされます。
/admin、 /admin/、または /admin/index.html	administrator ロールの認証されたユーザーには、/admin/index.html ファイルが提供されます。 administrator ロールに属していない認証されたユーザーには、`403` エラーが返されます¹。認証されていないユーザーは /login にリダイレクトされます。
/images/logo.png	最長有効期間が 182 日 (15,770,000 秒) を少し超えるカスタムキャッシュ規則を使用して画像を提供します。
/api/admin	registeredusers ロールの認証されたユーザーからの `GET` 要求は、API に送信されます。 registeredusers ロールに属していない認証されたユーザー、および認証されていないユーザーには、`401` エラーが返されます。 administrator ロールの認証されたユーザーからの `POST`、`PUT`、`PATCH`、および `DELETE` 要求は、API に送信されます。 administrator ロールに属していない認証されたユーザー、および認証されていないユーザーには、`401` エラーが返されます。
/customers/contoso	administrator または customers_contoso ロールに属している認証されたユーザーには、/customers/contoso/index.html ファイルが提供されます。 administrator または customers_contoso ロールに属していない認証されたユーザーには、`403` エラーが返されます¹。認証されていないユーザーは /login にリダイレクトされます。
/login	認証されていないユーザーは、GitHub で認証するように求められます。
/.auth/login/twitter	Twitter での承認がルート規則によって無効になっているため、`404` エラーが返されます。これにより、フォールバックされ、`200` 状態コードと共に /index.html が提供されます。
/logout	ユーザーは、すべての認証プロバイダーからログアウトされます。
/calendar/2021/01	ブラウザーには、/calendar.html ファイルが提供されます。
/specials	ブラウザーは、永続的に /deals にリダイレクトされます。
/data.json	MIME の種類 `text/json` で提供されるファイル。
/about、またはクライアント側のルーティングパターンに一致する任意のフォルダー	/index.html ファイルは、`200` 状態コードと共に提供されます。
/images/ フォルダーに存在しないファイル	`404` エラー。

¹応答のオーバーライド規則を使用することにより、カスタムエラーページを提供できます。

制限

staticwebapp.config.json ファイルには次の制限があります。

最大ファイルサイズは 20 KB です
最大 50 種類のロール

一般的な制限事項と限度については、クォータに関する記事を参照してください。

次のステップ

認証と承認の設定

Azure Static Web Apps を構成する

ファイルの場所

Routes

ルートの定義

ルート パターンを指定する

正確なルート

ワイルドカード パターン

ロールを使用してルートをセキュリティで保護する

アプリケーション全体へのアクセスを制限する

フォールバック ルート

グローバル ヘッダー

応答のオーバーライド

プラットフォーム

API 言語ランタイムのバージョンの選択

.NET

Node.js

Python

ネットワーク

認証

認証されたパスのキャッシュを無効にする

転送ゲートウェイ

許可された転送先ホスト

必須ヘッダー

末尾のスラッシュ

常時

なし

Auto

構成 ファイルの例

制限

次のステップ

関連記事

その他のリソース

ルートパターンを指定する

ワイルドカードパターン

フォールバックルート

グローバルヘッダー

構成ファイルの例