Catch up on everthing we announced at this year's Firebase Summit. Learn more

Conditions d'utilisation dans les règles de sécurité de Firebase Cloud Storage

Ce guide se fonde sur l' apprendre la syntaxe de base du langage Règles de sécurité Firebase guide pour montrer comment ajouter des conditions à vos règles de sécurité Firebase pour Cloud Storage.

Le bloc principal de Cloud Storage Les règles de sécurité est la condition. Une condition est une expression booléenne qui détermine si une opération particulière doit être autorisée ou refusée. Pour connaître les règles de base, en utilisant de true et false littéraux comme conditions fonctionne prefectly bien. Mais le langage Firebase Security Rules for Cloud Storage vous permet d'écrire des conditions plus complexes qui peuvent :

  • Vérifier l'authentification de l'utilisateur
  • Valider les données entrantes

Authentification

Les règles de sécurité Firebase pour Cloud Storage s'intègrent à Firebase Authentication pour fournir une authentification puissante basée sur l'utilisateur à Cloud Storage. Cela permet un contrôle d'accès granulaire basé sur les revendications d'un jeton d'authentification Firebase.

Lorsqu'un utilisateur effectue une demande authentifiée contre Cloud Storage, la request.auth variable est rempli avec de l'utilisateur uid ( request.auth.uid ), ainsi que les revendications de l'authentification Firebase JWT ( request.auth.token ).

En outre, lors de l'authentification personnalisée, autres revendications sont apparues dans le request.auth.token domaine.

Quand un utilisateur non authentifié effectue une demande, le request.auth variable est null .

À l'aide de ces données, il existe plusieurs façons courantes d'utiliser l'authentification pour sécuriser les fichiers :

  • Public: ignorer request.auth
  • Authentifiées privé: vérifier que request.auth est non null
  • Privé Utilisateur: vérifier que request.auth.uid est égal à un chemin uid
  • Groupe privé : vérifiez les revendications du jeton personnalisé pour qu'elles correspondent à une revendication choisie, ou lisez les métadonnées du fichier pour voir si un champ de métadonnées existe

Publique

Toute règle qui ne considère pas le request.auth contexte peut être considéré comme une public règle, car elle ne tient pas compte du contexte d'authentification de l'utilisateur. Ces règles peuvent être utiles pour faire apparaître des données publiques telles que des éléments de jeu, des fichiers audio ou d'autres contenus statiques.

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

Privé authentifié

Dans certains cas, vous pouvez souhaiter que les données soient visibles par tous les utilisateurs authentifiés de votre application, mais pas par les utilisateurs non authentifiés. Étant donné que la request.auth variable est null pour tous les utilisateurs non authentifiés, tout ce que vous devez faire est de vérifier la request.auth variable existe pour exiger une authentification:

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

Utilisateur privé

De loin le cas le plus d'usage courant pour request.auth sera de fournir aux utilisateurs individuels avec des autorisations granulaires sur leurs fichiers: des images de profil de téléchargement à la lecture des documents privés.

Étant donné que les fichiers Cloud Storage ont un « chemin » complet du fichier, il suffit de faire un fichier contrôlé par un utilisateur est une information unique utilisateur identifiant le préfixe de nom de fichier ( par exemple de l'utilisateur uid ) qui peut être vérifié lorsque la règle est évaluée :

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

Groupe privé

Un autre cas d'utilisation tout aussi courant sera d'autoriser des autorisations de groupe sur un objet, par exemple en permettant à plusieurs membres de l'équipe de collaborer sur un document partagé. Il existe plusieurs approches pour y parvenir :

  • Timbre une authentification Firebase jeton personnalisé qui contient des informations supplémentaires sur un membre du groupe ( par exemple un ID de groupe)
  • Inclure des informations de groupe ( par exemple un identifiant de groupe ou d'une liste de autorisé uid s) dans le metadata

Une fois ces données stockées dans le token ou les métadonnées du fichier, elles peuvent être référencées depuis une règle :

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

Demande d'évaluation

Uploads, des téléchargements, des changements de métadonnées, et les suppressions sont évaluées selon la request envoyée au Cloud Storage. En plus d'ID unique et la charge utile d' authentification Firebase de l'utilisateur dans le request.auth objet tel que décrit ci - dessus, la request variable contient le chemin du fichier dans lequel la demande est en cours d' exécution, le moment où la demande est reçue, et la nouvelle resource de valeur si la demande est une écriture. Les en-têtes HTTP et l'état d'authentification sont également inclus.

La request objet contient également unique ID de l'utilisateur et la charge utile d' authentification Firebase dans le request.auth objet, qui sera expliqué plus loin dans la sécurité basée sur la section de la documentation.

Une liste complète des propriétés dans la request objet est disponible ci - dessous:

Biens Taper La description
auth map<chaîne, chaîne> Lorsqu'un utilisateur est connecté, fournit uid , ID unique de l'utilisateur, et token , une carte des revendications Firebase authentification JWT. Dans le cas contraire, il sera null .
params map<chaîne, chaîne> Carte contenant les paramètres de requête de la requête.
path chemin Un path représentant le chemin de la demande est en cours d' exécution à.
resource map<chaîne, chaîne> La nouvelle valeur de ressources, présent uniquement sur write des demandes.
time horodatage Un horodatage représentant l'heure du serveur à laquelle la demande est évaluée.

Évaluation des ressources

Lors de l'évaluation des règles, vous souhaiterez peut-être également évaluer les métadonnées du fichier en cours de chargement, de téléchargement, de modification ou de suppression. Cela vous permet de créer des règles complexes et puissantes qui permettent, par exemple, le téléchargement de fichiers avec certains types de contenu ou la suppression de fichiers supérieurs à une certaine taille.

Firebase Règles de sécurité pour Cloud Storage fournit des métadonnées de fichier dans la resource objet qui contient des paires de clés de valeur / des métadonnées refait surface dans un objet Cloud Storage. Ces propriétés peuvent être inspectés en read ou write des demandes pour assurer l' intégrité des données.

En write des demandes (telles que les ajouts, les mises à jour des métadonnées, et les suppressions), en plus de la resource objet, qui contient des métadonnées de fichier pour le fichier qui existe actuellement sur le chemin de demande, vous avez également la possibilité d'utiliser le request.resource objet, qui contient un sous-ensemble des métadonnées du fichier à écrire si l'écriture est autorisée. Vous pouvez utiliser ces deux valeurs pour garantir l'intégrité des données ou appliquer des contraintes d'application telles que le type ou la taille de fichier.

Une liste complète des propriétés dans la resource objet est disponible ci - dessous:

Biens Taper La description
name chaîne de caractères Le nom complet de l'objet
bucket chaîne de caractères Le nom du bucket dans lequel réside cet objet.
generation entier La génération d'objets Google Cloud Storage de cet objet.
metageneration entier L' objet Google Cloud Storage metageneration de cet objet.
size entier La taille de l'objet en octets.
timeCreated horodatage Un horodatage représentant l'heure à laquelle un objet a été créé.
updated horodatage Un horodatage représentant l'heure à laquelle un objet a été mis à jour pour la dernière fois.
md5Hash chaîne de caractères Un hachage MD5 de l'objet.
crc32c chaîne de caractères Un hachage crc32c de l'objet.
etag chaîne de caractères L'etag associé à cet objet.
contentDisposition chaîne de caractères La disposition du contenu associée à cet objet.
contentEncoding chaîne de caractères L'encodage du contenu associé à cet objet.
contentLanguage chaîne de caractères La langue de contenu associée à cet objet.
contentType chaîne de caractères Le type de contenu associé à cet objet.
metadata map<chaîne, chaîne> Paires clé/valeur de métadonnées personnalisées supplémentaires spécifiées par le développeur.

request.resource contient tous ces éléments à l'exception de generation , metageneration , etag , timeCreated et updated à updated .

Valider les données

Firebase Règles de sécurité pour Cloud Storage peut également être utilisé pour la validation des données, y compris la validation de nom de fichier et chemin d' accès ainsi que les propriétés des métadonnées de fichiers tels que contentType et la 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/.*');
    }
  }
}

Fonctions personnalisées

À mesure que vos règles de sécurité Firebase deviennent plus complexes, vous souhaiterez peut-être encapsuler des ensembles de conditions dans des fonctions que vous pourrez réutiliser dans votre ensemble de règles. Les règles de sécurité prennent en charge les fonctions personnalisées. La syntaxe des fonctions personnalisées ressemble un peu à JavaScript, mais les fonctions des règles de sécurité Firebase sont écrites dans un langage spécifique au domaine qui présente des limitations importantes :

  • Les fonctions peuvent contenir qu'un seul return déclaration. Ils ne peuvent pas contenir de logique supplémentaire. Par exemple, ils ne peuvent pas exécuter de boucles ou appeler des services externes.
  • Les fonctions peuvent accéder automatiquement aux fonctions et variables à partir de la portée dans laquelle elles sont définies. Par exemple, une fonction définie dans le service firebase.storage portée a accès à la resource variable et pour Cloud Firestore seulement, intégré des fonctions telles que get() et exists() .
  • Les fonctions peuvent appeler d'autres fonctions mais ne peuvent pas se reproduire. La profondeur totale de la pile d'appels est limitée à 10.
  • Dans la version rules2 , les fonctions peuvent définir des variables à l' aide du let mot - clé. Les fonctions peuvent avoir n'importe quel nombre de liaisons let, mais doivent se terminer par une instruction return.

Une fonction est définie par la function mot - clé et prend zéro ou plusieurs arguments. Par exemple, vous pouvez combiner les deux types de conditions utilisées dans les exemples ci-dessus en une seule fonction :

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();
    }
  }
}

L'utilisation de fonctions dans vos règles de sécurité Firebase les rend plus faciles à gérer à mesure que la complexité de vos règles augmente.

Prochaines étapes

Après cette discussion sur les conditions, vous avez une compréhension plus sophistiquée des règles et êtes prêt à :

Apprenez à gérer les principaux cas d'utilisation et découvrez le flux de travail pour développer, tester et déployer des règles :