Bedingungen in Firebase Cloud Storage-Sicherheitsregeln verwenden

Dieser Leitfaden baut auf dem Leitfaden zur zentralen Syntax der Sprache Firebase Security Rules auf. um zu sehen, wie Sie der Firebase Security Rules für Cloud Storage Bedingungen hinzufügen.

Der primäre Baustein von Cloud Storage Security Rules ist die Bedingung. Eine Bedingung ist ein boolescher Ausdruck, der festlegt, ob ein bestimmter Vorgang zulässig oder nicht zulässig ist. Für grundlegende Regeln mit den Literalen true und false da die Bedingungen einwandfrei funktionieren. Aber die Firebase Security Rules für Cloud Storage Sprache bietet Ihnen die Möglichkeit, komplexere Bedingungen zu schreiben, die:

  • Nutzerauthentifizierung überprüfen
  • Eingehende Daten validieren

Authentifizierung

Firebase Security Rules für Cloud Storage wird in Firebase Authentication eingebunden, um Folgendes bereitzustellen: leistungsstarke, nutzerbasierte Authentifizierung bei Cloud Storage. So können Sie Detaillierte Zugriffssteuerung basierend auf Anforderungen eines Firebase Authentication-Tokens.

Wenn ein authentifizierter Nutzer eine Anfrage an Cloud Storage stellt, Die Variable request.auth wird mit dem uid des Nutzers gefüllt (request.auth.uid) sowie die Anforderungen des Firebase Authentication-JWT (request.auth.token).

Außerdem werden bei Verwendung der benutzerdefinierten Authentifizierung zusätzliche Ansprüche angezeigt. im Feld request.auth.token ein.

Wenn ein nicht authentifizierter Nutzer eine Anfrage ausführt, wird die Variable request.auth null.

Es gibt mehrere gängige Methoden, mithilfe der Authentifizierung Dateien:

  • Öffentlich: request.auth ignorieren
  • Privat authentifiziert: Prüfen Sie, ob request.auth nicht null ist
  • Privater Nutzer: Prüfen Sie, ob request.auth.uid mit einem Pfad uid übereinstimmt
  • Group private (Gruppe privat): Prüfen Sie die Anforderungen des benutzerdefinierten Tokens auf Übereinstimmungen mit einem ausgewählten Anspruch oder Die Metadaten der Datei lesen, um zu prüfen, ob ein Metadatenfeld vorhanden ist

Öffentlich

Jede Regel, die den Kontext request.auth nicht berücksichtigt, kann als public-Regel, da der Authentifizierungskontext des Nutzers nicht berücksichtigt wird. Diese Regeln können nützlich sein, um öffentliche Daten wie Spiel-Assets, Töne Dateien oder andere statische Inhalte.

// Anyone to read a public image if the file is less than 100kB
// Anyone can upload a public file ending in '.txt'
match /public/{imageId} {
  allow read: if resource.size < 100 * 1024;
  allow write: if imageId.matches(".*\\.txt");
}

Authentifiziert als privat

In bestimmten Fällen möchten Sie vielleicht, dass die Daten für alle authentifizierten Nutzer von nicht von nicht authentifizierten Nutzern. Da die Variable request.auth für alle nicht authentifizierten Nutzer null ist, müssen Sie nur prüfen, ob die Variable request.auth vorhanden ist, um die Authentifizierung zu erzwingen:

// Require authentication on all internal image reads
match /internal/{imageId} {
  allow read: if request.auth != null;
}

Nutzer privat

Der mit Abstand häufigste Anwendungsfall für request.auth besteht darin, einzelnen Nutzern detaillierte Berechtigungen für ihre Dateien zuzuweisen, vom Hochladen von Profilbildern bis zum Lesen privater Dokumente.

Da Dateien in Cloud Storage einen vollständigen „Pfad“ haben zur Datei hinzufügen, dass eine Datei, die von einem Nutzer gesteuert wird, eine eindeutige, im Dateinamenspräfix (z. B. uid des Nutzers), die geprüft, wenn die Regel ausgewertet wird:

// Only a user can upload their profile picture, but anyone can view it
match /users/{userId}/profilePicture.png {
  allow read;
  allow write: if request.auth.uid == userId;
}

Gruppe privat

Ein weiterer häufig vorkommender Anwendungsfall ist das Zulassen von Gruppenberechtigungen für ein Objekt, z. B. wenn mehrere Teammitglieder an einem freigegebenen Dokument zusammenarbeiten sollen. Es gibt es mehrere Ansätze:

Sobald diese Daten in den Token- oder Dateimetadaten gespeichert sind, können sie in einer Regel referenziert werden:

// Allow reads if the group ID in your token matches the file metadata's `owner` property
// Allow writes if the group ID is in the user's custom token
match /files/{groupId}/{fileName} {
  allow read: if resource.metadata.owner == request.auth.token.groupId;
  allow write: if request.auth.token.groupId == groupId;
}

Bewertung beantragen

Uploads, Downloads, Metadatenänderungen und Löschvorgänge werden mithilfe der request an Cloud Storage gesendet. Zusätzlich zur eindeutigen ID und die Firebase Authentication-Nutzlast im request.auth-Objekt, wie oben beschrieben, Die Variable request enthält den Dateipfad, unter dem die Anfrage gesendet wird. die ausgeführte Anfrage, den Zeitpunkt des Empfangs der Anfrage und den neuen Wert resource wenn die Anfrage ein Schreibvorgang ist.

Das request-Objekt enthält außerdem die eindeutige ID des Nutzers und die Firebase Authentication-Nutzlast im request.auth-Objekt. Weitere Informationen dazu findest du im Abschnitt Nutzerbasierte Sicherheit der Dokumentation.

Unten finden Sie eine vollständige Liste der Attribute im request-Objekt:

Attribut Typ Beschreibung
auth map<string, string> Wenn ein Nutzer angemeldet ist, gibt er uid, die eindeutige ID des Nutzers und token, eine Zuordnung von Firebase Authentication JWT-Anforderungen. Andernfalls wird es null
params Map<string, string> Zuordnung mit den Abfrageparametern der Anfrage.
path Pfad Ein path, der den Pfad darstellt, in dem sich die Anfrage befindet gearbeitet hat.
resource Map<string, string> Der neue Ressourcenwert, der nur in write-Anfragen vorhanden ist.
time timestamp Ein Zeitstempel, der die Serverzeit angibt, zu der die Anfrage ausgewertet wird.

Ressourcenbewertung

Bei der Auswertung von Regeln können Sie auch die Metadaten der Datei auswerten. hochgeladen, heruntergeladen, geändert oder gelöscht werden. So können Sie die beispielsweise nur Dateien mit bestimmten auszuwählen, die hochgeladen werden sollen, oder nur Dateien, die eine bestimmte Größe überschreiten, gelöscht.

Firebase Security Rules für Cloud Storage stellt Dateimetadaten in resource bereit , das Schlüssel/Wert-Paare der Metadaten enthält, die in einem Cloud Storage-Objekt. Diese Eigenschaften können bei read- oder write-Anfragen geprüft werden, um die Datenintegrität zu gewährleisten.

Bei write-Anfragen (z. B. Uploads, Metadatenaktualisierungen und Löschungen) in Zusätzlich zum resource-Objekt, das die Metadaten der Datei enthält derzeit im Anfragepfad vorhanden ist, können Sie auch den request.resource-Objekt, das eine Teilmenge der Dateimetadaten enthält, die verwendet werden sollen. geschrieben wird, wenn der Schreibvorgang erlaubt ist. Mit diesen beiden Werten können Sie sicherstellen, oder Anwendungseinschränkungen wie Dateityp oder -größe durchzusetzen.

Unten finden Sie eine vollständige Liste der Attribute im resource-Objekt:

Attribut Typ Beschreibung
name String Der vollständige Name des Objekts
bucket String Der Name des Buckets, in dem sich das Objekt befindet.
generation int Die Google Cloud Storage-Objektgenerierung dieses Objekts.
metageneration int Die Google Cloud Storage-Objektmetagenerierung dieses Objekts.
size int Größe des Objekts in Byte.
timeCreated timestamp Ein Zeitstempel, der angibt, wann ein Objekt erstellt wurde.
updated timestamp Ein Zeitstempel, der angibt, wann ein Objekt zuletzt aktualisiert wurde.
md5Hash String Ein MD5-Hash des Objekts.
crc32c String CRC32C-Hash des Objekts
etag String Der mit diesem Objekt verknüpfte Etag.
contentDisposition String Die mit diesem Objekt verknüpfte Inhaltsanordnung.
contentEncoding String Die Inhaltscodierung, die diesem Objekt zugeordnet ist.
contentLanguage String Die Sprache der Inhalte, die mit diesem Objekt verknüpft sind.
contentType String Der mit diesem Objekt verknüpfte Inhaltstyp.
metadata Map<string, string> Schlüssel/Wert-Paare mit zusätzlichen, vom Entwickler angegebenen benutzerdefinierten Metadaten.

request.resource enthält alle diese mit Ausnahme von generation, metageneration, etag, timeCreated und updated.

Mit Cloud Firestore optimieren

Du kannst in Cloud Firestore auf Dokumente zugreifen, um andere Autorisierungen zu prüfen Kriterien.

Mit den Funktionen firestore.get() und firestore.exists() wird Ihre Sicherheit können eingehende Anfragen anhand von Dokumenten in Cloud Firestore ausgewertet werden. Die Funktionen firestore.get() und firestore.exists() erwarten, dass angegebene Dokumentpfade. Wenn Sie zum Erstellen von Pfaden für firestore.get() und firestore.exists() müssen explizit maskiert werden Variablen mit der $(variable)-Syntax.

Im folgenden Beispiel sehen wir eine Regel, die den Lesezugriff auf Dateien auf diese die Mitglieder bestimmter Clubs sind.

service firebase.storage {
  match /b/{bucket}/o {
    match /users/{club}/files/{fileId} {
      allow read: if club in
        firestore.get(/databases/(default)/documents/users/$(request.auth.id)).memberships
    }
  }
}
Im nächsten Beispiel können nur die Freunde eines Nutzers ihre Fotos sehen.
service firebase.storage {
  match /b/{bucket}/o {
    match /users/{userId}/photos/{fileId} {
      allow read: if
        firestore.exists(/databases/(default)/documents/users/$(userId)/friends/$(request.auth.id))
    }
  }
}

Nachdem Sie Ihre ersten Cloud Storage Security Rules erstellt und gespeichert haben, die diese Cloud Firestore verwenden Funktionen verwenden, werden Sie in der Firebase-Konsole oder der Firebase CLI aufgefordert, Berechtigungen zum Verbinden der beiden Produkte aktivieren.

Sie können das Feature deaktivieren, indem Sie eine IAM-Rolle entfernen, wie unter Firebase Security Rules verwalten und bereitstellen

Daten validieren

Firebase Security Rules für Cloud Storage kann auch für die Datenvalidierung verwendet werden, einschließlich der Validierung von Dateinamen und Pfaden sowie von Dateimetadateneigenschaften wie contentType und size.

service firebase.storage {
  match /b/{bucket}/o {
    match /images/{imageId} {
      // Only allow uploads of any image file that's less than 5MB
      allow write: if request.resource.size < 5 * 1024 * 1024
                   && request.resource.contentType.matches('image/.*');
    }
  }
}

Benutzerdefinierte Funktionen

Wenn Ihr Firebase Security Rules komplexer wird, können Sie Sätze von Bedingungen in Funktionen, die Sie in Ihrem Regelsatz wiederverwenden können. Sicherheitsregeln unterstützen benutzerdefinierte Funktionen. Die Syntax für benutzerdefinierte Funktionen ähnelt der Syntax von JavaScript, Firebase Security Rules-Funktionen sind jedoch in einer domainspezifischen Sprache geschrieben. mit einigen wichtigen Einschränkungen:

  • Funktionen können nur eine einzige return-Anweisung enthalten. Es ist keine zusätzliche Logik möglich. Sie können beispielsweise keine Schleifen ausführen. oder externe Dienste aufrufen.
  • Funktionen bieten die Möglichkeit, automatisch auf Funktionen und Variablen aus dem Bereich zuzugreifen, in dem sie definiert sind. Zum Beispiel kann eine Funktion, die in Der Bereich service firebase.storage hat Zugriff auf resource und nur für Cloud Firestore integrierte Funktionen wie z. B. get() und exists().
  • Funktionen können andere Funktionen aufrufen, werden jedoch möglicherweise nicht rekursiv. Die Tiefe des Aufrufstapels ist auf 10 begrenzt.
  • In Version rules2 können Funktionen Variablen mithilfe des Schlüsselworts let definieren. Funktionen können eine beliebige Anzahl von let-Bindungen haben, müssen aber mit einer Rückgabe enden .

Eine Funktion wird mit dem Keyword function definiert und benötigt null oder mehr Argumente. Beispielsweise können Sie die beiden in den obigen Beispielen verwendeten Bedingungsarten in einer einzigen Funktion kombinieren:

service firebase.storage {
  match /b/{bucket}/o {
    // 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 /images/{imageId} {
      allow read, write: if signedInOrPublic();
    }
    match /mp3s/{mp3Ids} {
      allow read: if signedInOrPublic();
    }
  }
}

Die Verwendung von Funktionen in Ihrem Firebase Security Rules macht diese aufgrund der Komplexität leichter zu verwalten Ihrer Regeln wächst.

Nächste Schritte

Nach dieser Besprechung der Bedingungen haben Sie einen komplexeren die Regeln kennen und bereit sind,

Sie erfahren, wie Sie mit zentralen Anwendungsfällen umgehen und lernen den Workflow für die Entwicklung, Regeln testen und bereitstellen: