Règles de sécurité Firebase : différence entre get() et getAfter()

Question

Dans la documentation, il est dit :

En utilisant les fonctions get() et exists(), votre sécurité évaluer les demandes entrantes par rapport aux autres documents de la base de données.

Cela me convient, et l'exemple me semble logique :

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      // Make sure a 'users' document exists for the requesting user before allowing any writes to the 'cities' collection
      allow create: if exists(/databases/$(database)/documents/users/$(request.auth.uid))

      // Allow the user to delete cities if their user document has the
      // 'admin' field set to 'true'
      allow delete: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true
    }
  }
}

mais ensuite, il est dit

Pour les écritures, vous pouvez utiliser la fonction getAfter() pour accéder à l'état de d'un document après une transaction ou un batc avant que la transaction ou le lot ne soit validé.

Il se peut que je ne comprenne pas encore tout à fait le concept. Mes questions sont les suivantes :

1. Pourquoi faut-il utiliser spécifiquement getAfter() pour la transaction ou l'écriture par lots ? Peut-on simplement utiliser get() ?
2. Si vous devez utiliser getAfter() pour les transactions ou les écritures par lots, cela signifie-t-il que vous avez toujours besoin de get() pour les écritures normales ?

Merci.

Answer 1

Tout d'abord, il faut garder à l'esprit que les règles de sécurité pour les écritures entrent en vigueur avant que quoi que ce soit dans la base de données n'ait été modifié par l'écriture. C'est ainsi que les règles de sécurité peuvent rejeter l'accès de manière sûre et efficace, sans avoir à annuler les écritures déjà effectuées.

La documentation que vous citez suggère que getAfter est utile pour examiner le contenu de la base de données après l'enregistrement de l'état de l'ensemble de la transaction (dans une sorte d'environnement "staging" en mémoire), mais avant que la transaction ne modifie réellement la base de données visible par tous. Ce n'est pas la même chose que get parce que get n'examine que le contenu réel de la base de données, avant que la transaction ne soit définitivement engagée . En résumé, getAfter utilise alors l'écriture par étapes de l'ensemble de la transaction ou du lot, tandis que get utilise le contenu actuel de la base de données.

Vous n'êtes en aucun cas obligé d'utiliser getAfter si get fonctionne parfaitement dans votre cas.

getAfter est utile lorsque vous devez examiner d'autres documents susceptibles d'avoir été modifiés dans la transaction ou le lot, tout en ayant la possibilité de rejeter l'ensemble de la transaction ou du lot en cas d'échec de la règle. Ainsi, par exemple, si deux documents rédigés au cours d'une même transaction doivent avoir une valeur de champ en commun pour être cohérents, vous devez utiliser la règle getAfter pour vérifier l'égalité entre les deux. get ne serait pas utile ici, car il ne sait rien de l'autre document de la transaction qui n'a pas encore été rédigé.

D'autre part, si votre règle doit vérifier qu'un document de la transaction n'a pas modifié un champ dans un document existant (qui n'est pas le document en cours de vérification), get serait nécessaire pour récupérer cette valeur à la place, avant qu'elle ne soit écrite par la transaction.