Catch up on everthing we announced at this year's Firebase Summit. Learn more

Nutzungsbedingungen in Firebase Cloud Storage-Sicherheitsregeln

Dieser Leitfaden baut auf die den Kern Syntax der Firebase Sicherheitsregeln Sprache lernen Führer zu zeigen , wie die Bedingungen für Cloud Storage zu Ihrer Firebase Sicherheit Regeln hinzuzufügen.

Der primäre Baustein der Cloud Storage Sicherheitsregeln ist die Bedingung. Eine Bedingung ist ein boolescher Ausdruck, der bestimmt, ob eine bestimmte Operation zugelassen oder abgelehnt werden soll. Für Grundregeln, mit true und false arbeitet Literale als Bedingungen prefectly gut. Aber die Firebase Security Rules for Cloud Storage-Sprache bietet Ihnen Möglichkeiten, komplexere Bedingungen zu schreiben, die:

  • Überprüfen Sie die Benutzerauthentifizierung
  • Eingehende Daten validieren

Authentifizierung

Firebase Security Rules for Cloud Storage lässt sich in Firebase Authentication integrieren, um eine leistungsstarke benutzerbasierte Authentifizierung für Cloud Storage bereitzustellen. Dies ermöglicht eine granulare Zugriffskontrolle basierend auf den Ansprüchen eines Firebase-Authentifizierungstokens.

Wenn eine Anfrage , ein authentifizierter Benutzer führt gegen Cloud - Speicher, die request.auth wird Variable mit dem Benutzer bevölkerten uid ( request.auth.uid ) sowie den Ansprüchen der Firebase Authentication JWT ( request.auth.token ).

Zusätzlich wird , wenn individuelle Authentifizierung verwendet wird , werden zusätzliche Forderungen in taucht request.auth.token Feld.

Wenn ein nicht authentifizierter Benutzer eine Anfrage durchführt, die request.auth variabel ist null .

Mithilfe dieser Daten gibt es mehrere gängige Möglichkeiten, die Authentifizierung zum Sichern von Dateien zu verwenden:

  • Öffentlich: ignorieren request.auth
  • Authentifizierte privat: Überprüfen Sie, dass request.auth nicht ist null
  • Benutzer privat: Überprüfen Sie, dass request.auth.uid einen Pfad entspricht uid
  • Gruppe privat: Überprüfen Sie, ob die Ansprüche des benutzerdefinierten Tokens mit einem ausgewählten Anspruch übereinstimmen, oder lesen Sie die Dateimetadaten, um zu sehen, ob ein Metadatenfeld vorhanden ist

Öffentlich

Jede Regel , die nicht das ist nicht der Auffassung request.auth Kontext kann eine in Betracht gezogen werden public Regel, da sie nicht den Authentifizierungskontext des Benutzers nicht berücksichtigt. Diese Regeln können nützlich sein, um öffentliche Daten wie Spielinhalte, Sounddateien oder andere statische Inhalte anzuzeigen.

// Anyone to read a public image if the file is less than 100kB
// Anyone can upload a public file ending in '.txt'
match /public/{imageId} {
  allow read: if resource.size < 100 * 1024;
  allow write: if imageId.matches(".*\\.txt");
}

Authentifiziert privat

In bestimmten Fällen möchten Sie möglicherweise, dass die Daten von allen authentifizierten Benutzern Ihrer Anwendung angezeigt werden können, jedoch nicht von nicht authentifizierten Benutzern. Da die request.auth Variable ist null für alle nicht authentifizierte Benutzer, alles , was Sie tun müssen, ist die überprüfen request.auth variabel, um eine Authentifizierung erforderlich ist vorhanden:

// Require authentication on all internal image reads
match /internal/{imageId} {
  allow read: if request.auth != null;
}

Benutzer privat

Bei weitem die häufigste Anwendungsfall für request.auth werden einzelne Nutzer mit granulare Berechtigungen auf ihre Dateien: das Hochladen Profilbilder auf private Dokumente zu lesen.

Da Dateien in Cloud Storage einen vollständigen „Pfad“ auf die Datei haben, die alle es von einem Benutzer gesteuert , um eine Datei zu erstellen , nimmt ein Stück einzigartig, Benutzerkennung im Dateinamen - Präfix (wie der des Benutzers uid ) , das überprüft werden kann wenn die Regel ausgewertet wird:

// Only a user can upload their profile picture, but anyone can view it
match /users/{userId}/profilePicture.png {
  allow read;
  allow write: if request.auth.uid == userId;
}

Gruppe privat

Ein weiterer ebenso häufiger Anwendungsfall ist das Erteilen von Gruppenberechtigungen für ein Objekt, z. B. die Zusammenarbeit mehrerer Teammitglieder an einem freigegebenen Dokument. Dafür gibt es mehrere Ansätze:

  • Mint eine Firebase Authentication individuelle Token dass enthält weitere Informationen zu einem Mitglied der Gruppe (wie eine Gruppen - ID)
  • Umfassen Gruppeninformation (wie eine Gruppen - ID oder eine Liste von autorisierten uid s) in den Datei - Metadaten

Sobald diese Daten in den Token- oder Datei-Metadaten gespeichert sind, können sie innerhalb einer Regel referenziert werden:

// Allow reads if the group ID in your token matches the file metadata's `owner` property
// Allow writes if the group ID is in the user's custom token
match /files/{groupId}/{fileName} {
  allow read: if resource.metadata.owner == request.auth.token.groupId;
  allow write: if request.auth.token.groupId == groupId;
}

Bewertung anfordern

Uploads, Downloads, Metadaten Änderungen und Löschungen werden mit dem ausgewertet request an Cloud Storage gesendet. Zusätzlich zu dem einzigartigen ID und der Firebase Authentication Nutzlast des Benutzers in dem request.auth Objekt , wie oben beschrieben, die request enthält variable den Dateipfad , wo die Anfrage durchgeführt wird, die Zeit , wenn die Anforderung empfangen wird , und den neuen resource , wenn die Anfrage ist ein Schreiben. HTTP-Header und Authentifizierungsstatus sind ebenfalls enthalten.

Die request - Objekt enthält auch die eindeutige ID des Benutzers und die Firebase Authentication Nutzlast im request.auth Objekt, das weiter in dem erläutert wird Benutzerbasierte Sicherheit Abschnitt der Dokumentation.

Eine vollständige Liste der Eigenschaften in der request Objekt ist verfügbar unter:

Eigentum Typ Beschreibung
auth map<string, string> Wenn ein Benutzer angemeldet ist, liefert uid , die eindeutige ID des Benutzers und token , eine Karte von Firebase Authentication JWT Ansprüche. Andernfalls wird es null .
params map<string, string> Map mit den Abfrageparametern der Anfrage.
path Weg Ein path , die den Pfad der Anforderung an durchgeführt wird.
resource map<string, string> Der neue Ressourcenwert, präsentiert nur auf write
time Zeitstempel Ein Zeitstempel, der die Serverzeit darstellt, zu der die Anforderung ausgewertet wird.

Ressourcenbewertung

Beim Auswerten von Regeln möchten Sie möglicherweise auch die Metadaten der Datei auswerten, die hochgeladen, heruntergeladen, geändert oder gelöscht wird. Auf diese Weise können Sie komplexe und leistungsstarke Regeln erstellen, die beispielsweise nur das Hochladen von Dateien mit bestimmten Inhaltstypen oder das Löschen von Dateien ab einer bestimmten Größe zulassen.

Firebase Sicherheitsregeln für Cloud Storage bieten Datei - Metadaten in dem resource - Objekt, das in einem Cloud - Storage - Objekt aufgetaucht Schlüssel / Wert - Paare des Metadaten enthält. Diese Eigenschaften können auf inspiziert werden read oder write an die Datenintegrität sicherzustellen.

Auf write (wie Uploads, Metadaten Aktualisierungen und Löschungen), zusätzlich zu dem resource die Datei - Metadaten für die Datei enthält , die derzeit auf dem Anfragepfad vorhanden ist , haben Sie auch die Möglichkeit , das verwenden request.resource Objekt, die eine Teilmenge der zu schreibenden Dateimetadaten enthält, wenn das Schreiben erlaubt ist. Sie können diese beiden Werte verwenden, um die Datenintegrität sicherzustellen oder Anwendungseinschränkungen wie Dateityp oder -größe zu erzwingen.

Eine vollständige Liste der Eigenschaften in dem resource - Objekt ist verfügbar unter:

Eigentum Typ Beschreibung
name Schnur Der vollständige Name des Objekts
bucket Schnur Der Name des Buckets, in dem sich dieses Objekt befindet.
generation int Die Google Cloud Storage Objekterzeugung dieses Objekts.
metageneration int Die Google Cloud Storage - Objekt metageneration dieses Objekts.
size int Die Größe des Objekts in Byte.
timeCreated Zeitstempel Ein Zeitstempel, der die Zeit angibt, zu der ein Objekt erstellt wurde.
updated Zeitstempel Ein Zeitstempel, der die Zeit angibt, zu der ein Objekt zuletzt aktualisiert wurde.
md5Hash Schnur Ein MD5-Hash des Objekts.
crc32c Schnur Ein crc32c-Hash des Objekts.
etag Schnur Das mit diesem Objekt verknüpfte E-Tag.
contentDisposition Schnur Die diesem Objekt zugeordnete Inhaltsdisposition.
contentEncoding Schnur Die mit diesem Objekt verknüpfte Inhaltscodierung.
contentLanguage Schnur Die mit diesem Objekt verknüpfte Inhaltssprache.
contentType Schnur Der diesem Objekt zugeordnete Inhaltstyp.
metadata map<string, string> Schlüssel/Wert-Paare zusätzlicher, vom Entwickler spezifizierter benutzerdefinierter Metadaten.

request.resource enthält alle diese mit Ausnahme der generation , metageneration , etag , timeCreated und updated .

Daten validieren

Dateinamen und Pfad sowie Dateimetadaten Eigenschaften wie Feuerbasis Sicherheitsregeln für Cloud Storage können auch für die Datenüberprüfung verwendet werden, einschließlich Validierung von contentType und size .

service firebase.storage {
  match /b/{bucket}/o {
    match /images/{imageId} {
      // Only allow uploads of any image file that's less than 5MB
      allow write: if request.resource.size < 5 * 1024 * 1024
                   && request.resource.contentType.matches('image/.*');
    }
  }
}

Benutzerdefinierte Funktionen

Wenn Ihre Firebase-Sicherheitsregeln komplexer werden, möchten Sie möglicherweise Bedingungssätze in Funktionen einschließen, die Sie in Ihrem Regelsatz wiederverwenden können. Sicherheitsregeln unterstützen benutzerdefinierte Funktionen. Die Syntax für benutzerdefinierte Funktionen ähnelt ein wenig JavaScript, aber Firebase Security Rules-Funktionen sind in einer domänenspezifischen Sprache geschrieben, die einige wichtige Einschränkungen aufweist:

  • Funktionen können nur eine einzige enthalten return - Anweisung. Sie können keine zusätzliche Logik enthalten. Sie können beispielsweise keine Schleifen ausführen oder externe Dienste aufrufen.
  • Funktionen können automatisch auf Funktionen und Variablen aus dem Bereich zugreifen, in dem sie definiert sind. Zum Beispiel kann eine Funktion innerhalb des definierten service firebase.storage Umfangs hat Zugriff auf die resource variabel und für Cloud Firestor nur, integrierte Funktionen wie get() und exists() .
  • Funktionen können andere Funktionen aufrufen, aber nicht rekursiv sein. Die Gesamttiefe der Aufrufliste ist auf 10 begrenzt.
  • In der Version rules2 können Funktionen Variablen definieren die Verwendung von let - Schlüsselwort. Funktionen können eine beliebige Anzahl von let-Bindungen haben, müssen jedoch mit einer return-Anweisung enden.

Eine Funktion wird mit dem definierten function Schlüsselwort und nimmt null oder mehr Argumente. Sie können beispielsweise die beiden in den obigen Beispielen verwendeten Bedingungstypen in einer einzigen Funktion kombinieren:

service firebase.storage {
  match /b/{bucket}/o {
    // True if the user is signed in or the requested data is 'public'
    function signedInOrPublic() {
      return request.auth.uid != null || resource.data.visibility == 'public';
    }
    match /images/{imageId} {
      allow read, write: if signedInOrPublic();
    }
    match /mp3s/{mp3Ids} {
      allow read: if signedInOrPublic();
    }
  }
}

Durch die Verwendung von Funktionen in Ihren Firebase-Sicherheitsregeln werden diese mit zunehmender Komplexität Ihrer Regeln einfacher zu warten.

Nächste Schritte

Nach dieser Diskussion der Bedingungen haben Sie ein besseres Verständnis von Regeln und sind bereit:

Erfahren Sie, wie Sie mit Kernanwendungsfällen umgehen, und lernen Sie den Workflow zum Entwickeln, Testen und Bereitstellen von Regeln kennen: