Skonfiguruj zachowanie hostingu

Dzięki Firebase Hosting możesz skonfigurować niestandardowe zachowanie hostingu dla żądań kierowanych do Twojej witryny.

Co możesz skonfigurować dla Hostingu?

  • Określ, które pliki w lokalnym katalogu projektu chcesz wdrożyć w Hostingu Firebase. Naucz się jak.

  • Wyświetl dostosowaną stronę 404/Nie znaleziono. Naucz się jak.

  • Skonfiguruj redirects dla stron, które przeniosłeś lub usunąłeś. Naucz się jak.

  • Skonfiguruj rewrites w dowolnym z następujących celów:

    • Wyświetlaj tę samą treść dla wielu adresów URL. Naucz się jak.

    • Obsługuj funkcję lub uzyskuj dostęp do kontenera Cloud Run z adresu URL hostingu. Dowiedz się, jak: funkcja lub pojemnik .

    • Utwórz łącze dynamiczne domeny niestandardowej. Naucz się jak.

  • Dodaj headers , aby przekazać dodatkowe informacje o żądaniu lub odpowiedzi, takie jak sposób, w jaki przeglądarki powinny obsługiwać stronę i jej zawartość (uwierzytelnianie, buforowanie, kodowanie itp.). Naucz się jak.

  • Skonfiguruj przepisywanie internacjonalizacji (i18n), aby wyświetlać określoną treść w oparciu o preferencje językowe i/lub kraj użytkownika. Dowiedz się, jak (inna strona).

Gdzie definiujesz konfigurację hostingu?

Definiujesz konfigurację Firebase Hosting w pliku firebase.json . Firebase automatycznie tworzy plik firebase.json w katalogu głównym katalogu projektu po uruchomieniu polecenia firebase init .

Pełny przykład konfiguracji firebase.json (obejmujący tylko Hosting Firebase) znajdziesz na dole tej strony. Należy pamiętać, że plik firebase.json może również zawierać konfiguracje innych usług Firebase .

Możesz sprawdzić wdrożoną zawartość firebase.json za pomocą interfejsu API REST Hostingu .

Kolejność priorytetów odpowiedzi Hostingu

Różne opcje konfiguracji Firebase Hosting opisane na tej stronie mogą czasami się pokrywać. Jeśli wystąpi konflikt, Hosting określa swoją odpowiedź, stosując następującą kolejność priorytetów:

  1. Zarezerwowane przestrzenie nazw rozpoczynające się od segmentu ścieżki /__/*
  2. Skonfigurowane przekierowania
  3. Dokładne dopasowanie treści statycznych
  4. Skonfigurowane przepisywanie
  5. Niestandardowa strona 404
  6. Domyślna strona 404

Jeśli używasz przepisywania i18n , zakres dokładnego dopasowania i kolejności obsługi 404 są rozszerzane, aby uwzględnić twoją „treść i18n”.

Określ, które pliki mają zostać wdrożone

Domyślne atrybuty — public i ignore — zawarte w domyślnym pliku firebase.json definiują, które pliki w katalogu projektu powinny zostać wdrożone w projekcie Firebase.

Domyślna konfiguracja hosting w pliku firebase.json wygląda następująco:

"hosting": {
  "public": "public",  // the only required attribute for Hosting
  "ignore": [
    "firebase.json",
    "**/.*",
    "**/node_modules/**"
  ]
}

publiczny

Wymagany
Atrybut public określa, który katalog należy wdrożyć w Hostingu Firebase. Wartość domyślna to katalog o nazwie public , ale możesz określić ścieżkę dowolnego katalogu, o ile istnieje on w katalogu projektu.

Poniżej znajduje się domyślna nazwa katalogu do wdrożenia:

"hosting": {
  "public": "public"

  // ...
}

Możesz zmienić wartość domyślną na katalog, który chcesz wdrożyć:

"hosting": {
  "public": "dist/app"

  // ...
}

ignorować

Opcjonalny
Atrybut ignore określa pliki, które mają być ignorowane podczas wdrażania. Może przyjmować glob w ten sam sposób, w jaki Git obsługuje .gitignore .

Poniżej znajdują się domyślne wartości plików, które mają być ignorowane:

"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
  ]
}

Dostosuj stronę 404/Nie znaleziono

Opcjonalny
Możesz wyświetlić niestandardowy błąd 404 Not Found gdy użytkownik spróbuje uzyskać dostęp do strony, która nie istnieje.

Utwórz nowy plik w public katalogu swojego projektu, nadaj mu nazwę 404.html , a następnie dodaj do pliku niestandardową treść 404 Not Found .

Hosting Firebase wyświetli zawartość tej niestandardowej strony 404.html , jeśli przeglądarka wywoła błąd 404 Not Found w Twojej domenie lub subdomenie.

Skonfiguruj przekierowania

Opcjonalny
Użyj przekierowania adresu URL, aby zapobiec uszkodzeniu linków w przypadku przeniesienia strony lub skrócić adresy URL. Możesz na przykład przekierować przeglądarkę z example.com/team na example.com/about.html .

Określ przekierowania URL, tworząc atrybut redirects zawierający tablicę obiektów (tzw. „reguły przekierowań”). W każdej regule określ wzorzec adresu URL, który, jeśli zostanie dopasowany do ścieżki adresu URL żądania, spowoduje, że Hosting odpowie przekierowaniem na podany docelowy adres URL.

Oto podstawowa struktura atrybutu redirects . Ten przykład przekierowuje żądania do /foo , wysyłając nowe żądanie do /bar .

"hosting": {
  // ...

  // Returns a permanent redirect to "/bar" for requests to "/foo" (but not "/foo/**")
  "redirects": [ {
    "source": "/foo",
    "destination": "/bar",
    "type": 301
  } ]
}

Atrybut redirects zawiera tablicę reguł przekierowań, przy czym każda reguła musi zawierać pola z poniższej tabeli.

Firebase Hosting porównuje wartość source lub regex ze wszystkimi ścieżkami URL na początku każdego żądania (zanim przeglądarka ustali, czy w tej ścieżce istnieje plik lub folder). Jeśli zostanie znalezione dopasowanie, serwer pochodzenia Firebase Hosting wysyła odpowiedź przekierowania HTTPS, informując przeglądarkę, aby wysłała nowe żądanie pod destination adresem URL.

Pole Opis
redirects
source (zalecane)
lub regex

Wzorzec adresu URL, który, jeśli jest zgodny z początkowym adresem URL żądania, powoduje, że Hosting zastosował przekierowanie

destination

Statyczny adres URL, pod którym przeglądarka powinna wysłać nowe żądanie

Ten adres URL może być ścieżką względną lub bezwzględną.

type

Kod odpowiedzi HTTPS

  • Użyj typu 301 dla „Przeniesiono na stałe”
  • Użyj typu 302 dla „Znalezione” (tymczasowe przekierowanie)

Przechwytuj segmenty URL dla przekierowań

Opcjonalny
Czasami może zaistnieć potrzeba przechwycenia określonych segmentów wzorca adresu URL reguły przekierowania (wartości source lub regex ), a następnie ponownego użycia tych segmentów w ścieżce destination reguły.

Skonfiguruj przepisywanie

Opcjonalny
Użyj przepisania, aby wyświetlić tę samą treść dla wielu adresów URL. Przepisanie jest szczególnie przydatne w przypadku dopasowywania wzorców, ponieważ można zaakceptować dowolny adres URL pasujący do wzorca i pozwolić kodowi po stronie klienta zdecydować, co wyświetlić.

Możesz także użyć przepisywania do obsługi aplikacji korzystających z HTML5 pushState do nawigacji. Gdy przeglądarka próbuje otworzyć ścieżkę URL zgodną z określonym source lub wzorcem adresu URL regex , zamiast tego przeglądarka otrzyma zawartość pliku pod destination adresem URL.

Określ przepisywanie adresów URL, tworząc atrybut rewrites zawierający tablicę obiektów (tzw. „reguły przepisywania”). W każdej regule określ wzorzec adresu URL, który, jeśli zostanie dopasowany do ścieżki adresu URL żądania, spowoduje, że Hosting odpowie tak, jakby usługa otrzymała określony docelowy adres URL.

Oto podstawowa struktura atrybutu rewrites . Ten przykład obsługuje index.html dla żądań do plików lub katalogów, które nie istnieją.

"hosting": {
  // ...

  // Serves index.html for requests to files or directories that do not exist
  "rewrites": [ {
    "source": "**",
    "destination": "/index.html"
  } ]
}

Atrybut rewrites zawiera tablicę reguł przepisywania, przy czym każda reguła musi zawierać pola z poniższej tabeli.

Hosting Firebase stosuje regułę przepisywania tylko wtedy, gdy plik lub katalog nie istnieje pod ścieżką URL pasującą do określonego wzorca adresu URL source lub regex . Gdy żądanie wyzwala regułę przepisywania, przeglądarka zwraca rzeczywistą zawartość określonego pliku destination zamiast przekierowania HTTP.

Pole Opis
rewrites
source (zalecane)
lub regex

Wzorzec adresu URL, który, jeśli jest zgodny z początkowym adresem URL żądania, powoduje, że Hosting zastosuje przepisanie

destination

Plik lokalny, który musi istnieć

Ten adres URL może być ścieżką względną lub bezwzględną.

Kieruj żądania do funkcji

Możesz użyć rewrites , aby obsłużyć funkcję z adresu URL hostingu Firebase. Poniższy przykład jest fragmentem udostępniania treści dynamicznych przy użyciu funkcji Cloud Functions .

Na przykład, aby skierować wszystkie żądania ze strony /bigben w witrynie Hostingowej w celu wykonania funkcji bigben :

"hosting": {
  // ...

  // Directs all requests from the page `/bigben` to execute the `bigben` function
  "rewrites": [ {
    "source": "/bigben",
    "function": {
      "functionId": "bigben",
      "region": "us-central1"  // optional (see note below)
      "pinTag": true           // optional (see note below)
    }
  } ]
}

Po dodaniu tej reguły przepisywania i wdrożeniu w Firebase (przy użyciu firebase deploy ), Twoja funkcja jest dostępna za pośrednictwem następujących adresów URL:

  • Twoje subdomeny Firebase:
    PROJECT_ID .web.app/bigben i PROJECT_ID .firebaseapp.com/bigben

  • Wszelkie połączone domeny niestandardowe :
    CUSTOM_DOMAIN /bigben

Podczas przekierowywania żądań do funkcji w Hostingu obsługiwane metody żądań HTTP to GET , POST , HEAD , PUT , DELETE , PATCH i OPTIONS . Inne metody, takie jak REPORT lub PROFIND , nie są obsługiwane.

Kieruj żądania do kontenera Cloud Run

Możesz użyć rewrites , aby uzyskać dostęp do kontenera Cloud Run z adresu URL hostingu Firebase. Poniższy przykład to fragment udostępniania treści dynamicznych przy użyciu Cloud Run .

Na przykład, aby skierować wszystkie żądania ze strony /helloworld w witrynie hostingowej w celu uruchomienia i uruchomienia instancji kontenera 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)
   }
 } ]
}

Po dodaniu tej reguły przepisywania i wdrożeniu w Firebase (przy użyciu firebase deploy ) obraz kontenera będzie dostępny za pośrednictwem następujących adresów URL:

  • Twoje subdomeny Firebase:
    PROJECT_ID .web.app/helloworld i PROJECT_ID .firebaseapp.com/helloworld

  • Wszelkie połączone domeny niestandardowe :
    CUSTOM_DOMAIN /helloworld

Podczas przekierowywania żądań do kontenerów Cloud Run za pomocą Hostingu obsługiwane metody żądań HTTP to GET , POST , HEAD , PUT , DELETE , PATCH i OPTIONS . Inne metody, takie jak REPORT lub PROFIND , nie są obsługiwane.

Aby uzyskać najlepszą wydajność, połącz usługę Cloud Run z Hostingiem, korzystając z następujących regionów:

  • us-west1
  • us-central1
  • us-east1
  • europe-west1
  • asia-east1

Przepisywanie do Cloud Run z Hostingu jest obsługiwane w następujących regionach:

  • asia-east1
  • asia-east2
  • asia-northeast1
  • asia-northeast2
  • asia-northeast3
  • asia-south1
  • asia-south2
  • asia-southeast1
  • asia-southeast2
  • australia-southeast1
  • australia-southeast2
  • europe-central2
  • europe-north1
  • europe-southwest1
  • europe-west1
  • europe-west12
  • europe-west2
  • europe-west3
  • europe-west4
  • europe-west6
  • europe-west8
  • europe-west9
  • me-central1
  • me-west1
  • northamerica-northeast1
  • northamerica-northeast2
  • southamerica-east1
  • southamerica-west1
  • us-central1
  • us-east1
  • us-east4
  • us-east5
  • us-south1
  • us-west1
  • us-west2
  • us-west3
  • us-west4
  • us-west1
  • us-central1
  • us-east1
  • europe-west1
  • asia-east1

Możesz użyć rewrites , aby utworzyć niestandardowe linki dynamiczne domeny. Szczegółowe informacje na temat konfigurowania domeny niestandardowej dla łączy dynamicznych można znaleźć w dokumentacji Linków dynamicznych.

  • Używaj swojej domeny niestandardowej tylko w przypadku łączy dynamicznych

    "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
      } ]
    }
    
  • Określ niestandardowe prefiksy ścieżek domeny, które będą używane w przypadku łączy dynamicznych

    "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
      } ]
    }
    

Konfigurowanie łączy dynamicznych w pliku firebase.json wymaga następujących elementów:

Pole Opis
appAssociation

Należy ustawić na AUTO

  • Jeśli nie uwzględnisz tego atrybutu w konfiguracji, wartością domyślną dla appAssociation jest AUTO .
  • Ustawiając ten atrybut na AUTO , Hosting może dynamicznie generować pliki apple-app-site-association assetlinks.json i apple-app-site-site na żądanie.
rewrites
source

Ścieżka, której chcesz używać w przypadku łączy dynamicznych

W przeciwieństwie do reguł przepisywania ścieżek do adresów URL, reguły przepisywania dla łączy dynamicznych nie mogą zawierać wyrażeń regularnych.

dynamicLinks Musi być ustawione na true

Skonfiguruj nagłówki

Opcjonalny
Nagłówki umożliwiają klientowi i serwerowi przekazywanie dodatkowych informacji wraz z żądaniem lub odpowiedzią. Niektóre zestawy nagłówków mogą wpływać na sposób, w jaki przeglądarka obsługuje stronę i jej zawartość, w tym na kontrolę dostępu, uwierzytelnianie, buforowanie i kodowanie.

Określ niestandardowe, specyficzne dla pliku nagłówki odpowiedzi, tworząc atrybut headers zawierający tablicę obiektów nagłówków. W każdym obiekcie określ wzorzec adresu URL, który, jeśli zostanie dopasowany do ścieżki adresu URL żądania, spowoduje, że Hosting zastosuje określone niestandardowe nagłówki odpowiedzi.

Oto podstawowa struktura atrybutu headers . W tym przykładzie zastosowano nagłówek CORS dla wszystkich plików czcionek.

"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": "*"
    } ]
  } ]
}

Atrybut headers zawiera tablicę definicji, przy czym każda definicja musi zawierać pola z poniższej tabeli.

Pole Opis
headers
source (zalecane)
lub regex

Wzorzec adresu URL, który, jeśli jest dopasowany do początkowego adresu URL żądania, powoduje, że Hosting zastosuje niestandardowy nagłówek

Aby utworzyć nagłówek pasujący do niestandardowej strony 404 , użyj 404.html jako source lub wartości regex .

tablica (pod-) headers

Niestandardowe nagłówki stosowane przez Hosting do ścieżki żądania

Każdy podnagłówek musi zawierać parę key i value (patrz kolejne dwa wiersze).

key Nazwa nagłówka, na przykład Cache-Control
value Wartość nagłówka, na przykład max-age=7200

Możesz dowiedzieć się więcej o Cache-Control w sekcji Hosting, która opisuje udostępnianie treści dynamicznych i mikrousługi hostingowe. Możesz także dowiedzieć się więcej o nagłówkach CORS .

Kontroluj rozszerzenia .html

Opcjonalny
Atrybut cleanUrls pozwala kontrolować, czy adresy URL powinny zawierać rozszerzenie .html .

Jeśli ma true , Hosting automatycznie usuwa rozszerzenie .html z adresów URL przesyłanych plików. Jeśli w żądaniu dodane zostanie rozszerzenie .html , Hosting wykonuje przekierowanie 301 na tę samą ścieżkę, ale eliminuje rozszerzenie .html .

Oto jak kontrolować uwzględnianie .html w adresach URL, dołączając atrybut cleanUrls :

"hosting": {
  // ...

  // Drops `.html` from uploaded URLs
  "cleanUrls": true
}

Kontroluj końcowe ukośniki

Opcjonalny
Atrybut trailingSlash pozwala kontrolować, czy adresy URL treści statycznych powinny zawierać końcowe ukośniki.

  • Gdy true Hosting przekierowuje adresy URL, dodając końcowy ukośnik.
  • Gdy false , Hosting przekierowuje adresy URL, aby usunąć końcowy ukośnik.
  • Jeśli nie określono inaczej, Hosting używa tylko końcowych ukośników dla plików indeksu katalogów (na przykład about/index.html ).

Oto jak kontrolować końcowe ukośniki, dodając atrybut trailingSlash :

"hosting": {
  // ...

  // Removes trailing slashes from URLs
  "trailingSlash": false
}

Atrybut trailingSlash nie wpływa na ponowne zapisywanie zawartości dynamicznej udostępnianej przez Cloud Functions lub Cloud Run.

Dopasowanie wzoru globu

Opcje konfiguracyjne Firebase Hosting w szerokim zakresie wykorzystują notację dopasowywania wzorców glob z extglob, podobnie jak Git obsługuje reguły gitignore , a Bower obsługuje reguły ignore . Ta strona wiki jest bardziej szczegółowym odniesieniem, ale poniżej znajdują się wyjaśnienia przykładów użytych na tej stronie:

  • firebase.json — Pasuje tylko do pliku firebase.json w katalogu głównym katalogu public

  • ** — Dopasowuje dowolny plik lub folder w dowolnym podkatalogu

  • * — Dopasowuje tylko pliki i foldery w katalogu głównym katalogu public

  • **/.* — Dopasowuje dowolny plik rozpoczynający się od . (zwykle ukryte pliki, np. w folderze .git ) w dowolnym podkatalogu

  • **/node_modules/** — Dopasowuje dowolny plik lub folder w dowolnym podkatalogu folderu node_modules , który sam może znajdować się w dowolnym podkatalogu katalogu public

  • **/*.@(jpg|jpeg|gif|png) — dopasowuje dowolny plik w dowolnym podkatalogu, który kończy się dokładnie jednym z następujących: .jpg , .jpeg , .gif lub .png

Przykład pełnej konfiguracji hostingu

Poniżej znajduje się przykład pełnej konfiguracji firebase.json dla Hostingu Firebase. Należy pamiętać, że plik firebase.json może również zawierać konfiguracje innych usług 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",

  }
}