Firebase Summit で発表されたすべての情報をご覧ください。Firebase を使用してアプリ開発を加速し、自信を持ってアプリを実行する方法を紹介しています。詳細

ホスティング動作の構成

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

Firebase Hosting を使用すると、サイトへのリクエストに対してカスタマイズされたホスティング動作を構成できます。

ホスティング用に何を構成できますか?

  • Firebase Hosting にデプロイするローカル プロジェクト ディレクトリ内のファイルを指定します。方法を学ぶ。

  • カスタマイズされた 404/Not Found ページを提供します。方法を学ぶ。

  • 移動または削除したページのredirectsを設定します。方法を学ぶ。

  • 次のいずれかの目的でrewritesを設定します。

    • 複数の URL に対して同じコンテンツを表示します。方法を学ぶ。

    • 関数を提供するか、ホスティング URL から Cloud Run コンテナにアクセスします。方法を学ぶ: functionまたはcontainer .

    • カスタム ドメインのダイナミック リンクを作成します。方法を学ぶ。

  • 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 は次の優先順位を使用して応答を決定します。

  1. /__/*パス セグメントで始まる予約済みの名前空間
  2. 構成されたリダイレクト
  3. 完全一致の静的コンテンツ
  4. 構成された書き換え
  5. カスタム 404ページ
  6. デフォルトの 404 ページ

i18n rewritesを使用している場合、「i18n コンテンツ」に対応するために、完全一致と 404 処理の優先順位が範囲内で拡張されます。

デプロイするファイルを指定する

デフォルトのfirebase.jsonファイルに含まれるデフォルトの属性publicignoreは、プロジェクト ディレクトリ内のどのファイルを 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
  } ]
}

redirects属性には、リダイレクト ルールの配列が含まれます。各ルールには、以下の表のフィールドを含める必要があります。

Firebase Hosting は、すべてのリクエストの開始時 (ファイルまたはフォルダーがそのパスに存在するかどうかをブラウザーが判断する前) に、 sourceまたはregexの値をすべての URL パスと比較します。一致が見つかった場合、Firebase Hosting オリジン サーバーは HTTPS リダイレクト レスポンスを送信し、 destination URL で新しいリクエストを行うようにブラウザに指示します。

分野説明
redirects
source (推奨)
またはregex

最初のリクエスト URL と一致した場合に Hosting がリダイレクトを適用するようにトリガーする URL パターン

  • sourceを使用してglobを指定します(推奨)
  • regexを使用してRE2 正規表現を指定します。
destination

ブラウザが新しいリクエストを行う静的 URL

この URL は、相対パスまたは絶対パスにすることができます。

type

HTTPS 応答コード

  • 「Moved Permanently」にはタイプ301を使用します
  • 「Found」にはタイプ302を使用します (一時的なリダイレクト)

リダイレクト用の URL セグメントをキャプチャする

オプション
場合によっては、リダイレクト ルールの URL パターン ( sourceまたはregex値) の特定のセグメントをキャプチャし、ルールのdestinationパスでこれらのセグメントを再利用する必要がある場合があります。

書き換えを構成する

オプション
書き換えを使用して、複数の 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"
  } ]
}

rewrites属性には、一連の書き換えルールが含まれます。各ルールには、次の表のフィールドを含める必要があります。

Firebase Hosting は、指定されたsourceまたはregex URL パターンに一致する URL パスにファイルまたはディレクトリが存在しない場合にのみ、書き換えルールを適用します。要求が書き換えルールをトリガーすると、ブラウザは HTTP リダイレクトではなく、指定されたdestinationファイルの実際のコンテンツを返します。

分野説明
rewrites
source (推奨)
またはregex

最初のリクエスト URL と一致した場合に Hosting をトリガーして書き換えを適用する URL パターン

  • sourceを使用してglobを指定します(推奨)
  • regexを使用してRE2 正規表現を指定します。
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 リクエスト メソッドはGETPOSTHEADPUTDELETEPATCH 、およびOPTIONSです。 REPORTPROFINDなどの他の方法はサポートされていません。

リクエストを 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 リクエスト メソッドはGETPOSTHEADPUTDELETEPATCH 、およびOPTIONSです。 REPORTPROFINDなどの他の方法はサポートされていません。

現在、次のリージョンの 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

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

AUTOに設定する必要があります

  • この属性を構成に含めない場合、 appAssociationのデフォルトはAUTOです。
  • この属性をAUTOに設定すると、Hosting は、 assetlinks.jsonapple-app-site-associationファイルが要求されたときに動的に生成できます。
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": "*"
    } ]
  } ]
}

headers属性には一連の定義が含まれており、各定義には次の表のフィールドが含まれている必要があります。

分野説明
headers
source (推奨)
またはregex

最初のリクエスト URL と一致した場合に Hosting をトリガーしてカスタム ヘッダーを適用する URL パターン

  • sourceを使用してglobを指定します(推奨)
  • regexを使用してRE2 正規表現を指定します。

カスタム 404 ページと照合するヘッダーを作成するには、 sourceまたはregex値として404.htmlを使用します。

(サブ) headersの配列

Hosting がリクエスト パスに適用するカスタム ヘッダー

各サブヘッダーには、 keyvalueのペアを含める必要があります (次の 2 行を参照)。

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ルールを処理し、 Bowerignoreルールを処理する方法と同様に、extglob を使用したglob パターン マッチング表記を広範囲に使用します。この wiki ページはより詳細なリファレンスですが、以下はこのページで使用されている例の説明です:

  • firebase.jsonpublicディレクトリのルートにある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",

  }
}