Datenvalidierung

Sie können Firebase-Sicherheitsregeln verwenden, um bedingt neue Daten basierend auf vorhandenen Daten in Ihrer Datenbank oder Ihrem Storage-Bucket zu schreiben. Sie können auch Regeln schreiben, die Datenvalidierungen erzwingen, indem Sie Schreibvorgänge basierend auf den neu geschriebenen Daten einschränken. Lesen Sie weiter, um mehr über Regeln zu erfahren, die vorhandene Daten verwenden, um Sicherheitsbedingungen zu schaffen.

Wählen Sie in jedem Abschnitt ein Produkt aus, um mehr über Datenvalidierungsregeln zu erfahren.

Einschränkungen für neue Daten

Cloud Firestore

Wenn Sie sicherstellen möchten , dass ein Dokument , das ein bestimmtes Feld enthält , wird nicht erstellt haben , können Sie das Feld gehören in die allow Zustand. Zum Beispiel, wenn Sie Erstellung von Dokumenten verweigern mögen , dass die enthalten ranking Feld, würden Sie es in dem nicht zulassen create Zustand.

  service cloud.firestore {
    match /databases/{database}/documents {
      // Disallow
      match /cities/{city} {
        allow create: if !("ranking" in request.resource.data)
      }
    }
  }

Echtzeit-Datenbank

Wenn Sie sicherstellen möchten, dass Ihrer Datenbank keine Daten hinzugefügt werden, die bestimmte Werte enthalten, nehmen Sie diesen Wert in Ihre Regeln auf und lassen ihn für Schreibvorgänge nicht zu. Zum Beispiel, wenn Sie schreibt verweigern möchten , die enthalten ranking Werte, würden Sie schreibt für alle Dokumente mit nicht zulassen ranking Werte.

  {
    "rules": {
      // Write is allowed for all paths
      ".write": true,
      // Allows writes only if new data doesn't include a `ranking` child value
      ".validate": "!newData.hasChild('ranking')
    }
  }

Cloud-Speicher

Wenn Sie sicherstellen möchten , dass eine Datei , die bestimmte Metadaten enthält , wird nicht erstellt haben , können Sie die Metadaten enthalten in der allow Zustand. Zum Beispiel, wenn Sie Erstellung von Dateien verweigern mögen , die enthalten ranking Metadaten, würden Sie es in dem nicht zulassen create Zustand.

  service firebase.storage {
    match /b/{bucket}/o {
      match /files/{allFiles=**} {
      // Disallow
        allow create: if !("ranking" in request.resource.metadata)
      }
    }
  }

Vorhandene Daten in Firebase-Sicherheitsregeln verwenden

Cloud Firestore

Viele Apps speichern Zugriffskontrollinformationen als Felder in Dokumenten in der Datenbank. Cloud Firestore-Sicherheitsregeln können den Zugriff basierend auf Dokumentdaten dynamisch zulassen oder verweigern:

  service cloud.firestore {
    match /databases/{database}/documents {
      // Allow the user to read data if the document has the 'visibility'
      // field set to 'public'
      match /cities/{city} {
        allow read: if resource.data.visibility == 'public';
      }
    }
  }

Die resource Variable bezieht sich auf das angeforderte Dokument und resource.data ist eine Karte von allen Feldern und in dem Dokument gespeicherten Werte. Weitere Informationen zu der resource Variable finden Sie in der Referenzdokumentation .

Beim Schreiben von Daten möchten Sie möglicherweise eingehende Daten mit vorhandenen Daten vergleichen. Auf diese Weise können Sie beispielsweise sicherstellen, dass sich ein Feld nicht geändert hat, dass ein Feld nur um eins erhöht wurde oder dass der neue Wert mindestens eine Woche in der Zukunft liegt. In diesem Fall, wenn Sie Ihre Regeln den anstehenden Schreib erlaubt, die request.resource enthält Variable , um den zukünftigen Zustand des Dokuments. Für update - Operationen , die nur eine Teilmenge der Dokumentfelder ändern, die request.resource wird Variable den anstehende Dokument Zustand nach der Operation enthält. Sie können die Feldwerte in überprüfen request.resource , um unerwünschten oder inkonsistenten Daten - Updates zu verhindern:

   service cloud.firestore {
     match /databases/{database}/documents {
      // Make sure all cities have a positive population and
      // the name is not changed
      match /cities/{city} {
        allow update: if request.resource.data.population > 0
                      && request.resource.data.name == resource.data.name;
      }
    }
  }

Echtzeit-Datenbank

In Echtzeit - Datenbank verwendet .validate Regeln auf Datenstrukturen durchzusetzen und das Format und den Inhalt der Daten zu überprüfen. Regeln laufen .validate Regeln nach der Überprüfung , dass ein .write Regel Zugang gewährt.

Die .validate Regeln nicht kaskadiert werden . Wenn eine Validierungsregel für einen Pfad oder Unterpfad in der Regel fehlschlägt, wird der gesamte Schreibvorgang abgelehnt. Darüber hinaus prüfen die Validierungsdefinitionen nur auf Nicht-Null-Werte und ignorieren anschließend alle Anforderungen, die Daten löschen.

Betrachten Sie die folgenden .validate Regeln:

  {
    "rules": {
      // write is allowed for all paths
      ".write": true,
      "widget": {
        // a valid widget must have attributes "color" and "size"
        // allows deleting widgets (since .validate is not applied to delete rules)
        ".validate": "newData.hasChildren(['color', 'size'])",
        "size": {
          // the value of "size" must be a number between 0 and 99
          ".validate": "newData.isNumber() &&
                        newData.val() >= 0 &&
                        newData.val() <= 99"
        },
        "color": {
          // the value of "color" must exist as a key in our mythical
          // /valid_colors/ index
          ".validate": "root.child('valid_colors/' + newData.val()).exists()"
        }
      }
    }
  }

Schreibanforderungen an eine Datenbank mit den oben genannten Regeln haben folgende Ergebnisse:

JavaScript
var ref = db.ref("/widget");

// PERMISSION_DENIED: does not have children color and size
ref.set('foo');

// PERMISSION DENIED: does not have child color
ref.set({size: 22});

// PERMISSION_DENIED: size is not a number
ref.set({ size: 'foo', color: 'red' });

// SUCCESS (assuming 'blue' appears in our colors list)
ref.set({ size: 21, color: 'blue'});

// If the record already exists and has a color, this will
// succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
// will fail to validate
ref.child('size').set(99);
Ziel c
FIRDatabaseReference *ref = [[[FIRDatabase database] reference] child: @"widget"];

// PERMISSION_DENIED: does not have children color and size
[ref setValue: @"foo"];

// PERMISSION DENIED: does not have child color
[ref setValue: @{ @"size": @"foo" }];

// PERMISSION_DENIED: size is not a number
[ref setValue: @{ @"size": @"foo", @"color": @"red" }];

// SUCCESS (assuming 'blue' appears in our colors list)
[ref setValue: @{ @"size": @21, @"color": @"blue" }];

// If the record already exists and has a color, this will
// succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
// will fail to validate
[[ref child:@"size"] setValue: @99];
Schnell
var ref = FIRDatabase.database().reference().child("widget")

// PERMISSION_DENIED: does not have children color and size
ref.setValue("foo")

// PERMISSION DENIED: does not have child color
ref.setValue(["size": "foo"])

// PERMISSION_DENIED: size is not a number
ref.setValue(["size": "foo", "color": "red"])

// SUCCESS (assuming 'blue' appears in our colors list)
ref.setValue(["size": 21, "color": "blue"])

// If the record already exists and has a color, this will
// succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
// will fail to validate
ref.child("size").setValue(99);
Java
FirebaseDatabase database = FirebaseDatabase.getInstance();
DatabaseReference ref = database.getReference("widget");

// PERMISSION_DENIED: does not have children color and size
ref.setValue("foo");

// PERMISSION DENIED: does not have child color
ref.child("size").setValue(22);

// PERMISSION_DENIED: size is not a number
Map<String,Object> map = new HashMap<String, Object>();
map.put("size","foo");
map.put("color","red");
ref.setValue(map);

// SUCCESS (assuming 'blue' appears in our colors list)
map = new HashMap<String, Object>();
map.put("size", 21);
map.put("color","blue");
ref.setValue(map);

// If the record already exists and has a color, this will
// succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
// will fail to validate
ref.child("size").setValue(99);
SICH AUSRUHEN
# PERMISSION_DENIED: does not have children color and size
curl -X PUT -d 'foo' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# PERMISSION DENIED: does not have child color
curl -X PUT -d '{"size": 22}' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# PERMISSION_DENIED: size is not a number
curl -X PUT -d '{"size": "foo", "color": "red"}' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# SUCCESS (assuming 'blue' appears in our colors list)
curl -X PUT -d '{"size": 21, "color": "blue"}' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# If the record already exists and has a color, this will
# succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
# will fail to validate
curl -X PUT -d '99' \
https://docs-examples.firebaseio.com/rest/securing-data/example/size.json

Cloud-Speicher

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 ermöglichen.

Das resource - Objekt enthält Schlüssel / Wert - Paare mit Datei - Metadaten in einem Cloud - Storage - Objekt aufgetaucht. Diese Eigenschaften können auf inspiziert werden read oder write an die Datenintegrität sicherzustellen. Die resource prüft Metadaten auf vorhandene Dateien in Ihrer Cloud Storage Eimer.

  service firebase.storage {
    match /b/{bucket}/o {
      match /images {
        match /{allImages=**} {
          // Allow reads if a custom 'visibility' field is set to 'public'
          allow read: if resource.metadata.visibility == 'public';
        }
      }
    }
  }

Sie können auch die Verwendung request.resource Objekt auf write (wie Uploads, Metadaten Aktualisierungen und Löschungen. Die request.resource Objekt - Metadaten aus der Datei erhält , die geschrieben wird , wenn die write erlaubt.

Sie können diese beiden Werte verwenden, um unerwünschte oder inkonsistente Aktualisierungen zu verhindern oder Anwendungseinschränkungen wie Dateityp oder -größe zu erzwingen.

  service firebase.storage {
    match /b/{bucket}/o {
      match /images {
        // Cascade read to any image type at any path
        match /{allImages=**} {
          allow read;
        }

        // Allow write files to the path "images/*", subject to the constraints:
        // 1) File is less than 5MB
        // 2) Content type is an image
        // 3) Uploaded content type matches existing content type
        // 4) File name (stored in imageId wildcard variable) is less than 32 characters
        match /{imageId} {
          allow write: if request.resource.size < 5 * 1024 * 1024
                       && request.resource.contentType.matches('image/.*')
                       && request.resource.contentType == resource.contentType
                       && imageId.size() < 32
        }
      }
    }
  }

Eine vollständige Liste der Eigenschaften in dem resource - Objekt ist in der zur Verfügung stehenden Referenzdokumentation .