Lernen Sie die Kernsyntax der Firebase-Sicherheitsregeln für Cloud Storage-Sprache

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 an einer bestimmten Datei.

In diesem Leitfaden werden die grundlegende Syntax und Struktur von Cloud Storage-Sicherheitsregeln beschrieben, um vollständige Regelsätze zu erstellen.

Service- und Datenbankdeklaration

Firebase-Sicherheitsregeln für Cloud Storage beginnen immer mit der folgenden Erklärung:

service firebase.storage {
    // ...
}

Die service firebase.storage Erklärung Tive , die Regeln zu Cloud Storage, Konflikten zwischen Cloud Storage Sicherheit Regeln und Vorschriften für andere Produkte wie Cloud Firestor zu verhindern.

Grundlegende Lese-/Schreibregeln

Grundregeln bestehen aus einem match Erklärung mit Cloud Storage Eimer, eine Erklärung Spiel Angabe eines Dateinamens und eine allow Ausdruck Detaillierung , wenn die angegebenen Daten lesen darf. allow Ausdrücke die Zugriffsmethoden (zB Lesen, Schreiben) beteiligt, und die Bedingungen , unter denen Zugang entweder erlaubt oder verweigert wird angeben.

In Ihrem Standard - Regelsatz, die erste match verwendet Anweisung einen {bucket} Wildcard Ausdruck der Regeln gelten für alle Eimer in Ihrem Projekt anzuzeigen. Wir werden die Idee von Wildcard-Matches im nächsten Abschnitt genauer 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 match-Anweisungen zeigen auf Dateien. Eine Übereinstimmung Anweisung kann auf eine bestimmte Datei, wie in Punkt match /images/profilePhoto.png .

Platzhalter abgleichen

In additiont in einer einzigen Datei zu zeigen, können Regeln Platzhalter auf jede Datei zu Punkt verwenden , um mit einer bestimmten Zeichenfolge Präfix in seinem Namen, einschließlich Schrägstrichen, wie in match /images/{imageId} .

In dem obigen Beispiel verwendet das Spiel Anweisung , um die {imageId} Wildcard - Syntax. Diese Mittel gilt die Regel für jede Datei mit /images/ zu Beginn seines Namens, wie /images/profilePhoto.png oder /images/croppedProfilePhoto.png . Wenn die allow Ausdrücke in der Match - Anweisung ausgewertet werden, die imageId wird Variable auf den Bilddateinamen, wie lösen profilePhoto.png oder croppedProfilePhoto.png .

Eine Wildcard Variable kann innerhalb der referenziert werden match Dateiname oder Pfad Zulassung zur Verfügung zu stellen:

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

Betrachten Sie die Situation aus einer Reihe von Dateien mit Namen , dass alle beginnen mit dem /images/ eindämmen. Firebase Sicherheit Regeln gelten nur bei dem angepassten Dateinamen, so dass die Zugriffskontrollen auf dem definierten /images/ stem gelten nicht für die /mp3s/ eindämmen. Schreiben Sie stattdessen explizite Regeln, die verschiedenen Dateinamenmustern entsprechen:

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 Verschachtelung match Anweisungen, der Weg der inneren match ist Aussage immer auf den Pfad der äußeren beigefügtes match Aussage. 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 Match-Wildcards

Neben Platzhalter , dass Spiel und Rückkehr Saiten am Ende eines Dateinamen, eine Multi - Segment - Wildcard können durch Zugabe für komplexere Anpassungs deklariert werden =** zu dem Platzhalter Namen, wie {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 eine Datei übereinstimmt, ist das Ergebnis der OR des Ergebnisses aller Regeln Auswertungen. Das heißt, wenn eine Regel die Datei auswertet , um übereinstimmt true , ist das Ergebnis true .

In den oben genannten Regeln kann die Datei „images / profilePhoto.png“ gelesen werden , wenn entweder condition oder other_condition zu true ausgewertet, während die Datei „images / users / user: 12345 / profilePhoto.png“ auf das Ergebnis nur Gegenstand ist other_condition .

Cloud Storage-Sicherheitsregeln kaskadieren nicht und Regeln werden nur ausgewertet, wenn der Anfragepfad mit einem Pfad mit den angegebenen Regeln übereinstimmt.

Version 1

Firebase-Sicherheitsregeln verwenden standardmäßig Version 1. In Version 1 entsprechen rekursive Platzhalter einem oder mehreren Dateinamenselementen, nicht null oder mehr Elementen. Somit match /images/{filenamePrefixWildcard}/{imageFilename=**} entspricht einem Dateinamen wie /images/profilePics/profile.png, aber nicht /images/badge.png. Verwenden /images/{imagePrefixorFilename=**} statt.

Rekursive Wildcards müssen am Ende einer Match-Anweisung stehen.

Wir empfehlen Ihnen, Version 2 wegen der leistungsstärkeren Funktionen zu verwenden.

Version 2

In Version 2 der Firebase-Sicherheitsregeln entsprechen rekursive Platzhalter null oder mehr Pfadelementen. So /images/{filenamePrefixWildcard}/{imageFilename=**} entspricht Dateinamen /images/profilePics/profile.png und /images/badge.png.

Sie müssen Opt-in auf Version 2 durch Zugabe von rules_version = '2'; ganz oben in Ihren Sicherheitsregeln:

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

Sie können höchstens einen rekursiven Platzhalter pro Match-Anweisung verwenden, aber in Version 2 können Sie diesen Platzhalter an einer beliebigen Stelle in der Match-Anweisung platzieren. Zum 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>;
   }
  }
}

Granulare Operationen

In manchen Situationen ist es sinnvoll zu brechen read und write in körnigen Operationen. Beispielsweise möchte Ihre App möglicherweise andere Bedingungen für die Dateierstellung als für das Löschen von Dateien erzwingen.

Ein read kann in unterteilt werden get und list .

Eine write kann in gebrochen werden create , update und delete :

service firebase.storage {
  match /b/{bucket}/o {
    // A read rule can be divided into read and list rules
    match /images/{imageId} {
      // Applies to single document 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 nonexistent files
      allow create: if <condition>;

      // Applies to updates to file metadata
      allow update: if <condition>;

      // Applies to delete operations
      allow delete: if <condition>;
    }
  }
 }
}

Überlappende Match-Statements

Es ist möglich , dass ein Dateiname mehr als ein Übereinstimmen match Aussage. In dem Fall , in dem mehrere allow Ausdrücke eine Anfrage übereinstimmen, wird der Zugriff erlaubt , wenn eine der Bedingungen ist true :

service firebase.storage {
  match b/{bucket}/o {
    // Matches any filename containing string '/images/'.
    match /images/{imageId} {
      allow read, write: if false;
    }

    // Matches all filenames containing string `/images/`
    match /images/{imageId=**} {
      allow read, write: if true;
    }
  }
}

In dem obigen Beispiel alle lesen und schreiben Dateien mit der Zeichenfolge /images/ überall in ihrem Dateinamen ist zulässig, weil die zweite Regel immer ist true , auch wenn die erste Regel ist immer false .

Regeln sind keine Filter

Denken Sie daran, dass Sicherheitsregeln keine Filter sind, sobald Sie Ihre Daten sichern und mit der Durchführung von Dateivorgängen beginnen. 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 beispielsweise 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 gesendet , da die Ergebnismenge Dateien enthalten kann , wo contentType nicht image/png :

Netz
filesRef = storage.ref().child("aFilenamePrefix");

filesRef.listAll()
    .then(function(result) {
      console.log("Success: ", result.items);
    })
});

Regeln in Cloud Storage-Sicherheitsregeln bewerten jede Abfrage anhand ihres potenziellen Ergebnisses und schlagen die Anforderung fehl, wenn eine Datei zurückgegeben werden könnte, für die der Client keine Leseberechtigung hat. Zugriffsanforderungen müssen den durch Ihre Regeln festgelegten Einschränkungen entsprechen.

Nächste Schritte

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

  • Lernen Sie das nächste große Konzept der Sprachregeln, dynamischer Bedingungen , die Ihre Regeln Prüfung Benutzerberechtigung lassen, zu vergleichen , bestehende und eingehende Daten, zu validieren eingehenden Daten und vieles mehr.

  • Überprüfen Sie typische Sicherheits Use Cases und die Firebase Sicherheitsregeln Definitionen , die Adresse sie .

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