regole di autorizzazione corretta per il contenuto protetto in Firebase

Question

Esiste un approccio best practice per le regole di autorizzazione appropriate per il contenuto protetto in un'applicazione Firebase

• utilizzando Firepad specificamente
• Con contenuti protetti intendo in cui un utente crea un documento e lo condivide solo con alcuni altri utenti).
• Inoltre ho bisogno di essere in grado di interrogare Firebase per tutti i documenti che ho accesso a (documenti che ho creato e Documenti altri utenti condiviso con me)

Alcune delle mie ricerche finora:

Metodo 1: segreto URL

• ho bisogno di conoscere l'URL per essere in grado di visualizzare/modificare il documento

• Autenticazione non reale, in quanto qualsiasi utente che ha accesso che ha accesso a tale URL può modificarlo/modificarlo.

• indice Cant tutti i documenti ho accesso a

Metodo 2: Usando le regole di autorizzazione Firebase per aggiungere gli utenti a un documento e verificare se l'utente è document.users prima della lettura/scrittura.

Tratto da: Protected content in Firebase possible?

{ 

"documents": { 

    "$documents_id": { 

     // any friend can read my post 

     ".read": "auth.id === data.child('owner').val() || root.child('users/'+data.child.owner.val()+'/users/'+auth.id).exists()", 

     // any friend can edit my post 
     ".write": "auth.id === data.child('owner').val() || root.child('users/'+data.child.owner.val()+'/users/'+auth.id).exists()" 

    }, 

    users:{ 

    // List of user.ids that have access to this document 

    } 

} 

} 

Pro:

• debita autorizzazione/autenticazione. Solo gli utenti autenticati a cui è stato concesso l'accesso possono visualizzare/modificare.

Contro:

• Impossibile ricercare tutti i documenti di un utente è autorizzato ad editare (quelli che possiedo o sono stati condivisi con me) (? È questa assunzione corretta)

Metodo 3: Regole di autorizzazione di Firebase (metodo 2), oltre a un archivio ridondante di utenti con una serie di ID del documento a cui ogni utente ha accesso. Questo archivio utenti verrebbe utilizzato solo per interrogare tutti i documenti a cui un utente ha accesso. vale a dire:

{ 
"documents": { 
    "$documents_id": { 
     // any friend can read my post 
     ".read": "auth.id === data.child('owner').val() || root.child('users/'+data.child.owner.val()+'/users/'+auth.id).exists()", 
     // any friend can edit my post 
     ".write": "auth.id === data.child('owner').val() || root.child('users/'+data.child.owner.val()+'/users/'+auth.id).exists()" 
    } 
}, 
"users":{ 
    "$user":{ 
     ".read": "auth.id=$user.id", 
     ".write": "auth.id=$user.id" 
     "$documents":{ 
      // All the documents i have access to. This list gets ammended whenever I am granted/stripped access to a document. 
     } 
    } 
} 
} 

Pro:

• corretta autenticazione/autorizzazione

Contro: dati

• duplicati, hanno a che fare con i problemi di sincronizzazione tra due archivi di dati. Questo non sembra una buona idea.

Metodo 4: Gruppi

Uso gruppi per Granting access to Firebase locations to a group of users

• Abbiamo un gruppo per ogni documento in archivio dati

• Cant facilmente tua ricerca Firebase per tutti i documenti un utente può accedere a

C'è un modo migliore per farlo?

Answer 1

Hai fatto un buon lavoro di enumerazione delle opzioni e sei decisamente sulla buona strada. Come hai scoperto, non c'è modo di interrogare in base alle regole di sicurezza. Questo è stato fatto intenzionalmente, poiché (a seconda delle regole di sicurezza) questo potrebbe essere piuttosto costoso (Firebase evita query complesse in generale per questo motivo).

Quindi il tuo metodo 3 è esattamente il modo giusto per farlo. La duplicazione di dati per questo tipo di situazioni è in realtà una pratica molto comune. Vedi Denormalizing Your Data is Normal per un post sul blog che fornisce maggiori dettagli su questo.

Si potrebbe anche eseguire il metodo 1 con l'elenco di documenti duplicati. Ciò è particolarmente utile se si desidera essere in grado di "invitare" qualcuno a un documento solo con un URL (che contiene l'ID segreto). Oppure potresti fare una combinazione dei due (avere dei documenti "pubblici ma non in elenco" e alcuni essere "privati ​​per gli amici invitati" o qualsiasi altra cosa.)