Sicherheitsregeln für Pipelinevorgänge

Pipeline-Vorgänge bieten zwar eine Vielzahl von Funktionen, die Rules Engine kann jedoch nur Vergleichsfilter (z.B. >) und logische Filter (z.B. or) erkennen, um die Erfüllbarkeit von Einschränkungen und die Sicherheit zu gewährleisten.

Unterstützte Filterausdrücke

Damit Pipeline-Vorgänge auf die durch Ihre Regeln festgelegten Grenzen beschränkt werden, müssen logische und Vergleichsoperatoren für Konstanten verwendet werden. Die folgenden Filtertypen werden von der Rules Engine erkannt:

  • Vergleiche: eq, neq, gt, gte, lt, lte, in, arrayContains.
  • Logisch: and, or.

Hier einige Beispiele:

  • where(eq("foo", 2))
  • where(lt("foo", 2))
  • documents("/user/1", "/user/2").where(...)

Anfrageeigenschaften

Sie können das request -Objekt weiterhin verwenden, um die Authentifizierung und den Abfragekontext zu validieren. Einige Eigenschaften, die in Standardabfragen verfügbar sind, werden jedoch in Pipeline-Vorgängen nicht unterstützt.

Unterstützte Eigenschaften

Die neue Engine unterstützt weiterhin die folgenden Eigenschaften:

  • request.auth: Zugriff auf Nutzer-UID und Token-Daten.
  • request.method: Gibt den Vorgang an (z. B. get, list).
  • request.path: Der Pfad der Ressource, auf die zugegriffen wird.
  • request.time: Der serverseitige Zeitstempel der Anfrage.

Nicht unterstützte Eigenschaften

Die request.query-Eigenschaften wie limit, offset und orderBy werden für Regelprüfungen für Pipeline-Vorgänge nicht unterstützt, da es komplex ist, diese Werte in mehrstufigen Abfragen zu bestimmen.

Pipeline-Phasen und Berechtigungen

Es gibt verschiedene Pipeline-Phasen, die bestimmten detaillierten Vorgängen in Sicherheitsregeln zugeordnet sind:

  • allow list -Berechtigungen: Werden durch die Phasen collection(), collectionGroup() und database() ausgelöst.
  • allow get-Berechtigungen: Werden durch die Phase documents() ausgelöst, die ähnlich wie ein Batch-Vorgang get behandelt wird.
  • Literale-Phase: In der Phase literals() werden keine Daten aus der Datenbank gelesen, es können jedoch Kosten anfallen. Um Missbrauch zu verhindern, muss sie mit einer anderen Phase (z. B. collection()) kombiniert werden, die durch Regeln überprüft werden kann.

Phasen zur Feldänderung

Regeln werden nur auf gespeicherte Daten und nicht auf abgeleitete Werte angewendet. Wenn eine Pipeline Phasen enthält, in denen Felder geändert werden (z. B. add_fields(...), replace_with(...), select(...), remove_fields(...)), wendet die Rules Engine nach dieser Phase keine Filterbeschränkungen mehr an. Damit Regeln wie erwartet funktionieren, müssen Sie Ihre Filterphasen (d.h. where) vor allen Phasen platzieren, in denen die ursprünglich gespeicherten Dokumente geändert werden können.

Ein Beispiel ist die folgende Sicherheitsregel:

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

Abgelehnt: Diese Regel lehnt die folgende Pipeline ab, da die Phase addFields vor dem Filtern nach Dokumenten erfolgt, in denen visibility den Wert public hat:

const results = await db.pipeline()
  .collection("/cities")
  // Filters after a modification stage are ignored by Rules.
  .addFields(constant(1000).as("population"))
  .where(eq(field("visibility"), constant("public")))
  .execute();

Zugelassen (Allowed): Diese Regel lässt die folgende Pipeline zu, da die where(eq(field("visibility"), constant("public"))) Phase vor allen Änderungsphasen erfolgt:

const results = await db.pipeline()
  .collection("/cities")
  .where(eq(field("visibility"), constant("public")))
  .addFields(constant(1000).as("population"))
  .execute();