次の方法で共有


Azure Static Web Apps を構成する

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

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 いいえ すべてのメソッド ルートに一致する要求メソッドの配列を定義します。 使用可能なメソッドには、GETHEADPOSTPUTDELETECONNECTOPTIONSTRACEPATCH があります。
rewrite いいえ 該当なし 要求から返されるファイルまたはパスを定義します。
  • redirect 規則に対して相互に排他的です。
  • 書き換え規則では、ブラウザーの場所は変更されません。
  • 値は、アプリのルートを基準にする必要があります
redirect いいえ 該当なし 要求のファイルまたはパスのリダイレクト先を定義します。
  • rewrite 規則に対して相互に排他的です。
  • リダイレクト規則では、ブラウザーの場所が変更されます。
  • 既定の応答コードは 302 (一時的なリダイレクト) ですが、301 (永続的なリダイレクト) でオーバーライドできます。
statusCode いいえ 301または302リダイレクトの場合 応答の HTTP 状態コード
headers いいえ 該当なし 応答に追加される HTTP ヘッダーのセット。
  • ルート固有のヘッダーが応答内のグローバル ヘッダーと同じ場合、globalHeaders はルート固有のヘッダーによってオーバーライドされます。
  • ヘッダーを削除するには、値を空の文字列に設定します。
allowedRoles いいえ anonymous ルートにアクセスするために必要なロール名の配列を定義します。
  • 有効な文字は、a-zA-Z0-9_ です。
  • 組み込みのロールは、 anonymous、 すべてのユーザーに適用されます。
  • 組み込みロール authenticated は、ログインしている任意のユーザーに適用されます。
  • ユーザーは、少なくとも 1 つのロールに属している必要があります。
  • ロールは、OR に基づいて照合されます。
    • ユーザーが一覧にあるいずれかのロールに属している場合は、アクセス権が付与されます。
  • 個々のユーザーは、招待によってロールに関連付けられます。

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

目的 プロパティ
ルートと一致させる routemethods
規則が一致して承認された後に処理する rewrite (要求を変更する)

redirectheadersstatusCode (応答を変更する)
ルートが一致した後に承認する 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 として指定されます。

Note

ルート ルールは、navigationFallback をトリガーする要求には適用されません。

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
│
├── about.html
└── 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
/about.html HTML ページ。 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 -
Node.js 20.x (プレビュー) Linux 4.x node:20 -
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"]
}

認証

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

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

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 正規化とリダイレクト ルールを適用します。

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

常時

trailingSlashalways に設定すると、末尾のスラッシュを含まないすべての要求が末尾のスラッシュ付き 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/
/privacy.html /privacy.html ファイル 301 /privacy/

Never

trailingSlashnever に設定すると、末尾のスラッシュ付きのすべての要求が末尾のスラッシュなしの 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
/privacy.html /privacy.html ファイル 301 /privacy

Auto

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

"trailingSlash": "auto"
要求先 返されるもの 状態 パス
/about /about/index.html ファイル 301 /about/
/about/ /about/index.html ファイル 200 /about/
/about/index.html /about/index.html ファイル 301 /about/
/privacy.html /privacy.html ファイル 301 /privacy

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

既定では、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
/privacy.html /privacy.html ファイル 200 /privacy.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/x",
      "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 エラーが返されます1。 認証されていないユーザーは /login にリダイレクトされます。
/images/logo.png 最長有効期間が 182 日 (15,770,000 秒) を少し超えるカスタム キャッシュ規則を使用して画像を提供します。
/api/admin registeredusers ロールの認証されたユーザーからの GET 要求は、API に送信されます。 registeredusers ロールに属していない認証されたユーザー、および認証されていないユーザーには、401 エラーが返されます。

administrator ロールの認証されたユーザーからの POSTPUTPATCH、および DELETE 要求は、API に送信されます。 administrator ロールに属していない認証されたユーザー、および認証されていないユーザーには、401 エラーが返されます。
/customers/contoso administrator または customers_contoso ロールに属している認証されたユーザーには、/customers/contoso/index.html ファイルが提供されます。 administrator または customers_contoso ロールに属していない認証されたユーザーには、403 エラーが返されます1。 認証されていないユーザーは /login にリダイレクトされます。
/login 認証されていないユーザーは、GitHub で認証するように求められます。
_/.auth/login/x ルート ルールにより X 認証が無効になっているため、404 エラーが返されます。 このエラーは、200 状態コードを使用して /index.html を提供するためにフォールバックします。
/logout ユーザーは、すべての認証プロバイダーからログアウトされます。
/calendar/2021/01 ブラウザーには、/calendar.html ファイルが提供されます。
/specials ブラウザーは、永続的に /deals にリダイレクトされます。
/data.json MIME の種類 text/json で提供されるファイル。
/about、またはクライアント側のルーティング パターンに一致する任意のフォルダー /index.html ファイルは、200 状態コードと共に提供されます。
/images/ フォルダーに存在しないファイル 404 エラー。

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

制限

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

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

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

次のステップ