Sicherheitsregeln für Pipelinevorgänge

Pipeline-Vorgänge bieten zwar eine Vielzahl von Funktionen, die Rules Engine ist jedoch auf die Erkennung von Vergleichs- (z.B. >) und logischen (z.B. or) Filtern beschränkt, um die Einhaltung von Einschränkungen und die Sicherheit zu gewährleisten.

Unterstützte Filterausdrücke

Damit Pipelinevorgänge auf die durch Ihre Regeln festgelegten Grenzen beschränkt werden, müssen logische Operatoren 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(...)

Hinweis: Komplexe Ausdrücke wie Arithmetik in einem Filter (z. B. where(eq("foo" * 2, 10))) oder Stringfunktionen wie strContains werden nicht für die Einschränkung von Abfragen erkannt.

Anfrage-Properties

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 Pipelinevorgängen nicht unterstützt.

Unterstützte Properties

Die neue Engine unterstützt weiterhin die folgenden Eigenschaften:

• request.auth: Auf Nutzer-UID und Tokendaten zugreifen.
• 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 die Überprüfung von Pipeline-Vorgangsregeln nicht unterstützt, da es schwierig ist, diese Werte in mehrstufigen Abfragen zu ermitteln.

Verarbeitung und Berechtigungen für Pipelinephasen

Es gibt verschiedene Pipelinestufen, die bestimmten detaillierten Vorgängen in Sicherheitsregeln zugeordnet werden:

• allow list-Berechtigungen: Werden durch die Phasen collection(), collectionGroup() und database() ausgelöst.
• allow get-Berechtigungen: Werden durch die documents()-Phase ausgelöst, die ähnlich wie ein get-Batchvorgang behandelt wird.
• Literale-Phase: In der literals()-Phase werden keine Daten aus der Datenbank gelesen, es können aber 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 der Feldänderung

Regeln werden nur auf gespeicherte Daten angewendet, nicht auf abgeleitete Werte. 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, sollten Sie Ihre Filterphasen (z.B. 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 (Denied): Diese Regel lehnt die folgende Pipeline ab, da die addFields-Phase vor dem Filtern nach Dokumenten erfolgt, in denen visibility gleich public ist:

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: Diese Regel lässt die folgende Pipeline zu, weil 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();