Azure Static Web Apps を構成する

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

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

Note

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

これは、Azure Static Web Apps に関するドキュメントで、Azure Storage の静的 Web サイトのホスティング機能とは別の、スタンドアロン製品です。

ファイルの場所

staticwebapp.config.json の推奨される場所は、ワークフロー ファイルapp_location として設定されたフォルダー内です。 ただし、このファイルは app_location として設定されたフォルダー内の任意のサブフォルダーに配置できます。

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

重要

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

ルート

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

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

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

ルートの定義

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

重要

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

規則のプロパティ 必須 既定値 解説
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 に基づいて照合されます。
    • ユーザーが一覧にあるいずれかのロールに属している場合は、アクセス権が付与されます。
  • 個々のユーザーは、招待によってロールに関連付けられます。

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

目的 Properties
ルートと一致させる route, methods
規則が一致して承認された後に処理する 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/パスの下にあるすべての要求と一致します。 ただし、path /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/profile*で始まる可能性のあるすべてのルートをセキュリティで保護します。

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

アプリケーション内のすべてのルートについて認証を要求することが一般的です。 これを実現するには、すべてのルートに一致する規則を追加し、組み込みの authenticated ロールを allowedRoles 配列に格納します。

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

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

注意

既定では、構成済みのすべての 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"
  }
}

注意

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

応答のオーバーライド

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

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

状態コード 説明 考えられる原因
400 正しくない要求 無効な招待リンク
401 権限がありません 認証されていない状態での制限されたページへの要求
403 Forbidden
  • ユーザーはログインしているが、ページを表示するために必要なロールがない。
  • ユーザーはログインしているが、ランタイムが 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
.NET 6.0 インプロセス Windows 4.x dotnet:6.0
.NET 6.0 分離 Windows 4.x dotnet-isolated:6.0
Node.js 12.x Linux 3.x node:12
Node.js 14.x Linux 4.x node:14
Node.js 16.x Linux 4.x node:16
Python 3.8 Linux 3.x python:3.8
Python 3.9 Linux 4.x python:3.9

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

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

ネットワーク

networking セクションは、静的 Web アプリのネットワーク構成を制御します。 アプリへのアクセスを制限するには、allowedIpRanges で許可される IP アドレス ブロックの一覧を指定します。

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 セクションでは、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 サーバー上のディレクトリを参照し、末尾のスラッシュ以外の URL はファイルを示します。

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

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

Always

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/
/contact /contact.html ファイル 301 /contact/
/contact/ /contact.html ファイル 200 /contact/
/contact.html /contact.html ファイル 301 /contact/

行わない

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
/contact /contact.html ファイル 200 /contact
/contact/ /contact.html ファイル 301 /contact
/contact.html /contact.html ファイル 301 /contact

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/
/contact /contact.html ファイル 200 /contact
/contact/ /contact.html ファイル 301 /contact
/contact.html /contact.html ファイル 301 /contact

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
/contact /contact.html ファイル 200 /contact
/contact/ /contact.html ファイル 301 /contact
/contact.html /contact.html ファイル 200 /contact.html

構成ファイルの例

{
  "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 エラーが返されます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/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 エラー。

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

制限

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

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

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

次のステップ