Статьи:

  1. Основные примеры использования правил безопасности Cloud Firestore
  2. Расширенные примеры использования правил безопасности Cloud Firestore

Правила безопасности Cloud Firestore - это инструмент для определения контроля доступа к вашему Firestore. Вам не нужно беспокоиться о создании кода авторизации или аутентификации для своей базы данных. На панели управления Правилами безопасности Cloud Firestore определите совпадения с вашими коллекциями или вложенными коллекциями и создайте условия для каждой из них, чтобы управлять доступом к Firestore.

1. Заблокируйте Firestore.

Это часть кода для блокировки любых операций в Firestore. Вы должны помнить, что запросы от Admin SDK все еще возможны.

match /{document=**} {
   allow read, write: if false;
}
  • Синтаксис подстановочных знаков {document=**} используется для сопоставления всех коллекций и вложенных коллекций в Firestore.
  • Простое условие false для блокировки всех операций

2. Разблокируйте Firestore.

Это пример того, как сделать Firestore полностью открытым для всех запросов и всех пользователей.

match /{document=**} {
   allow read, write; // or allow read, write: if true;
}
  • Синтаксис подстановочных знаков {document=**} используется для сопоставления всех коллекций и вложенных коллекций в Firestore
  • Firestore не блокирует запросы, если вы не определяете условия.
  • Простое условие true для разрешения всех операций

3. Особые правила безопасности для конкретной коллекции

match /{collectionName}/{documentId} {
   allow read, write : if collectionName != "users";
}
  • Синтаксис подстановочных знаков collectionName был использован для создания особых условий для коллекции users

4. Доступ для аутентифицированного пользователя.

В правилах безопасности у вас есть доступ к объекту request. Request состоит из аутентификационной информации, поэтому вы можете использовать ее для проверки аутентификации запрашиваемого пользователя.

match /products/{productId} {
   allow read: if request.auth != null;
}
  • Этот матч обрабатывает все вызовы коллекции products
  • Операция чтения разрешена только для аутентифицированного пользователя.

5. Доступ для конкретного пользователя

Это очень конкретный пример, но его можно использовать в любом приложении. Это правило безопасности разрешает операцию чтения или записи только пользователю с тем же uid, что и идентификатор документа. Самый популярный пример использования этого правила безопасности - коллекция пользователей, в которой идентификатор пользователя совпадает с идентификатором документа.

match /users/{userId} {
   allow read: if request.auth.uid == userId;
}
  • Подстановочный знак идентификатора документа - userId - использовался для сравнения его с идентификатором запрошенного пользователя.

6. Доступ для пользователей, сохраненных в виде массива внутри документа

Пришло время показать вам, как использовать resource, хранящийся в Firestore или доступный в write операции. resource объект состоит из:

  • _name_ - полный путь к документу
  • data - все данные документа
  • id - идентификатор документа
match /posts/{postId} {
   allow read: if request.auth.uid in resource.data.contributors;
}

В нашем примере мы используем resource.data, чтобы получить массив участников и проверить, существует ли запрошенный пользователь в массиве.

  • request.auth.uid - информация об ID запрошенного пользователя
  • resource.data.contributors - в документе есть файл с именем contributors и он сохранен в базе данных как array
  • in используется для проверки наличия request.auth.uid в массиве contributors

Чтобы создать условие с использованием данных, доступных в операции записи, используйте request.resource.

7. Объект существует?

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

exists(/databases/$(database)/documents/collectionName/$(documentId))

  • $(database) - параметр, определяющий экземпляр базы данных, доступный как подстановочный знак в одной из основных строк каждого файла правил безопасности Cloud Firestore
    match /databases/{database}/documents
  • collectionName - название коллекции документа, который мы хотим проверить
  • documentId - ID запрашиваемого документа

Пример использования:

match /notificationStrategy/{strategyId} {
   allow write: if exists(/databases/$(database)/documents/
      user/$(request.auth.uid));
}
  • Операция записи разрешена только для пользователя, который существует в коллекции пользователей.
  • request.auth.uid - предоставляет требуемый идентификатор документа для пути

8. Доступ к другому документу

Другой метод, доступный в правилах безопасности Cloud Firestore, - это get() метод. Синтаксис этого метода такой же, как и в случае exists(), единственная разница заключается в результате метода. В этом случае у нас есть доступ к сохраненным данным, вызвав метод get(path).data.

match /post/{postId} {
   allow update, delete: if isPostOwner() || isAdmin();
   function isPostOwner() {
      return resource.data.ownerId == request.auth.uid;
   }
   function isAdmin() {
      return get(/databases/$(database)/documents/
          user/$(request.auth.uid)).data.role == "ADMIN";
   }
}
  • Условие было разделено на другие методы для большей прозрачности. Я рекомендую сделать это в вашем коде
  • условие разрешает update или delete публикацию только владельцу сообщения или администратору
  • isAdmin() - получить запрошенного пользователя из коллекции пользователей и проверить его роль, сравнив его с кодом роли администратора — “ADMIN”

Это все! Я представил основные принципы правил безопасности Cloud Firestore и объяснил, как работает каждый из этих примеров. Пожалуйста, прокомментируйте! С радостью вам помогу (или отвечу на любые вопросы)!