Это руководство основано на руководстве по структурированию правил безопасности и показывает, как добавлять условия в Cloud Firestore Security Rules . Если вы не знакомы с основами Cloud Firestore Security Rules , см. руководство по началу работы .
Основным строительным блоком Cloud Firestore Security Rules является условие. Условие — это логическое выражение, которое определяет, следует ли разрешить или запретить конкретную операцию. Используйте правила безопасности, чтобы писать условия, которые проверяют аутентификацию пользователей, проверяют входящие данные или даже получают доступ к другим частям вашей базы данных.
Аутентификация
Одним из наиболее распространенных шаблонов правил безопасности является управление доступом на основе состояния аутентификации пользователя. Например, ваше приложение может разрешить запись данных только вошедшим в систему пользователям:
service cloud.firestore {
match /databases/{database}/documents {
// Allow the user to access documents in the "cities" collection
// only if they are authenticated.
match /cities/{city} {
allow read, write: if request.auth != null;
}
}
}
Другой распространенный шаблон — убедиться, что пользователи могут читать и записывать только свои собственные данные:
service cloud.firestore {
match /databases/{database}/documents {
// Make sure the uid of the requesting user matches name of the user
// document. The wildcard expression {userId} makes the userId variable
// available in rules.
match /users/{userId} {
allow read, update, delete: if request.auth != null && request.auth.uid == userId;
allow create: if request.auth != null;
}
}
}
Если ваше приложение использует аутентификацию Firebase или Google Cloud Identity Platform , переменная request.auth
содержит информацию аутентификации для клиента, запрашивающего данные. Дополнительную информацию о request.auth
смотрите в справочной документации .
Проверка данных
Многие приложения хранят информацию о контроле доступа в виде полей документов в базе данных. Cloud Firestore Security Rules могут динамически разрешать или запрещать доступ на основе данных документа:
service cloud.firestore {
match /databases/{database}/documents {
// Allow the user to read data if the document has the 'visibility'
// field set to 'public'
match /cities/{city} {
allow read: if resource.data.visibility == 'public';
}
}
}
Переменная resource
относится к запрошенному документу, а resource.data
— это карта всех полей и значений, хранящихся в документе. Дополнительную информацию о переменной resource
смотрите в справочной документации .
При записи данных вам может потребоваться сравнить входящие данные с существующими. В этом случае, если ваш набор правил разрешает ожидающую запись, переменная request.resource
содержит будущее состояние документа. Для операций update
, которые изменяют только подмножество полей документа, переменная request.resource
будет содержать состояние ожидания документа после операции. Вы можете проверить значения полей в request.resource
, чтобы предотвратить нежелательные или противоречивые обновления данных:
service cloud.firestore {
match /databases/{database}/documents {
// Make sure all cities have a positive population and
// the name is not changed
match /cities/{city} {
allow update: if request.resource.data.population > 0
&& request.resource.data.name == resource.data.name;
}
}
}
Доступ к другим документам
Используя функции get()
и exists()
, ваши правила безопасности могут сравнивать входящие запросы с другими документами в базе данных. Обе функции get()
и exists()
ожидают полностью определенных путей к документу. При использовании переменных для создания путей для get()
и exists()
вам необходимо явно экранировать переменные, используя синтаксис $(variable)
.
В приведенном ниже примере переменная database
фиксируется оператором match match /databases/{database}/documents
и используется для формирования пути:
service cloud.firestore {
match /databases/{database}/documents {
match /cities/{city} {
// Make sure a 'users' document exists for the requesting user before
// allowing any writes to the 'cities' collection
allow create: if request.auth != null && exists(/databases/$(database)/documents/users/$(request.auth.uid));
// Allow the user to delete cities if their user document has the
// 'admin' field set to 'true'
allow delete: if request.auth != null && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true;
}
}
}
Для операций записи вы можете использовать функцию getAfter()
для доступа к состоянию документа после завершения транзакции или пакета операций записи, но до фиксации транзакции или пакета. Как и get()
, функция getAfter()
принимает полностью указанный путь к документу. Вы можете использовать getAfter()
для определения наборов операций записи, которые должны выполняться вместе как транзакция или пакет.
Доступ к лимитам звонков
Существует ограничение на количество вызовов доступа к документу для каждой оценки набора правил:
- 10 для запросов по одному документу и запросов.
20 для чтения нескольких документов, транзакций и пакетной записи. Предыдущее ограничение в 10 также применяется к каждой операции.
Например, представьте, что вы создаете пакетный запрос на запись с тремя операциями записи и что ваши правила безопасности используют два вызова доступа к документу для проверки каждой записи. В этом случае каждая запись использует 2 из 10 вызовов доступа, а пакетный запрос на запись использует 6 из 20 вызовов доступа.
Превышение любого ограничения приводит к ошибке отказа в разрешении. Некоторые вызовы доступа к документу могут быть кэшированы, и кэшированные вызовы не учитываются при расчете ограничений.
Подробное объяснение того, как эти ограничения влияют на транзакции и пакетную запись, см. в руководстве по обеспечению безопасности атомарных операций .
Доступ к звонкам и ценам
Использование этих функций выполняет операцию чтения в вашей базе данных, а это означает, что вам будет выставлен счет за чтение документов, даже если ваши правила отклонят запрос. Более подробную информацию о выставлении счетов см. в разделе «Цены Cloud Firestore .
Пользовательские функции
Поскольку ваши правила безопасности становятся более сложными, вы можете захотеть обернуть наборы условий в функции, которые вы сможете повторно использовать в своем наборе правил. Правила безопасности поддерживают пользовательские функции. Синтаксис пользовательских функций немного похож на JavaScript, но функции правил безопасности написаны на предметно-ориентированном языке, который имеет некоторые важные ограничения:
- Функции могут содержать только один оператор
return
. Они не могут содержать никакой дополнительной логики. Например, они не могут выполнять циклы или вызывать внешние службы. - Функции могут автоматически получать доступ к функциям и переменным из области, в которой они определены. Например, функция, определенная в области видимости
service cloud.firestore
, имеет доступ к переменнойresource
и встроенным функциям, таким какget()
иexists()
. - Функции могут вызывать другие функции, но не могут выполняться рекурсивно. Общая глубина стека вызовов ограничена 10.
- В версии правил
v2
функции могут определять переменные с помощью ключевого словаlet
. Функции могут иметь до 10 привязок let, но должны заканчиваться оператором return.
Функция определяется ключевым словом function
и принимает ноль или более аргументов. Например, вы можете объединить два типа условий, использованных в примерах выше, в одну функцию:
service cloud.firestore {
match /databases/{database}/documents {
// True if the user is signed in or the requested data is 'public'
function signedInOrPublic() {
return request.auth.uid != null || resource.data.visibility == 'public';
}
match /cities/{city} {
allow read, write: if signedInOrPublic();
}
match /users/{user} {
allow read, write: if signedInOrPublic();
}
}
}
Использование функций в правилах безопасности делает их более удобными в обслуживании по мере роста сложности правил.
Правила — это не фильтры
Когда вы защитите свои данные и начнете писать запросы, имейте в виду, что правила безопасности не являются фильтрами. Вы не можете написать запрос для всех документов в коллекции и ожидать, что Cloud Firestore вернет только те документы, к которым у текущего клиента есть разрешение.
Например, возьмем следующее правило безопасности:
service cloud.firestore {
match /databases/{database}/documents {
// Allow the user to read data if the document has the 'visibility'
// field set to 'public'
match /cities/{city} {
allow read: if resource.data.visibility == 'public';
}
}
}
Отказано : это правило отклоняет следующий запрос, поскольку набор результатов может включать документы, visibility
которых не является public
:
Интернет
db.collection("cities").get() .then(function(querySnapshot) { querySnapshot.forEach(function(doc) { console.log(doc.id, " => ", doc.data()); }); });
Разрешено : это правило разрешает следующий запрос, поскольку where("visibility", "==", "public")
гарантирует, что набор результатов удовлетворяет условию правила:
Интернет
db.collection("cities").where("visibility", "==", "public").get() .then(function(querySnapshot) { querySnapshot.forEach(function(doc) { console.log(doc.id, " => ", doc.data()); }); });
Правила безопасности Cloud Firestore оценивают каждый запрос на предмет его потенциального результата и отклоняют запрос, если он может вернуть документ, на чтение которого у клиента нет разрешения. Запросы должны соответствовать ограничениям, установленным вашими правилами безопасности. Дополнительные сведения о правилах и запросах безопасности см. в разделе безопасный запрос данных .
Следующие шаги
- Узнайте, как правила безопасности влияют на ваши запросы .
- Узнайте, как структурировать правила безопасности .
- Прочтите справочник правил безопасности .
- Узнайте, как написать условия Cloud Storage Security Rules Cloud Firestore для ваших приложений, использующих Cloud Storage for Firebase , для доступа к документам Cloud Firestore.