Firebase Hosting を使用すると、サイトへのリクエストに対してカスタマイズされたホスティング動作を構成できます。
ホスティング用に何を構成できますか?
Firebase Hosting にデプロイするローカル プロジェクト ディレクトリ内のファイルを指定します。方法を学ぶ。
カスタマイズされた 404/Not Found ページを提供します。方法を学ぶ。
移動または削除したページの
redirects
を設定します。方法を学ぶ。次のいずれかの目的で
rewrites
を設定します。headers
を追加して、ブラウザーがページとそのコンテンツを処理する方法 (認証、キャッシュ、エンコードなど) など、要求または応答に関する追加情報を渡します。方法を学ぶ。国際化 (i18n) 書き換えを設定して、ユーザーの言語設定や国に基づいて特定のコンテンツを提供します。方法を学びます(別のページ)。
ホスティング構成はどこで定義しますか?
firebase.json
ファイルで Firebase Hosting 構成を定義します。 firebase firebase init
コマンドを実行すると、Firebase はプロジェクト ディレクトリのルートにfirebase.json
ファイルを自動的に作成します。
このページの下部に、完全なfirebase.json
構成の例(Firebase Hosting のみをカバー) があります。 firebase.json
ファイルには、他の Firebase サービスの構成を含めることもできます。
Hosting REST APIを使用して、デプロイされたfirebase.json
コンテンツを確認できます。
Hosting レスポンスの優先順位
このページで説明されているさまざまな Firebase Hosting 構成オプションは、重複する場合があります。競合がある場合、Hosting は次の優先順位を使用して応答を決定します。
i18n rewritesを使用している場合、「i18n コンテンツ」に対応するために、完全一致と 404 処理の優先順位が範囲内で拡張されます。
デプロイするファイルを指定する
デフォルトのfirebase.json
ファイルに含まれるデフォルトの属性public
とignore
は、プロジェクト ディレクトリ内のどのファイルを Firebase プロジェクトにデプロイするかを定義します。
firebase.json
ファイルのデフォルトのhosting
構成は次のようになります。
"hosting": {
"public": "public", // the only required attribute for Hosting
"ignore": [
"firebase.json",
"**/.*",
"**/node_modules/**"
]
}
公共
必須public
属性は、Firebase Hosting にデプロイするディレクトリを指定します。デフォルト値はpublic
という名前のディレクトリですが、プロジェクト ディレクトリに存在する限り、任意のディレクトリのパスを指定できます。
デプロイするディレクトリのデフォルトの指定名は次のとおりです。
"hosting": {
"public": "public"
// ...
}
デフォルト値を、デプロイするディレクトリに変更できます。
"hosting": {
"public": "dist/app"
// ...
}
無視
オプションignore
属性は、デプロイ時に無視するファイルを指定します。 Gitが.gitignoreを処理するのと同じ方法でグロブを取ることができ.gitignore
。
無視するファイルのデフォルト値は次のとおりです。
"hosting": {
// ...
"ignore": [
"firebase.json", // the Firebase configuration file (the file described on this page)
"**/.*", // files with a leading period should be hidden from the system
"**/node_modules/**" // contains dependencies used to create your site but not run it
]
}
404/Not Found ページをカスタマイズする
オプション
ユーザーが存在しないページにアクセスしようとすると、カスタム404 Not Found
エラーを提供できます。
プロジェクトのpublic
ディレクトリに新しいファイルを作成し、 404.html
という名前を付けてから、カスタム404 Not Found
コンテンツをファイルに追加します。
ブラウザがドメインまたはサブドメインで404 Not Found
エラーをトリガーした場合、Firebase Hosting はこのカスタム404.html
ページのコンテンツを表示します。
リダイレクトを構成する
オプション
URL リダイレクトを使用して、ページを移動した場合にリンクが壊れないようにしたり、URL を短くしたりします。たとえば、ブラウザをexample.com/team
からexample.com/about.html
にリダイレクトできます。
オブジェクトの配列を含むredirects
属性を作成して、URL リダイレクトを指定します (「リダイレクト ルール」と呼ばれます)。各ルールで、リクエスト URL パスに一致する場合に Hosting が指定された宛先 URL へのリダイレクトで応答するようにトリガーする URL パターンを指定します。
これがredirects
属性の基本構造です。この例では、 /bar
に新しいリクエストを作成することで、リクエストを/foo
にリダイレクトします。
"hosting": {
// ...
// Returns a permanent redirect to "/bar" for requests to "/foo" (but not "/foo/**")
"redirects": [ {
"source": "/foo",
"destination": "/bar",
"type": 301
} ]
}
"hosting": {
// ...
// Add the "redirects" attribute within "hosting"
"redirects": [ {
// Returns a permanent redirect to "/bar" for requests to "/foo" (but not "/foo/**")
"source": "/foo",
"destination": "/bar",
"type": 301
}, {
// Returns a permanent redirect to "/bar" for requests to both "/foo" and "/foo/**"
"source": "/foo{,/**}"
"destination": "/bar"
"type": 301
}, {
// Returns a temporary redirect for all requests to files or directories in the "firebase" directory
"source": "/firebase/**",
"destination": "https://firebase.google.com/",
"type": 302
}, {
// A regular expression-based redirect equivalent to the above behavior
"regex": "/firebase/.*",
"destination": "https://firebase.google.com/",
"type": 302
} ]
}
redirects
属性には、リダイレクト ルールの配列が含まれます。各ルールには、以下の表のフィールドを含める必要があります。
Firebase Hosting は、すべてのリクエストの開始時 (ファイルまたはフォルダーがそのパスに存在するかどうかをブラウザーが判断する前) に、 source
またはregex
の値をすべての URL パスと比較します。一致が見つかった場合、Firebase Hosting オリジン サーバーは HTTPS リダイレクト レスポンスを送信し、 destination
URL で新しいリクエストを行うようにブラウザに指示します。
分野 | 説明 | |
---|---|---|
redirects | ||
source (推奨)または regex | 最初のリクエスト URL と一致した場合に Hosting がリダイレクトを適用するようにトリガーする URL パターン | |
destination | ブラウザが新しいリクエストを行う静的 URL この URL は、相対パスまたは絶対パスにすることができます。 | |
type | HTTPS 応答コード
|
リダイレクト用の URL セグメントをキャプチャする
オプション
場合によっては、リダイレクト ルールの URL パターン ( source
またはregex
値) の特定のセグメントをキャプチャし、ルールのdestination
パスでこれらのセグメントを再利用する必要がある場合があります。
source
フィールドを使用している (つまり、URL パターンに glob を指定している) 場合は、セグメントを識別するために:
プレフィックスを含めることで、セグメントをキャプチャできます。セグメントの後の残りの URL パスも取得する必要がある場合は、セグメントの直後に*
を含めます。例えば:
"hosting": { // ... "redirects": [ { "source": "/blog/:post*", // captures the entire URL segment beginning at "post" "destination": "https://blog.myapp.com/:post", // includes the entire URL segment identified and captured by the "source" value "type": 301 }, { "source": "/users/:id/profile", // captures only the URL segment "id", but nothing following "destination": "/users/:id/newProfile", // includes the URL segment identified and captured by the "source" value "type": 301 } ] }
regex
フィールドを使用している場合 (つまり、URL パターンに RE2 正規表現を指定している場合)、名前付きまたは名前なしの RE2 キャプチャ グループを使用してセグメントをキャプチャできます。名前付きのキャプチャ グループはdestination
フィールドで:
プレフィックスを使用して使用できますが、名前のないキャプチャ グループは、1 からregex
値の数値インデックスで参照できます。次に例を示します。
"hosting": { // ... "redirects": [ { "regex": "/blog/(?P<post>.+)", // if you're familiar with PCRE, be aware that RE2 requires named capture groups to begin with ?P "destination": "https://blog.myapp.com/:post", // includes the entire URL segment identified and captured by the `regex` value "type": 301 }, { "regex": "/users/(\d+)/profile", // uses the \d directive to only match numerical path segments "destination": "/users/:1/newProfile", // the first capture group to be seen in the `regex` value is named 1, and so on "type": 301 } ] }
書き換えを構成する
オプション
書き換えを使用して、複数の URL に対して同じコンテンツを表示します。書き換えは、パターン マッチングで特に役立ちます。パターンに一致する任意の URL を受け入れ、クライアント側のコードに何を表示するかを決定させることができるからです。
書き換えを使用して、ナビゲーションにHTML5 pushStateを使用するアプリをサポートすることもできます。ブラウザーが、指定されたsource
またはregex
URL パターンに一致する URL パスを開こうとすると、ブラウザーには、代わりにdestination
URL にあるファイルの内容が表示されます。
オブジェクトの配列を含むrewrites
属性を作成して、URL 書き換えを指定します (「書き換えルール」と呼ばれます)。各ルールで、要求 URL パスに一致した場合に Hosting をトリガーして、指定された宛先 URL がサービスに与えられたかのように応答する URL パターンを指定します。
rewrites
属性の基本構造は次のとおりです。この例では、存在しないファイルまたはディレクトリへのリクエストに対してindex.html
を提供します。
"hosting": {
// ...
// Serves index.html for requests to files or directories that do not exist
"rewrites": [ {
"source": "**",
"destination": "/index.html"
} ]
}
"hosting": { // ... // Add the "rewrites" attribute within "hosting" "rewrites": [ { // Serves index.html for requests to files or directories that do not exist "source": "**", "destination": "/index.html" }, { // Serves index.html for requests to both "/foo" and "/foo/**" // Using "/foo/**" only matches paths like "/foo/xyz", but not "/foo" "source": "/foo{,/**}", "destination": "/index.html" }, { // A regular expression-based rewrite equivalent to the above behavior "regex": "/foo(/.*)?", "destination": "/index.html" }, { // Excludes specified pathways from rewrites "source": "!/@(js|css)/**", "destination": "/index.html" } ] }
rewrites
属性には、一連の書き換えルールが含まれます。各ルールには、次の表のフィールドを含める必要があります。
Firebase Hosting は、指定されたsource
またはregex
URL パターンに一致する URL パスにファイルまたはディレクトリが存在しない場合にのみ、書き換えルールを適用します。要求が書き換えルールをトリガーすると、ブラウザは HTTP リダイレクトではなく、指定されたdestination
ファイルの実際のコンテンツを返します。
分野 | 説明 | |
---|---|---|
rewrites | ||
source (推奨)または regex | 最初のリクエスト URL と一致した場合に Hosting をトリガーして書き換えを適用する URL パターン | |
destination | 存在する必要があるローカル ファイル この URL は、相対パスまたは絶対パスにすることができます。 |
関数への直接リクエスト
rewrites
を使用して、Firebase Hosting URL から関数を提供できます。次の例は、 Cloud Functions を使用した動的コンテンツの提供からの抜粋です。
たとえば、ホスティング サイトのページ/bigben
からのすべての要求を、 bigben
関数を実行するように指示するには:
"hosting": {
// ...
// Directs all requests from the page `/bigben` to execute the `bigben` function
"rewrites": [ {
"source": "/bigben",
"function": "bigben",
"region": "us-central1" // optional (see note below)
} ]
}
この書き換えルールを追加し、( firebase deploy
を使用して) Firebase にデプロイすると、次の URL を介して関数にアクセスできるようになります。
Firebase サブドメイン:
PROJECT_ID .web.app/bigben
およびPROJECT_ID .firebaseapp.com/bigben
接続されているカスタム ドメイン:
CUSTOM_DOMAIN /bigben
Hosting でリクエストを関数にリダイレクトする場合、サポートされている HTTP リクエスト メソッドはGET
、 POST
、 HEAD
、 PUT
、 DELETE
、 PATCH
、およびOPTIONS
です。 REPORT
やPROFIND
などの他の方法はサポートされていません。
リクエストを Cloud Run コンテナに転送する
rewrites
を使用して、Firebase Hosting URL から Cloud Run コンテナにアクセスできます。次の例は、 Cloud Run を使用した動的コンテンツの提供からの抜粋です。
たとえば、ホスティング サイトのページ/helloworld
からのすべての要求を、 helloworld
コンテナー インスタンスの起動と実行をトリガーするように指示するには、次のようにします。
"hosting": {
// ...
// Directs all requests from the page `/helloworld` to trigger and run a `helloworld` container
"rewrites": [ {
"source": "/helloworld",
"run": {
"serviceId": "helloworld", // "service name" (from when you deployed the container image)
"region": "us-central1" // optional (if omitted, default is us-central1)
}
} ]
}
この書き換えルールを追加し、( firebase deploy
を使用して) Firebase にデプロイすると、次の URL からコンテナー イメージにアクセスできるようになります。
Firebase サブドメイン:
PROJECT_ID .web.app/helloworld
およびPROJECT_ID .firebaseapp.com/helloworld
接続されているカスタム ドメイン:
CUSTOM_DOMAIN /helloworld
Hosting を使用してリクエストを Cloud Run コンテナにリダイレクトする場合、サポートされている HTTP リクエスト メソッドはGET
、 POST
、 HEAD
、 PUT
、 DELETE
、 PATCH
、およびOPTIONS
です。 REPORT
やPROFIND
などの他の方法はサポートされていません。
現在、次のリージョンの Hosting で Cloud Run の書き換えを使用できます。
-
asia-east1
-
asia-east2
-
asia-northeast1
-
asia-northeast2
-
asia-northeast3
-
asia-south1
-
asia-southeast1
-
asia-southeast2
-
australia-southeast1
-
europe-north1
-
europe-west1
-
europe-west2
-
europe-west3
-
europe-west4
-
europe-west6
-
northamerica-northeast1
-
southamerica-east1
-
us-central1
-
us-east1
-
us-east4
-
us-west1
カスタム ドメインの Dynamic Links を作成する
rewrites
を使用して、カスタム ドメインの Dynamic Links を作成できます。 Dynamic Linksのカスタム ドメインの設定について詳しくは、Dynamic Links のドキュメントをご覧ください。
Dynamic Links にのみカスタム ドメインを使用する
"hosting": { // ... "appAssociation": "AUTO", // required for Dynamic Links (default is AUTO if not specified) // Add the "rewrites" attribute within "hosting" "rewrites": [ { "source": "/**", // the Dynamic Links start with "https://CUSTOM_DOMAIN/" "dynamicLinks": true } ] }
Dynamic Links に使用するカスタム ドメイン パス プレフィックスを指定する
"hosting": { // ... "appAssociation": "AUTO", // required for Dynamic Links (default is AUTO if not specified) // Add the "rewrites" attribute within "hosting" "rewrites": [ { "source": "/promos/**", // the Dynamic Links start with "https://CUSTOM_DOMAIN/promos/" "dynamicLinks": true }, { "source": "/links/share/**", // the Dynamic Links start with "https://CUSTOM_DOMAIN/links/share/" "dynamicLinks": true } ] }
firebase.json
ファイルで Dynamic Links を構成するには、以下が必要です。
分野 | 説明 | |
---|---|---|
appAssociation |
| |
rewrites | ||
source | Dynamic Links に使用するパス URL へのパスを書き換えるルールとは異なり、ダイナミック リンクの書き換えルールには正規表現を含めることはできません。 | |
dynamicLinks | true に設定する必要があります |
ヘッダーを構成する
オプション
ヘッダーを使用すると、クライアントとサーバーは要求または応答と共に追加情報を渡すことができます。一部のヘッダー セットは、アクセス制御、認証、キャッシュ、エンコーディングなど、ブラウザーがページとそのコンテンツを処理する方法に影響を与える可能性があります。
ヘッダー オブジェクトの配列を含むheaders
属性を作成して、カスタムのファイル固有の応答ヘッダーを指定します。各オブジェクトで、リクエスト URL パスに一致する場合に Hosting をトリガーして指定されたカスタム レスポンス ヘッダーを適用する URL パターンを指定します。
headers
属性の基本構造は次のとおりです。この例では、すべてのフォント ファイルに CORS ヘッダーを適用します。
"hosting": {
// ...
// Applies a CORS header for all font files
"headers": [ {
"source": "**/*.@(eot|otf|ttf|ttc|woff|font.css)",
"headers": [ {
"key": "Access-Control-Allow-Origin",
"value": "*"
} ]
} ]
}
"hosting": { // ... // Add the "headers" attribute within "hosting" "headers": [ { // Applies a CORS header for all font files "source": "**/*.@(eot|otf|ttf|ttc|woff|font.css)", "headers": [ { "key": "Access-Control-Allow-Origin", "value": "*" } ] }, { // Overrides the default 1 hour browser cache with a 2 hour cache for all image files "source": "**/*.@(jpg|jpeg|gif|png)", "headers": [ { "key": "Cache-Control", "value": "max-age=7200" } ] }, { // A regular expression-based rewrite equivalent to the above behavior "regex": ".+/\w+\.(jpg|jpeg|gif|png)$", "headers": [ { "key": "Cache-Control", "value": "max-age=7200" } ] }, { // Sets the cache header for 404 pages to cache for 5 minutes "source": "404.html", "headers": [ { "key": "Cache-Control", "value": "max-age=300" } ] } ] }
headers
属性には一連の定義が含まれており、各定義には次の表のフィールドが含まれている必要があります。
分野 | 説明 | ||
---|---|---|---|
headers | |||
source (推奨)または regex | 最初のリクエスト URL と一致した場合に Hosting をトリガーしてカスタム ヘッダーを適用する URL パターン カスタム 404 ページと照合するヘッダーを作成するには、 | ||
(サブ) headers の配列 | Hosting がリクエスト パスに適用するカスタム ヘッダー 各サブヘッダーには、 | ||
key | Cache-Control などのヘッダーの名前 | ||
value | ヘッダーの値、たとえばmax-age=7200 |
Cache-Control
詳細については、動的コンテンツの提供とマイクロサービスのホスティングについて説明しているホスティング セクションを参照してください。 CORSヘッダーについても詳しく知ることができます。
.html
拡張子を制御する
オプションcleanUrls
属性を使用すると、URL に.html
拡張子を含めるかどうかを制御できます。
true
、Hosting はアップロードされたファイル URL から.html
拡張子を自動的に削除します。リクエストに.html
拡張子が追加されている場合、Hosting は同じパスに301
リダイレクトを実行しますが、 .html
拡張子は削除します。
cleanUrls
属性を含めて、URL に.html
を含めることを制御する方法を次に示します。
"hosting": {
// ...
// Drops `.html` from uploaded URLs
"cleanUrls": true
}
末尾のスラッシュを制御する
オプションtrailingSlash
属性を使用すると、静的コンテンツの URL に末尾のスラッシュを含めるかどうかを制御できます。
-
true
、Hosting は URL をリダイレクトして、末尾にスラッシュを追加します。 -
false
の場合、Hosting は URL をリダイレクトして末尾のスラッシュを削除します。 - 指定しない場合、Hosting はディレクトリ インデックス ファイル (たとえば、
about/index.html
) の末尾のスラッシュのみを使用します。
ここでは、 trailingSlash
属性を追加して末尾のスラッシュを制御する方法を示します。
"hosting": {
// ...
// Removes trailing slashes from URLs
"trailingSlash": false
}
trailingSlash
属性は、Cloud Functions または Cloud Run によって提供される動的コンテンツへの書き換えには影響しません。
グロブ パターン マッチング
Firebase Hosting の構成オプションは、Git がgitignore
ルールを処理し、 Bowerがignore
ルールを処理する方法と同様に、extglob を使用したglob パターン マッチング表記を広範囲に使用します。この wiki ページはより詳細なリファレンスですが、以下はこのページで使用されている例の説明です:
firebase.json
—public
ディレクトリのルートにあるfirebase.json
ファイルのみに一致します**
— 任意のサブディレクトリ内の任意のファイルまたはフォルダーに一致します*
—public
ディレクトリのルートにあるファイルとフォルダーのみに一致します**/.*
— . で始まるすべてのファイルに一致します.
(通常、.git
フォルダーなどの隠しファイル) 任意のサブディレクトリ内**/node_modules/**
—node_modules
フォルダーの任意のサブディレクトリにある任意のファイルまたはフォルダーに一致し、それ自体がpublic
ディレクトリの任意のサブディレクトリにある場合があります**/*.@(jpg|jpeg|gif|png)
—.jpg
、.jpeg
、.gif
、または.png
のいずれかで終わる任意のサブディレクトリ内の任意のファイルに一致します。
フルホスティングの構成例
以下は、Firebase Hosting の完全なfirebase.json
構成の例です。 firebase.json
ファイルには、他の Firebase サービスの構成を含めることもできます。
{
"hosting": {
"public": "dist/app", // "public" is the only required attribute for Hosting
"ignore": [
"firebase.json",
"**/.*",
"**/node_modules/**"
],
"redirects": [ {
"source": "/foo",
"destination": "/bar",
"type": 301
}, {
"source": "/firebase/**",
"destination": "https://www.firebase.com",
"type": 302
} ],
"rewrites": [ {
// Shows the same content for multiple URLs
"source": "/app/**",
"destination": "/app/index.html"
}, {
// Configures a custom domain for Dynamic Links
"source": "/promos/**",
"dynamicLinks": true
}, {
// Directs a request to Cloud Functions
"source": "/bigben",
"function": "bigben"
}, {
// Directs a request to a Cloud Run containerized app
"source": "/helloworld",
"run": {
"serviceId": "helloworld",
"region": "us-central1"
}
} ],
"headers": [ {
"source": "**/*.@(eot|otf|ttf|ttc|woff|font.css)",
"headers": [ {
"key": "Access-Control-Allow-Origin",
"value": "*"
} ]
}, {
"source": "**/*.@(jpg|jpeg|gif|png)",
"headers": [ {
"key": "Cache-Control",
"value": "max-age=7200"
} ]
}, {
"source": "404.html",
"headers": [ {
"key": "Cache-Control",
"value": "max-age=300"
} ]
} ],
"cleanUrls": true,
"trailingSlash": false,
// Required to configure custom domains for Dynamic Links
"appAssociation": "AUTO",
}
}