2017-07-01 1 views
1

Nous sommes en train de construire une plateforme utilisant la base de données en temps réel Firebase et j'ai du mal à trouver le meilleur moyen de structurer nos données pour un accès privé et public.Comment structurer les données avec Firebase pour permettre aux données d'être spécifiques à l'utilisateur et aussi publiques?

Aujourd'hui, nous avons

database: { 
    items: { 
    $userUid: { 
     $itemUid: { 
     poster_link: "..." 
     format: "..." 
     title: "..." 
     } 
    } 
    } 
} 

Tous nos articles sont stockés sous chaque utilisateur afin de le rendre rapide et sécurisé à charger.

Nos règles sont définies comme ça

{ 
    "rules": { 
    "items": { 
     "$userId": { 
     "$itemId": { 
      ".read": "auth !== null, 
      ".write": "auth !== null" 
     } 
     } 
    } 
    } 
} 

Ainsi, seul un utilisateur autorisé peut lire et écrire les données. Je pourrais créer quelque chose comme ceci pour permettre les articles à être publique si la valeur est vraie:

".read": "auth !== null || data.child('public').val() == true" 

Mais ce sera encore moins de $ userUid

Je me demandais si vous avez des suggestions sur la façon de structurer Cet exemple permet à des éléments d'être sous un utilisateur et aussi vu publiquement, pas nécessaire sous cet utilisateur, un peu comme Dropbox quand vous partagez quelque chose.

+0

La solution la plus simple consiste à séparer les données publiques et privées. Voir ma réponse ici sur le pourquoi et le comment: https://stackoverflow.com/questions/38648669/firebase-how-to-structure-public-private-user-data –

Répondre

1

Vous structure de données choisie ne prend pas parti des principes de données à plat de Firebase. Cela rendra très difficile pour vous d'interroger des éléments de plusieurs utilisateurs. Par exemple, comment obtenez-vous tous les objets publics sans percer dans chaque utilisateur?

De même, un booléen appelé public n'est pas bon car vous ne pouvez pas l'étendre à d'autres scénarios ACL. Beaucoup mieux est un objet ACL qui peut être étendu dans le futur.

Par exemple:

items: { 
    itemsUid: { 
    [...], 
    userId: ..., 
    ACL: { public: true } 
    } 
} 

Maintenant, vous pouvez écrire la règle:

auth !== null && (root.child(items/ACL/public).exsists() || data.userId === auth.UID) 

Si dans trois mois, vous ajoutez un concept d'amis qui peuvent vous voir les messages ou disciples qui peuvent vous voir articles vous pouvez simplement ajouter friends: true, followers: true à l'objet ACL et ajuster la règle.

1

Vous pouvez structurer comme celui-ci

database: { 
    items: { 
     $itemUid: { 
     poster_link: "..." 
     format: "..." 
     title: "..." 
     user: "userid" 
     } 
    } 
} 

maintenant définir les règles

{ 
    "rules": { 
    "items": { 
     "$itemId": { 
      ".read": "auth !== null || data.child('public').val() == true, 
      ".write": "auth !== null" 
     } 
    } 
    } 
}