Sicherheit kann eines der komplexesten Puzzleteile bei der App-Entwicklung sein. Bei den meisten Anwendungen müssen Entwickler einen Server erstellen und betreiben, der die Authentifizierung (wer ein Benutzer ist) und die Autorisierung (was ein Benutzer tun kann) handhabt.
Firebase-Sicherheitsregeln entfernen die mittlere (Server-)Schicht und ermöglichen es Ihnen, pfadbasierte Berechtigungen für Clients anzugeben, die eine direkte Verbindung zu Ihren Daten herstellen. Verwenden Sie diese Anleitung, um mehr darüber zu erfahren, wie Regeln auf eingehende Anfragen angewendet werden.
Wählen Sie ein Produkt aus, um mehr über seine Regeln zu erfahren.
Cloud-Firestore
Grundstruktur
Firebase-Sicherheitsregeln in Cloud Firestore und Cloud Storage verwenden die folgende Struktur und Syntax:
service <<name>> {
// Match the resource path.
match <<path>> {
// Allow the request if the following conditions are true.
allow <<methods>> : if <<condition>>
}
}
Die folgenden Schlüsselkonzepte müssen beim Erstellen der Regeln unbedingt verstanden werden:
- Anfrage: Die Methode oder Methoden, die in der
allow
Anweisung aufgerufen werden. Dies sind Methoden, die Sie ausführen lassen. Die Standardmethoden sind:get
,list
,create
,update
unddelete
. Die bequemenread
undwrite
ermöglichen einen breiten Lese- und Schreibzugriff auf die angegebene Datenbank oder den angegebenen Speicherpfad. - Pfad: Die Datenbank oder der Speicherort, dargestellt als URI-Pfad.
- Regel: Die
allow
Anweisung, die eine Bedingung enthält, die eine Anfrage zulässt, wenn sie als wahr ausgewertet wird.
Sicherheitsregeln Version 2
Seit Mai 2019 ist nun Version 2 der Firebase-Sicherheitsregeln verfügbar. Version 2 der Regeln ändert das Verhalten von rekursiven Platzhaltern {name=**}
. Sie müssen Version 2 verwenden, wenn Sie Sammlungsgruppenabfragen verwenden möchten. Sie müssen sich für Version 2 anmelden, indem Sie rules_version = '2';
die erste Zeile in Ihren Sicherheitsregeln:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
Passende Pfade
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 cities
gilt, wie z. B. /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
.
Passende Teilkollektionen
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 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 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 Wildcard-Syntax {name=**}
:
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
befindet, 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 cities
, während match /cities/{document=**}
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 Sie 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. Zum Beispiel:
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
übereinstimmt. 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 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:
|
Cloud-Speicher
Grundstruktur
Firebase-Sicherheitsregeln in Cloud Firestore und Cloud Storage verwenden die folgende Struktur und Syntax:
service <<name>> {
// Match the resource path.
match <<path>> {
// Allow the request if the following conditions are true.
allow <<methods>> : if <<condition>>
}
}
Die folgenden Schlüsselkonzepte müssen beim Erstellen der Regeln unbedingt verstanden werden:
- Anfrage: Die Methode oder Methoden, die in der
allow
Anweisung aufgerufen werden. Dies sind Methoden, die Sie ausführen lassen. Die Standardmethoden sind:get
,list
,create
,update
unddelete
. Die bequemenread
undwrite
ermöglichen einen breiten Lese- und Schreibzugriff auf die angegebene Datenbank oder den angegebenen Speicherpfad. - Pfad: Die Datenbank oder der Speicherort, dargestellt als URI-Pfad.
- Regel: Die
allow
Anweisung, die eine Bedingung enthält, die eine Anfrage zulässt, wenn sie als wahr ausgewertet wird.
Passende Pfade
Cloud Storage-Sicherheitsregeln stimmen mit den Dateipfaden match
, die für den Zugriff auf Dateien in Cloud Storage verwendet werden. Regeln können mit exakten Pfaden oder Platzhalterpfaden match
, und Regeln können auch verschachtelt sein. Wenn keine Übereinstimmungsregel eine Anforderungsmethode zulässt oder die Bedingung zu false
ausgewertet wird, wird die Anforderung abgelehnt.
Exakte Übereinstimmungen
// Exact match for "images/profilePhoto.png" match /images/profilePhoto.png { allow write: if <condition>; } // Exact match for "images/croppedProfilePhoto.png" match /images/croppedProfilePhoto.png { allow write: if <other_condition>; }
Verschachtelte Übereinstimmungen
// Partial match for files that start with "images" match /images { // Exact match for "images/profilePhoto.png" match /profilePhoto.png { allow write: if <condition>; } // Exact match for "images/croppedProfilePhoto.png" match /croppedProfilePhoto.png { allow write: if <other_condition>; } }
Wildcard-Matches
Regeln können auch verwendet werden, um ein Muster mit Platzhaltern match
. Ein Platzhalter ist eine benannte Variable, die entweder eine einzelne Zeichenfolge wie profilePhoto.png
oder mehrere Pfadsegmente wie images/profilePhoto.png
darstellt.
Ein Platzhalter wird erstellt, indem geschweifte Klammern um den Namen des Platzhalters hinzugefügt werden, z. B. {string}
. Ein Platzhalter für mehrere Segmente kann deklariert werden, indem =**
an den Namen des Platzhalters angehängt wird, z. B. {path=**}
:
// Partial match for files that start with "images" match /images { // Exact match for "images/*" // e.g. images/profilePhoto.png is matched match /{imageId} { // This rule only matches a single path segment (*) // imageId is a string that contains the specific segment matched allow read: if <condition>; } // Exact match for "images/**" // e.g. images/users/user:12345/profilePhoto.png is matched // images/profilePhoto.png is also matched! match /{allImages=**} { // This rule matches one or more path segments (**) // allImages is a path that contains all segments matched allow read: if <other_condition>; } }
Wenn mehrere Regeln mit einer Datei übereinstimmen, ist das Ergebnis das OR
des Ergebnisses aller Regelauswertungen. Das heißt, wenn eine Regel, auf die die Datei zutrifft, als true
ausgewertet wird, ist das Ergebnis true
.
In den obigen Regeln kann die Datei „images/profilePhoto.png“ gelesen werden, wenn entweder condition
oder other_condition
als wahr ausgewertet wird, während die Datei „images/users/user:12345/profilePhoto.png“ nur dem Ergebnis von other_condition
unterliegt .
Auf eine Wildcard-Variable kann innerhalb des match
Dateinamens oder der Pfadautorisierung verwiesen werden:
// Another way to restrict the name of a file match /images/{imageId} { allow read: if imageId == "profilePhoto.png"; }
Cloud Storage-Sicherheitsregeln werden nicht kaskadiert und Regeln werden nur ausgewertet, wenn der Anforderungspfad mit einem Pfad mit angegebenen Regeln übereinstimmt.
Auswertung anfordern
Uploads, Downloads, Metadatenänderungen und Löschungen werden anhand der an Cloud Storage gesendeten request
ausgewertet. Die request
enthält den Dateipfad, in dem die Anforderung ausgeführt wird, die Zeit, zu der die Anforderung empfangen wird, und den neuen resource
, wenn die Anforderung eine Schreibanforderung ist. HTTP-Header und Authentifizierungsstatus sind ebenfalls enthalten.
Das request
enthält auch die eindeutige ID des Benutzers und die Firebase-Authentifizierungsnutzdaten im Objekt request.auth
, die im Abschnitt „Authentifizierung“ der Dokumentation näher erläutert werden.
Eine vollständige Liste der Eigenschaften im request
ist unten verfügbar:
Eigentum | Typ | Beschreibung |
---|---|---|
auth | map<Zeichenfolge, Zeichenfolge> | Wenn ein Benutzer angemeldet ist, werden uid , die eindeutige ID des Benutzers, und token , eine Zuordnung von JWT-Ansprüchen für die Firebase-Authentifizierung, bereitgestellt. Andernfalls ist es null . |
params | map<Zeichenfolge, Zeichenfolge> | Map mit den Abfrageparametern der Anfrage. |
path | Weg | Ein path , der den Pfad darstellt, auf dem die Anforderung ausgeführt wird. |
resource | map<Zeichenfolge, Zeichenfolge> | Der neue Ressourcenwert, der nur bei write vorhanden ist. |
time | Zeitstempel | Ein Zeitstempel, der die Serverzeit darstellt, zu der die Anfrage ausgewertet wird. |
Ressourcenbewertung
Beim Auswerten von Regeln möchten Sie möglicherweise auch die Metadaten der Datei auswerten, die hochgeladen, heruntergeladen, geändert oder gelöscht wird. Auf diese Weise können Sie komplexe und leistungsstarke Regeln erstellen, die beispielsweise das Hochladen von Dateien mit bestimmten Inhaltstypen zulassen oder nur das Löschen von Dateien, die eine bestimmte Größe überschreiten.
Firebase Security Rules for Cloud Storage stellt Dateimetadaten im resource
bereit, das Schlüssel/Wert-Paare der Metadaten enthält, die in einem Cloud Storage-Objekt angezeigt werden. Diese Eigenschaften können bei read
oder write
überprüft werden, um die Datenintegrität sicherzustellen.
Bei write
(z. B. Uploads, Aktualisierungen von Metadaten und Löschungen) haben Sie zusätzlich zum resource
, das Dateimetadaten für die Datei enthält, die derzeit im Anforderungspfad vorhanden ist, auch die Möglichkeit, das Objekt request.resource
zu verwenden. die eine Teilmenge der zu schreibenden Dateimetadaten enthält, wenn das Schreiben erlaubt ist. Sie können diese beiden Werte verwenden, um die Datenintegrität sicherzustellen oder Anwendungseinschränkungen wie Dateityp oder -größe durchzusetzen.
Eine vollständige Liste der Eigenschaften im resource
ist unten verfügbar:
Eigentum | Typ | Beschreibung |
---|---|---|
name | Schnur | Der vollständige Name des Objekts |
bucket | Schnur | Der Name des Buckets, in dem sich dieses Objekt befindet. |
generation | int | Die Google Cloud Storage-Objektgenerierung dieses Objekts. |
metageneration | int | Die Metagenerierung des Google Cloud Storage-Objekts dieses Objekts. |
size | int | Die Größe des Objekts in Byte. |
timeCreated | Zeitstempel | Ein Zeitstempel, der die Zeit darstellt, zu der ein Objekt erstellt wurde. |
updated | Zeitstempel | Ein Zeitstempel, der die Zeit darstellt, zu der ein Objekt zuletzt aktualisiert wurde. |
md5Hash | Schnur | Ein MD5-Hash des Objekts. |
crc32c | Schnur | Ein crc32c-Hash des Objekts. |
etag | Schnur | Das diesem Objekt zugeordnete Etag. |
contentDisposition | Schnur | Die Inhaltsdisposition, die diesem Objekt zugeordnet ist. |
contentEncoding | Schnur | Die diesem Objekt zugeordnete Inhaltscodierung. |
contentLanguage | Schnur | Die diesem Objekt zugeordnete Inhaltssprache. |
contentType | Schnur | Der diesem Objekt zugeordnete Inhaltstyp. |
metadata | map<Zeichenfolge, Zeichenfolge> | Schlüssel/Wert-Paare zusätzlicher, vom Entwickler angegebener benutzerdefinierter Metadaten. |
request.resource
enthält all diese mit Ausnahme von generation
, metageneration
, etag
, timeCreated
und updated
.
Grenzwerte für Sicherheitsregeln
Beachten Sie beim Arbeiten mit Sicherheitsregeln die folgenden Einschränkungen:
Grenze | Einzelheiten |
---|---|
Maximale Anzahl von firestore.exists() und firestore.get() Aufrufen pro Anfrage | 2 für Einzeldokumentanfragen und Abfrageanfragen. Das Überschreiten dieses Limits führt zu einem Fehler „Berechtigung verweigert“. Zugriffsaufrufe auf dieselben Dokumente können zwischengespeichert werden, und zwischengespeicherte Aufrufe werden nicht auf die Beschränkungen angerechnet. |
Vollständiges Beispiel
Alles zusammengenommen können Sie ein vollständiges Beispiel für Regeln für eine Bildspeicherlösung erstellen:
service firebase.storage { match /b/{bucket}/o { match /images { // Cascade read to any image type at any path match /{allImages=**} { allow read; } // Allow write files to the path "images/*", subject to the constraints: // 1) File is less than 5MB // 2) Content type is an image // 3) Uploaded content type matches existing content type // 4) File name (stored in imageId wildcard variable) is less than 32 characters match /{imageId} { allow write: if request.resource.size < 5 * 1024 * 1024 && request.resource.contentType.matches('image/.*') && request.resource.contentType == resource.contentType && imageId.size() < 32 } } } }
Echtzeit-Datenbank
Grundstruktur
In Realtime Database bestehen Firebase-Sicherheitsregeln aus JavaScript-ähnlichen Ausdrücken, die in einem JSON-Dokument enthalten sind.
Sie verwenden die folgende Syntax:
{
"rules": {
"<<path>>": {
// Allow the request if the condition for each method is true.
".read": <<condition>>,
".write": <<condition>>,
".validate": <<condition>>
}
}
}
Es gibt drei grundlegende Elemente in der Regel:
- Pfad: Der Datenbankspeicherort. Dies spiegelt die JSON-Struktur Ihrer Datenbank wider.
- Anfrage: Dies sind die Methoden, die die Regel verwendet, um Zugriff zu gewähren. Die
read
undwrite
gewähren breiten Lese- und Schreibzugriff, währendvalidate
als sekundäre Überprüfung dienen, um Zugriff basierend auf eingehenden oder vorhandenen Daten zu gewähren. - Bedingung: Die Bedingung, die eine Anfrage zulässt, wenn sie als wahr ausgewertet wird.
Wie Regeln auf Pfade angewendet werden
In Realtime Database gelten Regeln atomar, was bedeutet, dass Regeln auf übergeordneten Knoten höherer Ebene Regeln auf granulareren untergeordneten Knoten außer Kraft setzen und Regeln auf einem tieferen Knoten keinen Zugriff auf einen übergeordneten Pfad gewähren können. Sie können den Zugriff auf einen tieferen Pfad in Ihrer Datenbankstruktur nicht verfeinern oder widerrufen, wenn Sie ihn bereits für einen der übergeordneten Pfade gewährt haben.
Beachten Sie die folgenden Regeln:
{ "rules": { "foo": { // allows read to /foo/* ".read": "data.child('baz').val() === true", "bar": { // ignored, since read was allowed already ".read": false } } } }
Diese Sicherheitsstruktur ermöglicht das Lesen von /bar/
immer dann, wenn /foo/
ein untergeordnetes baz
mit dem Wert true
enthält. Die Regel ".read": false
unter /foo/bar/
hat hier keine Wirkung, da der Zugriff nicht durch einen untergeordneten Pfad widerrufen werden kann.
Auch wenn es nicht sofort intuitiv erscheint, ist dies ein mächtiger Teil der Regelsprache und ermöglicht die Implementierung sehr komplexer Zugriffsrechte mit minimalem Aufwand. Dies ist besonders nützlich für die benutzerbasierte Sicherheit .
.validate
Regeln werden jedoch nicht kaskadiert. Alle Validierungsregeln müssen auf allen Ebenen der Hierarchie erfüllt sein, damit ein Schreibvorgang zugelassen wird.
Da Regeln nicht auf einen übergeordneten Pfad zurück angewendet werden, schlagen außerdem Lese- oder Schreibvorgänge fehl, wenn am angeforderten Speicherort oder an einem übergeordneten Speicherort keine Regel vorhanden ist, die Zugriff gewährt. Selbst wenn auf jeden betroffenen untergeordneten Pfad zugegriffen werden kann, schlägt das Lesen am übergeordneten Speicherort vollständig fehl. Betrachten Sie diese Struktur:
{ "rules": { "records": { "rec1": { ".read": true }, "rec2": { ".read": false } } } }
Ohne zu verstehen, dass Regeln atomar ausgewertet werden, könnte es so aussehen, als würde das Abrufen des Pfads /records/
rec1
zurückgeben, aber nicht rec2
. Das tatsächliche Ergebnis ist jedoch ein Fehler:
JavaScript
var db = firebase.database(); db.ref("records").once("value", function(snap) { // success method is not called }, function(err) { // error callback triggered with PERMISSION_DENIED });
Ziel c
FIRDatabaseReference *ref = [[FIRDatabase database] reference]; [[_ref child:@"records"] observeSingleEventOfType:FIRDataEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) { // success block is not called } withCancelBlock:^(NSError * _Nonnull error) { // cancel block triggered with PERMISSION_DENIED }];
Schnell
var ref = FIRDatabase.database().reference() ref.child("records").observeSingleEventOfType(.Value, withBlock: { snapshot in // success block is not called }, withCancelBlock: { error in // cancel block triggered with PERMISSION_DENIED })
Java
FirebaseDatabase database = FirebaseDatabase.getInstance(); DatabaseReference ref = database.getReference("records"); ref.addListenerForSingleValueEvent(new ValueEventListener() { @Override public void onDataChange(DataSnapshot snapshot) { // success method is not called } @Override public void onCancelled(FirebaseError firebaseError) { // error callback triggered with PERMISSION_DENIED }); });
AUSRUHEN
curl https://docs-examples.firebaseio.com/rest/records/ # response returns a PERMISSION_DENIED error
Da der Lesevorgang bei /records/
atomar ist und es keine Leseregel gibt, die Zugriff auf alle Daten unter /records/
gewährt, wird dies einen PERMISSION_DENIED
Fehler auslösen. Wenn wir diese Regel im Sicherheitssimulator unserer Firebase-Konsole auswerten, sehen wir, dass der Lesevorgang verweigert wurde:
Attempt to read /records with auth=Success(null) / /records No .read rule allowed the operation. Read was denied.
Der Vorgang wurde verweigert, da keine Leseregel den Zugriff auf den Pfad /records/
zuließ. Beachten Sie jedoch, dass die Regel für rec1
nie ausgewertet wurde, da sie sich nicht in dem von uns angeforderten Pfad befand. Um rec1
abzurufen, müssten wir direkt darauf zugreifen:
JavaScript
var db = firebase.database(); db.ref("records/rec1").once("value", function(snap) { // SUCCESS! }, function(err) { // error callback is not called });
Ziel c
FIRDatabaseReference *ref = [[FIRDatabase database] reference]; [[ref child:@"records/rec1"] observeSingleEventOfType:FEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) { // SUCCESS! }];
Schnell
var ref = FIRDatabase.database().reference() ref.child("records/rec1").observeSingleEventOfType(.Value, withBlock: { snapshot in // SUCCESS! })
Java
FirebaseDatabase database = FirebaseDatabase.getInstance(); DatabaseReference ref = database.getReference("records/rec1"); ref.addListenerForSingleValueEvent(new ValueEventListener() { @Override public void onDataChange(DataSnapshot snapshot) { // SUCCESS! } @Override public void onCancelled(FirebaseError firebaseError) { // error callback is not called } });
AUSRUHEN
curl https://docs-examples.firebaseio.com/rest/records/rec1 # SUCCESS!
Standortvariable
Echtzeit-Datenbankregeln unterstützen eine $location
Variable, um Pfadsegmente abzugleichen. Verwenden Sie das $
-Präfix vor Ihrem Pfadsegment, um Ihre Regel mit allen untergeordneten Knoten entlang des Pfads abzugleichen.
{
"rules": {
"rooms": {
// This rule applies to any child of /rooms/, the key for each room id
// is stored inside $room_id variable for reference
"$room_id": {
"topic": {
// The room's topic can be changed if the room id has "public" in it
".write": "$room_id.contains('public')"
}
}
}
}
}
Sie können die $variable
auch parallel mit konstanten Pfadnamen verwenden.
{
"rules": {
"widget": {
// a widget can have a title or color attribute
"title": { ".validate": true },
"color": { ".validate": true },
// but no other child paths are allowed
// in this case, $other means any key excluding "title" and "color"
"$other": { ".validate": false }
}
}
}