Mit Firebase Security Rules für Cloud Storage können Sie den Zugriff auf Objekte steuern, die in Cloud Storage-Buckets gespeichert sind. Mit der flexiblen Regelsyntax können Sie Regeln für beliebige Vorgänge erstellen – von sämtlichen Schreibvorgängen über den Cloud Storage-Bucket bis hin zu Vorgängen in einer bestimmten Datei.
In diesem Leitfaden werden die grundlegende Syntax und die Struktur von Cloud Storage Security Rules beschrieben, um vollständige Regelsätze zu erstellen.
Dienste und Datenbanken deklarieren
Firebase Security Rules für Cloud Storage beginnt immer mit der folgenden Deklaration:
service firebase.storage {
// ...
}
Die Deklaration service firebase.storage wendet die Regeln auf Cloud Storage an, wodurch Konflikte zwischen Cloud Storage Security Rules und Regeln für andere Produkte wie Cloud Firestore vermieden werden.
Grundlegende Lese-/Schreibregeln
Grundlegende Regeln bestehen aus einer match-Anweisung, mit der Cloud Storage-Buckets angegeben werden, einer Übereinstimmungsanweisung, in der ein Dateiname angegeben wird, und einem allow-Ausdruck, der festlegt, wann das Lesen der angegebenen Daten erlaubt ist. allow-Ausdrücke geben die jeweiligen Zugriffsmethoden (z.B. Lese- und Schreibvorgänge) und die Bedingungen an, unter denen der Zugriff erlaubt oder verweigert wird.
In Ihrer Standardregelsatz wird in der ersten match-Anweisung ein {bucket}-Platzhalterausdruck verwendet, um anzugeben, dass die Regeln für alle Buckets in Ihrem Projekt gelten. Im nächsten Abschnitt gehen wir näher auf das Thema Platzhalter ein.
service firebase.storage {
// The {bucket} wildcard indicates we match files in all Cloud Storage buckets
match /b/{bucket}/o {
// Match filename
match /filename {
allow read: if <condition>;
allow write: if <condition>;
}
}
}
Alle Match-Anweisungen verweisen auf Dateien. Eine Match-Anweisung kann auf eine bestimmte Datei verweisen, z. B. in match /images/profilePhoto.png.
Platzhalter verwenden
Rules kann nicht nur auf eine einzelne Datei verweisen, sondern auch mithilfe von Platzhaltern auf eine beliebige Datei mit einem bestimmten Stringpräfix im Namen verweisen, einschließlich Schrägstriche, wie in match /images/{imageId}.
In dem Beispiel oben verwendet die Match-Anweisung die Platzhaltersyntax {imageId}.
Das bedeutet, dass die Regel für alle Dateien gilt, deren Name mit /images/ beginnt, z. B. /images/profilePhoto.png oder /images/croppedProfilePhoto.png. Wenn die allow-Ausdrücke in der Match-Anweisung ausgewertet werden, wird die imageId-Variable in den Dateinamen des Bilds aufgelöst, z. B. profilePhoto.png oder croppedProfilePhoto.png.
Eine Platzhaltervariable kann innerhalb von match referenziert werden, um eine Autorisierung für Dateinamen oder Pfade anzugeben:
// Another way to restrict the name of a file
match /images/{imageId} {
allow read: if imageId == "profilePhoto.png";
}
Hierarchische Daten
Wie bereits erwähnt, gibt es in einem Cloud Storage-Bucket keine hierarchische Struktur. Mit einer Dateibenennungskonvention, die häufig Schrägstriche in Dateinamen enthält, können wir jedoch eine Struktur nachahmen, die wie eine verschachtelte Reihe von Verzeichnissen und Unterverzeichnissen aussieht. Es ist wichtig zu verstehen, wie Firebase Security Rules mit diesen Dateinamen interagiert.
Angenommen, Sie haben eine Reihe von Dateien mit Namen, die alle mit dem Stamm /images/ beginnen. Firebase Security Rules gelten nur für den übereinstimmenden Dateinamen. Daher gelten die in der Stammdatei /images/ definierten Zugriffssteuerungen nicht für die Stammdatei /mp3s/.
Schreiben Sie stattdessen explizite Regeln, die mit verschiedenen Dateinamenmustern übereinstimmen:
service firebase.storage {
match /b/{bucket}/o {
match /images/{imageId} {
allow read, write: if <condition>;
}
// Explicitly define rules for the 'mp3s' pattern
match /mp3s/{mp3Id} {
allow read, write: if <condition>;
}
}
}
Beim Verschachteln von match-Anweisungen wird der Pfad der inneren match-Anweisung immer an den Pfad der äußeren match-Anweisung angehängt. Die folgenden beiden Regelsätze sind daher äquivalent:
service firebase.storage {
match /b/{bucket}/o {
match /images {
// Exact match for "images/profilePhoto.png"
match /profilePhoto.png {
allow write: if <condition>;
}
}
}
}
service firebase.storage {
match /b/{bucket}/o {
// Exact match for "images/profilePhoto.png"
match /images/profilePhoto.png {
allow write: if <condition>;
}
}
}
Platzhalter für rekursive Übereinstimmungen
Zusätzlich zu Platzhaltern, die Strings am Ende eines Dateinamens abgleichen und zurückgeben, kann für eine komplexere Übereinstimmung ein Platzhalter mit mehreren Segmenten deklariert werden. Dazu wird dem Platzhalternamen =** hinzugefügt, z. B. {path=**}:
// Partial match for files that start with "images"
match /images {
// Exact match for "images/**"
// e.g. images/users/user:12345/profilePhoto.png is matched
// images/profilePhoto.png is also matched!
match /{allImages=**} {
// This rule matches one or more path segments (**)
// allImages is a path that contains all segments matched
allow read: if <other_condition>;
}
}
Wenn mehrere Regeln mit einer Datei übereinstimmen, ist das Ergebnis das OR des Ergebnisses aller Regelauswertungen. Wenn also eine Regel, mit der die Datei übereinstimmt, den Wert true hat, ist das Ergebnis true.
In den obigen Regeln kann die Datei „images/profilePhoto.png“ gelesen werden, wenn entweder condition oder other_condition zu „wahr“ ausgewertet wird. Für die Datei „images/users/user:12345/profilePhoto.png“ gilt dagegen nur das Ergebnis von other_condition.
Cloud Storage Security Rules werden nicht kaskadiert und Regeln werden nur ausgewertet, wenn der Anfragepfad mit einem Pfad mit angegebenen Regeln übereinstimmt.
Version 1
Firebase Security Rules verwenden standardmäßig Version 1. In Version 1 entsprechen rekursive Platzhalter einem oder mehreren Dateinamenelementen, nicht null oder mehr Elementen. match /images/{filenamePrefixWildcard}/{imageFilename=**} stimmt also mit einem Dateinamen wie /images/profilePics/profile.png überein, aber nicht mit /images/badge.png. Verwenden Sie stattdessen /images/{imagePrefixorFilename=**}.
Rekursive Platzhalter müssen am Ende einer Match-Anweisung stehen.
Wir empfehlen Version 2 aufgrund ihrer erweiterten Funktionen.
Version 2
In Version 2 von Firebase Security Rules entsprechen rekursive Platzhalter null oder mehr Pfadelementen. /images/{filenamePrefixWildcard}/{imageFilename=**} entspricht also den Dateinamen /images/profilePics/profile.png und /images/badge.png.
Sie müssen die Version 2 aktivieren, indem Sie rules_version = '2'; oben in Ihren Sicherheitsregeln hinzufügen:
rules_version = '2';
service cloud.storage {
match /b/{bucket}/o {
...
}
}
Sie können höchstens einen rekursiven Platzhalter pro Match-Anweisung haben, aber in Version 2 können Sie diesen Platzhalter überall in der Match-Anweisung platzieren. Beispiel:
rules_version = '2';
service firebase.storage {
match /b/{bucket}/o {
// Matches any file in a songs "subdirectory" under the
// top level of your Cloud Storage bucket.
match /{prefixSegment=**}/songs/{mp3filenames} {
allow read, write: if <condition>;
}
}
}
Detaillierte Vorgänge
In manchen Fällen ist es sinnvoll, read und write in detailliertere Vorgänge zu untergliedern. Möglicherweise möchte Ihre Anwendung bei der Erstellung von Dateien andere Bedingungen erzwingen als beim Löschen von Dateien.
Ein read-Vorgang kann in get und list unterteilt werden.
Eine write-Regel kann in create, update und delete aufgeteilt werden:
service firebase.storage { match /b/{bucket}/o { // A read rule can be divided into read and list rules match /images/{imageId} { // Applies to single file read requests allow get: if <condition>; // Applies to list and listAll requests (Rules Version 2) allow list: if <condition>; // A write rule can be divided into create, update, and delete rules match /images/{imageId} { // Applies to writes to file contents allow create: if <condition>; // Applies to updates to (pre-existing) file metadata allow update: if <condition>; // Applies to delete operations allow delete: if <condition>; } } } }
Überlappende Match-Anweisungen
Es ist möglich, dass ein Dateiname mit mehr als einer match-Anweisung übereinstimmt. Falls mehrere allow-Ausdrücke mit einer Anfrage übereinstimmen, wird der Zugriff erlaubt, wenneine der Bedingungen true ist:
service firebase.storage {
match b/{bucket}/o {
// Matches file names directly inside of '/images/'.
match /images/{imageId} {
allow read, write: if false;
}
// Matches file names anywhere under `/images/`
match /images/{imageId=**} {
allow read, write: if true;
}
}
}
Im obigen Beispiel sind alle Lese- und Schreibzugriffe auf Dateien zulässig, deren Name mit /images/ beginnt, da die zweite Regel immer true ist, auch wenn die erste Regel false ist.
Regeln sind keine Filter
Wenn Sie Ihre Daten gesichert haben und mit dem Ausführen von Dateiaktionen beginnen, müssen Sie beachten, dass Sicherheitsregeln keine Filter sind. Sie können keine Vorgänge auf eine Gruppe von Dateien ausführen, die einem Dateinamenmuster entsprechen, und erwarten, dass Cloud Storage nur auf die Dateien zugreift, auf die der aktuelle Client Zugriff hat.
Ein Beispiel ist die folgende Sicherheitsregel:
service firebase.storage {
match /b/{bucket}/o {
// Allow the client to read files with contentType 'image/png'
match /aFileNamePrefix/{aFileName} {
allow read: if resource.contentType == 'image/png';
}
}
}
Abgelehnt: Diese Regel lehnt die folgende Anfrage ab, da die Ergebnismenge Dateien enthalten kann, in denen contentType nicht image/png ist:
Web
filesRef = storage.ref().child("aFilenamePrefix"); filesRef.listAll() .then(function(result) { console.log("Success: ", result.items); }) });
Regeln in Cloud Storage Security Rules werten jede Abfrage anhand ihres potenziellen Ergebnisses aus. Die Anfrage schlägt fehl, wenn eine Datei zurückgegeben werden könnte, für die der Client keine Leseberechtigung hat. Zugriffsanfragen müssen den durch Ihre Regeln festgelegten Beschränkungen entsprechen.
Nächste Schritte
Weitere Informationen zu Firebase Security Rules für Cloud Storage:
Das nächste wichtige Konzept der Rules-Sprache sind dynamische Bedingungen. Mit diesen können Sie unter anderem die Nutzerautorisierung prüfen, vorhandene und eingehende Daten vergleichen und eingehende Daten validieren.
Sehen Sie sich typische Anwendungsfälle für die Sicherheit und die zugehörigen Firebase Security Rules-Definitionen an.
Sie können sich Firebase Security Rules Anwendungsfälle für Cloud Storage ansehen: