Cloud Firestore Security Rules umożliwiają kontrolowanie dostępu do dokumentów i kolekcji w bazie danych. Elastyczna składnia reguł umożliwia tworzenie reguł, które pasują do wszystkiego, od wszystkich zapisów w całej bazie danych po operacje na konkretnym 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
Cloud Firestore Security Rules zawsze zaczyna się od następującej deklaracji:
service cloud.firestore {
match /databases/{database}/documents {
// ...
}
}
Deklaracja service cloud.firestore
ogranicza zakres reguł do Cloud Firestore, zapobiegając konfliktom między Cloud Firestore Security Rules a regułami dotyczącymi innych usług, takich jak Cloud Storage.
Deklaracja match /databases/{database}/documents
określa, że reguły powinny być zgodne z dowolną bazą 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 oświadczenia match
określającego ścieżkę dokumentu oraz wyrażenia allow
określającego, kiedy jest dozwolone odczytywanie określonych danych:
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 powyższym przykładzie instrukcja dopasowania używa składni zastępnika {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ć operacje read
i write
na bardziej szczegółowe operacje. Aplikacja może na przykład wymuszać w aplikacji różne
warunków tworzenia dokumentu niż przy jego usunięciu. Możesz też zezwolić na odczyt pojedynczego dokumentu, ale odrzucić duże zapytania.
Regułę read
można podzielić na get
i list
, a regułę write
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 usłudze Cloud Firestore są porządkowane w kolekcje dokumentów, z których każda 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 napisz wyraźne reguły, które będą 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
jest zawsze względna względem ś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>;
}
}
}
Symbole wieloznaczne rekurencyjne
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 1 elementu ścieżki. Nie pasują do pustej ścieżki, więc match /cities/{city}/{document=**}
pasuje do dokumentów w podkolekcjach, ale nie w kolekcji cities
, podczas gdy match /cities/{document=**}
pasuje do dokumentów w kolekcji cities
i podkolekcjach.
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 dowolnych podkolekcjach, a także do dokumentów w kolekcji cities
.
Musisz wyrazić zgodę na wersję 2, dodając rules_version = '2';
na początku reguł 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 używać wersji 2. Więcej informacji znajdziesz w sekcji Zabezpieczanie zapytań dotyczących grup kolekcji.
Nakładające się instrukcje dopasowania
Dokument może pasować do więcej niż jednego oświadczenia 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 operacje odczytu i zapisu do kolekcji cities
będą dozwolone, ponieważ druga reguła jest zawsze true
, mimo że pierwsza reguła jest zawsze false
.
Ograniczenia 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 ujęć match |
100 |
Maksymalna liczba zmiennych przechwytywania ścieżki dozwolonych w zestawie zagnięć 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 zbioru reguł | Zestawy reguł muszą przestrzegać 2 limitów rozmiarów:
|
Dalsze kroki
- Napisać warunki reguł zabezpieczeń niestandardowych.
- Przeczytaj dokumentację reguł zabezpieczeń.