Firebase的“规则不是过滤器”约束的解决方法

我想要一个安全规则，允许任何人获取用户列表并读取其名称，但只允许登录的用户查看自己的电子邮件。Firebase的“规则不是过滤器”约束的解决方法

下面是一个例子的数据结构：

"User" : { 
     "abc123" : { 
      "name" : "Bob", 
      "email" : "[email protected]" 
     } 
    }

一个天真的方式，以安全规则可能是做到以下几点：

"User" : { 
    "$user" : { 
     "name" : { 
      ".read" : true 
     }, 
     "email" : { 
      ".read” : "auth.uid === $user" 
     } 
    } 
}

但是因为在用户层面没有读取的规则，请求阅读清单将被拒绝。但在用户级别添加读取规则将覆盖电子邮件规则，并使每个子节点都可读（请参阅Firebase安全指南中的Rules Cascade）。

安全指南确实指出，Rules Are Not Filters，但没有提供关于如何处理它的很多指导。

我应该把我的User实体分成PrivateUser和PublicUser吗？

来源

2016-01-21 Zac

这确实是这样做的一个常见方式。一般来说，在NoSQL中建模数据时，需要对数据进行建模，以确定如何在应用程序中使用它。看到这篇文章更好的建议：https：//highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/ –

谢谢弗兰克，我没有任何有关NoSQL数据库的经验。我天真的做法是，“好吧，我需要一个用户对象，并且用户拥有这些属性，其中一些属性是私有的”。那么你是说，一个更好的思维过程将首先考虑访问，然后对完全公开或完全私有的对象进行建模？ – Zac

对于来自SQL背景的人来说，尝试将其关系模型建模为分层系统（如Firebase）非常普遍。它只是不起作用。阅读文章，你会更好地装备应付。还建议您阅读Firebase网站：https：//www.firebase.com/blog/2013-04-12-denormalizing-is-normal.html，https://www.firebase.com/docs/web/guide /structuring-data.html。这看起来也不错：https：//www.airpair.com/firebase/posts/structuring-your-firebase-data，以及我们Google群组的最近一篇文章：https：//groups.google.com/forum/#!topic /火力通话/ 1p4O4Pc2w6k –

让任何人获得用户列表并阅读他们的名字。并允许登录用户查看他们自己的电子邮件。

Zac说：先想一下访问，然后到要么是完全公开的或完全私人的对象进行建模。

类型1：

{"rules":{ 
    "user_publicly":{"$user:{ 
    ".read":true, 
    "name":{} 
    }}, 
    "user_privately":{"$user:{ 
    ".read":"auth != null && $user == auth.uid", 
    "email":{} 
    }} 
}}

类型2：

{"rules":{ 
    "user":{"$user:{ 
    "public":{ 
     ".read":true, 
     "name":{} 
    }, 
    "private":{ 
     ".read":"auth != null && $user == auth.uid", 
     "email":{} 
    } 
    }} 
}}

来源

2016-07-16 18:29:36 Nik