Firebase的“规则不是过滤器”的解决方法约束 [英] Workaround for Firebase's "Rules Are Not Filters" constraint

查看:114
本文介绍了Firebase的“规则不是过滤器”的解决方法约束的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我想要一个安全规则,允许任何人获得用户列表并阅读他们的名字,但只允许登录用户查看他们自己的电子邮件。



这里有一个示例数据结构:

pre $ User:{
abc123:{
name :Bob,
email:bob@hotmail.com
}
}

对安全规则的一种天真的做法可能是执行以下操作:

 用户:{
$ user:{
name:{
.read:true
},
email:{
.read:auth.uid === $ user
}
}
}

然而,因为在用户级别没有读取规则,读取列表的请求将被拒绝,但是在用户级别添加读取规则将覆盖电子邮件规则,并使每个孩子节点可读(参见

安全指南指出规则不是过滤器,但是并没有提供太多的指导,我该怎么办。



我应该把我的User实体分成PrivateUser和PublicUser吗?$ b $为了让任何人获得用户名单并阅读他们的名字。

并允许登录用户查看他们自己的电子邮件。


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&& amp ; $ user == auth.uid,
email:{}
}
}}
}}


I’d like a security rule that lets anyone get a list of users and read their names, but only allows logged in users to view their own email.

Here’s an example data structure:

    "User" : {
        "abc123" : {
          "name" : "Bob",
          "email" : "bob@hotmail.com"
        }   
    }

A naive approach to a security rule might be to do the following:

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

However because there is no read rule at the User level, requests to read the list will be denied. But adding a read rule at the User level will override the email rule, and make every child node readable (see Rules Cascade in Firebase's Security Guide).

The Security guide does point out that Rules Are Not Filters, but doesn’t offer much guidance as to what to do about it.

Should I just split my User entity up into PrivateUser and PublicUser?

解决方案

To let anyone get a list of users and read their names. AND to allow logged in users to view their own email.

Zac says: first think about access, and then to model objects that are either completely public or completely private.

Type 1:

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

Type 2:

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

这篇关于Firebase的“规则不是过滤器”的解决方法约束的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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