Grundlegende Syntax der Firebase-Sicherheitsregeln für Cloud Storage

Mit Firebase Security Rules für Cloud Storage können Sie den Zugriff auf gespeicherte Objekte steuern in Cloud Storage Buckets. 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 Struktur von Cloud Storage Security Rules beschrieben, 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, 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 die verwendeten Zugriffsmethoden (z.B. Lese- und Schreibvorgänge) und die Bedingungen angeben unter dem der Zugriff erlaubt oder verweigert 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 wie in match /images/profilePhoto.png.

Übereinstimmung mit Platzhaltern

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 jede Datei gilt, bei der /images/ am Anfang des Namens steht, wie /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.

Auf eine Platzhaltervariable kann innerhalb von match verwiesen werden, um die Datei bereitzustellen Namens- oder Pfadautorisierung:

// 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 keine hierarchische Struktur innerhalb Cloud Storage Bucket. 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.

Stellen Sie sich die Situation vor, bei dem eine Reihe von Dateien Namen hat, die alle mit dem Stamm /images/. Firebase Security Rules gilt nur für den übereinstimmenden Dateinamen, sodass der Zugriff Steuerelemente, die für den Stamm „/images/“ definiert sind, gelten nicht für den Stamm „/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 lautet der Pfad der inneren match-Anweisung wie 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 die OR der Ergebnisse aller für die Auswertung von Regeln. Das heißt, wenn eine Regel, mit der die Datei übereinstimmt, true ergibt, Ergebnis ist 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 die Anfragepfad stimmt mit einem Pfad mit angegebenen Regeln überein.

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 aufgeteilt 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 für mehrere Dateien, die einem Dateinamenmuster entsprechen, und erwarten, dass Cloud Storage nur auf sie zugreift Die Dateien, auf die der aktuelle Client zugreifen darf.

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 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.

Sehen Sie sich Firebase Security Rules-spezifische Anwendungsfälle für Cloud Storage an: