Google is committed to advancing racial equity for Black communities. See how.
Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

Wie Sicherheitsregeln funktionieren

Sicherheit kann eines der komplexesten Teile des App-Entwicklungspuzzles 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) verwaltet.

Firebase-Sicherheitsregeln entfernen die mittlere (Server-) Ebene und ermöglichen es Ihnen, pfadbasierte Berechtigungen für Clients anzugeben, die eine direkte Verbindung zu Ihren Daten herstellen. In diesem Handbuch 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 Speicher 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 sind wichtig, um sie beim Erstellen der Regeln zu verstehen:

  • Anforderung: Die Methode oder Methoden, die in der allow Anweisung aufgerufen werden. Dies sind Methoden, die Sie ausführen dürfen. Die Standardmethoden sind: get , list , create , update und delete . Die bequemen read und write 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 Anforderung zulässt, wenn sie als wahr ausgewertet wird.

Sicherheitsregeln Version 2

Ab Mai 2019 ist Version 2 der Firebase-Sicherheitsregeln verfügbar. Version 2 der Regeln ändert das Verhalten rekursiver Platzhalter {name=**} . Sie müssen Version 2 verwenden, wenn Sie Sammlungsgruppenabfragen verwenden möchten . Sie müssen sich für Version 2 rules_version = '2'; indem Sie rules_version = '2'; Die erste Zeile in Ihren Sicherheitsregeln:

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

Übereinstimmende Pfade

Alle Übereinstimmungsanweisungen sollten auf Dokumente verweisen, nicht auf Sammlungen. Eine Übereinstimmungsanweisung kann auf ein bestimmtes Dokument verweisen, wie in match /cities/SF oder Platzhalter verwenden, um auf ein Dokument im angegebenen Pfad zu verweisen, wie in match /cities/{city} .

Im obigen Beispiel verwendet die match-Anweisung die Wildcard-Syntax {city} . Dies bedeutet, dass die Regel für alle Dokumente in der cities , z. B. /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 im 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 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 ist der Pfad der inneren match immer relativ zum Pfad der äußeren match . 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 Platzhalter-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. Beispielsweise stimmen die oben aufgeführten Regeln mit einem Dokument /cities/SF/landmarks/coit_tower , das sich unter /cities/SF/landmarks/coit_tower , und der Wert der document 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 stimmen rekursive Platzhalter mit einem oder mehreren Pfadelementen überein. Sie stimmen nicht mit einem leeren Pfad match /cities/{city}/{document=**} , daher stimmt match /cities/{city}/{document=**} mit Dokumenten in Untersammlungen überein, jedoch nicht in der cities , während match /cities/{document=**} mit beiden Dokumenten in übereinstimmt cities Sammlung und Untersammlungen.

Rekursive Platzhalter müssen am Ende einer Übereinstimmungsanweisung stehen.

Version 2

In Version 2 der Sicherheitsregeln stimmen rekursive Platzhalter mit null oder mehr Pfadelementen überein. match/cities/{city}/{document=**} entspricht Dokumente in beliebigen Subkollektionen sowie Dokumente in den cities Sammlung.

Sie müssen sich für Version 2 rules_version = '2'; indem Sie rules_version = '2'; hinzufügen rules_version = '2'; ganz oben auf 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 Übereinstimmungsanweisung haben, aber in Version 2 können Sie diesen Platzhalter an einer beliebigen Stelle in der Übereinstimmungsanweisung 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 Übereinstimmungsanweisungen

Es ist möglich, dass ein Dokument mit mehr als einer match . 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;
    }
  }
}

Im obigen Beispiel sind alle Lese- und Schreibvorgänge in der cities zulässig, da die zweite Regel immer true , obwohl die erste Regel immer false .

Sicherheitsregelgrenzen

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

Grenze Einzelheiten
Maximale Anzahl exists() , get() und getAfter() Aufrufe pro Anforderung
  • 10 für Einzeldokumentanforderungen und Abfrageanforderungen.
  • 20 für Lese-, Transaktions- und Stapelschreibvorgänge mit mehreren Dokumenten. Die vorherige Grenze von 10 gilt auch für jede Operation.

    Stellen Sie sich beispielsweise vor, Sie erstellen eine Stapelschreibanforderung mit drei Schreibvorgängen und Ihre Sicherheitsregeln verwenden zwei 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 einer der beiden Grenzwerte führt zu einem Fehler, dem die Berechtigung verweigert wurde.

Einige Dokumentzugriffsaufrufe werden möglicherweise zwischengespeichert, und zwischengespeicherte Anrufe zählen nicht für die Grenzwerte.

Maximale Tiefe verschachtelter match 10
Maximale Pfadlänge in Pfadsegmenten, die innerhalb einer Reihe verschachtelter match zulässig ist 100
Maximale Anzahl von Pfaderfassungsvariablen, die in einer Reihe verschachtelter match zulässig sind 20
Maximale Funktionsaufruftiefe 20
Maximale Anzahl von Funktionsargumenten 7
Maximale Anzahl von let variablen Bindungen pro Funktion 10
Maximale Anzahl rekursiver oder zyklischer Funktionsaufrufe 0 (nicht erlaubt)
Maximale Anzahl von Ausdrücken, die pro Anforderung ausgewertet werden 1.000
Maximale Größe eines Regelsatzes Verax-Regelsätze müssen zwei Größenbeschränkungen einhalten:
  • Eine Beschränkung von 256 KB für die Größe der Textquelle des Verax-Regelsatzes, die von der Firebase-Konsole oder von der CLI mithilfe von firebase deploy .
  • Eine Beschränkung der Größe des kompilierten Regelsatzes auf 250 KB, die sich ergibt, wenn Firebase die Verax-Quelle verarbeitet und im Back-End aktiviert.

Cloud-Speicher

Grundstruktur

Firebase-Sicherheitsregeln in Cloud Firestore und Speicher 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 sind wichtig, um sie beim Erstellen der Regeln zu verstehen:

  • Anforderung: Die Methode oder Methoden, die in der allow Anweisung aufgerufen werden. Dies sind Methoden, die Sie ausführen dürfen. Die Standardmethoden sind: get , list , create , update und delete . Die bequemen read und write 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 Anforderung zulässt, wenn sie als wahr ausgewertet wird.

Übereinstimmende Pfade

Die Speichersicherheitsregeln match den Dateipfaden match die für den Zugriff auf Dateien im Cloud-Speicher verwendet werden. Regeln können match genaue Pfade oder Wildcard - Pfade und Regeln auch verschachtelt werden können. Wenn keine Übereinstimmungsregel eine Anforderungsmethode zulässt oder die Bedingung als false ausgewertet wird, wird die Anforderung 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>;
  }
}

Platzhalter-Übereinstimmungen

Regeln können auch verwendet werden, match ein Muster mithilfe von Platzhaltern abzugleichen. Ein Platzhalter ist eine benannte Variable, die entweder eine einzelne Zeichenfolge wie profilePhoto.png oder mehrere profilePhoto.png wie images/profilePhoto.png .

Ein Platzhalter wird erstellt, indem um den Platzhalternamen geschweifte Klammern wie {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. Das heißt, wenn eine Regel, mit der die Datei übereinstimmt, mit 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 true ausgewertet wird, während die Datei "images / users / user: 12345 / profilePhoto.png" nur dem Ergebnis other_condition .

Auf eine Platzhaltervariable kann innerhalb der match verwiesen werden. match den Dateinamen oder die Pfadberechtigung an:

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

Speichersicherheitsregeln kaskadieren nicht und Regeln werden nur ausgewertet, wenn der Anforderungspfad mit einem Pfad mit den angegebenen Regeln übereinstimmt.

Bewertung anfordern

Uploads, Downloads, Änderungen und Löschungen von Metadaten werden anhand der an Cloud Storage gesendeten request ausgewertet. Die request enthält den Dateipfad, in dem die Anforderung ausgeführt wird, den Zeitpunkt, zu dem die Anforderung empfangen wird, und den neuen resource , wenn die Anforderung ein Schreibvorgang ist. HTTP-Header und Authentifizierungsstatus sind ebenfalls enthalten.

Das request enthält auch die eindeutige ID des Benutzers und die Nutzdaten für die Firebase-Authentifizierung im Objekt request.auth , die im Abschnitt Authentifizierung der Dokumente näher erläutert werden.

Eine vollständige Liste der Eigenschaften im request unten:

Eigentum Art Beschreibung
auth map <string, string> Wenn ein Benutzer angemeldet ist, gibt er uid , die eindeutige ID des Benutzers und das token , eine Karte mit Firebase-Authentifizierungsansprüchen von JWT. Andernfalls ist es null .
params map <string, string> Karte mit den Abfrageparametern der Anforderung.
path Pfad Ein path der den Pfad darstellt, auf dem die Anforderung ausgeführt wird.
resource map <string, string> Der neue Ressourcenwert, der nur bei write .
time Zeitstempel Ein Zeitstempel, der die Serverzeit darstellt, zu der die Anforderung ausgewertet wird.

Ressourcenbewertung

Bei der Auswertung 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, mit denen beispielsweise nur Dateien mit bestimmten Inhaltstypen hochgeladen oder nur Dateien mit einer bestimmten Größe gelöscht werden können.

Die Firebase-Sicherheitsregeln für Cloud-Speicher stellen Dateimetadaten im resource bereit, die Schlüssel / Wert-Paare der in einem Cloud-Speicherobjekt aufgetauchten Metadaten enthalten. Diese Eigenschaften können bei read oder write überprüft werden, um die Datenintegrität sicherzustellen.

Bei write (z. B. Uploads, Aktualisierungen und Löschungen von Metadaten) können Sie zusätzlich zum resource , das Dateimetadaten für die Datei enthält, die derzeit im Anforderungspfad vorhanden ist, auch das Objekt request.resource . Dies enthält eine Teilmenge der zu schreibenden Dateimetadaten, wenn das Schreiben zulässig 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 unten:

Eigentum Art Beschreibung
name Zeichenfolge Der vollständige Name des Objekts
bucket Zeichenfolge Der Name des Buckets, in dem sich dieses Objekt befindet.
generation int Die GCS-Objektgenerierung dieses Objekts.
metageneration int Die GCS-Objektmetageneration dieses Objekts.
size int Die Größe des Objekts in Bytes.
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 Zeichenfolge Ein MD5-Hash des Objekts.
crc32c Zeichenfolge Ein crc32c-Hash des Objekts.
etag Zeichenfolge Das mit diesem Objekt verknüpfte Etag.
contentDisposition Zeichenfolge Die diesem Objekt zugeordnete Inhaltsdisposition.
contentEncoding Zeichenfolge Die diesem Objekt zugeordnete Inhaltscodierung.
contentLanguage Zeichenfolge Die diesem Objekt zugeordnete Inhaltssprache.
contentType Zeichenfolge Der diesem Objekt zugeordnete Inhaltstyp.
metadata map <string, string> Schlüssel / Wert-Paare zusätzlicher, vom Entwickler angegebener benutzerdefinierter Metadaten.

request.resource enthält alle diese request.resource mit Ausnahme von 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
     }
   }
 }
}

Echtzeitdatenbank

Grundstruktur

In der Echtzeitdatenbank 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>>
    }
  }
}

Die Regel enthält drei Grundelemente:

  • Pfad: Der Datenbankspeicherort. Dies spiegelt die JSON-Struktur Ihrer Datenbank wider.
  • Anforderung: Dies sind die Methoden, mit denen die Regel den Zugriff gewährt. Die read und write gewähren einen breiten Lese- und Schreibzugriff, während validate als sekundäre Überprüfung dienen, um den Zugriff basierend auf eingehenden oder vorhandenen Daten zu gewähren.
  • Bedingung: Die Bedingung, die eine Anforderung zulässt, wenn sie als wahr ausgewertet wird.

Wie Regeln für Pfade gelten

In der Echtzeitdatenbank gelten Regeln atomar. Dies 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 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/ , wenn /foo/ einen baz mit dem Wert true . Die Regel ".read": false unter /foo/bar/ hat hier keine Auswirkung, da der Zugriff nicht durch einen untergeordneten Pfad widerrufen werden kann.

Dies scheint zwar nicht sofort intuitiv zu sein, ist jedoch ein wichtiger Bestandteil 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 .validate jedoch nicht. Alle Validierungsregeln müssen auf allen Hierarchieebenen erfüllt sein, damit ein Schreibvorgang zulässig ist.

Da Regeln nicht für einen übergeordneten Pfad gelten, schlägt der Lese- oder Schreibvorgang fehl, wenn am angeforderten Speicherort oder an einem übergeordneten Speicherort, der den Zugriff gewährt, keine Regel vorhanden ist. 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, scheint es, als würde das Abrufen des Pfads /records/ rec1 , nicht jedoch 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
  });
});
SICH AUSRUHEN
curl https://docs-examples.firebaseio.com/rest/records/
# response returns a PERMISSION_DENIED error

Da die Leseoperation bei /records/ atomar ist und es keine PERMISSION_DENIED gibt, die den Zugriff auf alle Daten unter /records/ gewährt, wird ein Fehler PERMISSION_DENIED . Wenn wir diese Regel im Sicherheitssimulator in unserer Firebase-Konsole auswerten, können wir feststellen, 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 rec1 den Zugriff auf den Pfad /records/ zuließ. Beachten Sie jedoch, dass die Regel für rec1 nie ausgewertet wurde, da sie nicht in dem von uns angeforderten Pfad enthalten war. Um rec1 , 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
  }
});
SICH AUSRUHEN
curl https://docs-examples.firebaseio.com/rest/records/rec1
# SUCCESS!

Standortvariable

Echtzeit-Datenbankregeln unterstützen eine $location Variable, die mit Pfadsegmenten übereinstimmt. 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 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 }
      }
    }
  }