Lernen Sie die Kernsyntax der Sprache Firebase Security Rules for Cloud Storage kennen

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.

Dieser Leitfaden beschreibt die grundlegende Syntax und Struktur von Cloud Storage-Sicherheitsregeln, um vollständige Regelsätze zu erstellen.

Dienst- und Datenbankdeklaration

Firebase-Sicherheitsregeln für Cloud Storage beginnen immer mit der folgenden Deklaration:

service firebase.storage {
    // ...
}

Die service firebase.storage Deklaration ordnet die Regeln Cloud Storage zu 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 -Ausdruck, der angibt, wann das Lesen der angegebenen Daten zulässig ist. allow Ausdrücke spezifizieren die beteiligten Zugriffsmethoden (z. B. Lesen, Schreiben) und Bedingungen , 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 Platzhalterübereinstimmungen 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 Übereinstimmungsanweisungen verweisen auf Dateien. Eine Match-Anweisung kann auf eine bestimmte Datei verweisen, wie in match /images/profilePhoto.png .

Passen Sie Wildcards an

Rules kann nicht nur auf eine einzelne Datei verweisen, sondern auch Platzhalter verwenden, um auf jede Datei mit einem bestimmten Zeichenfolgenpräfix im Namen zu verweisen, einschließlich Schrägstrichen, wie in match /images/{imageId} .

Im obigen Beispiel verwendet die Match-Anweisung die Wildcard-Syntax {imageId} . Das bedeutet, dass die Regel für alle Dateien mit /images/ am Anfang ihres Namens gilt, wie etwa /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 .

Innerhalb der match kann auf eine Platzhaltervariable verwiesen 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. Aber durch die Verwendung einer Dateinamenskonvention, die häufig Schrägstriche in Dateinamen enthält, können wir 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, sodass die für den /images/ -Stamm definierten Zugriffskontrollen nicht für den /mp3s/ -Stamm gelten. 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 übereinstimmen und Zeichenfolgen am Ende eines Dateinamens zurückgeben, kann ein Platzhalter für mehrere Segmente für komplexere Übereinstimmungen deklariert werden, indem =** an den Platzhalternamen angehängt 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. Das heißt, wenn eine Regel, auf die 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 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.

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>;
   }
  }
}

Granulare Operationen

In manchen Situationen ist es hilfreich, 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.

Eine read kann in get und list aufgeteilt 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 Spielaussagen

Es ist möglich, dass ein Dateiname mehr als einer match entspricht. 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 sind alle Lese- und Schreibvorgänge in Dateien erlaubt, 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 Dateioperationen 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 Zugriffsberechtigungen 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 die Ergebnismenge Dateien enthalten kann, bei 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-Sicherheitsregeln werten jede Abfrage anhand ihres potenziellen Ergebnisses aus und lassen die Anforderung fehlschlagen, wenn sie eine Datei zurückgeben könnte, für die der Client keine Leseberechtigung hat. Zugriffsanfragen müssen den von Ihren Regeln festgelegten Einschränkungen entsprechen.

Nächste Schritte

Sie können Ihr Verständnis der Firebase-Sicherheitsregeln für Cloud Storage vertiefen:

• Lernen Sie das nächste große Konzept der Rules-Sprache kennen, dynamische Bedingungen , mit denen Ihre Rules die Benutzerautorisierung überprüfen, vorhandene und eingehende Daten vergleichen, eingehende Daten validieren und vieles mehr.

• Sehen Sie sich typische Sicherheitsanwendungsfälle und die entsprechenden Definitionen der Firebase-Sicherheitsregeln an .

Sie können die für Cloud Storage spezifischen Anwendungsfälle für Firebase-Sicherheitsregeln untersuchen: