Google 致力于为黑人社区推动种族平等。查看具体举措
Эта страница переведена с помощью Cloud Translation API.
Switch to English

Условия использования в правилах безопасности Firebase Cloud Storage

Это руководство основано на изучении основного синтаксиса языкового руководства Firebase Security Rules, чтобы показать, как добавить условия в ваши правила безопасности Firebase для облачного хранилища.

Основным строительным блоком правил безопасности облачного хранилища является условие . Условие - это логическое выражение, которое определяет, следует ли разрешить или запретить конкретную операцию. Для основных правил использование true и false литералов в качестве условий идеально работает. Но язык Firebase Security Rules for Cloud Storage дает вам возможность писать более сложные условия, которые могут:

  • Проверить аутентификацию пользователя
  • Проверить входящие данные

Аутентификация

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

Когда аутентифицированный пользователь выполняет запрос от Cloud Storage, то request.auth переменного заполняются пользователь uid ( request.auth.uid ), а также требования к Firebase аутентификация JWT ( request.auth.token ).

Кроме того, при использовании настраиваемой проверки подлинности дополнительные утверждения отображаются в поле request.auth.token .

Когда неаутентифицированный пользователь выполняет запрос, переменная request.auth имеет значение null .

Используя эти данные, существует несколько распространенных способов использования аутентификации для защиты файлов:

  • Общедоступно: игнорировать request.auth
  • Аутентифицированный частный: убедитесь, что request.auth не равен null
  • Личный пользователь: убедитесь, что request.auth.uid равен uid пути
  • Частная группа: проверьте утверждения настраиваемого токена на соответствие выбранному утверждению или прочтите метаданные файла, чтобы узнать, существует ли поле метаданных

Общественные

Любое правило, которое не учитывает контекст request.auth может считаться public правилом, поскольку оно не учитывает контекст аутентификации пользователя. Эти правила могут быть полезны для вывода общедоступных данных, таких как игровые ресурсы, звуковые файлы или другой статический контент.

// Anyone to read a public image if the file is less than 100kB
// Anyone can upload a public file ending in '.txt'
match /public/{imageId} {
  allow read: if resource.size < 100 * 1024;
  allow write: if imageId.matches(".*\\.txt");
}

Аутентифицированный частный

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

// Require authentication on all internal image reads
match /internal/{imageId} {
  allow read: if request.auth != null;
}

Личный пользователь

Безусловно, наиболее распространенным вариантом использования request.auth будет предоставление отдельным пользователям детальных разрешений на их файлы: от загрузки изображений профиля до чтения личных документов.

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

// Only a user can upload their profile picture, but anyone can view it
match /users/{userId}/profilePicture.png {
  allow read;
  allow write: if request.auth.uid == userId;
}

Группа закрытая

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

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

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

// 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;
}

Запросить оценку

Выгрузки, загрузки, изменения метаданных и удаления оцениваются с помощью request отправленного в облачное хранилище. Помимо уникального идентификатора пользователя и полезной нагрузки Firebase Authentication в объекте request.auth как описано выше, переменная request содержит путь к файлу, в котором выполняется запрос, время получения запроса и новое значение resource если запрос - запись. Заголовки HTTP и состояние аутентификации также включены.

Объект request также содержит уникальный идентификатор пользователя и полезную нагрузку аутентификации Firebase в объекте request.auth , что будет объяснено далее в разделе « Безопасность на основе пользователя» документации.

Полный список свойств объекта request доступен ниже:

Имущество Тип Описание
auth карта <строка, строка> Когда пользователь входит в систему, предоставляет uid , уникальный идентификатор пользователя и token , карту утверждений Firebase Authentication JWT. В противном случае он будет null .
params карта <строка, строка> Карта, содержащая параметры запроса запроса.
path дорожка path представляющий путь, по которому выполняется запрос.
resource карта <строка, строка> Новое значение ресурса, присутствует только в запросах на write .
time отметка времени Отметка времени, представляющая время сервера, в которое оценивается запрос.

Оценка ресурсов

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

Правила безопасности Firebase для облачного хранилища предоставляют метаданные файла в объекте resource , который содержит пары ключ / значение метаданных, отображаемых в объекте облачного хранилища. Эти свойства можно проверить при запросах на read или write чтобы гарантировать целостность данных.

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

Полный список свойств объекта resource доступен ниже:

Имущество Тип Описание
name нить Полное название объекта
bucket нить Имя сегмента, в котором находится этот объект.
generation int Генерация этого объекта в Google Cloud Storage .
metageneration int Метагенерация этого объекта в Google Cloud Storage .
size int Размер объекта в байтах.
timeCreated отметка времени Отметка времени, представляющая время создания объекта.
updated отметка времени Отметка времени, представляющая время последнего обновления объекта.
md5Hash нить Хеш MD5 объекта.
crc32c нить Хеш crc32c объекта.
etag нить Тег, связанный с этим объектом.
contentDisposition нить Расположение содержимого, связанное с этим объектом.
contentEncoding нить Кодировка содержимого, связанная с этим объектом.
contentLanguage нить Язык содержимого, связанный с этим объектом.
contentType нить Тип контента, связанный с этим объектом.
metadata карта <строка, строка> Пары ключ / значение дополнительных пользовательских метаданных, указанных разработчиком.

request.resource содержит все это, за исключением generation , metageneration , etag , timeCreated и updated .

Подтвердить данные

Правила безопасности Firebase для облачного хранилища также можно использовать для проверки данных, включая проверку имени файла и пути, а также свойств метаданных файла, таких как contentType и size .

service firebase.storage {
  match /b/{bucket}/o {
    match /images/{imageId} {
      // Only allow uploads of any image file that's less than 5MB
      allow write: if request.resource.size < 5 * 1024 * 1024
                   && request.resource.contentType.matches('image/.*');
    }
  }
}

Пользовательские функции

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

  • Функции могут содержать только один оператор return . Они не могут содержать никакой дополнительной логики. Например, они не могут выполнять циклы или вызывать внешние службы.
  • Функции могут автоматически обращаться к функциям и переменным из области, в которой они определены. Например, функция, определенная в области действия service firebase.storage имеет доступ к переменной resource , а только для Cloud Firestore встроенным функциям, таким как get() и exists() .
  • Функции могут вызывать другие функции, но не могут выполнять рекурсию. Общая глубина стека вызовов ограничена 10.
  • В версии rules2 функции могут определять переменные с помощью ключевого слова let . Функции могут иметь любое количество привязок let, но должны заканчиваться оператором return.

Функция определяется ключевым словом function и принимает ноль или более аргументов. Например, вы можете объединить два типа условий, использованных в приведенных выше примерах, в одну функцию:

service firebase.storage {
  match /b/{bucket}/o {
    // 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 /images/{imageId} {
      allow read, write: if signedInOrPublic();
    }
    match /mp3s/{mp3Ids} {
      allow read: if signedInOrPublic();
    }
  }
}

Использование функций в ваших правилах безопасности Firebase делает их более удобными в обслуживании по мере роста сложности ваших правил.

Следующие шаги

После обсуждения условий вы лучше понимаете Правила и готовы:

Узнайте, как обрабатывать основные варианты использования, и изучите рабочий процесс для разработки, тестирования и развертывания правил: