Firebase:协作应用程序的安全性规则 [英] Firebase: Security rules for a collaborative app

查看:76
本文介绍了Firebase:协作应用程序的安全性规则的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在编写一个笔记共享应用程序,我试图找到一种最佳的数据结构方法,以允许向用户笔记中添加协作者,同时对所讨论的结构具有合理的安全性规则.

I'm writing a note sharing app and I'm trying to find the best approach for the data structure to allow adding collaborators to user notes, while at the same time having sensible security rules for the structure in question.

我现在所拥有的是以下内容:

What I have now is the following:

"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  
    }
    ...
}

当"John Doe"创建便笺时,便笺将存储在notes/noteKey中,并授予所有者和所有者添加的协作者读写权限.此外,笔记的密钥存储在user/johndoe/notes/noteKey中,只有他才能对其进行读写.当该用户想要在他的便笺中添加一个协作者(简")时,该便笺键存储在shared/jane/noteKey中,该键可以全局读取和存储.写给.这样,在列出每个用户的注释时,我只需要从两个位置读取即可列出用户可以访问的所有注释:user/johndoe/notesshared/johndoe.

When "John Doe" creates a note, the note is stored in notes/noteKey with read/write access granted to owner and collaborators added by the owner. Additionally the note's key is stored in user/johndoe/notes/noteKey, which can be read and written to only by him. When this user wants to add a collaborator ("Jane") to his note, this same note key is stored in shared/jane/noteKey which can be globally read & written to. This way, when listing each user's notes, I have to read from only 2 locations to list all notes a user has access to: user/johndoe/notes and shared/johndoe.

有没有更好的方法?我不希望全局访问shared索引,我可以以某种方式限制它吗?由于一个用户可以与大量不同的用户在不同的注释上进行协作,因此我不确定如何设置安全规则来限制对该索引的读/写访问.

Is there a better approach? I don't like to have the shared index globally accessible, could I somehow limit it? Since one user can potentially collaborate with a big number of different users on different notes, I'm not really sure how to set the security rules, to limit the read/write access to this index.

我当时正在考虑反转shared节点逻辑,以将音符键存储在受尊重的所有者子节点下,并包括如下合作者列表:shared/jane/noteKey/collaborators/johndoe.这样,我可以拥有一个全局读取规则和一个更严格的写入规则(每个用户只能在自己的shared节点中写入),但是这将大大增加列出用户可以访问的所有笔记的复杂性.

I was thinking about reversing the shared node logic, to store note key's under it's respectful owners sub-nodes and including a list of collaborators like so: shared/jane/noteKey/collaborators/johndoe. This way I could have a global read rule and a more restrictive write rule (each user can only write in his own shared node), however this would greatly increase the complexity of listing all notes a user has access to.

推荐答案

您想:

  1. 允许添加所有者&用户注释的协作者.
  2. 列出用户拥有的所有注释.
  3. 列出用户有权访问的所有注释.
  1. allow adding owner & collaborators to user notes.
  2. list all notes a user owned.
  3. list all notes a user has access to.

您应该将collaborators列表添加到每个注释中,如下所示:

You should have added collaborators list to each notes as follows:

{"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

    }
    //...
  }
}}

查看相关问题:
Firebase规则:我们有更好的方法吗?管理对象所有权的方法?

See related question:
Firebase rule: Do we have better ways to manage object ownership?

这篇关于Firebase:协作应用程序的安全性规则的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆