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 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 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 angibt, einer Übereinstimmungsanweisung, die einen Dateinamen angibt, und einem allow-Ausdruck, der festlegt, wann das Lesen der angegebenen Daten erlaubt ist. Mit allow-Ausdrücken werden die beteiligten Zugriffsmethoden (z.B. Lesen, Schreiben) und die Bedingungen angegeben, unter denen der Zugriff entweder zugelassen oder abgelehnt wird.

In Ihrer Standardregelsammlung verwendet die erste match-Anweisung einen {bucket}-Platzhalterausdruck, 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 jede 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 mit Strings am Ende eines Dateinamens übereinstimmen und diese 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.

rules_version = '2';
service cloud.storage {
  match /b/{bucket}/o {
   ...
 }
}

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 untergliedert 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:

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 Regelsprache 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: