Grundlegende Syntax der Firebase-Sicherheitsregeln für Cloud Storage

Firebase Security Rules für Cloud Storage ermöglichen Ihnen die Steuerung des Zugriffs auf Objekte, 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 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 beschrieben, mit denen Sie vollständige Regelsätze erstellen können.

Dienste und Datenbanken deklarieren

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

service firebase.storage {
    // ...
}

Die 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 Zugriffsmethoden (z.B. Lesen, Schreiben) und Bedingungen an, unter denen der Zugriff entweder erlaubt oder verweigert wird.

Im Standardregelsatz verwendet die erste match-Anweisung einen Platzhalterausdruck {bucket}, um anzugeben, dass die Regeln für alle Buckets in Ihrem Projekt gelten. Im nächsten Abschnitt gehen wir näher auf Platzhalterübereinstimmungen 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 für Übereinstimmungen

Sicherheitsregeln können nicht nur auf eine einzelne Datei verweisen, sondern auch Security Rules Platzhalter verwenden, um auf eine beliebige Datei zu verweisen, deren Name ein bestimmtes Stringpräfix enthält, einschließlich Schrägstrichen, z. B. match /images/{imageId}.

Im obigen Beispiel 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 Variable imageId in den Dateinamen des Bildes aufgelöst, z. B. profilePhoto.png oder croppedProfilePhoto.png.

Eine Platzhaltervariable kann in der match-Anweisung referenziert werden, um den Dateinamen oder den Pfad zu autorisieren:

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

Nehmen wir an, es gibt eine Reihe von Dateien, deren Namen alle mit dem Stamm /images/ beginnen. Firebase Security Rules gelten nur für den übereinstimmenden Dateinamen. Daher gelten die für den Stamm /images/ definierten Zugriffs steuerungen nicht für den Stamm /mp3s/. Stattdessen müssen Sie explizite Regeln schreiben, 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>;
    }
  }
}

Wenn Sie match-Anweisungen verschachteln, 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 Übereinstimmungen

Neben Platzhaltern, die mit Strings am Ende eines Dateinamens übereinstimmen und diese zurückgeben, kann auch ein Platzhalter für mehrere Segmente für komplexere Übereinstimmungen deklariert werden. Dazu fügen Sie dem Platzhalternamen =** hinzu, 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-Verknüpfung der Ergebnisse aller Regelauswertungen. Wenn also eine Regel, die mit der Datei übereinstimmt, zu 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 zu „true“ ausgewertet wird. Die Datei "images/users/user:12345/profilePhoto.png" unterliegt nur dem Ergebnis von other_condition.

Cloud Storage Security Rules werden nicht kaskadiert. Regeln werden nur ausgewertet, wenn der Anfragepfad mit einem Pfad übereinstimmt, für den Regeln angegeben sind.

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 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 (Security 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, 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 werden alle Lese- und Schreibzugriffe auf Dateien erlaubt, deren Name mit /images/ beginnt, 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 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 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:

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

Sie können Ihr Wissen über Firebase Security Rules für Cloud Storage vertiefen:

• Lernen Sie das nächste wichtige Konzept der Regelsprache kennen: dynamische Bedingungen. Mit diesen können Sie die Nutzerautorisierung prüfen, vorhandene und eingehende Daten vergleichen, eingehende Daten validieren und vieles mehr.

• Sehen Sie sich typische Anwendungsfälle für die Sicherheit und die Firebase Security Rules entsprechenden Definitionen an.

Sie können Firebase Security Rules Anwendungsfälle speziell für Cloud Storage untersuchen: