Статьи:
- Основные примеры использования правил безопасности Cloud Firestore
- Расширенные примеры использования правил безопасности 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 Firestorematch /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 и объяснил, как работает каждый из этих примеров. Пожалуйста, прокомментируйте! С радостью вам помогу (или отвечу на любые вопросы)!