Reguły zabezpieczeń Cloud Firestore pozwalają kontrolować dostęp do dokumentów oraz w swojej bazie danych. Elastyczna składnia reguł umożliwia reguły, które pasują do wszystkiego, od wszystkich zapisów przez całą bazę danych po operacje w określonym dokumencie.
W tym przewodniku opisano podstawową składnię i strukturę reguł zabezpieczeń. Połącz tę składnię z warunkami reguł zabezpieczeń, aby utworzyć aby utworzyć kompletne zestawy reguł.
Deklaracja dotycząca usługi i bazy danych
Reguły zabezpieczeń Cloud Firestore zawsze zaczynają się od tej deklaracji:
service cloud.firestore {
match /databases/{database}/documents {
// ...
}
}
Deklaracja service cloud.firestore
ogranicza reguły do zakresu
Cloud Firestore, co zapobiega konfliktom między regułami zabezpieczeń Cloud Firestore
reguł dla innych usług, takich jak Cloud Storage.
Deklaracja match /databases/{database}/documents
określa, że reguły powinny
pasują do dowolnej bazy danych Cloud Firestore w projekcie. Obecnie każdy projekt
ma tylko jedną bazę danych o nazwie (default)
.
Podstawowe reguły odczytu/zapisu
Podstawowe reguły składają się z instrukcji match
określającej ścieżkę dokumentu i
wyrażenie allow
określające szczegóły podczas odczytu określonych danych jest dozwolone:
service cloud.firestore {
match /databases/{database}/documents {
// Match any document in the 'cities' collection
match /cities/{city} {
allow read: if <condition>;
allow write: if <condition>;
}
}
}
Wszystkie instrukcje dopasowania powinny wskazywać dokumenty, a nie kolekcje. Dopasowanie
instrukcja może wskazywać konkretny dokument, na przykład match /cities/SF
, lub użyć symboli wieloznacznych
na dowolny dokument w określonej ścieżce, np. match /cities/{city}
.
W przykładzie powyżej instrukcja dopasowania używa składni z symbolem wieloznacznym {city}
.
Oznacza to, że reguła ma zastosowanie do wszystkich dokumentów w kolekcji cities
, na przykład
/cities/SF
lub /cities/NYC
. Gdy wyrażenia allow
w instrukcji dopasowania to
analizowana, zmienna city
przyjmie nazwę dokumentu miasta,
na przykład SF
lub NYC
.
Operacje szczegółowe
W niektórych sytuacjach warto podzielić read
i write
na bardziej szczegółowe
do bardziej szczegółowych działań. Aplikacja może na przykład wymuszać w aplikacji różne
warunków tworzenia dokumentu niż przy jego usunięciu. Możesz też
zezwala na odczyt pojedynczego dokumentu, ale odrzuca duże zapytania.
Regułę read
można podzielić na get
i list
, a regułę write
–
zostanie podzielony na create
, update
i delete
:
service cloud.firestore {
match /databases/{database}/documents {
// A read rule can be divided into get and list rules
match /cities/{city} {
// Applies to single document read requests
allow get: if <condition>;
// Applies to queries and collection read requests
allow list: if <condition>;
}
// A write rule can be divided into create, update, and delete rules
match /cities/{city} {
// Applies to writes to nonexistent documents
allow create: if <condition>;
// Applies to writes to existing documents
allow update: if <condition>;
// Applies to delete operations
allow delete: if <condition>;
}
}
}
Dane hierarchiczne
Dane w Cloud Firestore są zorganizowane w kolekcje dokumentów, a każdy z nich dokument może rozszerzyć hierarchię za pomocą kolekcji podrzędnych. Ważne jest, zrozumieć, jak reguły zabezpieczeń współdziałają z danymi hierarchicznymi.
Weźmy pod uwagę sytuację, w której każdy dokument w kolekcji cities
zawiera element
landmarks
kolekcja podrzędna. Reguły zabezpieczeń są stosowane tylko w przypadku dopasowanej ścieżki, więc
kontrole dostępu zdefiniowane w kolekcji cities
nie mają zastosowania do
landmarks
kolekcja podrzędna. Zamiast tego utwórz jawne reguły, aby kontrolować dostęp
do podzbiorów:
service cloud.firestore {
match /databases/{database}/documents {
match /cities/{city} {
allow read, write: if <condition>;
// Explicitly define rules for the 'landmarks' subcollection
match /landmarks/{landmark} {
allow read, write: if <condition>;
}
}
}
}
Gdy zagnieżdżasz instrukcje match
, ścieżka wewnętrznej instrukcji match
wynosi zawsze
w stosunku do ścieżki zewnętrznej instrukcji match
. Te zestawy reguł
są więc równoważne:
service cloud.firestore {
match /databases/{database}/documents {
match /cities/{city} {
match /landmarks/{landmark} {
allow read, write: if <condition>;
}
}
}
}
service cloud.firestore {
match /databases/{database}/documents {
match /cities/{city}/landmarks/{landmark} {
allow read, write: if <condition>;
}
}
}
Rekurencyjne symbole wieloznaczne
Jeśli chcesz, aby reguły były stosowane do dowolnie głębszej hierarchii, użyj funkcji
rekurencyjna składnia symbolu wieloznacznego, {name=**}
. Przykład:
service cloud.firestore {
match /databases/{database}/documents {
// Matches any document in the cities collection as well as any document
// in a subcollection.
match /cities/{document=**} {
allow read, write: if <condition>;
}
}
}
Jeśli używasz składni rekurencyjnego symbolu wieloznacznego, zmienna z symbolem wieloznacznym będzie zawierać parametr
całego pasującego segmentu ścieżki, nawet jeśli dokument znajduje się w głęboko zagnieżdżonym
podkolekcja. Na przykład wymienione powyżej reguły będą pasować
dokumentu znajdującego się pod adresem /cities/SF/landmarks/coit_tower
, a wartość
zmienna document
będzie miała wartość SF/landmarks/coit_tower
.
Pamiętaj jednak, że działanie rekurencyjnych symboli wieloznacznych zależy od reguł wersji.
Wersja 1
Reguły zabezpieczeń używają domyślnie wersji 1. w wersji 1 rekurencyjne symbole wieloznaczne;
pasują do co najmniej jednego elementu ścieżki. Nie pasują one do pustej ścieżki, więc
match /cities/{city}/{document=**}
dopasowuje dokumenty w podkolekcjach, ale
nie należy do kolekcji cities
, a match /cities/{document=**}
pasuje
zarówno dokumentów z kolekcji cities
, jak i kolekcji podrzędnych.
Rekurencyjne symbole wieloznaczne muszą znajdować się na końcu instrukcji dopasowania.
Wersja 2
W wersji 2 reguł zabezpieczeń rekurencyjne symbole wieloznaczne pasują do 0 lub większej liczby ścieżek
elementy(ów). match/cities/{city}/{document=**}
pasuje do dokumentów w dowolnym
podzbiorów oraz dokumentów z kolekcji cities
.
Musisz zaakceptować wersję 2, dodając rules_version = '2';
u góry
Twoje reguły zabezpieczeń:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
// Matches any document in the cities collection as well as any document
// in a subcollection.
match /cities/{city}/{document=**} {
allow read, write: if <condition>;
}
}
}
Możesz użyć maksymalnie 1 rekurencyjnego symbolu wieloznacznego na wyrażenie dopasowania, ale w wersji 2, możesz umieścić ten symbol wieloznaczny w dowolnym miejscu w instrukcji dopasowania. Przykład:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
// Matches any document in the songs collection group
match /{path=**}/songs/{song} {
allow read, write: if <condition>;
}
}
}
Jeśli używasz zapytań dotyczących grup kolekcji, musisz stosować parametry w wersji 2 znajdziesz informacje na temat zabezpieczania zapytań dotyczących grup kolekcji.
Nakładające się instrukcje dopasowania
Dokument może pasować do więcej niż jednej instrukcji match
. W
jeśli do żądania pasuje wiele wyrażeń allow
, dostęp jest dozwolony
jeśli którykolwiek z warunków jest true
:
service cloud.firestore {
match /databases/{database}/documents {
// Matches any document in the 'cities' collection.
match /cities/{city} {
allow read, write: if false;
}
// Matches any document in the 'cities' collection or subcollections.
match /cities/{document=**} {
allow read, write: if true;
}
}
}
W powyższym przykładzie wszystkie odczyty i zapisy w kolekcji cities
będą
jest dozwolona, ponieważ druga reguła ma zawsze wartość true
, mimo że pierwsza
ma zawsze wartość false
.
Limity reguł zabezpieczeń
Podczas pracy z regułami zabezpieczeń pamiętaj o tych ograniczeniach:
Limit | Szczegóły |
---|---|
Maksymalna liczba wywołań exists() , get() i getAfter() na żądanie |
Przekroczenie dowolnego z limitów skutkuje błędem braku uprawnień. Niektóre wywołania dostępu do dokumentów mogą być przechowywane w pamięci podręcznej, i połączenia z pamięci podręcznej nie wliczają się do tych limitów. |
Maksymalna głębokość zagnieżdżonej instrukcji match |
10 |
Maksymalna długość ścieżki w segmentach ścieżki dozwolona w zbiorze zagnieżdżonych
Wyciągi: match |
100 |
Maksymalna liczba zmiennych przechwytywania ścieżki dozwolona w zbiorze
zagnieżdżone instrukcje match |
20 |
Maksymalna głębokość wywołania funkcji | 20 |
Maksymalna liczba argumentów funkcji | 7 |
Maksymalna liczba powiązań zmiennych na funkcję (let ) |
10 |
Maksymalna liczba rekurencyjnych lub cyklicznych wywołań funkcji | 0 (niedozwolone) |
Maksymalna liczba wyrażeń ocenianych na żądanie | 1000 |
Maksymalny rozmiar zestawu reguł | Zestawy reguł muszą przestrzegać 2 limitów rozmiarów:
|
Dalsze kroki
- Utwórz niestandardowe warunki reguł zabezpieczeń.
- Zapoznaj się z informacjami o regułach zabezpieczeń.