2016-03-21 4 views
0

Gibt es eine Möglichkeit, eine Datenobergrenze für Firebase-Kinder festzulegen?Firebase-Datenkappe für Kinder

z. B. ...

{ 
    Customer1: {}, 
    Customer2: {}, 
    Customer3: {} 
} 

Für meine speziellen Beispiel in Abhängigkeit von einem Zahlungsmodell des Kunden bestimmen, wie viel Platz sie verwenden dürfen. Sagen für Customer1 und Customer2, ich möchte nur maximal 25 MB Speicherplatz verwendet. Alle neuen Daten entfernen entweder ältere Daten oder werden überhaupt nicht angehängt.

Sollte ich etwas wo für einen bestimmten Kunden tun, überprüfe ich die Größe des gesamten Datensatzes und verhindern, dass Kunden neue Daten hinzufügen, wenn sie einen bestimmten Betrag überschreiten?

Es ist nicht wie eine ideale Lösung scheint ehrlich zu sein ...

+0

Im Moment denke ich, diese Frage ist ein bisschen breit. Möchten Sie die Cap auf der Client- oder der Serverseite? Ist es eine feste Kappe oder ist es dynamisch? Kannst du hinzufügen, was du bisher versucht hast? Werfen Sie einen Blick auf [mvc] (http://stackoverflow.com/help/mcve) und [Hilfe-Center] (http://stackoverflow.com/help/on-topic) –

+0

Ich gebe zu, die Frage ist vage. Das tut mir leid. Die Daten wären dynamisch (abhängig vom Mitgliedsstatus eines Kunden). Ich habe die meiste Zeit damit verbracht, herauszufinden, ob es Möglichkeiten gibt, dies über die Sicherheitsregeln zu implementieren. –

+0

Ich habe eine Antwort hinzugefügt, um dies nur mit Firebase-Sicherheitsregeln zu tun. Es ist keine perfekte Lösung, aber vielleicht eine Möglichkeit, die verbessert werden kann. –

Antwort

0

Das eine dieser Anforderungen ist, dass Sie nicht in der Client-seitige Anwendung implementieren können, da die Nutzer in der Lage sein wird, sie zu umgehen wenn Sie tun.

Stattdessen sollten Sie diese serverseitige Implementierung, die Blätter:

  • implementieren es in Sicherheitsregeln
  • implementieren es in serverseitigen Code

Es gibt keine Betreiber Einbau- Firebase-Sicherheitsregeln, die die Größe eines Knotens angeben. Sie können die Länge eines Strings bestimmen, aber das ist ein bisschen zu lang.

Sie sollten also den serverseitigen Prozess verwenden, dh: einen Prozess, den Sie steuern, der nicht auf dem Clientgerät ausgeführt wird. Mit diesem serverseitigen Prozess können Sie die Knotengröße beliebig berechnen.

Der Prozess schreibt dann die Knotengröße zurück in Firebase in einen gesicherten Speicherort (den nur der Prozess schreiben kann). Die Sicherheitsregeln können dann diesen Speicherort überprüfen und Schreibvorgänge ablehnen, wenn der Knoten größer als das Kontingent ist.

+0

Sind Sie sicher, dass dies in den Sicherheitsregeln nicht möglich ist? Persönlich möchte ich die Möglichkeiten für Exploits begrenzen, ohne serverseitigen Code zu verwenden, und da Sie zahlen müssen, wenn Sie Ihre Firebase-Grenzen für Datenspeicherung und Übertragung überschreiten, würde ich denken, dass es eine Option geben würde, um dies zu überprüfen. –

+0

Ich konnte nicht schnell einen Weg finden. Aber ich bin offen für Vorschläge, wie dies rein in Sicherheitsregeln getan werden könnte. –

+0

Ich hatte auf eine nicht serverseitige Implementierung gehofft. Eines der ersten Dinge, die ich gemacht habe, war die Sicherheitsdokumentation, aber ich konnte nichts über die Datengröße herausfinden. –

1

Nach ein paar Versuchen und Fehler habe ich herausgefunden, dass es tatsächlich möglich ist, eine Kappe auf Daten innerhalb der Firebase Sicherheitsregeln zu haben. Aber nur bis zu einem gewissen Grad!

Der einschränkende Faktor ist, dass Sie nur den Wert eines primitiven Typs (String, Zahl oder bool) überprüfen können. Wenn ein Knoten untergeordnete Elemente aufweist, müssen Sie den Wert jedes dieser untergeordneten Elemente überprüfen. Dies bedeutet, dass Sie wissen, welche Daten Sie erwarten können.

Im Folgenden finden Sie ein Beispiel für die Sicherheitsregeln, die hierfür erforderlich sind. Die Regeln gelten nur für einen primitiven Typ oder einen Knoten mit maximal 3 (angegebenen) primitiven Kindern.

"rules": { 
    ".read": true, 
    ".write": true, 
    "$key":{ 
    //validate that the data has no children 
    ".validate":"(!newData.hasChildren() && 
    //and validate if it is a string within a certain length 
    (newData.isString() && newData.val().length < 10) || 
    //or validate if it is a number within a certain range 
    (newData.isNumber() && (newData.val() < 10 && newData.val() > -10)) || 
    //or validate if it is a bool 
    newData.isBoolean()) || 
    //Or rince and repeat for all possible child nodes 
    newData.hasChildren()", 
    "childA":{ 
     ".validate":"(!newData.hasChildren() && 
     (newData.isString() && newData.val().length < 10) || 
     (newData.isNumber() && (newData.val() < 10 && newData.val() > -10)) || 
     newData.isBoolean())" 
    }, 
    "childB":{ 
     ".validate":"(!newData.hasChildren() && 
     (newData.isString() && newData.val().length < 10) || 
     (newData.isNumber() && (newData.val() < 10 && newData.val() > -10)) || 
     newData.isBoolean())" 
    }, 
    "childC":{ 
     ".validate":"(!newData.hasChildren() && 
     (newData.isString() && newData.val().length < 10) || 
     (newData.isNumber() && (newData.val() < 10 && newData.val() > -10)) || 
     newData.isBoolean())" 
    }, 
    //dismiss all child nodes you don't want 
    "$other": {".validate": false} 
    } 
} 

Einige der Nachteile dieses sollution sind:

  1. Sie müssen wissen, welche Daten Sie erwarten können (und Ihre Regeln jedes Mal aktualisieren, dies ändert)
  2. Die Regeln exponentiell größer bekommen Je mehr untergeordnete Knoten Sie haben können
  3. Sie können nicht wirklich eine "Gesamt" -Kappe auf einem Knoten, sondern nur auf den Primitiven, die einen Knoten bilden.Zum Beispiel (childA + childB + childC) ist kleiner als X ist nicht möglich.
  4. Sie können keine dynamische Obergrenze haben. Aber man könnte sagen, dass locationFree eine Obergrenze von 10 und locationPremium eine Obergrenze von 100 hat. Leider würde dies die Anzahl der erforderlichen Regeln verdoppeln und die Benutzer würden je nach ihrer Obergrenze unterschiedliche Schreiborte haben.
+0

Gute Sachen! Das würde tatsächlich funktionieren, obwohl ich bezweifle, dass es für irgendeine realistische Baumgröße machbar ist. Ich frage mich, ob Sie mit Bolt den Aggregator generieren könnten. Und ich frage mich noch mehr, was die Größe der rules.json sein wird, die daraus entsteht. :-) –