Firebase Security Rules для Cloud Storage позволяют контролировать доступ к объектам, хранящимся в сегментах Cloud Storage . Гибкий синтаксис правил позволяет создавать правила для управления любой операцией, от всех операций записи в ваш сегмент Cloud Storage до операций с конкретным файлом.
В этом руководстве описаны базовый синтаксис и структура Cloud Storage Security Rules для создания полных наборов правил.
Объявление об услугах и базе данных
Firebase Security Rules для Cloud Storage всегда начинаются со следующего заявления:
service firebase.storage {
// ...
}
Объявление service firebase.storage ограничивает действие правил только Cloud Storage , предотвращая конфликты между Cloud Storage Security Rules и правилами для других продуктов, таких как Cloud Firestore .
Основные правила чтения/записи
Основные правила состоят из оператора match , определяющего сегменты Cloud Storage , оператора match, указывающего имя файла, и выражения allow описывающего, когда разрешено чтение указанных данных. Выражения allow определяют задействованные методы доступа (например, чтение, запись) и условия, при которых доступ разрешен или запрещен.
В вашем стандартном наборе правил первое выражение match использует подстановочное выражение {bucket} чтобы указать, что правила применяются ко всем корзинам в вашем проекте. Мы подробнее обсудим идею соответствия с использованием подстановочных символов в следующем разделе.
service firebase.storage {
// The {bucket} wildcard indicates we match files in all Cloud Storage buckets
match /b/{bucket}/o {
// Match filename
match /filename {
allow read: if <condition>;
allow write: if <condition>;
}
}
}
Все операторы match указывают на файлы. Оператор match может указывать на конкретный файл, например, match /images/profilePhoto.png .
Сопоставление с использованием джокеров
Помимо указания на один файл, Rules могут использовать подстановочные знаки для указания на любой файл, в имени которого присутствует заданный строковый префикс, включая косые черты, например, match /images/{imageId} .
В приведенном выше примере оператор match использует синтаксис подстановочного знака {imageId} . Это означает, что правило применяется к любому файлу, имя которого начинается с /images/ , например, /images/profilePhoto.png или /images/croppedProfilePhoto.png . При оценке выражений allow в операторе match переменная imageId будет преобразована в имя файла изображения, например, profilePhoto.png или croppedProfilePhoto.png .
В рамках match можно использовать переменную с подстановочным знаком для указания имени файла или пути к нему:
// Another way to restrict the name of a file
match /images/{imageId} {
allow read: if imageId == "profilePhoto.png";
}
Иерархические данные
Как мы уже говорили, внутри хранилища Cloud Storage нет иерархической структуры. Но, используя соглашение об именовании файлов, часто включающее косые черты в имена файлов, мы можем имитировать структуру, которая выглядит как вложенная последовательность каталогов и подкаталогов. Важно понимать, как Firebase Security Rules взаимодействуют с этими именами файлов.
Рассмотрим ситуацию с набором файлов, имена которых начинаются с корневого каталога /images/ . Firebase Security Rules применяются только к соответствующему имени файла, поэтому ограничения доступа, определенные для корневого каталога /images/ не применяются к корневому каталогу /mp3s/ . Вместо этого напишите явные правила, которые соответствуют различным шаблонам имен файлов:
service firebase.storage {
match /b/{bucket}/o {
match /images/{imageId} {
allow read, write: if <condition>;
}
// Explicitly define rules for the 'mp3s' pattern
match /mp3s/{mp3Id} {
allow read, write: if <condition>;
}
}
}
При вложенных операторах match путь внутреннего оператора match всегда добавляется к пути внешнего оператора match . Поэтому следующие два набора правил эквивалентны:
service firebase.storage {
match /b/{bucket}/o {
match /images {
// Exact match for "images/profilePhoto.png"
match /profilePhoto.png {
allow write: if <condition>;
}
}
}
}
service firebase.storage {
match /b/{bucket}/o {
// Exact match for "images/profilePhoto.png"
match /images/profilePhoto.png {
allow write: if <condition>;
}
}
}
Рекурсивные совпадения с использованием джокеров
В дополнение к подстановочным символам, которые соответствуют строке в конце имени файла и возвращают её, для более сложного сопоставления можно объявить подстановочный символ, состоящий из нескольких сегментов , добавив к имени подстановочного символа =** , например, {path=**} :
// Partial match for files that start with "images"
match /images {
// Exact match for "images/**"
// e.g. images/users/user:12345/profilePhoto.png is matched
// images/profilePhoto.png is also matched!
match /{allImages=**} {
// This rule matches one or more path segments (**)
// allImages is a path that contains all segments matched
allow read: if <other_condition>;
}
}
Если файлу соответствует несколько правил, результатом является операция OR результатов всех проверок правил. То есть, если хотя бы одно правило, которому соответствует файл, оценивается как true , результат также true .
В приведенных выше правилах файл "images/profilePhoto.png" может быть прочитан, если condition или other_condition оцениваются как истинные, тогда как файл "images/users/user:12345/profilePhoto.png" зависит только от результата other_condition .
Cloud Storage Security Rules не распространяются последовательно, и правила оцениваются только тогда, когда путь запроса совпадает с путем, для которого указаны правила.
Версия 1
Firebase Security Rules по умолчанию используют версию 1. В версии 1 рекурсивные подстановочные знаки соответствуют одному или нескольким элементам имени файла, а не нулю или более элементам. Таким образом, match /images/{filenamePrefixWildcard}/{imageFilename=**} соответствует имени файла типа /images/profilePics/profile.png, но не /images/badge.png. Вместо этого используйте /images/{imagePrefixorFilename=**} .
Рекурсивные подстановочные символы должны располагаться в конце оператора сопоставления.
Мы рекомендуем использовать версию 2 из-за её более мощных функций.
Версия 2
В версии 2 Firebase Security Rules рекурсивные подстановочные знаки соответствуют нулю или более элементам пути. Таким образом, /images/{filenamePrefixWildcard}/{imageFilename=**} соответствует именам файлов /images/profilePics/profile.png и /images/badge.png.
Для активации версии 2 необходимо добавить в начало правил безопасности rules_version = '2';
rules_version = '2';
service cloud.storage {
match /b/{bucket}/o {
...
}
}
В одном операторе match можно использовать не более одного рекурсивного подстановочного знака, но во второй версии этот подстановочный знак можно разместить в любом месте оператора match. Например:
rules_version = '2';
service firebase.storage {
match /b/{bucket}/o {
// Matches any file in a songs "subdirectory" under the
// top level of your Cloud Storage bucket.
match /{prefixSegment=**}/songs/{mp3filenames} {
allow read, write: if <condition>;
}
}
}
Гранулярные операции
В некоторых ситуациях полезно разбить операции read и write на более мелкие этапы. Например, ваше приложение может захотеть применять разные условия при создании и удалении файлов.
Операция read может быть разбита на get и list .
Правило write можно разбить на create , update и delete :
service firebase.storage { match /b/{bucket}/o { // A read rule can be divided into read and list rules match /images/{imageId} { // Applies to single file read requests allow get: if <condition>; // Applies to list and listAll requests (Rules Version 2) allow list: if <condition>; // A write rule can be divided into create, update, and delete rules match /images/{imageId} { // Applies to writes to file contents allow create: if <condition>; // Applies to updates to (pre-existing) file metadata allow update: if <condition>; // Applies to delete operations allow delete: if <condition>; } } } }
Перекрывающиеся заявления о матче
Имя файла может соответствовать нескольким match . В случае, если несколько выражений allow соответствуют запросу, доступ разрешается, если true хотя бы одно из следующих условий:
service firebase.storage {
match b/{bucket}/o {
// Matches file names directly inside of '/images/'.
match /images/{imageId} {
allow read, write: if false;
}
// Matches file names anywhere under `/images/`
match /images/{imageId=**} {
allow read, write: if true;
}
}
}
В приведенном выше примере разрешены все операции чтения и записи файлов, имена которых начинаются с /images/ поскольку второе правило всегда true , даже если первое правило false .
Правила — это не фильтры.
После того как вы защитите свои данные и начнете выполнять операции с файлами, помните, что правила безопасности — это не фильтры. Вы не можете выполнять операции с набором файлов, соответствующих определенному шаблону имени файла, и ожидать, что Cloud Storage получит доступ только к тем файлам, к которым у текущего клиента есть разрешение на доступ.
Например, рассмотрим следующее правило безопасности:
service firebase.storage {
match /b/{bucket}/o {
// Allow the client to read files with contentType 'image/png'
match /aFileNamePrefix/{aFileName} {
allow read: if resource.contentType == 'image/png';
}
}
}
Отклонено : Это правило отклоняет следующий запрос, поскольку результирующий набор может включать файлы, у которых contentType не равен image/png :
Веб
filesRef = storage.ref().child("aFilenamePrefix"); filesRef.listAll() .then(function(result) { console.log("Success: ", result.items); }) });
Cloud Storage Security Rules оценивают каждый запрос на предмет его потенциального результата и отклоняют запрос, если он может вернуть файл, на чтение которого у клиента нет разрешения. Запросы на доступ должны соответствовать ограничениям, установленным вашими правилами.
Следующие шаги
Вы можете углубить свои знания о Firebase Security Rules для Cloud Storage :
Изучите следующую важную концепцию языка правил — динамические условия , которые позволяют вашим правилам проверять авторизацию пользователей, сравнивать существующие и входящие данные, подтверждать достоверность входящих данных и многое другое.
Ознакомьтесь с типичными сценариями использования безопасности и определениями Firebase Security Rules , которые их охватывают .
Вы можете ознакомиться с примерами использования Firebase Security Rules специфичными для Cloud Storage :