Cette page s'appuie sur les concepts de Structuration des règles de sécurité et d'écriture des conditions pour les règles de sécurité pour expliquer comment les règles de sécurité Cloud Firestore interagissent avec les requêtes. Il examine de plus près la façon dont les règles de sécurité affectent les requêtes que vous pouvez écrire et décrit comment garantir que vos requêtes utilisent les mêmes contraintes que vos règles de sécurité. Cette page décrit également comment écrire des règles de sécurité pour autoriser ou refuser les requêtes en fonction de propriétés de requête telles que limit
et orderBy
.
Les règles ne sont pas des filtres
Lorsque vous rédigez des requêtes pour récupérer des documents, gardez à l’esprit que les règles de sécurité ne sont pas des filtres : les requêtes sont tout ou rien. Pour vous faire gagner du temps et des ressources, Cloud Firestore évalue une requête par rapport à son ensemble de résultats potentiels au lieu des valeurs réelles des champs pour tous vos documents. Si une requête est susceptible de renvoyer des documents que le client n'est pas autorisé à lire, la requête entière échoue.
Requêtes et règles de sécurité
Comme le démontrent les exemples ci-dessous, vous devez rédiger vos requêtes pour répondre aux contraintes de vos règles de sécurité.
Sécurisez et interrogez des documents basés sur auth.uid
L'exemple suivant montre comment écrire une requête pour récupérer des documents protégés par une règle de sécurité. Prenons l'exemple d'une base de données contenant une collection de documents story
:
/histoires/{identifiant de l'histoire}
{
title: "A Great Story",
content: "Once upon a time...",
author: "some_auth_id",
published: false
}
En plus des champs title
et content
, chaque document stocke les champs author
et published
à utiliser pour le contrôle d'accès. Ces exemples supposent que l'application utilise l'authentification Firebase pour définir le champ author
sur l'UID de l'utilisateur qui a créé le document. L'authentification Firebase renseigne également la variable request.auth
dans les règles de sécurité.
La règle de sécurité suivante utilise les variables request.auth
et resource.data
pour restreindre l'accès en lecture et en écriture de chaque story
à son auteur :
service cloud.firestore {
match /databases/{database}/documents {
match /stories/{storyid} {
// Only the authenticated user who authored the document can read or write
allow read, write: if request.auth != null && request.auth.uid == resource.data.author;
}
}
}
Supposons que votre application inclut une page qui montre à l’utilisateur une liste de documents story
qu’il a créés. Vous pourriez vous attendre à pouvoir utiliser la requête suivante pour remplir cette page. Cependant, cette requête échouera, car elle n'inclut pas les mêmes contraintes que vos règles de sécurité :
Invalide : les contraintes de requête ne correspondent pas aux contraintes des règles de sécurité
// This query will fail
db.collection("stories").get()
La requête échoue même si l'utilisateur actuel est en réalité l'auteur de chaque document story
. La raison de ce comportement est que lorsque Cloud Firestore applique vos règles de sécurité, il évalue la requête par rapport à son ensemble de résultats potentiels , et non par rapport aux propriétés réelles des documents de votre base de données. Si une requête est susceptible d'inclure des documents qui violent vos règles de sécurité, la requête échouera.
En revanche, la requête suivante réussit, car elle inclut la même contrainte sur le champ author
que les règles de sécurité :
Valide : les contraintes de requête correspondent aux contraintes des règles de sécurité
var user = firebase.auth().currentUser;
db.collection("stories").where("author", "==", user.uid).get()
Sécurisez et interrogez des documents en fonction d'un champ
Pour démontrer davantage l'interaction entre les requêtes et les règles, les règles de sécurité ci-dessous étendent l'accès en lecture à la collection stories
pour permettre à tout utilisateur de lire les documents story
où le champ published
est défini sur true
.
service cloud.firestore {
match /databases/{database}/documents {
match /stories/{storyid} {
// Anyone can read a published story; only story authors can read unpublished stories
allow read: if resource.data.published == true || (request.auth != null && request.auth.uid == resource.data.author);
// Only story authors can write
allow write: if request.auth != null && request.auth.uid == resource.data.author;
}
}
}
La requête des pages publiées doit inclure les mêmes contraintes que les règles de sécurité :
db.collection("stories").where("published", "==", true).get()
La contrainte de requête .where("published", "==", true)
garantit que resource.data.published
est true
pour tout résultat. Par conséquent, cette requête satisfait aux règles de sécurité et est autorisée à lire des données.
OR
requêtes
Lors de l'évaluation d'une requête OR
logique ( or
, in
ou array-contains-any
) par rapport à un ensemble de règles, Cloud Firestore évalue chaque valeur de comparaison séparément. Chaque valeur de comparaison doit répondre aux contraintes des règles de sécurité. Par exemple, pour la règle suivante :
match /mydocuments/{doc} {
allow read: if resource.data.x > 5;
}
Invalide : la requête ne garantit pas que x > 5
pour tous les documents potentiels
// These queries will fail
query(db.collection("mydocuments"),
or(where("x", "==", 1),
where("x", "==", 6)
)
)
query(db.collection("mydocuments"),
where("x", "in", [1, 3, 6, 42, 99])
)
Valide : la requête garantit que x > 5
pour tous les documents potentiels
query(db.collection("mydocuments"),
or(where("x", "==", 6),
where("x", "==", 42)
)
)
query(db.collection("mydocuments"),
where("x", "in", [6, 42, 99, 105, 200])
)
Évaluation des contraintes sur les requêtes
Vos règles de sécurité peuvent également accepter ou refuser des requêtes en fonction de leurs contraintes. La variable request.query
contient les limit
, offset
et orderBy
d'une requête. Par exemple, vos règles de sécurité peuvent refuser toute requête qui ne limite pas le nombre maximum de documents récupérés à une certaine plage :
allow list: if request.query.limit <= 10;
L'ensemble de règles suivant montre comment écrire des règles de sécurité qui évaluent les contraintes imposées aux requêtes. Cet exemple étend l'ensemble de règles stories
précédentes avec les modifications suivantes :
- L'ensemble de règles sépare la règle de lecture en règles pour
get
etlist
. - La règle
get
limite la récupération de documents uniques aux documents publics ou aux documents créés par l'utilisateur. - La règle
list
applique les mêmes restrictions queget
mais pour les requêtes. Il vérifie également la limite de requêtes, puis refuse toute requête sans limite ou avec une limite supérieure à 10. - L'ensemble de règles définit une fonction
authorOrPublished()
pour éviter la duplication de code.
service cloud.firestore {
match /databases/{database}/documents {
match /stories/{storyid} {
// Returns `true` if the requested story is 'published'
// or the user authored the story
function authorOrPublished() {
return resource.data.published == true || request.auth.uid == resource.data.author;
}
// Deny any query not limited to 10 or fewer documents
// Anyone can query published stories
// Authors can query their unpublished stories
allow list: if request.query.limit <= 10 &&
authorOrPublished();
// Anyone can retrieve a published story
// Only a story's author can retrieve an unpublished story
allow get: if authorOrPublished();
// Only a story's author can write to a story
allow write: if request.auth.uid == resource.data.author;
}
}
}
Requêtes de groupe de collecte et règles de sécurité
Par défaut, les requêtes sont limitées à une seule collection et récupèrent uniquement les résultats de cette collection. Avec les requêtes de groupe de collections , vous pouvez récupérer les résultats d'un groupe de collections composé de toutes les collections portant le même ID. Cette section décrit comment sécuriser vos requêtes de groupe de collecte à l'aide de règles de sécurité.
Sécurisez et interrogez des documents en fonction de groupes de collections
Dans vos règles de sécurité, vous devez autoriser explicitement les requêtes de groupe de collecte en écrivant une règle pour le groupe de collecte :
- Assurez-vous que
rules_version = '2';
est la première ligne de votre ensemble de règles. Les requêtes de groupe de collecte nécessitent le nouveau comportement de caractère générique récursif{name=**}
des règles de sécurité version 2. - Écrivez une règle pour votre groupe de collecte en utilisant
match /{path=**}/ [COLLECTION_ID] /{doc}
.
Par exemple, considérons un forum organisé en documents forum
contenant des sous-collections posts
:
/forums/{forumid}/posts/{postid}
{
author: "some_auth_id",
authorname: "some_username",
content: "I just read a great story.",
}
Dans cette application, nous rendons les publications modifiables par leurs propriétaires et lisibles par les utilisateurs authentifiés :
service cloud.firestore {
match /databases/{database}/documents {
match /forums/{forumid}/posts/{post} {
// Only authenticated users can read
allow read: if request.auth != null;
// Only the post author can write
allow write: if request.auth != null && request.auth.uid == resource.data.author;
}
}
}
Tout utilisateur authentifié peut récupérer les messages de n'importe quel forum :
db.collection("forums/technology/posts").get()
Mais que se passe-t-il si vous souhaitez montrer à l'utilisateur actuel ses publications sur tous les forums ? Vous pouvez utiliser une requête de groupe de collections pour récupérer les résultats de toutes les collections posts
:
var user = firebase.auth().currentUser;
db.collectionGroup("posts").where("author", "==", user.uid).get()
Dans vos règles de sécurité, vous devez autoriser cette requête en écrivant une règle de lecture ou de liste pour le groupe de collecte posts
:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
// Authenticated users can query the posts collection group
// Applies to collection queries, collection group queries, and
// single document retrievals
match /{path=**}/posts/{post} {
allow read: if request.auth != null;
}
match /forums/{forumid}/posts/{postid} {
// Only a post's author can write to a post
allow write: if request.auth != null && request.auth.uid == resource.data.author;
}
}
}
Notez cependant que ces règles s'appliqueront à toutes les collections avec posts
ID, quelle que soit la hiérarchie. Par exemple, ces règles s'appliquent à toutes les collections posts
suivantes :
-
/posts/{postid}
-
/forums/{forumid}/posts/{postid}
-
/forums/{forumid}/subforum/{subforumid}/posts/{postid}
Requêtes de groupe de collecte sécurisée basées sur un champ
Comme les requêtes à collection unique, les requêtes de groupe de collections doivent également répondre aux contraintes définies par vos règles de sécurité. Par exemple, nous pouvons ajouter un champ published
à chaque message du forum, comme nous l'avons fait dans l'exemple stories
ci-dessus :
/forums/{forumid}/posts/{postid}
{
author: "some_auth_id",
authorname: "some_username",
content: "I just read a great story.",
published: false
}
Nous pouvons ensuite écrire des règles pour le groupe de collecte posts
en fonction du statut published
et de l' author
de la publication :
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
// Returns `true` if the requested post is 'published'
// or the user authored the post
function authorOrPublished() {
return resource.data.published == true || request.auth.uid == resource.data.author;
}
match /{path=**}/posts/{post} {
// Anyone can query published posts
// Authors can query their unpublished posts
allow list: if authorOrPublished();
// Anyone can retrieve a published post
// Authors can retrieve an unpublished post
allow get: if authorOrPublished();
}
match /forums/{forumid}/posts/{postid} {
// Only a post's author can write to a post
allow write: if request.auth.uid == resource.data.author;
}
}
}
Avec ces règles, les clients Web, Apple et Android peuvent effectuer les requêtes suivantes :
Tout le monde peut récupérer les messages publiés dans un forum :
db.collection("forums/technology/posts").where('published', '==', true).get()
N'importe qui peut récupérer les messages publiés par un auteur sur tous les forums :
db.collectionGroup("posts").where("author", "==", "some_auth_id").where('published', '==', true).get()
Les auteurs peuvent récupérer tous leurs articles publiés et non publiés sur tous les forums :
var user = firebase.auth().currentUser; db.collectionGroup("posts").where("author", "==", user.uid).get()
Sécurisez et interrogez les documents en fonction du groupe de collecte et du chemin du document
Dans certains cas, vous souhaiterez peut-être restreindre les requêtes des groupes de collections en fonction du chemin du document. Pour créer ces restrictions, vous pouvez utiliser les mêmes techniques de sécurisation et d'interrogation de documents en fonction d'un champ.
Prenons l'exemple d'une application qui assure le suivi des transactions de chaque utilisateur entre plusieurs bourses d'actions et de crypto-monnaie :
/users/{userid}/exchange/{exchangeid}/transactions/{transaction}
{
amount: 100,
exchange: 'some_exchange_name',
timestamp: April 1, 2019 at 12:00:00 PM UTC-7,
user: "some_auth_id",
}
Notez le champ user
. Même si nous savons quel utilisateur possède un document transaction
grâce au chemin du document, nous dupliquons cette information dans chaque document transaction
car cela nous permet de faire deux choses :
Écrivez des requêtes de groupe de collection limitées aux documents qui incluent un
/users/{userid}
spécifique dans leur chemin de document. Par exemple:var user = firebase.auth().currentUser; // Return current user's last five transactions across all exchanges db.collectionGroup("transactions").where("user", "==", user).orderBy('timestamp').limit(5)
Appliquez cette restriction pour toutes les requêtes sur le groupe de collecte
transactions
afin qu'un utilisateur ne puisse pas récupérer les documentstransaction
d'un autre utilisateur.
Nous appliquons cette restriction dans nos règles de sécurité et incluons la validation des données pour le champ user
:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /{path=**}/transactions/{transaction} {
// Authenticated users can retrieve only their own transactions
allow read: if resource.data.user == request.auth.uid;
}
match /users/{userid}/exchange/{exchangeid}/transactions/{transaction} {
// Authenticated users can write to their own transactions subcollections
// Writes must populate the user field with the correct auth id
allow write: if userid == request.auth.uid && request.data.user == request.auth.uid
}
}
}
Prochaines étapes
- Pour un exemple plus détaillé de contrôle d'accès basé sur les rôles, consultez Sécurisation de l'accès aux données pour les utilisateurs et les groupes .
- Lisez la référence des règles de sécurité .