Bedingungen für Cloud Firestore-Sicherheitsregeln schreiben

Dieser Leitfaden baut auf der Strukturierung Sicherheitsregeln Führung zu zeigen , wie die Bedingungen Ihre Wolke Firestor Sicherheit Regeln hinzuzufügen. Wenn Sie nicht vertraut mit den Grundlagen der Cloud Firestor Sicherheitsregeln sind, finden Sie in der Ersten Schritt Führung.

Der primäre Baustein der Cloud Firestore-Sicherheitsregeln ist die Bedingung. Eine Bedingung ist ein boolescher Ausdruck, der bestimmt, ob eine bestimmte Operation zugelassen oder abgelehnt werden soll. Verwenden Sie Sicherheitsregeln, um Bedingungen zu schreiben, die die Benutzerauthentifizierung überprüfen, eingehende Daten validieren oder sogar auf andere Teile Ihrer Datenbank zugreifen.

Authentifizierung

Eines der gängigsten Sicherheitsregelmuster ist die Zugriffssteuerung basierend auf dem Authentifizierungsstatus des Benutzers. Ihre App möchte beispielsweise nur angemeldeten Benutzern erlauben, Daten zu schreiben:

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow the user to access documents in the "cities" collection
    // only if they are authenticated.
    match /cities/{city} {
      allow read, write: if request.auth != null;
    }
  }
}

Ein weiteres gängiges Muster besteht darin, sicherzustellen, dass Benutzer nur ihre eigenen Daten lesen und schreiben können:

service cloud.firestore {
  match /databases/{database}/documents {
    // Make sure the uid of the requesting user matches name of the user
    // document. The wildcard expression {userId} makes the userId variable
    // available in rules.
    match /users/{userId} {
      allow read, update, delete: if request.auth != null && request.auth.uid == userId;
      allow create: if request.auth != null;
    }
  }
}

Wenn Ihre App Firebase - Authentifizierung oder verwendet Google Cloud Identity - request.auth Plattform , die request.auth enthält Variable , die die Authentifizierungsinformationen für den Client Daten anfordert. Weitere Informationen über request.auth finden Sie in der Referenzdokumentation .

Datenvalidierung

Viele Apps speichern Zugriffskontrollinformationen als Felder in Dokumenten in der Datenbank. Cloud Firestore-Sicherheitsregeln können den Zugriff basierend auf Dokumentdaten dynamisch zulassen oder verweigern:

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow the user to read data if the document has the 'visibility'
    // field set to 'public'
    match /cities/{city} {
      allow read: if resource.data.visibility == 'public';
    }
  }
}

Die resource Variable bezieht sich auf das angeforderte Dokument und resource.data ist eine Karte von allen Feldern und in dem Dokument gespeicherten Werte. Weitere Informationen zu der resource Variable finden Sie in der Referenzdokumentation .

Beim Schreiben von Daten möchten Sie möglicherweise eingehende Daten mit vorhandenen Daten vergleichen. In diesem Fall, wenn Sie Ihre Regeln den anstehenden Schreib erlaubt, die request.resource enthält Variable , um den zukünftigen Zustand des Dokuments. Für update - Operationen , die nur eine Teilmenge der Dokumentfelder ändern, die request.resource wird Variable den anstehende Dokument Zustand nach der Operation enthält. Sie können die Feldwerte in überprüfen request.resource , um unerwünschten oder inkonsistenten Daten - Updates zu verhindern:

service cloud.firestore {
  match /databases/{database}/documents {
    // Make sure all cities have a positive population and
    // the name is not changed
    match /cities/{city} {
      allow update: if request.resource.data.population > 0
                    && request.resource.data.name == resource.data.name;
    }
  }
}

Auf andere Dokumente zugreifen

Unter Verwendung der get() und exists() Funktionen können Sie Ihre Sicherheitsregeln auswerten eingehende Anfragen gegen andere Dokumente in der Datenbank. Die get() und exists() Funktionen beide erwarten vollständig spezifizierte Dokumentenpfade. Wenn Variablen Konstrukt Pfade für die Verwendung von get() und exists() , müssen Sie explizit Variablen entkommen , die mit $(variable) Syntax.

Im Beispiel unten, die database wird variabel durch die Übereinstimmung Anweisung erfaßt match /databases/{database}/documents und verwendet , um den Pfad zu bilden:

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      // Make sure a 'users' document exists for the requesting user before
      // allowing any writes to the 'cities' collection
      allow create: if request.auth != null && exists(/databases/$(database)/documents/users/$(request.auth.uid))

      // Allow the user to delete cities if their user document has the
      // 'admin' field set to 'true'
      allow delete: if request.auth != null && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true
    }
  }
}

Für schreibt, können Sie die Verwendung getAfter() Funktion , um den Zustand eines Dokuments nach einer Transaktion oder Charge schreibt abgeschlossen ist zuzugreifen, bevor die Transaktion oder Batch - Commits. Wie get() , die getAfter() nimmt Funktion eine vollständig spezifizierte Dokumentpfad. Sie können mit getAfter() Sätze von Schreibvorgängen zu definieren, den Ort zusammen als eine Transaktion oder Batch erfolgen muss.

Auf Anruflimits zugreifen

Es gibt ein Limit für Dokumentzugriffsaufrufe pro Regelsatzauswertung:

  • 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.

Eine ausführliche Erläuterung, wie diese Grenzen Transaktionen und batched schreibt beeinflussen, finden Sie im Handbuch für atomare Operationen zu sichern .

Zugriff auf Anrufe und Preise

Die Verwendung dieser Funktionen führt einen Lesevorgang in Ihrer Datenbank aus, dh das Lesen von Dokumenten wird Ihnen auch dann in Rechnung gestellt, wenn Ihre Regeln die Anforderung ablehnen. Siehe Wolke Firestor Preise für spezifischere Rechnungsinformationen.

Benutzerdefinierte Funktionen

Wenn Ihre Sicherheitsregeln komplexer werden, möchten Sie möglicherweise Bedingungssätze in Funktionen einschließen, die Sie in Ihrem Regelsatz wiederverwenden können. Sicherheitsregeln unterstützen benutzerdefinierte Funktionen. Die Syntax für benutzerdefinierte Funktionen ähnelt ein wenig JavaScript, aber Sicherheitsregelfunktionen sind in einer domänenspezifischen Sprache geschrieben, die einige wichtige Einschränkungen aufweist:

  • Funktionen können nur eine einzige enthalten return - Anweisung. Sie können keine zusätzliche Logik enthalten. Sie können beispielsweise keine Schleifen ausführen oder externe Dienste aufrufen.
  • Funktionen können automatisch auf Funktionen und Variablen aus dem Bereich zugreifen, in dem sie definiert sind. Zum Beispiel kann eine Funktion innerhalb des definierten service cloud.firestore Umfang hat Zugriff auf die resource Variable und integrierte Funktionen wie get() und exists() .
  • Funktionen können andere Funktionen aufrufen, aber nicht rekursiv sein. Die Gesamttiefe der Aufrufliste ist auf 10 begrenzt.
  • In Regeln Version v2 können Funktionen Variablen definieren die Verwendung von let - Schlüsselwort. Funktionen können bis zu 10 let-Bindungen haben, müssen jedoch mit einer return-Anweisung enden.

Eine Funktion wird mit dem definierten function Schlüsselwort und nimmt null oder mehr Argumente. Sie können beispielsweise die beiden in den obigen Beispielen verwendeten Bedingungstypen in einer einzigen Funktion kombinieren:

service cloud.firestore {
  match /databases/{database}/documents {
    // True if the user is signed in or the requested data is 'public'
    function signedInOrPublic() {
      return request.auth.uid != null || resource.data.visibility == 'public';
    }

    match /cities/{city} {
      allow read, write: if signedInOrPublic();
    }

    match /users/{user} {
      allow read, write: if signedInOrPublic();
    }
  }
}

Durch die Verwendung von Funktionen in Ihren Sicherheitsregeln werden diese mit zunehmender Komplexität Ihrer Regeln leichter wartbar.

Regeln sind keine Filter

Wenn Sie Ihre Daten sichern und mit dem Schreiben von Abfragen beginnen, denken Sie daran, dass Sicherheitsregeln keine Filter sind. Sie können keine Abfrage für alle Dokumente in einer Sammlung schreiben und erwarten, dass Cloud Firestore nur die Dokumente zurückgibt, auf die der aktuelle Client Zugriff hat.

Nehmen Sie beispielsweise die folgende Sicherheitsregel:

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow the user to read data if the document has the 'visibility'
    // field set to 'public'
    match /cities/{city} {
      allow read: if resource.data.visibility == 'public';
    }
  }
}

Verweigert: Diese Regel weist die folgende Abfrage , da die Ergebnismenge Dokumente enthalten kann , wo die visibility nicht ist public :

Netz
db.collection("cities").get()
    .then(function(querySnapshot) {
        querySnapshot.forEach(function(doc) {
            console.log(doc.id, " => ", doc.data());
    });
});

Erlaubt: Diese Regel erlaubt die folgende Abfrage , da die in where("visibility", "==", "public") Klausel garantiert , dass die Ergebnismenge erfüllt die Bedingung der Regel:

Netz
db.collection("cities").where("visibility", "==", "public").get()
    .then(function(querySnapshot) {
        querySnapshot.forEach(function(doc) {
            console.log(doc.id, " => ", doc.data());
        });
    });

Cloud Firestore-Sicherheitsregeln werten jede Abfrage anhand ihres potenziellen Ergebnisses aus und schlagen die Anforderung fehl, wenn ein Dokument zurückgegeben werden könnte, für das der Client keine Leseberechtigung hat. Abfragen müssen den Einschränkungen Ihrer Sicherheitsregeln entsprechen. Weitere Informationen über die Sicherheitsregeln und Abfragen finden Abfrage Daten sicher .

Nächste Schritte