Правила безопасности Firebase Storage и пожарного депо - PullRequest
Новая
       23

Правила безопасности Firebase Storage и пожарного депо

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

У меня есть «группы» в Firestore. У каждой группы есть ключ «члены». Моя цель - написать правило безопасности Firebase Storage, чтобы разрешить «запись» только членам группы: 

# I want something like this
match /groups/{groupId} {
  allow read, write: if request.auth.uid in get(/database/groups/{groupId}/members);
}

1 Ответ

1 голос
/ 22 марта 2020

Правила безопасности не могут считываться из другой службы, поэтому вы не сможете создавать группы так, как описано здесь. Вместо этого вам придется кодировать сведения о том, к каким группам кто-то принадлежит, либо в самих ваших правилах, либо в ID-токене пользователя (как пользовательское утверждение).

Встраивание членства в группах в пользователя token

Пример последнего см. в следующем фрагменте документации Firebase о , делающем данные «частной группой» :

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

  • Создайте собственный токен аутентификации Firebase, который содержит дополнительную информацию о члене группы (например, идентификатор группы)

  • Включить информацию о группе (например, идентификатор группы или список авторизованных идентификаторов) в метаданные файла

После сохранения этих данных в метаданных токена или файла на них можно ссылаться из правила: 

// Allow reads if the group ID in your token matches the file metadata's `owner` property
// Allow writes if the group ID is in the user's custom token
match /files/{groupId}/{fileName} {
  allow read: if resource.metadata.owner == request.auth.token.groupId;
  allow write: if request.auth.token.groupId == groupId;
}

В наши дни вам не нужно чеканить полный пользовательский токен, чтобы включить идентификатор группы, но вы можете включить информацию в обычный токен в виде пользовательская заявка через SDK Firebase Admin. Например, в Node.js вы можете добавить идентификатор группы, как показано выше: 

admin.auth().setCustomUserClaims(uid, {groupId: "group"})

Этот подход хорошо работает для случаев, когда вы можете четко идентифицировать одну группу (или небольшую группу). набор групп), частью которого является пользователь. Если вы получаете большие иерархии членства в группах, с включениями и исключениями, становится сложнее захватывать их в утверждениях, особенно для всех утверждений должно быть меньше 1000 байт.

Включение членства в группах в правилах

Другой подход заключается во внедрении знаний о членстве в группах в сами правила. В этом сценарии вы возьмете структуру, которую вы сейчас имеете в своей базе данных, и закодируете ее в свои правила.

Вы можете сделать это вручную, если членство в группах достаточно стабильно. И в этом случае в ваших правилах безопасности вы получите жестко запрограммированные UID.

Но поскольку вы решили сохранить членство в группе в базе данных, эти членства, скорее всего, по крайней мере несколько динамичны c. В этом случае вы можете использовать комбинацию предыдущего подхода для захвата части членства, а затем сгенерировать правила безопасности для других частей.

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

Хотя это более грубый подход, чем (просто) встраивание информации в токены пользователя, я видел, что она использовалась для создания расширенного членства тесты. Моя главная неприятность в том, что сгенерированные правила безопасности становятся нечитаемыми. Вы можете уменьшить это, сгенерировав «групповую проверку» в отдельной функции в ваших правилах, так что рукописные правила (которые вы будете чаще читать) могут просто включать вызов isMemberOfValidGroup(...) или что-то в этом роде.

...