Frage Umgehung der Firebase-Einschränkung "Regeln sind keine Filter"


Ich hätte gerne eine Sicherheitsregel, die es jedem ermöglicht, eine Liste von Benutzern zu erhalten und deren Namen zu lesen, aber nur eingeloggten Benutzern erlaubt, ihre eigenen E-Mails anzuzeigen.

Hier ist eine Beispieldatenstruktur:

    "User" : {
        "abc123" : {
          "name" : "Bob",
          "email" : "bob@hotmail.com"
        }   
    }

Ein naive Ansatz für eine Sicherheitsregel könnte Folgendes sein:

"User" : {
    "$user" : {
        "name" : {
            ".read" : true
        },
        "email" : {
            ".read” : "auth.uid === $user"
        }
    }
}

Da jedoch auf der Benutzerebene keine Lese-Regel existiert, werden Anfragen zum Lesen der Liste abgelehnt. Wenn Sie jedoch eine Leseregel auf Benutzerebene hinzufügen, wird die E-Mail-Regel überschrieben und alle untergeordneten Knoten werden lesbar (siehe Regeln Cascade im Firebase Sicherheitsleitfaden).

Der Sicherheitsleitfaden weist darauf hin, dass Regeln sind keine Filter, aber bietet nicht viel Anleitung, was man dagegen tun kann.

Soll ich meine User-Entity einfach in PrivateUser und PublicUser aufteilen?


10
2018-01-21 02:27


Ursprung


Antworten:


Ein "Workaround" wäre die Verwendung von Firestore (enthält viele der guten Dinge aus der Firebase Realtime Database, fügt aber weitere Abfrageoptionen hinzu usw.).

In Firestore gibt es keine Einschränkung "Regeln sind nicht Filter"!

Allerdings müssen Sie Ihre Abfrage so konstruieren, dass nur Objekte zurückgegeben werden, für die Sie Leseberechtigung haben (andernfalls erhalten Sie eine Sicherheitsausnahme).

Hier sind einige Startpunkt-Dokumente:

Sicherheitsregeln: https://firebase.google.com/docs/firestore/reference/security/

Abfragen: https://firebase.google.com/docs/firestore/query-data/queries


1
2017-11-30 15:47



Damit jeder eine Liste von Benutzern erhält und deren Namen liest. UND damit angemeldete Benutzer ihre eigene E-Mail anzeigen können.

Zac sagt: Denken Sie zuerst über den Zugriff nach, und dann, um Objekte zu modellieren, die entweder vollständig öffentlich oder vollständig privat sind.

Typ 1:

{"rules":{
  "user_publicly":{"$user:{
    ".read":true,
    "name":{}
  }},
  "user_privately":{"$user:{
    ".read":"auth != null && $user == auth.uid",
    "email":{}
  }}
}}

Typ 2:

{"rules":{
  "user":{"$user:{
    "public":{
        ".read":true,
        "name":{}
    },
    "private":{
        ".read":"auth != null && $user == auth.uid",
        "email":{}
    }
  }}
}}

0
2017-07-16 18:29