Google is committed to advancing racial equity for Black communities. See how.
Эта страница была переведа с помощью Cloud Translation API.
Switch to English

Безопасные данные пользователя

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

Аутентификация пользователя

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

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

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

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

  • Public: игнорировать 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 != null && 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;
}

Полный пример

Простые случаи четырех общих типов ограничений аутентификации показаны в примере ниже:

service firebase.storage {
  match /b/{bucket}/o {
    match /images {
      // Anyone can view any image (no auth, publicly readable)
      match /{allImages=**} {
        allow read;
      }

      // Only authenticated users can write to "public" images
      match /public/{imageId} {
        allow write: if request.auth != null;
      }

      // Only an individual user can write to "their" images
      match /{userId}/{imageId} {
        allow write: if request.auth.uid == userId;
      }

      // Allow a "group" of users to read/write to shared images
      // An owner metadata property on the object contains the groupId for reads
      // A custom token has been minted with a groupId property for writes
      match /{groupId}/{imageId} {
        allow read: if resource.metadata.owner == request.auth.token.groupId;
        allow write: if request.auth.token.groupId == groupId;
      }
    }
  }
}