Защита путей с помощью параметра userID - PullRequest
0 голосов
/ 09 декабря 2018

Данные структурированы следующим образом:

leads
|__(ID)
   |__name
   |__email
   |__userID

Текущее правило пожарной базы:

{
  "rules": {
    "leads": {
        ".indexOn": ["userID"],
        ".read": "auth !== null",
        ".write": "auth !== null"
    }
}

Это защищает данные, только если пользователь не вошел в систему. Я хотел бы добавитьдополнительный уровень защиты, чтобы гарантировать, что вошедший в систему пользователь не может прочитать никаких отведений, где auth.uid !== userID, но у меня возникают проблемы с его структурированием выше.

Я думал, что это будет работать, но родительский ".read": "auth !== null", кажется,переопределить его.

{
  "rules": {
     "leads": {
        ".indexOn": ["userID"],
        ".read": "auth !== null",
        ".write": "auth !== null",
        "$id": {
          ".read": "data.child('userID').val() === auth.uid"
        }
     }
   }
}

Ответы [ 2 ]

0 голосов
/ 09 декабря 2018

Когда вы предоставляете пользователю доступ к любому узлу, вы неявно предоставляете этому пользователю доступ к этому узлу и всему, что находится под ним .Вы не можете отключить доступ к ребенку, которому кто-то предоставил доступ для чтения на более высоком уровне.Когда вы предоставили доступ к "потенциальным клиентам" всем аутентифицированным пользователям, ваше правило для $ id в соответствии с этим фактически не имеет никакого эффекта для аутентифицированных пользователей.

0 голосов
/ 09 декабря 2018

Правило действительно работает.Путь, который я использовал для запуска моделирования, был с идентификатором другого родительского узла, поэтому фактические данные не существовали, и моделирование не удалось.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...