Mit Firebase-Sicherheitsregeln 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 erstellen, um jeden Vorgang zu steuern, von allen Schreibvorgängen in Ihren Cloud Storage-Bucket bis hin zu Vorgängen für eine bestimmte Datei.
In diesem Handbuch werden die grundlegende Syntax und Struktur von Cloud Storage-Sicherheitsregeln zum Erstellen vollständiger Regelsätze beschrieben.
Dienst- und Datenbankdeklaration
Firebase-Sicherheitsregeln für Cloud-Speicher beginnen immer mit der folgenden Erklärung:
service firebase.storage {
// ...
}
Die Deklaration des service firebase.storage
beschränkt die Regeln auf Cloud Storage und verhindert so Konflikte zwischen Cloud Storage-Sicherheitsregeln und Regeln für andere Produkte wie Cloud Firestore.
Grundlegende Lese-/Schreibregeln
Grundregeln bestehen aus einer match
Anweisung, die Cloud Storage-Buckets identifiziert, einer Match-Anweisung, die einen Dateinamen angibt, und einem allow
, der detailliert angibt, wann das Lesen der angegebenen Daten zulässig ist. allow
Ausdrücke geben die beteiligten Zugriffsmethoden (z. B. Lesen, Schreiben) und Bedingungen an, unter denen der Zugriff entweder erlaubt oder verweigert wird.
In Ihrem Standardregelsatz verwendet die erste match
Anweisung einen {bucket}
-Platzhalterausdruck, um anzugeben, dass die Regeln für alle Buckets in Ihrem Projekt gelten. Wir werden die Idee von Wildcard-Matches im nächsten Abschnitt ausführlicher besprechen.
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, wie in match /images/profilePhoto.png
.
Passen Sie Wildcards an
Zusätzlich zum Verweis auf eine einzelne Datei können Regeln Platzhalter verwenden, um auf jede Datei zu verweisen, deren Name ein bestimmtes Zeichenfolgenpräfix enthält, einschließlich Schrägstrichen, wie in match /images/{imageId}
.
Im obigen Beispiel verwendet die Match-Anweisung die Platzhaltersyntax {imageId}
. Dies bedeutet, dass die Regel für alle Dateien gilt, deren Name /images/
am Anfang steht, beispielsweise /images/profilePhoto.png
oder /images/croppedProfilePhoto.png
. Wenn die allow
in der Match-Anweisung ausgewertet werden, wird die Variable imageId
in den Bilddateinamen aufgelöst, z. B. profilePhoto.png
“ oder croppedProfilePhoto.png
“.
Innerhalb der match
kann auf eine Platzhaltervariable verwiesen werden, um eine Dateinamen- oder Pfadautorisierung bereitzustellen:
// 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 innerhalb eines Cloud Storage-Buckets keine hierarchische Struktur. Durch die Verwendung einer Dateinamenskonvention, 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-Sicherheitsregeln mit diesen Dateinamen interagieren.
Stellen Sie sich die Situation einer Reihe von Dateien vor, deren Namen alle mit dem Stamm /images/
beginnen. Firebase-Sicherheitsregeln gelten nur für den übereinstimmenden Dateinamen, daher gelten die für den /images/
-Stamm definierten Zugriffskontrollen nicht für den /mp3s/
-Stamm. Schreiben Sie stattdessen explizite Regeln, die verschiedenen Dateinamenmustern entsprechen:
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 zwei Regelsätze sind daher gleichwertig:
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>;
}
}
}
Rekursive Match-Wildcards
Zusätzlich zu Platzhaltern, die Zeichenfolgen am Ende eines Dateinamens abgleichen und zurückgeben, kann für komplexere Übereinstimmungen ein Platzhalter mit mehreren Segmenten deklariert werden, indem =**
zum Platzhalternamen hinzugefügt wird, wie zum Beispiel {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. Das heißt, wenn eine Regel, mit der die Datei übereinstimmt, als true
ausgewertet wird, ist das Ergebnis true
.
In den obigen Regeln kann die Datei „images/profilePhoto.png“ gelesen werden, wenn entweder condition
“ oder other_condition
“ als wahr ausgewertet wird, während die Datei „images/users/user:12345/profilePhoto.png“ nur dem Ergebnis von other_condition
unterliegt .
Cloud Storage-Sicherheitsregeln werden nicht kaskadiert und Regeln werden nur ausgewertet, wenn der Anforderungspfad mit einem Pfad mit angegebenen Regeln übereinstimmt.
Version 1
Firebase-Sicherheitsregeln verwenden standardmäßig Version 1. In Version 1 stimmen rekursive Platzhalter mit einem oder mehreren Dateinamenelementen überein, nicht mit null oder mehreren Elementen. Somit match /images/{filenamePrefixWildcard}/{imageFilename=**}
einem Dateinamen wie /images/profilePics/profile.png, aber nicht /images/badge.png. Verwenden Sie stattdessen /images/{imagePrefixorFilename=**}
.
Rekursive Platzhalter müssen am Ende einer Match-Anweisung stehen.
Aufgrund der leistungsstärkeren Funktionen empfehlen wir Ihnen die Verwendung von Version 2.
Version 2
In Version 2 der Firebase-Sicherheitsregeln stimmen rekursive Platzhalter mit null oder mehr Pfadelementen überein. Somit stimmt /images/{filenamePrefixWildcard}/{imageFilename=**}
mit den Dateinamen /images/profilePics/profile.png und /images/badge.png überein.
Sie müssen sich für Version 2 anmelden, indem Sie rules_version = '2';
ganz oben in Ihren Sicherheitsregeln:
rules_version = '2';
service cloud.storage {
match /b/{bucket}/o {
...
}
}
Sie können höchstens einen rekursiven Platzhalter pro Match-Anweisung verwenden, aber in Version 2 können Sie diesen Platzhalter an einer beliebigen Stelle in der Match-Anweisung platzieren. Zum 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>;
}
}
}
Granulare Operationen
In manchen Situationen ist es sinnvoll, read
und write
in detailliertere Vorgänge aufzuteilen. Beispielsweise möchte Ihre App möglicherweise andere Bedingungen für die Dateierstellung als für das Löschen von Dateien erzwingen.
Ein read
kann in get
und list
unterteilt werden.
Eine write
kann in create
, update
und delete
unterteilt 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
mit einer Anfrage übereinstimmen, wird der Zugriff zugelassen, wenn eine 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 Schreibvorgänge in 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 sichern und mit der Ausführung von Dateivorgängen beginnen, denken Sie daran, dass Sicherheitsregeln keine Filter sind. Sie können keine Vorgänge für eine Reihe von Dateien ausführen, die einem Dateinamenmuster entsprechen, und erwarten, dass Cloud Storage nur auf die Dateien zugreift, für die der aktuelle Client eine Zugriffsberechtigung hat.
Nehmen Sie zum Beispiel 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';
}
}
}
Verweigert : Diese Regel lehnt die folgende Anfrage ab, da der Ergebnissatz Dateien enthalten kann, bei denen contentType
nicht image/png
ist:
Netz
filesRef = storage.ref().child("aFilenamePrefix"); filesRef.listAll() .then(function(result) { console.log("Success: ", result.items); }) });
Regeln in Cloud Storage-Sicherheitsregeln bewerten jede Abfrage anhand ihres potenziellen Ergebnisses und schlagen die Anforderung fehl, wenn sie eine Datei zurückgeben könnte, für die der Client keine Leseberechtigung hat. Zugriffsanfragen müssen den durch Ihre Regeln festgelegten Einschränkungen entsprechen.
Nächste Schritte
Sie können Ihr Verständnis der Firebase-Sicherheitsregeln für Cloud-Speicher vertiefen:
Lernen Sie das nächste Hauptkonzept der Regelsprache kennen: dynamische Bedingungen , mit denen Ihre Regeln die Benutzerberechtigung überprüfen, vorhandene und eingehende Daten vergleichen, eingehende Daten validieren und vieles mehr.
Sehen Sie sich typische Sicherheitsanwendungsfälle und die Definitionen der Firebase-Sicherheitsregeln an, die diese behandeln .
Sie können Anwendungsfälle für Firebase-Sicherheitsregeln speziell für Cloud-Speicher erkunden: