Sicherheitsregeln für Pipelinevorgänge

Pipeline-Vorgänge bieten zwar eine Vielzahl von Funktionen, die Rules Engine ist jedoch auf die Erkennung von Vergleichsfiltern (z.B. >) und logischen Filtern (z.B. or) beschränkt, 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-Stufen und Berechtigungen

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

• allow list -Berechtigungen: Werden durch die Stufen collection(), collectionGroup() und database() ausgelöst.
• allow get-Berechtigungen: Werden durch die Stufe documents() ausgelöst, die ähnlich wie ein Batch-Vorgang get behandelt wird.
• Literale-Stufe: Die Stufe literals() liest nicht aus der Datenbank, kann aber Kosten verursachen. Um Missbrauch zu verhindern, muss sie mit einer anderen Stufe (z. B. collection()) kombiniert werden, die durch Regeln überprüft werden kann.

Stufen zur Feldänderung

Regeln werden nur auf gespeicherte Daten und nicht auf abgeleitete Werte angewendet. Wenn eine Pipeline Stufen enthält, die Felder ändern (z. B. add_fields(...), replace_with(...), select(...), remove_fields(...)), wendet die Rules Engine nach dieser Stufe keine Filterbeschränkungen mehr an. Damit Regeln wie erwartet funktionieren, platzieren Sie Ihre Filterstufen (d.h. where) vor allen Stufen, die die ursprünglich gespeicherten Dokumente ändern 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 Stufe addFields vor dem Filtern nach Dokumenten mit visibility gleich public erfolgt:

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"))) Stufe vor allen Änderungsstufen erfolgt:

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