2016-05-03 1 views
3

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.

Répondre

0

Vous vouliez:

  1. permettent d'ajouter des propriétaires & collaborateurs aux notes de l'utilisateur.
  2. liste toutes les notes appartenant à un utilisateur.
  3. liste toutes les notes auxquelles un utilisateur a accès.

Vous devriez avoir ajouté collaborators liste à chaque note comme suit:

{"rules":{ 

    "users": { 
    "$user_id": { 
     "profile_and_settings":{ 
      ".write":"auth != null && auth.uid == $user_id" 
     }, 
     "owned_notes":{ 
      ".write":"auth != null && auth.uid == $user_id", 
      "$note_id":{} 
     }, 
     "accesssible_notes": { 
      ".write":"auth != null", 
      "$note_id":{} 
     } 
    } 
    }, 

    "notes": { 
    "$note_id": { 

     // to edit this node: must authenticated, new entry or owner of this node. 
     ".write":"auth != null && (!data.exists() || data.child('owner').val() == auth.uid)", 

     "owner":{ 
      ".validate":"newData.val() == auth.uid" 
     }, 

     "collaborators":{ 
      "$user_id":{} 
     }, 

     // ... other note data 

    } 
    //... 
    } 
}} 

Voir question connexe:
Firebase rule: Do we have better ways to manage object ownership?