消息数组火力地堡安全规则 [英] Firebase security rule for array of messages

查看:131
本文介绍了消息数组火力地堡安全规则的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我想显示根据收件人的邮件列表,但现在,让我们保持它的简单。我只是想显示邮件列表。

I am trying to display a list of messages based on the recipient but for now, let's keep it simple. I am just trying to display a list of messages.

我的规则看起来像这样

{
"rules": {
  "communications" : {
    "$communication":{
      ".read" : true,
      ".write": true
    }
  }
}

由于某些原因,虽然,我的应用程序并不想读

For some reason though, my application does not want to read it

fireRef = new Firebase(url);
fireRef.auth(MY_TOKEN);
commsRef = fireRef.child('communications')
$scope.communications = $firebase(commsRef)

这只有当我有一个规则看起来像作品

It only works if I have a rule looking like

{
"rules": {
  "communications" : {
    ".read" : true,
    ".write": true
  }
}

但是,这会导致问题,因为我想我沟通的子节点上添加条件。是这样的:

But that will cause problem as I would like to add condition on the children node of my communication. Something like:

{
"rules": {
  "communications" : {
    ".read" : true, ### I would like to get rid of this line as well and have the child handling it
    ".write": true,

    "$communication":{
      ".read" : "data.child('to').val() == auth.uid"
    }
  }
}

我假设是因为我对通信$火力点,这需要一定的读写规则,但我如何才能当,否则增加了新的消息的事件

I am assuming that is because I have a $firebase on the communications and it needs some read or write rules but how do I get the event when a new message is added otherwise

感谢

推荐答案

在安全性方面的规则,火力地堡操作是全有或全无。

With respect to security rules, Firebase operations are all-or-nothing.

这意味着,发送到客户端数据列表永远是不完整的,或者的过滤的意见完整的服务器数据。其结果是,试图加载所有数据的 /通讯使用第一组安全规则时会失败,即使你有权限读取一些数据有作为 /通信/通讯$由管辖子规则

That means that lists of data sent to the client will never be incomplete, or filtered views of the complete server data. As a result, attempting to load all of the data at /communications will fail when using your first set of security rules, even though you do have permission to read some of the data there as governed by the child rule at /communications/$communication.

要处理这种使用情况,可以考虑调整你的数据使得每个通信由收件人,即指数 /通信/ $收件人/ $通讯,这将简化您的安全规则。

To handle this use case, consider restructuring your data such that each communication is indexed by recipient, i.e. /communications/$recipient/$communication, which will simplify your security rules.

此外,你甚至可以作出这样的桶只读接受者(即 .read:auth.id == $收件人),同时允许任何人发送消息(!即 .WRITE:AUTH = NULL&放大器;&安培; data.exists()!)给该用户。这最后一条规则确保发送客户端进行身份验证并写入尚不存在,如新推的id的位置。

Additionally, you could even make that bucket read-only by the recipient (i.e. .read: auth.id == $recipient) while allowing anyone to send a message to that user (i.e. .write: auth != null && !data.exists()). That last rule ensures that the sending client is authenticated and writing to a location that does not yet exist, such as a new push id.

这篇关于消息数组火力地堡安全规则的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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