Join us for Firebase Summit on November 10, 2021. Tune in to learn how Firebase can help you accelerate app development, release with confidence, and scale with ease. Register

So funktionieren Sicherheitsregeln

Sicherheit kann eines der komplexesten Puzzleteile der App-Entwicklung sein. In den meisten Anwendungen müssen Entwickler einen Server erstellen und ausführen, 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 sich direkt mit Ihren Daten verbinden. In diesem Leitfaden erfahren Sie mehr darüber, wie Regeln auf eingehende Anforderungen 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>>
  }
}

Es ist wichtig, die folgenden Schlüsselkonzepte beim Erstellen der Regeln zu verstehen:

  • Anforderung: Das Verfahren oder die aufgerufenen Methoden in der allow Aussage. Dies sind Methoden, die Sie ausführen dürfen. Die Standardmethoden sind: get , list , create , update und delete . Die read und write Methoden ermöglichen breite Lese- und Schreibzugriff auf die angegebene Datenbank oder Speicherpfad.
  • Pfad: Die Datenbank oder Speicherort, als URI - Pfad dargestellt.
  • Regel: Die allow Anweisung, die eine Bedingung enthält , die eine Anforderung erlaubt , wenn es true ergibt.

Sicherheitsregeln Version 2

Ab Mai 2019 ist jetzt Version 2 der Firebase-Sicherheitsregeln verfügbar. Version 2 der Regeln ändert das Verhalten von rekursiven Platzhalter {name=**} . Sie müssen Version 2 verwenden , wenn Sie verwenden möchten Abfragen Sammelgruppe . Sie müssen Opt-in auf Version 2 , indem rules_version = '2'; die erste Zeile in Ihren Sicherheitsregeln:

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

Passende Pfade

Alle Match-Anweisungen sollten auf Dokumente verweisen, nicht auf Sammlungen. Eine Übereinstimmung Anweisung kann auf ein bestimmtes Dokument verweisen, wie in match /cities/SF oder Platzhalter verwenden , um Punkt auf jedes Dokument in dem angegebenen Pfad, wie in match /cities/{city} .

In dem obigen Beispiel verwendet das Spiel Anweisung , um die {city} Wildcard - Syntax. Das heißt , die Regel in der zu jedem Dokument gilt cities Sammlung, wie /cities/SF oder /cities/NYC . Wenn die allow Ausdrücke in der Match - Anweisung ausgewertet werden, die city wird variabel in die Stadt Dokumentnamen, wie lösen SF oder NYC .

Passende Untersammlungen

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 wir die Situation , in der jedes Dokument in den cities Kollektion enthält landmarks Untersammlung. Sicherheitsregeln gelten nur in dem Anpassungspfad, so dass die Zugriffskontrollen auf der definierten cities Sammlung nicht auf die Anwendung der landmarks Untersammlung. Schreiben Sie stattdessen explizite Regeln, um den Zugriff auf Untersammlungen zu kontrollieren:

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

Wenn Verschachtelung match Anweisungen, der Weg der inneren match ist Aussage auf den Pfad der äußeren immer relativ match Aussage. 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 Sie Regeln auf eine beliebig tiefe Hierarchie anwenden möchten, 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 Platzhaltersyntax enthält die Platzhaltervariable das gesamte übereinstimmende Pfadsegment, auch wenn sich das Dokument in einer tief verschachtelten Untersammlung befindet. Zum Beispiel aufgeführten Regeln oben würde ein Dokument befindet passen /cities/SF/landmarks/coit_tower , und der Wert des 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 haben nicht einen leeren Pfad übereinstimmen, so match /cities/{city}/{document=**} trifft Dokumente in Subkollektionen aber nicht in den cities Sammlung, während match /cities/{document=**} passt beide Dokumente in der cities Sammlung und Subkollektionen.

Rekursive Wildcards 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=**} entspricht Dokumente in beliebigen Subkollektionen sowie Dokumente in den cities Sammlung.

Sie müssen Opt-in auf Version 2 durch Zugabe von 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 verwenden, aber in Version 2 können Sie diesen Platzhalter an einer beliebigen 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 Sammelgruppenabfragen , müssen Sie Version 2 verwenden , sehen Sammlung Gruppenabfragen sichern .

Überlappende Match-Statements

Es ist möglich , dass ein Dokument mehr als eine passen match Aussage. In dem Fall , in dem mehrere allow Ausdrücke eine Anfrage übereinstimmen, wird der Zugriff erlaubt , wenn eine der Bedingungen ist 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;
    }
  }
}

In dem obigen Beispiel alle Lese- und Schreibvorgänge in die cities Sammlung erlaubt werden, weil die zweite Regel immer ist true , auch wenn die erste Regel ist immer false .

Grenzwerte für Sicherheitsregeln

Beachten Sie beim Arbeiten mit Sicherheitsregeln die folgenden Beschränkungen:

Grenze Einzelheiten
Maximale Anzahl der exists() ist get() getAfter() exists() , get() und getAfter() ruft pro Anfrage
  • 10 für Einzeldokumentanforderungen und Abfrageanforderungen.
  • 20 für Multi-Dokument-Lesevorgänge, Transaktionen und Schreibvorgänge im Stapel. Die bisherige Grenze von 10 gilt auch für jeden Vorgang.

    Stellen Sie sich beispielsweise vor, Sie erstellen eine Batch-Schreibanforderung mit 3 Schreibvorgängen und Ihre Sicherheitsregeln verwenden 2 Dokumentzugriffsaufrufe, um jeden Schreibvorgang zu validieren. In diesem Fall verwendet jeder Schreibvorgang 2 seiner 10 Zugriffsaufrufe und die gestapelte Schreibanforderung verwendet 6 seiner 20 Zugriffsaufrufe.

Das Überschreiten eines der Grenzwerte führt zu einem Berechtigungsverweigerungsfehler.

Einige Dokumentzugriffsaufrufe können zwischengespeichert werden, und zwischengespeicherte Aufrufe zählen nicht zu den Grenzwerten.

Maximale verschachtelte match Anweisung Tiefe 10
Maximale Pfadlänge, in Pfadsegmente, innerhalb eines Satzes von verschachtelten erlaubt match Aussagen 100
Maximale Anzahl der Pfaderfassung Variablen erlaubt innerhalb eines Satzes von verschachtelten match - Anweisungen 20
Maximale Tiefe des Funktionsaufrufs 20
Maximale Anzahl von Funktionsargumenten 7
Maximale Anzahl an let Variablenbindungen pro Funktion 10
Maximale Anzahl rekursiver oder zyklischer Funktionsaufrufe 0 (nicht zulässig)
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:
  • eine 256 KB Grenze für die Größe der ruleset Textquelle von der Firebase - Konsole oder von der Verwendung von CLI veröffentlicht firebase deploy .
  • eine Beschränkung von 250 KB für die Größe des kompilierten Regelsatzes, die entsteht, wenn Firebase die Quelle verarbeitet und im Back-End aktiviert.

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

Es ist wichtig, die folgenden Schlüsselkonzepte beim Erstellen der Regeln zu verstehen:

  • Anforderung: Das Verfahren oder die aufgerufenen Methoden in der allow Aussage. Dies sind Methoden, die Sie ausführen dürfen. Die Standardmethoden sind: get , list , create , update und delete . Die read und write Methoden ermöglichen breite Lese- und Schreibzugriff auf die angegebene Datenbank oder Speicherpfad.
  • Pfad: Die Datenbank oder Speicherort, als URI - Pfad dargestellt.
  • Regel: Die allow Anweisung, die eine Bedingung enthält , die eine Anforderung erlaubt , wenn es true ergibt.

Passende Pfade

Cloud Storage Sicherheitsregeln match die Dateipfade verwendet , um Zugriff auf Dateien in Cloud Storage. Regeln können match genaue Pfade oder Wildcard - Pfade und Regeln auch verschachtelt werden können. Wenn keine Übereinstimmung Regel eine Anforderungsmethode oder die Bedingung das Ergebnis erlaubt es false , wird die Anforderung verweigert.

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

Wildcard-Übereinstimmungen

Regeln können auch verwendet werden , um match mit Wildcards ein Muster. Ein Platzhalter ist eine benannte Variable, die entweder eine einzelne Zeichenfolge wie repräsentiert profilePhoto.png oder mehrere Pfadsegmente, wie beispielsweise images/profilePhoto.png .

Ein Platzhalter wird durch Zugabe von geschweiften Klammern um den Platzhalter - Namen, wie erstellt {string} . Eine Multi - Segment - Wildcard kann durch Zugabe deklariert werden =** zu dem Platzhalter Namen, wie {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 eine Datei übereinstimmt, ist das Ergebnis der OR des Ergebnisses aller Regeln Auswertungen. Das heißt, wenn eine Regel die Datei auswertet , um übereinstimmt true , ist das Ergebnis true .

In den oben genannten Regeln kann die Datei „images / profilePhoto.png“ gelesen werden , wenn entweder condition oder other_condition zu true ausgewertet, während die Datei „images / users / user: 12345 / profilePhoto.png“ auf das Ergebnis nur Gegenstand ist other_condition .

Ein Wildcard - Variable kann aus dem referenziert wird match liefern Dateinamen oder Pfad Berechtigung:

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

Cloud Storage-Sicherheitsregeln kaskadieren nicht und Regeln werden nur ausgewertet, wenn der Anfragepfad mit einem Pfad mit den angegebenen Regeln übereinstimmt.

Bewertung anfordern

Uploads, Downloads, Metadaten Änderungen und Löschungen werden mit dem ausgewertet request an Cloud Storage gesendet. Der request enthält den Dateipfad , in dem die Anforderung ausgeführt wird, die Zeit , wenn die Anforderung empfangen wird , und den neuen resource , wenn die Anforderung eine Schreib ist. HTTP-Header und Authentifizierungsstatus sind ebenfalls enthalten.

Die request - Objekt enthält auch die eindeutige ID des Benutzers und die Firebase Authentication Nutzlast in dem request.auth Objekt, das weiter in dem erläutert wird Authentication Abschnitt der Dokumentation.

Eine vollständige Liste der Eigenschaften in der request Objekt ist verfügbar unter:

Eigentum Typ Beschreibung
auth map<string, string> Wenn ein Benutzer angemeldet ist, liefert uid , die eindeutige ID des Benutzers und token , eine Karte von Firebase Authentication JWT Ansprüche. Andernfalls wird es null .
params map<string, string> Map mit den Abfrageparametern der Anfrage.
path Weg Ein path , die den Pfad der Anforderung an durchgeführt wird.
resource map<string, string> Der neue Ressourcenwert, präsentiert nur auf write
time Zeitstempel Ein Zeitstempel, der die Serverzeit darstellt, zu der die Anforderung 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 nur das Hochladen von Dateien mit bestimmten Inhaltstypen oder das Löschen von Dateien ab einer bestimmten Größe zulassen.

Firebase Sicherheitsregeln für Cloud Storage bieten Datei - Metadaten in dem resource - Objekt, das in einem Cloud - Storage - Objekt aufgetaucht Schlüssel / Wert - Paare des Metadaten enthält. Diese Eigenschaften können auf inspiziert werden read oder write an die Datenintegrität sicherzustellen.

Auf write (wie Uploads, Metadaten Aktualisierungen und Löschungen), zusätzlich zu dem resource die Datei - Metadaten für die Datei enthält , die derzeit auf dem Anfragepfad vorhanden ist , haben Sie auch die Möglichkeit , das verwenden request.resource Objekt, 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 zu erzwingen.

Eine vollständige Liste der Eigenschaften in dem resource - Objekt ist verfügbar unter:

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 Objekterzeugung dieses Objekts.
metageneration int Die Google Cloud Storage - Objekt metageneration dieses Objekts.
size int Die Größe des Objekts in Byte.
timeCreated Zeitstempel Ein Zeitstempel, der die Zeit angibt, zu der ein Objekt erstellt wurde.
updated Zeitstempel Ein Zeitstempel, der die Zeit angibt, zu der ein Objekt zuletzt aktualisiert wurde.
md5Hash Schnur Ein MD5-Hash des Objekts.
crc32c Schnur Ein crc32c-Hash des Objekts.
etag Schnur Das mit diesem Objekt verknüpfte E-Tag.
contentDisposition Schnur Die diesem Objekt zugeordnete Inhaltsdisposition.
contentEncoding Schnur Die mit diesem Objekt verknüpfte Inhaltscodierung.
contentLanguage Schnur Die mit diesem Objekt verknüpfte Inhaltssprache.
contentType Schnur Der diesem Objekt zugeordnete Inhaltstyp.
metadata map<string, string> Schlüssel/Wert-Paare zusätzlicher, vom Entwickler spezifizierter benutzerdefinierter Metadaten.

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

Vollständiges Beispiel

Wenn Sie alles zusammenfassen, 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 Speicherort der Datenbank. Dies spiegelt die JSON-Struktur Ihrer Datenbank wider.
  • Anfrage: Dies sind die Methoden der Regel Anwendungen Zugriff zu gewähren. Die read und write gewähren breite Lese- und Schreibzugriff, während validate Regeln als sekundäre Überprüfung zur Gewährung des Zugangs handeln basierend auf eingehenden oder bestehende Daten.
  • Zustand: Der Zustand, der eine Anforderung erlaubt , wenn es true ergibt.

So gelten Regeln für Pfade

In der Echtzeitdatenbank gelten Regeln atomar, was bedeutet, dass Regeln auf übergeordneten übergeordneten Knoten 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 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 erlaubt /bar/ zu aus gelesen werden , wenn /foo/ enthält ein Kind baz mit dem Wert true . Die ".read": false Regel unter /foo/bar/ hat keinen Einfluss hier, da der Zugang nicht von einem Kind Weg widerrufen werden kann.

Auch wenn es nicht sofort intuitiv erscheinen mag, 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 benutzerbasierte Sicherheit .

Allerdings .validate Regeln nicht kaskadiert werden . Alle Validierungsregeln müssen auf allen Ebenen der Hierarchie erfüllt sein, damit ein Schreibvorgang zulässig ist.

Da Regeln nicht wieder auf einen übergeordneten Pfad angewendet werden, schlagen außerdem Lese- oder Schreibvorgänge fehl, wenn am angeforderten Speicherort oder an einem übergeordneten Speicherort keine Regel vorhanden ist, die den Zugriff gewährt. Selbst wenn auf alle betroffenen untergeordneten Pfade 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 die Regeln atomar ausgewertet werden, könnte es scheinen , wie das Abrufen der /records/ Pfad zurückkehren würde rec1 aber nicht rec2 . Das eigentliche 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
  });
});
SICH AUSRUHEN
curl https://docs-examples.firebaseio.com/rest/records/
# response returns a PERMISSION_DENIED error

Da der Lesevorgang bei /records/ atomar ist , und es gibt keine Lese Regel , dass gewährt den Zugriff auf alle Daten unter /records/ , dies einen werfen PERMISSION_DENIED Fehler. Wenn wir diese Regel im Sicherheits Simulator in unserer bewerten Firebase - Konsole , können wir sehen , dass die Leseoperation verweigert wurde:

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

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

Der Betrieb wurde abgelehnt , weil keine Lese Regel Zugriff auf die erlaubten /records/ Pfad, aber beachten Sie, dass die Regel für rec1 nie ausgewertet worden , weil es nicht im Weg war , dass wir angefordert. Holen rec1 , müssten wir es direkt zugreifen zu können :

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
  }
});
SICH AUSRUHEN
curl https://docs-examples.firebaseio.com/rest/records/rec1
# SUCCESS!

Standortvariable

Realtime Datenbank - Regeln unterstützen eine $location variable Pfadsegmente entsprechen. Verwenden Sie den $ Präfix vor dem Pfadsegment der Regel auf alle untergeordneten Knoten auf dem Weg zu entsprechen.

  {
    "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 auch die Verwendung $variable parallel zu konstanten Pfadnamen.

  {
    "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 }
      }
    }
  }