Grundlegende Syntax der Firebase-Sicherheitsregeln für Cloud Storage

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 erstellen, um beliebige Vorgänge zu steuern – von sämtlichen Schreibvorgängen in Ihrem 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 zum Erstellen vollständiger Regelsätze beschrieben.

Dienste und Datenbanken deklarieren

Firebase Security Rules für Cloud Storage beginnen immer mit der folgenden Deklaration:

service firebase.storage {
    // ...
}

Die Deklaration service firebase.storage weist die Regeln Cloud Storage zu und verhindert Konflikte zwischen Cloud Storage Security Rules und Regeln für andere Produkte wie Cloud Firestore.

Grundlegende Lese-/Schreibregeln

Grundlegende Regeln bestehen aus einer match-Anweisung, die Cloud Storage-Buckets identifiziert, einer Match-Anweisung, die einen Dateinamen angibt, und einem allow-Ausdruck, der festlegt, wann das Lesen der angegebenen Daten erlaubt ist. allow-Ausdrücke geben die beteiligten Zugriffsmethoden (z.B. Lesen, Schreiben) und Bedingungen an, unter denen der Zugriff entweder gewährt oder verweigert wird.

Im Standardregelsatz wird in der ersten match-Anweisung der Platzhalterausdruck {bucket} verwendet, um anzugeben, dass die Regeln für alle Buckets in Ihrem Projekt gelten. Das Konzept von Platzhalterübereinstimmungen wird im nächsten Abschnitt näher erläutert.

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 abgleichen

Rules kann nicht nur auf eine einzelne Datei verweisen, sondern auch Platzhalter verwenden, um auf alle Dateien mit einem bestimmten Stringpräfix im Namen zu verweisen, einschließlich Schrägstrichen, 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 Bilddateinamen aufgelöst, z. B. profilePhoto.png oder croppedProfilePhoto.png.

Eine Platzhaltervariable kann über match referenziert werden, um die Autorisierung von Dateinamen oder Pfaden zu ermöglichen:

// 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. Wenn wir jedoch eine Dateibenennungskonvention verwenden, die oft Schrägstriche in Dateinamen enthält, können wir eine Struktur simulieren, die wie eine verschachtelte Reihe von Verzeichnissen und Unterverzeichnissen aussieht. Es ist wichtig zu verstehen, wie Firebase Security Rules mit diesen Dateinamen interagiert.

Stellen Sie sich eine Reihe von Dateien vor, deren Namen alle mit dem Stamm /images/ beginnen. Firebase Security Rules gelten nur für den übereinstimmenden Dateinamen. Daher gelten die im /images/-Stamm definierten Zugriffssteuerungen nicht für den /mp3s/-Stamm. 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>;
      }
  }
}

Rekursive Platzhalter für den Abgleich

Zusätzlich zu Platzhaltern, die mit Strings am Ende eines Dateinamens übereinstimmen und diese zurückgeben, kann ein Platzhalter mit mehreren Segmenten für komplexere Übereinstimmungen deklariert werden, indem dem Platzhalternamen =** hinzugefügt wird, 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, die auf die Datei zutrifft, 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 „true“ ausgewertet werden. Die Datei „images/users/user:12345/profilePhoto.png“ unterliegt nur dem 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 Dateinamen-Elementen, nicht null oder mehr Elementen. Daher stimmt match /images/{filenamePrefixWildcard}/{imageFilename=**} 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 Ihnen, Version 2 zu verwenden, da sie leistungsstärkere Funktionen bietet.

Version 2

In Version 2 von Firebase Security Rules entsprechen rekursive Platzhalter null oder mehr Pfadelementen. Daher entspricht /images/{filenamePrefixWildcard}/{imageFilename=**} 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 App 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 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-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 Beispiel oben sind alle Lese- und Schreibzugriffe auf Dateien, deren Name mit /images/ beginnt, zulässig, weil 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 Dateivorgängen beginnen, müssen Sie beachten, dass Sicherheitsregeln keine Filter sind. Sie können keine Vorgänge für 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 (Denied): 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 müsste, 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:

Hier finden Sie Firebase Security Rules-Anwendungsfälle für Cloud Storage: