Защитите данные пользователя

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

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

Когда аутентифицированный пользователь выполняет запрос к Cloud Storage , переменная request.auth заполняется uid пользователя ( request.auth.uid ), а также утверждениями JWT Firebase Authentication ( 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 будет предоставление отдельным пользователям детальных прав доступа к их файлам: от загрузки изображений профиля до чтения личных документов.

Поскольку файлы в Cloud Storage имеют полный путь к файлу, все, что нужно для того, чтобы файл контролировался пользователем, — это часть уникальной информации, идентифицирующей пользователя, в пути к файлу (например, 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 Authentication , содержащий дополнительную информацию о члене группы (например, идентификатор группы).
  • Включите информацию о группе (например, идентификатор группы или список авторизованных 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;
      }
    }
  }
}