Mit Cloud Firestore-Sicherheitsregeln können Sie den Zugriff auf Dokumente und Sammlungen in Ihrer Datenbank steuern. Mit der flexiblen Regelsyntax können Sie Regeln erstellen, die mit allem übereinstimmen, von allen Schreibvorgängen in die gesamte Datenbank bis hin zu Operationen in einem bestimmten Dokument.
Dieses Handbuch beschreibt die grundlegende Syntax und Struktur von Sicherheitsregeln. Kombinieren Sie diese Syntax mit Sicherheitsregelbedingungen , um vollständige Regelsätze zu erstellen.
Dienst- und Datenbankdeklaration
Cloud Firestore-Sicherheitsregeln beginnen immer mit der folgenden Deklaration:
service cloud.firestore {
match /databases/{database}/documents {
// ...
}
}
Die Deklaration des service cloud.firestore
die Regeln Cloud Firestore zu und verhindert so Konflikte zwischen Cloud Firestore-Sicherheitsregeln und Regeln für andere Produkte wie Cloud Storage.
Die Deklaration match /databases/{database}/documents
gibt an, dass Regeln mit jeder Cloud Firestore-Datenbank im Projekt übereinstimmen sollten. Derzeit hat jedes Projekt nur eine einzige Datenbank namens (default)
.
Grundlegende Lese-/Schreibregeln
Grundregeln bestehen aus einer match
-Anweisung, die einen Dokumentpfad angibt, und einem allow
-Ausdruck, der angibt, wann das Lesen der angegebenen Daten erlaubt ist:
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>;
}
}
}
Alle Übereinstimmungsanweisungen sollten auf Dokumente und nicht auf Sammlungen verweisen. Eine match-Anweisung kann auf ein bestimmtes Dokument verweisen, wie in match /cities/SF
, oder Platzhalter verwenden, um auf ein beliebiges Dokument im angegebenen Pfad zu verweisen, wie in match /cities/{city}
.
Im obigen Beispiel verwendet die match-Anweisung die Wildcard-Syntax {city}
. Das bedeutet, dass die Regel für alle Dokumente in der Städtesammlung gilt, wie z. B. / cities
/cities/SF
oder /cities/NYC
. Wenn die allow
Ausdrücke in der Match-Anweisung ausgewertet werden, wird die city
in den Namen des Stadtdokuments aufgelöst, z. B. SF
oder NYC
.
Granulare Operationen
In manchen Situationen ist es hilfreich, read
und write
in detailliertere Vorgänge aufzuteilen. Beispielsweise möchte Ihre App möglicherweise andere Bedingungen für die Dokumenterstellung als für das Löschen von Dokumenten erzwingen. Oder Sie möchten vielleicht das Lesen einzelner Dokumente zulassen, aber große Abfragen verweigern.
Eine read
kann in get
und list
werden, während eine write
in create
, update
und delete
werden kann:
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>;
}
}
}
Hierarchische Daten
Daten in Cloud Firestore sind in Dokumentensammlungen organisiert, und jedes Dokument kann die Hierarchie durch Untersammlungen erweitern. Es ist wichtig zu verstehen, wie Sicherheitsregeln mit hierarchischen Daten interagieren.
Betrachten Sie die Situation, in der jedes Dokument in der cities
eine Untersammlung von landmarks
enthält. Sicherheitsregeln gelten nur für den übereinstimmenden Pfad, sodass die für die Sammlung „ cities
“ definierten Zugriffskontrollen nicht für die Untersammlung „ landmarks
“ gelten. Schreiben Sie stattdessen explizite Regeln, um den Zugriff auf Untersammlungen zu steuern:
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>;
}
}
}
}
Beim Verschachteln von match
-Anweisungen ist der Pfad der inneren match
-Anweisung immer relativ zum Pfad der äußeren match
-Anweisung. Die folgenden Regelsätze sind daher gleichwertig:
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>;
}
}
}
Rekursive Platzhalter
Wenn Regeln auf eine beliebig tiefe Hierarchie angewendet werden sollen, verwenden Sie die rekursive Platzhaltersyntax {name=**}
. Beispielsweise:
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>;
}
}
}
Bei Verwendung der rekursiven Wildcard-Syntax enthält die Wildcard-Variable das gesamte übereinstimmende Pfadsegment, selbst wenn sich das Dokument in einer tief verschachtelten Untersammlung befindet. Beispielsweise würden die oben aufgeführten Regeln mit einem Dokument übereinstimmen, das sich unter /cities/SF/landmarks/coit_tower
, und der Wert der document
wäre SF/landmarks/coit_tower
.
Beachten Sie jedoch, dass das Verhalten von rekursiven Platzhaltern von der Regelversion abhängt.
Version 1
Sicherheitsregeln verwenden standardmäßig Version 1. In Version 1 stimmen rekursive Platzhalter mit einem oder mehreren Pfadelementen überein. Sie stimmen nicht mit einem leeren Pfad überein, daher passt match /cities/{city}/{document=**}
auf Dokumente in Untersammlungen, aber nicht in der Städtesammlung, während match /cities/{document=**}
cities
beiden Dokumenten in der übereinstimmt cities
Sammlung und Untersammlungen.
Rekursive Platzhalter müssen am Ende einer Match-Anweisung stehen.
Version 2
In Version 2 der Sicherheitsregeln stimmen rekursive Platzhalter mit null oder mehr Pfadelementen überein. match/cities/{city}/{document=**}
gleicht Dokumente in beliebigen Untersammlungen sowie Dokumente in der cities
ab.
Sie müssen sich für Version 2 anmelden, indem rules_version = '2';
ganz oben in Ihren Sicherheitsregeln:
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>;
}
}
}
Sie können höchstens einen rekursiven Platzhalter pro Match-Anweisung haben, aber in Version 2 können Sie diesen Platzhalter an beliebiger Stelle in der Match-Anweisung platzieren. Beispielsweise:
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>;
}
}
}
Wenn Sie Sammlungsgruppenabfragen verwenden, müssen Sie Version 2 verwenden, siehe Sichern von Sammlungsgruppenabfragen .
Überlappende Spielaussagen
Es ist möglich, dass ein Dokument mit mehr als einer match
. Falls mehrere allow
Ausdrücke mit einer Anfrage übereinstimmen, wird der Zugriff erlaubt, wenn eine der Bedingungen true
ist:
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;
}
}
}
Im obigen Beispiel werden alle Lese- und Schreibvorgänge in die cities
zugelassen, da die zweite Regel immer true
ist, obwohl die erste Regel immer false
ist.
Grenzwerte für Sicherheitsregeln
Beachten Sie beim Arbeiten mit Sicherheitsregeln die folgenden Einschränkungen:
Grenze | Einzelheiten |
---|---|
Maximale Anzahl vonexists( exists() -, get() - und getAfter() Aufrufen pro Anfrage |
Das Überschreiten eines der beiden Grenzwerte führt zu einem Fehler „Berechtigung verweigert“. Einige Dokumentzugriffsaufrufe können zwischengespeichert werden, und zwischengespeicherte Aufrufe werden nicht auf die Grenzwerte angerechnet. |
Maximale Tiefe der verschachtelten match -Anweisung | 10 |
Maximale Pfadlänge in Pfadsegmenten, die innerhalb eines Satzes verschachtelter match -Anweisungen zulässig ist | 100 |
Maximal zulässige Anzahl von Pfaderfassungsvariablen innerhalb eines Satzes verschachtelter match -Anweisungen | 20 |
Maximale Funktionsaufruftiefe | 20 |
Maximale Anzahl von Funktionsargumenten | 7 |
Maximale Anzahl von let -Variablenbindungen pro Funktion | 10 |
Maximale Anzahl rekursiver oder zyklischer Funktionsaufrufe | 0 (nicht erlaubt) |
Maximale Anzahl von Ausdrücken, die pro Anfrage ausgewertet werden | 1.000 |
Maximale Größe eines Regelsatzes | Regelsätze müssen zwei Größenbeschränkungen einhalten:
|
Nächste Schritte
- Schreiben Sie benutzerdefinierte Bedingungen für Sicherheitsregeln .
- Lesen Sie die Referenz zu den Sicherheitsregeln .