Google is committed to advancing racial equity for Black communities. See how.
Ta strona została przetłumaczona przez Cloud Translation API.
Switch to English

Skonfiguruj zachowanie hostingowe

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

Co możesz skonfigurować dla hostingu?

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

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

  • Skonfiguruj redirects dla stron, które zostały przeniesione lub usunięte. Naucz się jak.

  • Skonfiguruj rewrites do dowolnego z tych celów:

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

    • Służyć jako funkcja lub uzyskiwać dostęp do kontenera Cloud Run z adresu URL hostingu. Dowiedz się, jak to zrobić: funkcja lub kontener .

    • 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 udostępniać określone treści w oparciu o preferencje językowe użytkownika i / lub kraj. Dowiedz się, jak to zrobić (inna strona).

Gdzie definiujesz konfigurację hostingu?

Konfigurację Hostingu Firebase definiujesz 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) znajduje się u dołu tej strony. Pamiętaj, że plik firebase.json może również zawierać konfiguracje dla innych usług Firebase .

firebase.json zawartość firebase.json można sprawdzić za pomocą interfejsu Hosting REST API .

Priorytet odpowiedzi hostingu

Różne opcje konfiguracji Hostingu Firebase opisane na tej stronie mogą czasami się nakładać. W przypadku konfliktu Hosting określa swoją odpowiedź w następującej kolejności:

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

Jeśli używasz przepisywania i18n , dokładna zgodność i kolejność priorytetów obsługi 404 są rozszerzane w zakresie, aby pomieścić "zawartość 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 z 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ścią domyślną jest katalog o nazwie public , ale można określić ścieżkę do dowolnego katalogu, o ile istnieje w katalogu projektu.

Poniżej znajduje się domyślna określona 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ć elementy globalne w taki sam sposób, w jaki Git obsługuje .gitignore .

Poniżej przedstawiono domyślne wartości ignorowane przez pliki:

"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 próbuje uzyskać dostęp do strony, która nie istnieje.

Utwórz nowy plik w katalogu public projektu, nazwij go 404.html , a następnie dodaj do pliku niestandardową zawartość 404 Not Found .

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

Skonfiguruj przekierowania

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

Określ przekierowania adresów URL, tworząc atrybut redirects który zawiera tablicę obiektów (nazywanych „regułami przekierowań”). W każdej regule określ wzorzec adresu URL, który po dopasowaniu do ścieżki adresu URL żądania spowoduje, że usługa Hosting odpowie przekierowaniem na określony docelowy adres URL.

Oto podstawowa struktura atrybutu redirects . Ten przykład przekierowuje żądania do /foo 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ł 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 adresu 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 Hostingu Firebase wysyła odpowiedź przekierowania HTTP, informując przeglądarkę o konieczności wysłania nowego żądania pod destination adresem URL.

Pole Opis
redirects
source (zalecane)
lub regex

Wzorzec adresu URL, który po dopasowaniu do adresu URL początkowego żądania powoduje, że usługa Hosting stosuje 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 HTTP

  • Użyj typu 301 dla opcji „Przeniesione na stałe”
  • Użyj typu 302 polu „Znaleziono” (przekierowanie tymczasowe)

Przechwytuj segmenty adresów URL na potrzeby przekierowań

Opcjonalny
Czasami może być konieczne przechwycenie określonych segmentów wzorca adresu URL reguły przekierowania (wartość source lub regex ), a następnie ponowne użycie tych segmentów w ścieżce destination reguły.

Skonfiguruj przepisywanie

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

Możesz także użyć przepisywania do obsługi aplikacji, które używają HTML5 pushState do nawigacji. Gdy przeglądarka próbuje otworzyć ścieżkę URL, która pasuje do określonego source lub wzorca adresu URL regex , przeglądarka otrzyma zamiast tego zawartość pliku pod destination adresem URL.

Określ przepisywanie adresów URL, tworząc atrybut rewrites który zawiera tablicę obiektów (nazywanych „regułami przepisywania”). W każdej regule określ wzorzec adresu URL, którego dopasowanie do ścieżki adresu URL żądania spowoduje, że usługa Hosting będzie odpowiadać tak, jakby usługa otrzymała określony docelowy adres URL.

Oto podstawowa struktura atrybutu rewrites . Ten przykład służy do obsługi index.html przypadku żą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 zgodną z określonym wzorcem 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 po dopasowaniu do adresu URL początkowego żądania powoduje, że Hosting stosuje przepisywanie

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

Możesz użyć rewrites aby wyświetlić funkcję z adresu URL hostingu Firebase. Poniższy przykład jest fragmentem udostępniania zawartości dynamicznej za pomocą 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": "bigben"
  } ]
}

Po dodaniu tej reguły przepisywania i wdrożeniu w Firebase (przy użyciu firebase deploy ) Twoja funkcja jest dostępna pod następującymi adresami URL:

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

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

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 jest fragmentem udostępniania zawartości dynamicznej za pomocą Cloud Run .

Na przykład, aby skierować wszystkie żądania ze strony /helloworld w witrynie Hosting w celu wyzwolenia 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 jest 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

Za pomocą funkcji rewrites można tworzyć łącza dynamiczne domeny niestandardowej. Odwiedź dokumentację Dynamic Links, aby uzyskać szczegółowe informacje o konfigurowaniu niestandardowej domeny dla Dynamic Links .

  • Używaj domeny niestandardowej tylko w przypadku 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 prefiksy niestandardowych ścieżek domeny, które mają być używane dla łą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
      } ]
    }
    

Konfiguracja linków dynamicznych w pliku firebase.json wymaga następujących elementów:

Pole Opis
appAssociation

Musi być ustawiony 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ć assetlinks.json i apple-app-site-association , gdy są żądane.
rewrites
source

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

W przeciwieństwie do reguł, które przepisują ścieżki do adresów URL, reguły przepisywania linków 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 kontrolę dostępu, uwierzytelnianie, buforowanie i kodowanie.

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

Oto podstawowa struktura atrybutu headers . Ten przykład stosuje 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 po dopasowaniu do adresu URL początkowego żądania powoduje, że usługa Hosting stosuje niestandardowy nagłówek

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

tablica (pod-) headers

Niestandardowe nagłówki, które Hosting stosuje do ścieżki żądania

Każdy nagłówek podrzędny musi zawierać parę key i value (patrz następne dwa wiersze).

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

Więcej informacji na temat Cache-Control w sekcji Hosting, w której opisano obsługę zawartości dynamicznej i hosting mikrousług. Możesz również dowiedzieć się więcej o nagłówkach CORS .

Kontroluj rozszerzenia .html

Opcjonalny
Atrybut cleanUrls umożliwia kontrolowanie, czy adresy URL powinny zawierać rozszerzenie .html .

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

Oto jak kontrolować dołączanie .html do adresów URL, cleanUrls atrybut cleanUrls :

"hosting": {
  // ...

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

Kontroluj końcowe ukośniki

Opcjonalny
Atrybut trailingSlash umożliwia kontrolowanie, czy adresy URL zawartości statycznej powinny zawierać końcowe ukośniki.

  • Gdy true , Hosting przekierowuje adresy URL w celu dodania końcowego ukośnika.
  • W przypadku wartości false Hosting przekierowuje adresy URL w celu usunięcia końcowego ukośnika.
  • Jeśli nie zostanie określony, 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 przepisywanie do zawartości dynamicznej obsługiwanej przez Cloud Functions lub Cloud Run.

Dopasowanie wzorca Glob

Opcje konfiguracyjne Hostingu Firebase w szerokim zakresie wykorzystują notację dopasowywania wzorców glob z extglob, podobnie jak Git obsługuje reguły gitignore , a Bower obsługuje ignore reguł. Ta strona wiki jest bardziej szczegółowym odniesieniem, ale poniżej znajdują się objaś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

  • * - pasuje tylko do plików i folderów w katalogu głównym katalogu public

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

  • **/node_modules/** - **/node_modules/** 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ę pełny przykład konfiguracji firebase.json dla Hostingu Firebase. Pamiętaj, że plik firebase.json może również zawierać konfiguracje dla 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",

  }
}