Skonfiguruj działanie Hostingu

Hosting Firebase pozwala skonfigurować niestandardowe zachowanie hostingu w przypadku żądań wysyłanych do Twojej witryny.

Co można skonfigurować w Hostingu?

  • Określ, które pliki w lokalnym katalogu projektu chcesz wdrożyć w Hostingu Firebase. Więcej informacji

  • Wyświetlanie dostosowanej strony 404/nie znaleziono. Więcej informacji

  • Skonfiguruj redirects dla stron, które zostały przeniesione lub usunięte. Więcej informacji

  • Skonfiguruj usługę rewrites w dowolnym z tych celów:

    • Wyświetlaj tę samą treść pod wieloma adresami URL. Więcej informacji

    • obsługiwać funkcję lub uzyskiwać dostęp do kontenera Cloud Run z adresu URL Hostingu. Dowiedz się, jak to zrobić: funkcja lub kontener.

    • Utwórz link dynamiczny dla domeny niestandardowej. Więcej informacji

  • Dodaj atrybut headers, aby przekazywać dodatkowe informacje o żądaniu lub odpowiedzi, np. o tym, jak przeglądarki powinny obsługiwać stronę i jej zawartość (uwierzytelnianie, zapisywanie w pamięci podręcznej, kodowanie itp.). Więcej informacji

  • Przygotowanie przeredagowanych wersji językowych (i18n) w celu wyświetlania określonych treści na podstawie języka lub kraju użytkownika. Więcej informacji (inna strona).

Gdzie definiujesz swoją konfigurację Hostingu?

Konfigurację Hostingu Firebase definiuje się w pliku firebase.json. Gdy uruchamiasz polecenie firebase init, Firebase automatycznie tworzy plik firebase.json w katalogu głównym katalogu projektów.

Na dole tej strony znajdziesz pełny przykład konfiguracji firebase.json (obejmujący tylko Hosting Firebase). Pamiętaj, że plik firebase.json może też zawierać konfiguracje innych usług Firebase.

Wdrożoną treść firebase.json możesz sprawdzić za pomocą interfejsu Hosting API typu REST.

Kolejność priorytetów odpowiedzi w Hostingu

Różne opcje konfiguracji Hostingu Firebase opisane na tej stronie mogą się czasem pokrywać. W przypadku konfliktu Hosting określa swoją odpowiedź według tej kolejności:

  1. Zarezerwowane przestrzenie nazw zaczynają się od segmentu ścieżki /__/*
  2. skonfigurowane przekierowania,
  3. Treść statyczna w dopasowaniu ścisłym
  4. skonfigurowane przepisy.
  5. Niestandardowa strona 404
  6. Domyślna strona błędu 404

Jeśli używasz przepisów i18n, kolejność priorytetowa dopasowania ścisłego i kodu 404 zostanie powiększona o „treści i18n”.

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

Atrybuty domyślne – public i ignore – zawarte w domyślnym pliku firebase.json określają, które pliki w katalogu projektu mają zostać wdrożone w projekcie Firebase.

Domyślna konfiguracja hosting w pliku firebase.json wygląda tak:

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

publiczna

Wymagany
Atrybut public określa katalog, który ma zostać wdrożony w Hostingu Firebase. Wartością domyślną jest katalog o nazwie public, ale możesz podać ścieżkę dowolnego katalogu, o ile istnieje on w Twoim katalogu projektu.

Poniżej znajdziesz domyślną nazwę katalogu do wdrożenia:

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

  // ...
}

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

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

  // ...
}

Ignoruj

Opcjonalny
Atrybut ignore określa pliki, które mają być ignorowane podczas wdrażania. Może działać globs w taki sam sposób jak Git obsługuje .gitignore.

Oto domyślne wartości, 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
  ]
}

Dostosowywanie strony 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 katalogu public projektu, nadaj mu nazwę 404.html, a następnie dodaj do niego niestandardową zawartość 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.

Konfigurowanie przekierowań

Opcjonalnie
Użyj przekierowania adresu URL, aby zapobiec uszkodzonym linkom po przeniesieniu strony lub skróceniu adresów URL. Możesz na przykład przekierować przeglądarkę z example.com/team do example.com/about.html.

Określ przekierowania adresu URL, tworząc atrybut redirects, który zawiera tablicę obiektów (nazywanych „regułami przekierowania”). W każdej regule określ wzorzec adresu URL, który, jeśli jest dopasowany do ścieżki adresu URL żądania, powoduje, że Hosting odpowiada za pomocą przekierowania na określony docelowy adres URL.

Oto podstawowa struktura atrybutu redirects. W tym przykładzie żądania są przekierowywane do /foo przez wysłanie nowego żądania 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ł przekierowania, przy czym każda reguła musi zawierać pola z poniższej tabeli.

Hosting Firebase porównuje wartość source lub regex ze wszystkimi ścieżkami adresów URL na początku każdego żądania (zanim przeglądarka sprawdzi, czy na tej ścieżce znajduje się plik lub folder). W przypadku znalezienia dopasowania serwer pierwotny Hostingu Firebase wysyła odpowiedź HTTPS wskazującą przeglądarce, że ma wysłać nowe żądanie pod adresem URL destination.

Pole Opis
redirects
source (zalecane)
lub regex

Wzorzec adresu URL, który, jeśli pasuje do początkowego adresu URL żądania, powoduje, że Hosting zastosuje 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

  • W przypadku ustawienia „Przeniesiono na stałe” użyj typu 301
  • Używaj typu 302 w przypadku błędu „Znaleziono” (tymczasowe przekierowanie)

Przechwytuj segmenty adresów URL na potrzeby przekierowań

Opcjonalny
Czasami musisz zarejestrować określone segmenty wzorca adresu URL reguły przekierowania (wartość source lub regex), a następnie ponownie użyć tych segmentów w ścieżce destination reguły.

Skonfiguruj przepisywanie

Opcjonalne
Używaj przepisywania, aby wyświetlać tę samą treść pod wieloma adresami URL. Przepisywanie jest szczególnie przydatne w przypadku dopasowywania do wzorców, ponieważ możesz zaakceptować dowolny URL, który pasuje do wzorca, a kod po stronie klienta decyduje, co ma być wyświetlane.

Możesz też używać przepisywania, aby obsługiwać aplikacje, które do nawigacji używają metody HTML5 pushState. Gdy przeglądarka spróbuje otworzyć ścieżkę adresu URL, która pasuje do określonego wzorca adresu URL source lub regex, otrzyma zamiast tego zawartość pliku pod adresem URL destination.

Określ przepisywanie adresów URL przez utworzenie atrybutu rewrites, który zawiera tablicę obiektów (nazywane „regułami przepisywania”). W każdej regule określ wzorzec adresu URL, który, jeśli jest dopasowany do ścieżki adresu URL żądania, powoduje, że Hosting odpowiada tak, jak gdyby usługa otrzymywała określony docelowy adres URL.

Oto podstawowa struktura atrybutu rewrites. Ten przykład obsługuje index.html w przypadku żądań dotyczących nieistniejących plików lub katalogów.

"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, w której każda reguła musi zawierać pola z poniższej tabeli.

Hosting Firebase stosuje regułę przepisywania tylko wtedy, gdy plik lub katalog nie istnieje na ścieżce URL, która pasuje do określonego wzorca adresu URL source lub regex. Gdy żądanie wywoła 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 pasuje do początkowego adresu URL żądania, powoduje, że Hosting zastosuje przepisy

destination

Plik lokalny, który musi istnieć

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

Bezpośrednie żądania do funkcji

Za pomocą polecenia rewrites możesz obsługiwać funkcję z adresu URL Hostingu Firebase. Poniższy przykład przedstawia fragment dotyczący udostępniania zawartości dynamicznej za pomocą Cloud Functions.

Aby np. przekierować 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 (za pomocą firebase deploy) Twoja funkcja jest dostępna pod tymi adresami URL:

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

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

W przypadku przekierowania żądań do funkcji przy użyciu Hostingu obsługiwane są metody żądań HTTP: GET, POST, HEAD, PUT, DELETE, PATCH i OPTIONS. Inne metody, takie jak REPORT czy PROFIND, nie są obsługiwane.

Bezpośrednie żądania do kontenera Cloud Run

Za pomocą rewrites możesz uzyskać dostęp do kontenera Cloud Run z poziomu adresu URL Hostingu Firebase. Poniższy przykład jest fragmentem udostępniania zawartości dynamicznej za pomocą Cloud Run.

Aby na przykład kierować wszystkie żądania ze strony /helloworld w witrynie hostingowej w celu aktywowania 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 (za pomocą firebase deploy) obraz kontenera jest osiągalny pod tymi adresami URL:

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

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

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

Aby uzyskać najlepszą wydajność, skolokuj swoją usługę Cloud Run z Hostingiem przy użyciu tych regionów:

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

Przepisywanie w Cloud Run z Hostingu jest obsługiwane w tych 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

Za pomocą rewrites możesz tworzyć linki dynamiczne w domenie niestandardowej. Szczegółowe informacje o konfigurowaniu niestandardowej domeny na potrzeby linków dynamicznych znajdziesz w dokumentacji Linków dynamicznych.

  • Używaj domeny niestandardowej tylko na potrzeby Linków 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 domen, które mają być używane w Linkach 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
      } ]
    }
    

Konfiguracja linków dynamicznych w pliku firebase.json wymaga:

Pole Opis
appAssociation

Musi być ustawiona na AUTO

  • Jeśli nie umieścisz tego atrybutu w konfiguracji, domyślną wartością dla atrybutu appAssociation będzie AUTO.
  • Gdy ustawisz ten atrybut na AUTO, Hosting może dynamicznie generować pliki assetlinks.json i apple-app-site-association, gdy o to poprosi.
rewrites
source

Ścieżka, której chcesz używać w Linkach dynamicznych

W przeciwieństwie do reguł, które zmieniają ścieżki do adresów URL, reguły przepisywania dotyczące linków dynamicznych nie mogą zawierać wyrażeń regularnych.

dynamicLinks Musi być ustawiona na true

Skonfiguruj nagłówki

Opcjonalny
Nagłówki umożliwiają klientowi i serwerowi przekazywanie dodatkowych informacji razem z żądaniem lub odpowiedzią. Niektóre zestawy nagłówków, w tym kontrola dostępu, uwierzytelnianie, zapisywanie w pamięci podręcznej i kodowanie, mogą wpływać na sposób obsługi strony i jej zawartości przez przeglądarkę.

Określ niestandardowe nagłówki odpowiedzi dla konkretnych plików, tworząc atrybut headers, który zawiera tablicę obiektów nagłówka. W każdym obiekcie określ wzorzec adresu URL, który w przypadku dopasowania do ścieżki adresu URL żądania powoduje, że Hosting zastosuje określone niestandardowe nagłówki odpowiedzi.

Oto podstawowa struktura atrybutu headers. W tym przykładzie do wszystkich plików czcionek zastosowano nagłówek 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": "*"
    } ]
  } ]
}

Atrybut headers zawiera tablicę definicji, z której każda definicja musi zawierać pola z poniższej tabeli.

Pole Opis
headers
source (zalecane)
lub regex

Wzorzec adresu URL, który, jeśli pasuje do początkowego adresu URL żądania, powoduje zastosowanie nagłówka niestandardowego przez Hosting

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

tablica dla (pod-)headers

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

Każdy podtytuł musi zawierać pary key i value (zobacz 2 następne wiersze).

key Nazwa nagłówka, np. Cache-Control
value Wartość nagłówka, np. max-age=7200

Więcej informacji o Cache-Control znajdziesz w sekcji dotyczącej hostingu, która opisuje wyświetlanie treści dynamicznych i hostowanie mikroserwisów. Możesz też dowiedzieć się więcej o nagłówkach CORS.

Zarządzanie rozszerzeniami (.html)

Opcjonalny
Atrybut cleanUrls pozwala określić, czy adresy URL mają zawierać rozszerzenie .html.

Gdy true, Hosting automatycznie usuwa rozszerzenie .html z adresów URL przesłanych plików. Jeśli do żądania dodasz rozszerzenie .html, Hosting wykonuje przekierowanie 301 na tę samą ścieżkę, ale eliminuje rozszerzenie .html.

Aby kontrolować uwzględnianie elementu .html w adresach URL, dodając atrybut cleanUrls:

"hosting": {
  // ...

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

Steruj ukośnikami końcowymi

Opcjonalny
Atrybut trailingSlash pozwala określić, czy statyczne adresy URL treści mają zawierać końcowe ukośniki.

  • Gdy jest true, Hosting przekierowuje adresy URL, dodając ukośnik.
  • W przypadku false Hosting przekierowuje adresy URL, aby usunąć końcowy ukośnik.
  • Gdy nie określono inaczej, w plikach indeksów katalogów (na przykład about/index.html) używane są tylko końcowe ukośniki.

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

"hosting": {
  // ...

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

Atrybut trailingSlash nie ma wpływu na przepisywanie treści dynamicznych udostępnianych przez Cloud Functions lub Cloud Run.

Dopasowywanie wzorców kuli ziemskiej

Opcje konfiguracyjne Hostingu Firebase umożliwiają szerokie korzystanie z notacji dopasowywania wzorców glob z extglob, podobnie jak Git obsługuje reguły gitignore, a Bower – reguły ignore. Ta strona wiki zawiera bardziej szczegółowe omówienie przykładów, które zostały na niej użyte:

  • 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 z katalogu głównego katalogu public

  • **/.* – dopasowuje każdy plik zaczynający się od . (zwykle pliki ukryte, np. w folderze .git) w dowolnym podkatalogu

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

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

Przykład pełnej konfiguracji hostingu

Poniżej znajdziesz przykład pełnej konfiguracji firebase.json w Hostingu Firebase. Pamiętaj, że plik firebase.json może też 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",

  }
}