Правила безопасности Firestore с несколькими разрешениями - PullRequest
Новая
       2

Правила безопасности Firestore с несколькими разрешениями

1 голос
/ 20 февраля 2020

У моего веб-сайта есть несколько учетных записей с разными разрешениями.

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

До сих пор с этой настройкой все работало идеально :

Заявки на пользователя 1 с доступом к 1 местоположению выглядят следующим образом: {"companyLocation": "testLocation1"}

Скоро у меня появятся пользователи, которые могут получить доступ к одному или нескольким местоположениям. Например, пользователь 2 может обращаться к «testLocation2» и «testLocation3», не имея доступа к «testLocation1».

Заявки пользователя 2 могут, например, иметь разделитель («¤») и выглядеть примерно так: {"companyLocation": "testLocation2 ¤ testLocation3"}

Как мне добиться этого с помощью правил безопасности? Я попытался: 

function checkMultipleLocations(){
  return request.auth.token.companyLocation.contains('testLocation2');
}

Это дает мне сообщение об ошибке:

Недопустимое имя функции: содержит

В документах, которые вы можете использовать in: v in x (Проверяет, есть ли значение v в списке x), но это не работает для списков (не возвращает true), работает только для объектов / карт (пробуется путем разбиения строки заявки пользователя на массив без удачи).

Есть идеи?

1 Ответ

1 голос
/ 20 февраля 2020

Оператор in работает только со списком. Значение этого утверждения {"companyLocation": "testLocation2 ¤ testLocation3"} является не списком, а строкой. Поэтому оператор in здесь не будет работать.

Список поддерживаемых операторов см. В документации по типу строки в правилах безопасности . В нем не упоминается метод contains, но имеет метод matches, который позволяет выполнить sh этот вариант использования. 

request.auth.token.companyLocation.matches('.*testLocation2.*')

Вы также можете попытаться сохранить заявку в виде массива: 

{"companyLocation": ["testLocation2", "testLocation3"]}

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

...