2017-05-09 145 views
2

我在Firebase中遇到了用户拥有角色的情况。根据已经在另一个“模式”中定义的一些配置文件,用户可以删除,更新,创建,删除和更新等等...许多组合。Firebase为用户设置角色

例:

Users/: 
    user_1: 
     create: "ok" 
     delete: "no" 
     update: "ok" 
    user_2: 
     create: "no" 
     ... etc ... 

如何在火力管理这个曾经” .WRITE的许可不接受动态条件?我发现博尔特有一些别名(创建()更新()删除())到然而,你只有创建OR更新删除。一旦一个定义,你不能改变。

谢谢

+0

也许尝试做每个用户的Linux chmod样式字段和创建权限的方式?这样,您只有一个字段,并在权限中定义所有组合。 –

+0

为了准确,Bolt是一个实验性的安全性和规则编译器,并且处于Beta版。 – Mario

+0

Hi @PrestonGarno。是的,这是有效的。恢复角色是可能的,但符合代表角色的条件是我没有意识到如何去做的部分。你可以恢复说777或765等角色,但是你不能根据这个改变firebase的.write规则。 – Mario

回答

2

我找到了一个解决方案...没有理想,如果是最好的...但是,解决我的问题。 无论如何,写条件都有点痛苦。

users roles"


,然后在你的火力点规则:

firebase rules

CUD手段Ç reate ü PDATE d elete。你也可以使用chmod数字(777,765等)。

现在,我需要了解如何编写条件-ud,--D等 :)

+0

这可以工作,但也可能会变得混乱。看看我的解决方案,让我知道你的想法。我更愿意采用每个“主”节点权限结构的路由,因为它看起来更加灵活。请记住 - 不要害怕有一堆条目 - 似乎违反直觉,但数据库设置为分散在各地,但易于维护/组织 –

3

好了,所以我会假设你的数据的结构类似下面。这个答案是我自己的主观方法,我将如何动态管理访问数据库不同部分的用户。

注意 ::我使用的chmod代表READ-WRITE-DELETE,而不是READ-WRITE-EXECUTE(即6 =读取+写入但不是删除,7 =完全CRUD特权)。此示例数据库分为三部分,并模拟社交媒体应用程序。 。此外,对于“世界”(第3位的默认很可能将只有经过身份验证的用户这是一个很简单的例子:

root/ 
| 
|-- user/     <-main node that contains profile info 
|  \uid    <-node name - one for each user with sub-nodes containing profile info 
|  \user    
|   |-<UID>  <-shows who has "user" privileges (1st digit) 
|  \group 
|   |-<UID>  <-shows who has "group" privileges (1st digit) 
| \permissions = 744 <-universal "user" entry rule 
| 
|-- trending/    <-node that contains global, read only info 
|  \user    <-No one will be here for "trending" 
|  \group 
|  \feed-data 
|   \<POST_UUIDS> <-Data here 
|  \permissions = 444 <-Everyone can read the global feed 
| 
|-- messaging/ 
|  \<chat-uuid-number-1>    
|   \user    
|    |-<User1> 
|    |-<User2> 
|   \group 
|   \messages node 
|  \<chat-uuid-number-2>    
|   \user    
|    |-<User8> 
|    |-<User5> 
|   \messages-node 
| 
|  \permissions = 600 <-Only 2 users can read&send messages in their node 
| 
|-- chatrooms/    <-each node contains a list of UID, and list of messages 
|  \<room-uuid-number> 
|  \user    
|   |-<Admin1> 
|   |-<Admin2...> 
|  \group 
|   |-<uid1> 
|   |-<uid2> 
|   |-<uid3...infinity> 
|  \permissions = 760 <-Only admins have user privilege, users in chat can send and receive in the chat though 

所以这是一个有点denormalized数据库结构,如JSON数据库显然应该在这里阅读:https://firebase.googleblog.com/2013/04/denormalizing-your-data-is-normal.html每个分支除了它所关心的东西外,并不包含非常多的信息现在,如果你有统一的“继承”类型结构,那么你可以使用相对目录路径来检查相对于目录用户试图访问并隔离验证规则的一个位置 - 然后所有的子节点都将被覆盖,只要它们具有统一的基本权限结构!

所以只要你的新数据永远不会进入根目录其下的任何主节点/目录(你可以编写规则来确保这一点),你可以使用data.parent()来获得你的条目的父母,然后再次调用parent()以进入主目录(例如,聊天室),那么你检查每个连续的数字对用户/组/世界列表的权限值,并匹配:

".write": "data.parent().parent().child('permissions').val().beginsWith('6') && data.parent().child('users').child($uid).exists" 

这(伪)检查的权限代码的第一个数字,然后检查节点的“用户”子目录查看当前用户是否具有该特定子节点的用户权限。在此之后添加一个条件OR来检查是否存在group写入权限并且用户存在于组中。等等...所有从根目录!只要确保你防止在'/'或'//'下写入(首先使用'& &'写入这些条件,以便在尝试获取根父级之前检查失败,等等),并且它应该可以正常工作。

这不是一个绝对的结构,但我把我的数据库设置为'浅'数据库,同时限制每个条目像“消息”这样的主目录下有一个权限代码并检查用户的UID数据库读/写,它为我节省了大量的痛苦。虽然我上次使用它的时间大约是5个月前,但我不确定事情是否现在变得更简单或者简单的工具/库。希望这有助于!

+0

非常感谢您的回答!我会仔细看看。无论如何,我只是推出了一个解决方案(到现在为止)为我工作。 – Mario

+0

@Mario没有问题,希望你找出任何方式。如果这对您有用,请不要忘记标记正确:)祝您好运。 –

+0

@Mario有一件事我忘了说清楚:'permission'节点位于“/ messages/permissions”(直接在主节点下)*定义每个单个消息对话的规则*。然后'user'和'group'节点以*每个聊天*为基础存在,所以它会是/ messages//users和/ messages//group ,所以每消息聊天1个。我认为我的根本规则是不正确的,这就是为什么我要澄清 –