J'écris une application de partage de notes et j'essaie de trouver la meilleure approche pour que la structure de données permette d'ajouter des collaborateurs aux notes des utilisateurs, tout en ayant des règles de sécurité raisonnables pour la structure en question.Firebase: règles de sécurité pour une application collaborative
Ce que j'est maintenant la suivante:
"users": {
"johndoe": {
"notes": {
"note1Key",
"note2Key"
}
},
"jane": {
"notes": {
"note3Key",
"note4Key",
"note5Key"
}
}
...
},
"notes": {
"note1Key": {
// actual note data
},
"note2Key": {
// actual note data
},
"note3Key": {
// actual note data
},
...
},
"shared": {
"johndoe" : {
"note5Key" : true,
"note3Key" : true
},
"jane" : {
"note1Key" : true
}
...
}
Quand « John Doe » crée une note, la note est stockée dans notes/noteKey
avec un accès en lecture/écriture accordée au propriétaire et les collaborateurs ajoutés par le propriétaire. De plus, la clé de la note est stockée dans user/johndoe/notes/noteKey
, qui peut être lue et écrite uniquement par lui. Lorsque cet utilisateur veut ajouter un collaborateur ("Jane") à sa note, cette même note est stockée dans shared/jane/noteKey
qui peut être lu globalement & écrit dans. De cette façon, lors de la liste des notes de chaque utilisateur, je dois lire à partir de seulement 2 emplacements pour lister toutes les notes auxquelles un utilisateur a accès: user/johndoe/notes
et shared/johndoe
.
Y a-t-il une meilleure approche? Je n'aime pas avoir l'index shared
globalement accessible, pourrais-je le limiter d'une manière ou d'une autre? Puisqu'un utilisateur peut potentiellement collaborer avec un grand nombre d'utilisateurs différents sur des notes différentes, je ne suis pas vraiment sûr de savoir comment définir les règles de sécurité, afin de limiter l'accès en lecture/écriture à cet index.
Je pensais à inverser la logique du nœud shared
, pour stocker les clés de note sous ses sous-nœuds propriétaires respectueux et y inclure une liste de collaborateurs comme suit: shared/jane/noteKey/collaborators/johndoe
. De cette façon, je pourrais avoir une règle de lecture globale et une règle d'écriture plus restrictive (chaque utilisateur ne peut écrire que dans son propre noeud shared
), mais cela augmenterait considérablement la complexité de la liste de toutes les notes auxquelles un utilisateur a accès.