了解 2023 年 Google I/O 大会上介绍的 Firebase 亮点。了解详情

Diese Seite wurde von der Cloud Translation API übersetzt.

Funktionsweise von Sicherheitsregeln

Sicherheit kann eines der komplexesten Puzzleteile bei der App-Entwicklung sein. Bei den meisten Anwendungen müssen Entwickler einen Server erstellen und ausführen, der die Authentifizierung (wer ein Nutzer ist) und Autorisierung (was ein Nutzer tun kann) übernimmt.

Firebase Security Rules die mittlere (Server-)Schicht entfernen und pfadbasierte Berechtigungen für Clients angeben, die direkt eine Verbindung zu Ihren Daten herstellen. In diesem Leitfaden erfahren Sie mehr darüber, wie Regeln auf eingehende Anfragen angewendet werden.

Wählen Sie ein Produkt aus, um mehr über die zugehörigen Regeln zu erfahren.

Cloud Firestore

Grundstruktur

Firebase Security Rules in Cloud Firestore und Cloud Storage hat 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 wichtigen Konzepte sollten Sie beim Erstellen der Regeln kennen:

Anfrage: Die Methode oder Methoden, die in der allow-Anweisung aufgerufen werden. Das sind Methoden, die Sie zulassen. Die Standardmethoden sind: get, list, create, update und delete. Die Methoden read und write ermöglichen umfassenden 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 Version 2 der Firebase-Sicherheitsregeln verfügbar. In Version 2 der Sicherheitsregeln wird das Verhalten von rekursiven Platzhaltern {name=**} verändert. Sie müssen Version 2 verwenden, wenn Sie Sammlungsgruppenabfragen verwenden möchten. Sie müssen Version 2 aktivieren, indem Sie rules_version = '2'; als erste Zeile in Ihren Sicherheitsregeln festlegen:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {

Übereinstimmende Pfade

Alle Match-Anweisungen sollten auf Dokumente und nicht auf Sammlungen verweisen. Eine Match-Anweisung kann auf ein bestimmtes Dokument verweisen, z. B. in match /cities/SF, oder Platzhalter verwenden, um auf ein beliebiges Dokument im angegebenen Pfad zu verweisen, z. B. in match /cities/{city}.

In dem Beispiel oben verwendet die Match-Anweisung die Platzhaltersyntax {city}. Das bedeutet, dass die Regel für alle Dokumente in der Sammlung cities gilt, z. B. für /cities/SF oder /cities/NYC . Wenn die allow-Ausdrücke in der Match-Anweisung ausgewertet werden, wird die city-Variable in den Namen des Stadtdokuments aufgelöst, z. B. SF oder NYC .

Übereinstimmende Untersammlungen

Daten in Cloud Firestore sind in Dokumentensammlungen organisiert. Jedes Dokument kann die Hierarchie durch untergeordnete Sammlungen (Untersammlungen) erweitern. Für die Nutzung der Hierarchie ist es wichtig zu verstehen, wie Sicherheitsregeln mit hierarchischen Daten interagieren.

Betrachten Sie die Situation, in der jedes Dokument in der Sammlung cities eine Untersammlung landmarks enthält. Sicherheitsregeln gelten nur für den übereinstimmenden Pfad. Daher gelten die in der Sammlung cities definierten Zugriffssteuerungen nicht für die Untersammlung landmarks. Um den Zugriff auf untergeordnete Sammlungen zu steuern, müssen Sie stattdessen explizite Regeln schreiben:

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 bezieht sich der Pfad der inneren match-Anweisung immer auf den Pfad der äußeren match-Anweisung. Die folgenden Regelsätze sind daher äquivalent:

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=**}:

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 Platzhaltersyntax enthält die Platzhaltervariable das gesamte übereinstimmende Pfadsegment, auch wenn sich das Dokument in einer tief verschachtelten Untersammlung befindet. Die oben aufgeführten Regeln würden beispielsweise mit einem Dokument unter /cities/SF/landmarks/coit_tower übereinstimmen und der Wert der document-Variable wäre SF/landmarks/coit_tower.

Beachten Sie jedoch, dass das Verhalten rekursiver Platzhalter von der Regelversion abhängt.

Version 1

Sicherheitsregeln verwenden standardmäßig Version 1. In Version 1 entsprechen rekursive Platzhalter einem oder mehreren Pfadelementen. Sie stimmen nicht mit einem leeren Pfad überein. match /cities/{city}/{document=**} entspricht also Dokumenten in Untersammlungen, aber nicht mit Dokumenten in der Sammlung cities überein. Dagegen stimmt match /cities/{document=**} mit beiden Dokumenten in der Sammlung cities und mit Untersammlungen überein.

Rekursive Platzhalter müssen am Ende einer Match-Anweisung stehen.

Version 2

In Version 2 der Sicherheitsregeln entsprechen rekursive Platzhalter null oder mehr Pfadelementen. match/cities/{city}/{document=**} stimmt mit Dokumenten in allen Untersammlungen sowie mit Dokumenten in der Sammlung cities überein.

Sie müssen die Version 2 aktivieren, indem Sie rules_version = '2'; oben in Ihren Sicherheitsregeln hinzufügen:

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 überall in der Match-Anweisung platzieren. 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 Abfragen von Sammlungsgruppen verwenden, müssen Sie die Version 2 verwenden, siehe Abfragen von Sammlungsgruppen schützen.

Überlappende Match-Anweisungen

Es ist möglich, dass ein Dokument mit mehr als einer match-Anweisung übereinstimmt. Falls mehrere allow-Ausdrücke mit einer Anfrage übereinstimmen, wird der Zugriff erlaubt, wenneine 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 oberen Beispiel werden alle Lese- und Schreibzugriffe auf die Sammlung cities erlaubt, weil die zweite Regel immer true ist, obwohl die erste Regel immer false ist.

Beschränkungen für Sicherheitsregeln

Beachten Sie bei der Arbeit mit Sicherheitsregeln die folgenden Beschränkungen:

Limit	Details
Maximale Anzahl `exists()`-, `get()`- und `getAfter()`-Aufrufe pro Anfrage	10 für Einzeldokumentanfragen und Abfrage-Anfragen. 20 für Lesevorgänge, Transaktionen und Batch-Schreibvorgänge für mehrere Dokumente. Das vorherige Limit von 10 gilt auch für jeden Vorgang. Angenommen, Sie erstellen eine Batch-Schreibanfrage mit 3 Schreibvorgängen und Ihre Sicherheitsregeln verwenden 2 Dokumentzugriffsaufrufe, um jeden Schreibvorgang zu validieren. In diesem Fall verwendet jeder Schreibvorgang 2 von seinen 10 Zugriffsaufrufen und die Batch-Schreibanfrage 6 von ihren 20 Zugriffsaufrufen. Das Überschreiten eines dieser Limits führt zu einem Fehler mit Berechtigungsverweigerung. Einige Dokumentzugriffsaufrufe können zwischengespeichert werden. Zwischengespeicherte Aufrufe werden nicht in die Limits einberechnet.
Maximale Tiefe verschachtelter `match`-Anweisungen	10
Maximale Pfadlänge in Pfadsegmenten, die innerhalb eines Satzes von verschachtelten `match`-Anweisungen zulässig ist	100
Maximale Anzahl Pfaderfassungsvariablen, die in einem Satz verschachtelter `match`-Anweisungen zulässig ist	20
Maximale Funktionsaufruftiefe	20
Maximale Anzahl Funktionsargumente	7
Maximale Anzahl `let`-Variablenbindungen pro Funktion	10
Maximale Anzahl rekursiver oder zyklischer Funktionsaufrufe	0 (nicht zulässig)
Maximale Anzahl bewerteter Ausdrücke pro Anfrage	1.000
Maximale Größe eines Regelsatzes	Regelsätze müssen zwei Größenbeschränkungen genügen: Ein Limit von 256 KB für die Größe der Textquelle des Regelsatzes, die über die Firebase Console oder die Befehlszeile mit `firebase deploy` veröffentlicht wird. Ein Limit von 250 KB für die Größe des kompilierten Regelsatzes, der entsteht, wenn Firebase die Quelle verarbeitet und im Backend aktiviert.

Cloud Storage

Grundstruktur

Firebase Security Rules in Cloud Firestore und Cloud Storage hat 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 wichtigen Konzepte sollten Sie beim Erstellen der Regeln kennen:

Anfrage: Die Methode oder Methoden, die in der allow-Anweisung aufgerufen werden. Das sind Methoden, die Sie zulassen. Die Standardmethoden sind: get, list, create, update und delete. Die Methoden read und write ermöglichen umfassenden 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.

Übereinstimmende Pfade

Cloud Storage Security Rules match die Dateipfade, die für den Zugriff auf Dateien in Cloud Storage verwendet werden. Regeln können match genaue Pfade oder Platzhalterpfade sein und auch verschachtelt werden. Wenn keine Übereinstimmungsregel eine Anfragemethode zulässt oder die Bedingung false ergibt, wird die Anfrage abgelehnt.

Genaue Ü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>;
  }
}

Platzhalterabgleich

Mithilfe von Regeln können Sie auch ein Muster mit Platzhaltern match. Ein Platzhalter ist eine benannte Variable, die entweder einen einzelnen String wie profilePhoto.png oder mehrere Pfadsegmente wie images/profilePhoto.png darstellt.

Platzhalter werden durch geschweifte Klammern um den Platzhalternamen herum erstellt, z. B. {string}. Ein Platzhalter mit mehreren Segmenten kann deklariert werden, indem dem Platzhalternamen =** hinzugefügt 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. Wenn also eine Regel, mit der die Datei übereinstimmt, den Wert true hat, ist das Ergebnis true.

In den obigen Regeln kann die Datei „images/profilePhoto.png“ gelesen werden, wenn entweder condition oder other_condition zu „wahr“ ausgewertet wird. Für die Datei „images/users/user:12345/profilePhoto.png“ gilt dagegen nur das Ergebnis von other_condition.

Eine Platzhaltervariable kann innerhalb der match-Anweisung für die Dateinamen- oder Pfadautorisierung referenziert werden:

// Another way to restrict the name of a file
match /images/{imageId} {
  allow read: if imageId == "profilePhoto.png";
}

Cloud Storage Security Rules werden nicht kaskadiert und Regeln werden nur ausgewertet, wenn der Anfragepfad mit einem Pfad mit angegebenen Regeln übereinstimmt.

Bewertung beantragen

Uploads, Downloads, Metadatenänderungen und Löschungen werden anhand der request bewertet, die an Cloud Storage gesendet wird. Die Variable request enthält den Dateipfad, unter dem die Anfrage ausgeführt wird, die Uhrzeit, zu der die Anfrage empfangen wird, und den neuen Wert für resource, wenn es sich um eine Schreibanfrage handelt. HTTP-Header und Authentifizierungsstatus sind ebenfalls enthalten.

Das request-Objekt enthält außerdem die eindeutige ID des Nutzers und die Firebase Authentication-Nutzlast im request.auth-Objekt. Weitere Informationen dazu findest du im Abschnitt Authentifizierung der Dokumentation.

Unten finden Sie eine vollständige Liste der Attribute im request-Objekt:

Attribut	Typ	Beschreibung
`auth`	map<string, string>	Wenn ein Nutzer angemeldet ist, gibt er `uid`, die eindeutige ID des Nutzers, und `token`, eine Zuordnung von Firebase Authentication JWT-Ansprüchen, an. Andernfalls ist es `null`.
`params`	map<string, string>	Ein Dictionary mit den Abfrageparametern der Anfrage.
`path`	Pfad	Ein `path`, das den Pfad angibt, unter dem die Anfrage ausgeführt wird.
`resource`	map<string, string>	Der neue Ressourcenwert, der nur in `write`-Anfragen vorhanden ist.
`time`	timestamp	Ein Zeitstempel, der die Serverzeit angibt, zu der die Anfrage ausgewertet wird.

Ressourcenbewertung

Bei der Auswertung von Regeln können Sie auch die Metadaten der hochgeladenen, heruntergeladenen, geänderten oder gelöschten Dateien berücksichtigen. So können Sie komplexe und leistungsstarke Regeln erstellen, mit denen beispielsweise nur Dateien mit bestimmten Inhaltstypen hochgeladen oder nur Dateien mit einer bestimmten Größe gelöscht werden dürfen.

Firebase Security Rules für Cloud Storage stellt Dateimetadaten im resource-Objekt 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-Anfragen geprüft werden, um die Datenintegrität zu gewährleisten.

Bei write-Anfragen (z. B. Uploads, Metadatenaktualisierungen und Löschvorgänge) können Sie zusätzlich zum resource-Objekt, das Dateimetadaten für die Datei enthält, die sich derzeit am Anfragepfad befindet, auch das request.resource-Objekt verwenden. Dieses enthält einen Teil der Dateimetadaten, die geschrieben werden sollen, sofern das Schreiben zulässig ist. Mit diesen beiden Werten können Sie die Datenintegrität gewährleisten oder Anwendungseinschränkungen wie Dateityp oder -größe erzwingen.

Unten finden Sie eine vollständige Liste der Attribute im resource-Objekt:

Attribut	Typ	Beschreibung
`name`	String	Der vollständige Name des Objekts
`bucket`	String	Der Name des Buckets, in dem sich dieses Objekt befindet.
`generation`	int	Die Google Cloud Storage-Objektgenerierung dieses Objekts.
`metageneration`	int	Die Google Cloud Storage-Objektmetagenerierung dieses Objekts.
`size`	int	Größe des Objekts in Byte.
`timeCreated`	timestamp	Ein Zeitstempel, der angibt, wann ein Objekt erstellt wurde.
`updated`	timestamp	Ein Zeitstempel, der angibt, wann ein Objekt zuletzt aktualisiert wurde.
`md5Hash`	String	Einen MD5-Hash des Objekts.
`crc32c`	String	Ein CRC32C-Hash des Objekts.
`etag`	String	Der mit diesem Objekt verknüpfte Etag.
`contentDisposition`	String	Die mit diesem Objekt verknüpfte Inhaltsdisposition.
`contentEncoding`	String	Die Inhaltscodierung, die mit diesem Objekt verknüpft ist.
`contentLanguage`	String	Die Sprache der Inhalte, die mit diesem Objekt verknüpft sind.
`contentType`	String	Der Inhaltstyp, der mit diesem Objekt verknüpft ist.
`metadata`	map<string, string>	Schlüssel/Wert-Paare für zusätzliche, vom Entwickler angegebene benutzerdefinierte Metadaten.

request.resource enthält alle diese mit Ausnahme von generation, metageneration, etag, timeCreated und updated.

Beschränkungen für Sicherheitsregeln

Beachten Sie bei der Arbeit mit Sicherheitsregeln die folgenden Beschränkungen:

Limit Details

Limit	Details
Maximale Anzahl von `firestore.exists()`- und `firestore.get()`-Aufrufen pro Anfrage	2 für Einzeldokumentanfragen und Abfrage-Anfragen. Das Überschreiten dieses Limits führt zu einem Fehler mit Berechtigungsverweigerung. Zugriffsaufrufe auf dieselben Dokumente können zwischengespeichert werden. Zwischengespeicherte Aufrufe werden nicht in die Limits einberechnet.

Maximale Anzahl von firestore.exists()- und firestore.get()-Aufrufen pro Anfrage

2 für Einzeldokumentanfragen und Abfrage-Anfragen.

Das Überschreiten dieses Limits führt zu einem Fehler mit Berechtigungsverweigerung.

Zugriffsaufrufe auf dieselben Dokumente können zwischengespeichert werden. Zwischengespeicherte Aufrufe werden nicht in die Limits einberechnet.

Vollständiges Beispiel

Zusammenfassend können Sie ein vollständiges Beispiel für Regeln für eine Lösung zum Speichern von Bildern 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
     }
   }
 }
}

Realtime Database

Grundstruktur

In Realtime Database bestehen Firebase Security Rules aus JavaScript-ähnlichen Ausdrücken in einem JSON-Dokument.

Sie verwenden die folgende Syntax:

{
  "rules": {
    "<<path>>": {
    // Allow the request if the condition for each method is true.
      ".read": <<condition>>,
      ".write": <<condition>>,
      ".validate": <<condition>>
    }
  }
}

Die Regel besteht aus drei grundlegenden Elementen:

Pfad:Der Speicherort der Datenbank. Dies entspricht der JSON-Struktur Ihrer Datenbank.
Anfrage:Dies sind die Methoden, mit denen die Regel den Zugriff gewährt. Die read- und write-Regeln gewähren umfassenden Lese- und Schreibzugriff, während validate-Regeln als sekundäre Bestätigung dienen, um den Zugriff basierend auf eingehenden oder vorhandenen Daten zu gewähren.
Bedingung:Bedingung, die eine Anfrage zulässt, wenn sie als wahr ausgewertet wird.

Anwendung von Regeln auf Pfade

In Realtime Database werden Rules atomar angewendet. Das bedeutet, dass Regeln auf übergeordneten Knoten höherer Ebene Regeln auf detaillierteren untergeordneten Knoten überschreiben 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 dabei die folgenden Regeln:

{
  "rules": {
     "foo": {
        // allows read to /foo/*
        ".read": "data.child('baz').val() === true",
        "bar": {
          // ignored, since read was allowed already
          ".read": false
        }
     }
  }
}

Mit dieser Sicherheitsstruktur kann /bar/ gelesen werden, wenn /foo/ ein untergeordnetes Element baz mit dem Wert true enthält. Die Regel ".read": false unter /foo/bar/ hat hier keine Auswirkungen, da der Zugriff nicht über einen untergeordneten Pfad widerrufen werden kann.

Dieser Teil der Regelsprache ist zwar nicht sofort intuitiv, bietet aber sehr leistungsfähige Funktionen und ermöglicht die Implementierung sehr komplexer Zugriffsberechtigungen mit minimalem Aufwand. Das ist besonders für die nutzerbasierte Sicherheit nützlich.

.validate-Regeln werden jedoch nicht kaskadiert. Damit ein Schreibvorgang zulässig ist, müssen alle Validierungsregeln auf allen Ebenen der Hierarchie erfüllt sein.

Da Regeln nicht auf übergeordnete Pfade angewendet werden, schlagen Lese- oder Schreibvorgänge fehl, wenn sich am angeforderten Speicherort oder an einem übergeordneten Speicherort keine Regel befindet, die den 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
      }
    }
  }
}

Wenn Sie nicht wissen, dass Regeln atomar ausgewertet werden, könnte es so aussehen, als würde beim Abrufen des Pfads /records/ rec1 zurückgegeben, 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
});

Objective-C

Hinweis:Dieses Firebase-Produkt ist für das App-Clip-Ziel nicht verfügbar.

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
}];

Swift

Hinweis:Dieses Firebase-Produkt ist für das App-Clip-Ziel nicht verfügbar.

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
  });
});

REST

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 ein PERMISSION_DENIED-Fehler ausgegeben. Wenn wir diese Regel im Sicherheitssimulator in der Firebase-Konsole auswerten, sehen wir, dass der Lesevorgang abgelehnt wurde:

Attempt to read /records with auth=Success(null)
    /
    /records

No .read rule allowed the operation.
Read was denied.

Der Vorgang wurde abgelehnt, da keine Leseregel den Zugriff auf den Pfad /records/ erlaubte. Die Regel für rec1 wurde jedoch nie ausgewertet, da sie sich nicht im 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
});

Objective-C

Hinweis:Dieses Firebase-Produkt ist für das App-Clip-Ziel nicht verfügbar.

FIRDatabaseReference *ref = [[FIRDatabase database] reference];
[[ref child:@"records/rec1"] observeSingleEventOfType:FEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) {
    // SUCCESS!
}];

Swift

Hinweis:Dieses Firebase-Produkt ist für das App-Clip-Ziel nicht verfügbar.

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
  }
});

REST

curl https://docs-examples.firebaseio.com/rest/records/rec1
# SUCCESS!

Standortvariable

Realtime Database Rules unterstützt eine $location-Variable zum Abgleichen von Pfadsegmenten. Verwenden Sie das Präfix $ vor dem 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 $variable auch parallel zu 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 }
      }
    }
  }