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 informacjiSkonfiguruj 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 informacjiPrzygotowanie 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:
- Zarezerwowane przestrzenie nazw zaczynają się od segmentu ścieżki
/__/*
- skonfigurowane przekierowania,
- Treść statyczna w dopasowaniu ścisłym
- skonfigurowane przepisy.
- Niestandardowa strona 404
- 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
|
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
iPROJECT_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
iPROJECT_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
Tworzenie linków dynamicznych dla domen niestandardowych
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
|
|
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 |
||
tablica dla (pod-)headers |
Niestandardowe nagłówki stosowane przez Hosting do ścieżki żądania Każdy podtytuł musi zawierać pary |
||
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 plikufirebase.json
w katalogu głównym katalogupublic
**
– dopasowuje dowolny plik lub folder w dowolnym podkatalogu*
– dopasowuje tylko pliki i foldery z katalogu głównego katalogupublic
**/.*
– 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 folderunode_modules
, który może się znajdować w dowolnym podkatalogu katalogupublic
**/*.@(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",
}
}