Problemumgehung für Firebases "Regeln sind keine Filter" Einschränkung

Ich möchte eine Sicherheitsregel, die jedermann eine Liste von Benutzern erhalten und ihre Namen lesen kann, aber nur angemeldeten Benutzern ermöglicht, ihre eigenen E-Mails anzuzeigen.Problemumgehung für Firebases "Regeln sind keine Filter" Einschränkung

Hier ist eine Beispiel-Datenstruktur:

"User" : { 
     "abc123" : { 
      "name" : "Bob", 
      "email" : "[email protected]" 
     } 
    }

Ein naiver Ansatz für eine Sicherheitsregel Folgendes tun könnte:

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

jedoch, weil es auf der Benutzerebene keine Leseregel ist, Anfragen zum Lesen der Liste werden abgelehnt. Wenn Sie jedoch eine Leseregel auf Benutzerebene hinzufügen, wird die E-Mail-Regel überschrieben und alle untergeordneten Knoten werden lesbar (siehe Firebase-Sicherheitsleitfaden unter Rules Cascade).

Der Sicherheitsleitfaden weist darauf hin, dass Rules Are Not Filters, aber bietet nicht viel Anleitung, was Sie dagegen tun können.

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

Quelle

2016-01-21 Zac

Der in der Tat, dies zu tun ein gemeinsamer Weg. Wenn Sie Daten in NoSQL modellieren, modellieren Sie die Daten im Allgemeinen so, wie Sie sie in Ihrer App verwenden möchten. Siehe diesen Artikel für mehr guten Rat: https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/ –

Danke Frank, ich habe keine Erfahrung mit NoSQL-Datenbanken. Mein naives Vorgehen war: "Ok, ich brauche ein Benutzerobjekt, und ein Benutzer hat diese Eigenschaften, von denen einige privat sind". Wollen Sie also sagen, ein besserer Denkprozess wäre, zuerst über den Zugang nachzudenken und dann Objekte zu modellieren, die entweder vollständig öffentlich oder völlig privat sind? – Zac

Es ist sehr üblich für Menschen aus einem SQL-Hintergrund zu versuchen, ihr relationales Modell in ein hierarchisches System (wie Firebase) zu modellieren. Es funktioniert einfach nicht. Lesen Sie den Artikel und Sie werden besser dafür gerüstet sein. Auch empfohlen liest auf der Firebase-Website: https://www.firebase.com/blog/2013-04-12-denormalizing-is-normal.html, https://www.firebase.com/docs/web/guide /strukturierende_daten.html. Dies scheint auch gut zu sein: https://www.airpair.com/firebase/posts/structuring-your-firebase-data und diesen letzten Beitrag in unserer Google Group: https://groups.google.com/forum/#!topic/Firebase-Talk/1p4O4Pc2w6k –

Um jemanden eine Liste von Benutzern zu erhalten und ihre Namen zu lesen. UND damit angemeldete Benutzer ihre eigene E-Mail anzeigen können.

Zac sagt: zuerst über den Zugang denken, und dann Objekte zu modellieren, die entweder vollständig öffentlich oder ganz 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":{} 
    } 
    }} 
}}

Quelle

2016-07-16 18:29:36 Nik

A "Abhilfe" wäre Firestor zu verwenden (hat eine Menge von den guten Dingen, von Firebase Realtime Datenbank, fügt jedoch weitere Abfrageoptionen hinzu usw.).

Es gibt keine "Regeln sind nicht Filter" Beschränkung in Firestore!

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

Hier sind einige Ausgangspunkte docs:

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

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

Quelle

2017-11-30 15:47:44 KarolDepka

Problemumgehung für Firebases "Regeln sind keine Filter" Einschränkung

Antwort

Verwandte Themen