Правило безопасности Firebase для массива сообщений

Я пытаюсь отобразить список сообщений в зависимости от получателя, но пока давайте не будем усложнять. Я просто пытаюсь отобразить список сообщений.

Мое правило выглядит так

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

По какой-то причине мое приложение не хочет его читать

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

Это работает, только если у меня есть правило, похожее на

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

Но это вызовет проблемы, так как я хотел бы добавить условие для дочернего узла моего сообщения. Что-то типа:

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

Я предполагаю, что это связано с тем, что у меня есть $firebase в сообщениях, и ему нужны некоторые правила чтения или записи, но как я могу получить событие, когда в противном случае добавляется новое сообщение

Спасибо


firebase firebase-security angularfire angularjs
person Matthieu    schedule 23.10.2014    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Что касается правил безопасности, операции Firebase работают по принципу «все или ничего».

Это означает, что списки данных, отправляемых клиенту, никогда не будут неполными, или отфильтрованными представлениями полных данных сервера. В результате попытка загрузить все данные в /communications завершится ошибкой при использовании вашего первого набора правил безопасности, даже если у вас есть разрешение на чтение некоторых данных в соответствии с дочерним правилом в /communications/$communication.

Чтобы справиться с этим вариантом использования, рассмотрите возможность реструктуризации ваших данных таким образом, чтобы каждое сообщение индексировалось по получателю, т. е. /communications/$recipient/$communication, что упростит ваши правила безопасности.

Кроме того, вы даже можете сделать это ведро доступным только для чтения для получателя (например, .read: auth.id == $recipient), позволяя любому отправлять сообщение этому пользователю (например, .write: auth != null && !data.exists()). Это последнее правило гарантирует, что клиент-отправитель аутентифицирован и записывает в место, которое еще не существует, например новый идентификатор push-уведомления.

person Rob DiMarco    schedule 23.10.2014
comment
Я просто просматривал ваше руководство по структурированию данных. firebase.com/docs/web/guide/structuring-data.html и думаю, не ошибся ли я. Видимо, я сделал. Спасибо. Это объясняет, почему чату нужна комната даже для 121, я думаю. - person Matthieu; 23.10.2014
comment
Имеет ли смысл иметь сообщения/$ отправителя/$ получателя/$ сообщения, или они слишком вложены? - person Matthieu; 23.10.2014
comment
@Matthieu Нет особого беспокойства по поводу того, что Firebase будет слишком вложенным, так как наш предел вложенности довольно высок, и производительность не пострадает. Ключ в том, чтобы структурировать ваши данные таким образом, чтобы они соответствовали вашему шаблону доступа. - person Rob DiMarco; 23.10.2014
comment
См. также: Каскад правил безопасности - person Kato; 27.10.2014