Правила безопасности Firestore - использование пользовательских утверждений - PullRequest
Новая
       0

Правила безопасности Firestore - использование пользовательских утверждений

0 голосов
/ 01 марта 2020

Я просто хочу убедиться, что правильно понимаю пользовательские утверждения, вот один пример того, как я хочу их использовать: в своем приложении я связываю каждого пользователя с уникальным удобным идентификатором пользователя (например, «Билл») и некоторыми из них. мои правила безопасности используют этот идентификатор. Информация о пользователе и профиль хранятся в документе / users / {user}, где я также храню соответствующий идентификатор аутентификации Firestore.

Например: в документе / users / bill у меня есть 

  { firstname: "William"
    lastname: "Clinton"
    ...
    userid: "Bill"            // Case sensitive userid
    uid: "faergq34tfawefawef" // A valid Firestore authentication id }

Затем у меня есть несколько коллекций, в которых я хочу определить доступ на основе этого идентификатора пользователя, например: 

match /users/{user}/friends/{friend} {
  allow create, update: if request.auth.uid != null
    && get(/databases/$(database)/documents/users/$(user)).data.uid==request.auth.uid;
}

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

match /users/{user}/friends/{friend} {
  allow create, update: if request.auth.uid != null
    && request.auth.token.userid.lower() == user;
}

Гораздо проще и сохраняет 1 чтение при каждом выполнении правила. Есть отзывы? Имеет ли это смысл? Прежде чем переписать все свои правила, просто убедитесь, что я что-то не упустил ...

1 Ответ

2 голосов
/ 01 марта 2020

Я не уверен, почему вы когда-нибудь захотите использовать userid в правиле, когда кажется, что обычная Firebase uid столь же уникальна и всегда доступна в request.auth.uid. Я вижу userid как нечто, что важно только для целей отображения.

Цель пользовательских утверждений состоит в том, чтобы прикрепить данные к учетной записи пользователя, которая предоставляет ей особые привилегии или разрешения. Обычно люди вводят логическое значение для предоставления доступа «администратор» или указывают какой-либо тип членства в группе.

Идентификатор пользователя на самом деле не относится ни к одной из этих вещей. Хотя не обязательно неправильно указывать идентификатор пользователя в пользовательских утверждениях, я не вижу, какое значение он имеет здесь. У пользователя уже есть уникальный идентификатор со своим идентификатором Firestore UID - это должен быть предпочтительный способ проверки личности пользователя.

...