Soluzione alternativa per il vincolo "Regole non filtri" di Firebase

Vorrei una regola di sicurezza che consenta a chiunque di ottenere un elenco di utenti e leggere i loro nomi, ma consente solo agli utenti registrati di visualizzare la propria email.Soluzione alternativa per il vincolo "Regole non filtri" di Firebase

Ecco una struttura di dati di esempio:

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

Un approccio ingenuo una regola di sicurezza potrebbe essere quello di effettuare le seguenti operazioni:

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

Tuttavia, poiché non v'è alcuna regola di lettura a livello di utente, Le richieste di leggere la lista saranno negate. Tuttavia, l'aggiunta di una regola di lettura a livello di utente annullerà la regola di posta elettronica e renderà leggibile ogni nodo figlio (vedere Rules Cascade nella Guida alla sicurezza di Firebase).

La guida alla sicurezza segnala che Rules Are Not Filters, ma non offre molte indicazioni su cosa fare al riguardo.

Devo dividere l'entità utente in PrivateUser e PublicUser?

fonte

2016-01-21 Zac

che è davvero un modo comune di fare questo. In generale, quando si modellano i dati in NoSQL, modellare i dati per come intendete utilizzarli nella vostra app. Vedi questo articolo per ulteriori buoni consigli: https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/ –

Grazie Frank, non ho alcuna esperienza con i database NoSQL. Il mio approccio ingenuo era: "Ok, ho bisogno di un oggetto utente e un utente ha queste proprietà, alcune delle quali sono private". Quindi stai dicendo che un processo di pensiero migliore sarebbe pensare prima all'accesso e quindi modellare oggetti che sono completamente pubblici o completamente privati? – Zac

È molto comune per le persone che provengono da uno sfondo SQL per provare e modellare il loro modello relazionale in un sistema gerarchico (come Firebase). Semplicemente non funziona. Leggi l'articolo e sarai meglio equipaggiato per far fronte. Letture consigliate anche sul sito Web di Firebase: https://www.firebase.com/blog/2013-04-12-denormalizing-is-normal.html, https://www.firebase.com/docs/web/guide /structuring-data.html. Anche questo sembra buono: https://www.airpair.com/firebase/posts/structuring-your-firebase-data e questo post recente sul nostro gruppo Google: https://groups.google.com/forum/#!topic/Firebase-talk/1p4O4Pc2w6k –

Per consentire a chiunque di ottenere un elenco di utenti e leggere i loro nomi. E consentire agli utenti registrati di visualizzare la propria email.

Zac dice: prima pensare di accesso, e quindi di modellare gli oggetti che sono o completamente pubblico o completamente privato.

Tipo 1:

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

Tipo 2:

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

fonte

2016-07-16 18:29:36 Nik

A "soluzione" sarebbe quella di utilizzare FireStore (ha un sacco di cose buone da Firebase in tempo reale Database, ma aggiunge più opzioni di interrogazione, ecc.).

Non esiste una restrizione "regole non sono filtri" in Firestore!

Tuttavia, è necessario costruire la query in modo tale da restituire solo gli oggetti per i quali si dispone dell'autorizzazione di lettura (altrimenti si ottiene un'eccezione di sicurezza).

Ecco alcuni documenti Punto di partenza:

regole di sicurezza: https://firebase.google.com/docs/firestore/reference/security/

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

fonte

2017-11-30 15:47:44 KarolDepka

Soluzione alternativa per il vincolo "Regole non filtri" di Firebase

risposta

Problemi correlati