Conditions d'utilisation dans les règles de sécurité de la base de données en temps réel

Ce guide s'appuie sur le guide d'apprentissage du langage des règles de sécurité principales de Firebase pour montrer comment ajouter des conditions à vos règles de sécurité de base de données en temps réel Firebase.

Le bloc de construction principal des règles de sécurité de la base de données en temps réel 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 les règles de base, l'utilisation de littéraux true et false comme conditions fonctionne parfaitement bien. Mais le langage des règles de sécurité de la base de données en temps réel vous permet d'écrire des conditions plus complexes qui peuvent :

• Vérifier l'authentification de l'utilisateur
• Évaluer les données existantes par rapport aux données nouvellement soumises
• Accédez et comparez différentes parties de votre base de données
• Valider les données entrantes
• Utiliser la structure des requêtes entrantes pour la logique de sécurité

Utilisation de variables $ pour capturer des segments de chemin

Vous pouvez capturer des parties du chemin pour une lecture ou une écriture en déclarant des variables de capture avec le préfixe $ . Cela sert de joker et stocke la valeur de cette clé pour une utilisation dans les conditions de règles :

{
  "rules": {
    "rooms": {
      // this rule applies to any child of /rooms/, the key for each room id
      // is stored inside $room_id variable for reference
      "$room_id": {
        "topic": {
          // the room's topic can be changed if the room id has "public" in it
          ".write": "$room_id.contains('public')"
        }
      }
    }
  }
}

Les variables dynamiques $ peuvent également être utilisées en parallèle avec des noms de chemin constants. Dans cet exemple, nous utilisons la variable $other pour déclarer une règle .validate qui garantit que widget n'a pas d'autres enfants que title et color . Toute écriture qui entraînerait la création d'enfants supplémentaires échouerait.

{
  "rules": {
    "widget": {
      // a widget can have a title or color attribute
      "title": { ".validate": true },
      "color": { ".validate": true },

      // but no other child paths are allowed
      // in this case, $other means any key excluding "title" and "color"
      "$other": { ".validate": false }
    }
  }
}

Authentification

L'un des modèles de règles de sécurité les plus courants consiste à contrôler l'accès en fonction de l'état d'authentification de l'utilisateur. Par exemple, votre application peut vouloir autoriser uniquement les utilisateurs connectés à écrire des données.

Si votre application utilise Firebase Authentication, la variable request.auth contient les informations d'authentification pour le client demandant des données. Pour plus d'informations sur request.auth , consultez la documentation de référence .

Firebase Authentication s'intègre à la base de données en temps réel Firebase pour vous permettre de contrôler l'accès aux données par utilisateur à l'aide de conditions. Une fois qu'un utilisateur s'est authentifié, la variable auth de vos règles de règles de sécurité de base de données en temps réel sera renseignée avec les informations de l'utilisateur. Ces informations incluent leur identifiant unique ( uid ) ainsi que les données de compte liées, telles qu'un identifiant Facebook ou une adresse e-mail, et d'autres informations. Si vous implémentez un fournisseur d'authentification personnalisé, vous pouvez ajouter vos propres champs à la charge utile d'authentification de votre utilisateur.

Cette section explique comment combiner le langage des règles de sécurité de la base de données en temps réel Firebase avec les informations d'authentification de vos utilisateurs. En combinant ces deux concepts, vous pouvez contrôler l'accès aux données en fonction de l'identité de l'utilisateur.

La variable auth

La variable auth prédéfinie dans les règles est nulle avant que l'authentification n'ait lieu.

Une fois qu'un utilisateur est authentifié avec Firebase Authentication, il contiendra les attributs suivants :

Voici un exemple de règle qui utilise la variable auth pour s'assurer que chaque utilisateur ne peut écrire que dans un chemin spécifique à l'utilisateur :

{
  "rules": {
    "users": {
      "$user_id": {
        // grants write access to the owner of this user account
        // whose uid must exactly match the key ($user_id)
        ".write": "$user_id === auth.uid"
      }
    }
  }
}

Structurer votre base de données pour prendre en charge les conditions d'authentification

Il est généralement utile de structurer votre base de données de manière à faciliter l'écriture des règles. Un modèle courant de stockage des données utilisateur dans la base de données en temps réel consiste à stocker tous vos utilisateurs dans un seul nœud users dont les enfants sont les valeurs uid de chaque utilisateur. Si vous vouliez restreindre l'accès à ces données de sorte que seul l'utilisateur connecté puisse voir ses propres données, vos règles ressembleraient à ceci.

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "auth !== null && auth.uid === $uid"
      }
    }
  }
}

Utilisation des revendications personnalisées d'authentification

Pour les applications qui nécessitent un contrôle d'accès personnalisé pour différents utilisateurs, Firebase Authentication permet aux développeurs de définir des revendications sur un utilisateur Firebase . Ces réclamations sont accessibles dans la variable auth.token de vos règles. Voici un exemple de règles qui utilisent la revendication personnalisée hasEmergencyTowel :

{
  "rules": {
    "frood": {
      // A towel is about the most massively useful thing an interstellar
      // hitchhiker can have
      ".read": "auth.token.hasEmergencyTowel === true"
    }
  }
}

Les développeurs qui créent leurs propres jetons d'authentification personnalisés peuvent éventuellement ajouter des revendications à ces jetons. Ces revendications sont disponibles sur la variable auth.token dans vos règles.

Données existantes vs nouvelles données

La variable data prédéfinie est utilisée pour faire référence aux données avant qu'une opération d'écriture n'ait lieu. Inversement, la variable newData contient les nouvelles données qui existeront si l'opération d'écriture réussit. newData représente le résultat fusionné des nouvelles données en cours d'écriture et des données existantes.

Pour illustrer, cette règle nous permettrait de créer de nouveaux enregistrements ou de supprimer des enregistrements existants, mais pas d'apporter des modifications aux données non nulles existantes :

// we can write as long as old data or new data does not exist
// in other words, if this is a delete or a create, but not an update
".write": "!data.exists() || !newData.exists()"

Référencer des données dans d'autres chemins

Toutes les données peuvent être utilisées comme critère pour les règles. En utilisant les variables prédéfinies root , data et newData , nous pouvons accéder à n'importe quel chemin tel qu'il existerait avant ou après un événement d'écriture.

Considérez cet exemple, qui autorise les opérations d'écriture tant que la valeur du nœud /allow_writes/ est true , que le nœud parent n'a pas d'indicateur readOnly défini et qu'il existe un enfant nommé foo dans les données nouvellement écrites :

".write": "root.child('allow_writes').val() === true &&
          !data.parent().child('readOnly').exists() &&
          newData.child('foo').exists()"

Validation des données

L'application des structures de données et la validation du format et du contenu des données doivent être effectuées à l'aide de règles .validate , qui ne sont exécutées qu'après qu'une règle .write a réussi à accorder l'accès. Vous trouverez ci-dessous un exemple de définition de règle .validate qui n'autorise que les dates au format AAAA-MM-JJ entre les années 1900-2099, qui est vérifiée à l'aide d'une expression régulière.

".validate": "newData.isString() &&
              newData.val().matches(/^(19|20)[0-9][0-9][-\\/. ](0[1-9]|1[012])[-\\/. ](0[1-9]|[12][0-9]|3[01])$/)"

Les règles .validate sont le seul type de règle de sécurité qui ne se cascade pas. Si une règle de validation échoue sur un enregistrement enfant, l'intégralité de l'opération d'écriture sera rejetée. De plus, les définitions de validation sont ignorées lorsque les données sont supprimées (c'est-à-dire lorsque la nouvelle valeur en cours d'écriture est null ).

Ceux-ci peuvent sembler anodins, mais sont en fait des fonctionnalités importantes pour l'écriture de puissantes règles de sécurité de base de données en temps réel Firebase. Tenez compte des règles suivantes :

{
  "rules": {
    // write is allowed for all paths
    ".write": true,
    "widget": {
      // a valid widget must have attributes "color" and "size"
      // allows deleting widgets (since .validate is not applied to delete rules)
      ".validate": "newData.hasChildren(['color', 'size'])",
      "size": {
        // the value of "size" must be a number between 0 and 99
        ".validate": "newData.isNumber() &&
                      newData.val() >= 0 &&
                      newData.val() <= 99"
      },
      "color": {
        // the value of "color" must exist as a key in our mythical
        // /valid_colors/ index
        ".validate": "root.child('valid_colors/' + newData.val()).exists()"
      }
    }
  }
}

Avec cette variante à l'esprit, examinez les résultats des opérations d'écriture suivantes :

var ref = db.ref("/widget");

// PERMISSION_DENIED: does not have children color and size
ref.set('foo');

// PERMISSION DENIED: does not have child color
ref.set({size: 22});

// PERMISSION_DENIED: size is not a number
ref.set({ size: 'foo', color: 'red' });

// SUCCESS (assuming 'blue' appears in our colors list)
ref.set({ size: 21, color: 'blue'});

// If the record already exists and has a color, this will
// succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
// will fail to validate
ref.child('size').set(99);

FIRDatabaseReference *ref = [[[FIRDatabase database] reference] child: @"widget"];

// PERMISSION_DENIED: does not have children color and size
[ref setValue: @"foo"];

// PERMISSION DENIED: does not have child color
[ref setValue: @{ @"size": @"foo" }];

// PERMISSION_DENIED: size is not a number
[ref setValue: @{ @"size": @"foo", @"color": @"red" }];

// SUCCESS (assuming 'blue' appears in our colors list)
[ref setValue: @{ @"size": @21, @"color": @"blue" }];

// If the record already exists and has a color, this will
// succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
// will fail to validate
[[ref child:@"size"] setValue: @99];

var ref = FIRDatabase.database().reference().child("widget")

// PERMISSION_DENIED: does not have children color and size
ref.setValue("foo")

// PERMISSION DENIED: does not have child color
ref.setValue(["size": "foo"])

// PERMISSION_DENIED: size is not a number
ref.setValue(["size": "foo", "color": "red"])

// SUCCESS (assuming 'blue' appears in our colors list)
ref.setValue(["size": 21, "color": "blue"])

// If the record already exists and has a color, this will
// succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
// will fail to validate
ref.child("size").setValue(99);

FirebaseDatabase database = FirebaseDatabase.getInstance();
DatabaseReference ref = database.getReference("widget");

// PERMISSION_DENIED: does not have children color and size
ref.setValue("foo");

// PERMISSION DENIED: does not have child color
ref.child("size").setValue(22);

// PERMISSION_DENIED: size is not a number
Map<String,Object> map = new HashMap<String, Object>();
map.put("size","foo");
map.put("color","red");
ref.setValue(map);

// SUCCESS (assuming 'blue' appears in our colors list)
map = new HashMap<String, Object>();
map.put("size", 21);
map.put("color","blue");
ref.setValue(map);

// If the record already exists and has a color, this will
// succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
// will fail to validate
ref.child("size").setValue(99);

# PERMISSION_DENIED: does not have children color and size
curl -X PUT -d 'foo' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# PERMISSION DENIED: does not have child color
curl -X PUT -d '{"size": 22}' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# PERMISSION_DENIED: size is not a number
curl -X PUT -d '{"size": "foo", "color": "red"}' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# SUCCESS (assuming 'blue' appears in our colors list)
curl -X PUT -d '{"size": 21, "color": "blue"}' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# If the record already exists and has a color, this will
# succeed, otherwise it will fail since newData.hasChildren(['color', 'size'])
# will fail to validate
curl -X PUT -d '99' \
https://docs-examples.firebaseio.com/rest/securing-data/example/size.json

Regardons maintenant la même structure, mais en utilisant les règles .write au lieu de .validate :

{
  "rules": {
    // this variant will NOT allow deleting records (since .write would be disallowed)
    "widget": {
      // a widget must have 'color' and 'size' in order to be written to this path
      ".write": "newData.hasChildren(['color', 'size'])",
      "size": {
        // the value of "size" must be a number between 0 and 99, ONLY IF WE WRITE DIRECTLY TO SIZE
        ".write": "newData.isNumber() && newData.val() >= 0 && newData.val() <= 99"
      },
      "color": {
        // the value of "color" must exist as a key in our mythical valid_colors/ index
        // BUT ONLY IF WE WRITE DIRECTLY TO COLOR
        ".write": "root.child('valid_colors/'+newData.val()).exists()"
      }
    }
  }
}

Dans cette variante, l'une des opérations suivantes réussirait :

var ref = new Firebase(URL + "/widget");

// ALLOWED? Even though size is invalid, widget has children color and size,
// so write is allowed and the .write rule under color is ignored
ref.set({size: 99999, color: 'red'});

// ALLOWED? Works even if widget does not exist, allowing us to create a widget
// which is invalid and does not have a valid color.
// (allowed by the write rule under "color")
ref.child('size').set(99);

Firebase *ref = [[Firebase alloc] initWithUrl:URL];

// ALLOWED? Even though size is invalid, widget has children color and size,
// so write is allowed and the .write rule under color is ignored
[ref setValue: @{ @"size": @9999, @"color": @"red" }];

// ALLOWED? Works even if widget does not exist, allowing us to create a widget
// which is invalid and does not have a valid color.
// (allowed by the write rule under "color")
[[ref childByAppendingPath:@"size"] setValue: @99];

var ref = Firebase(url:URL)

// ALLOWED? Even though size is invalid, widget has children color and size,
// so write is allowed and the .write rule under color is ignored
ref.setValue(["size": 9999, "color": "red"])

// ALLOWED? Works even if widget does not exist, allowing us to create a widget
// which is invalid and does not have a valid color.
// (allowed by the write rule under "color")
ref.childByAppendingPath("size").setValue(99)

Firebase ref = new Firebase(URL + "/widget");

// ALLOWED? Even though size is invalid, widget has children color and size,
// so write is allowed and the .write rule under color is ignored
Map<String,Object> map = new HashMap<String, Object>();
map.put("size", 99999);
map.put("color", "red");
ref.setValue(map);

// ALLOWED? Works even if widget does not exist, allowing us to create a widget
// which is invalid and does not have a valid color.
// (allowed by the write rule under "color")
ref.child("size").setValue(99);

# ALLOWED? Even though size is invalid, widget has children color and size,
# so write is allowed and the .write rule under color is ignored
curl -X PUT -d '{size: 99999, color: "red"}' \
https://docs-examples.firebaseio.com/rest/securing-data/example.json

# ALLOWED? Works even if widget does not exist, allowing us to create a widget
# which is invalid and does not have a valid color.
# (allowed by the write rule under "color")
curl -X PUT -d '99' \
https://docs-examples.firebaseio.com/rest/securing-data/example/size.json

Ceci illustre les différences entre les règles .write et .validate . Comme démontré, toutes ces règles doivent être écrites à l'aide de .validate , à l'exception possible de la règle newData.hasChildren() , qui dépend de l'autorisation ou non des suppressions.

Règles basées sur les requêtes

Bien que vous ne puissiez pas utiliser de règles comme filtres , vous pouvez limiter l'accès à des sous-ensembles de données en utilisant des paramètres de requête dans vos règles. Utilisez query. expressions dans vos règles pour accorder un accès en lecture ou en écriture en fonction des paramètres de requête.

Par exemple, la règle basée sur les requêtes suivante utilise des règles de sécurité basées sur l'utilisateur et des règles basées sur les requêtes pour limiter l'accès aux données de la collection de baskets aux seuls paniers que l'utilisateur actif possède :

"baskets": {
  ".read": "auth.uid !== null &&
            query.orderByChild === 'owner' &&
            query.equalTo === auth.uid" // restrict basket access to owner of basket
}

La requête suivante, qui inclut les paramètres de requête dans la règle, réussirait :

db.ref("baskets").orderByChild("owner")
                 .equalTo(auth.currentUser.uid)
                 .on("value", cb)                 // Would succeed

Cependant, les requêtes qui n'incluent pas les paramètres dans la règle échoueraient avec une erreur PermissionDenied :

db.ref("baskets").on("value", cb)                 // Would fail with PermissionDenied

Vous pouvez également utiliser des règles basées sur des requêtes pour limiter la quantité de données qu'un client télécharge via des opérations de lecture.

Par exemple, la règle suivante limite l'accès en lecture aux seuls 1 000 premiers résultats d'une requête, classés par priorité :

messages: {
  ".read": "query.orderByKey &&
            query.limitToFirst <= 1000"
}

// Example queries:

db.ref("messages").on("value", cb)                // Would fail with PermissionDenied

db.ref("messages").limitToFirst(1000)
                  .on("value", cb)                // Would succeed (default order by key)

La query. les expressions sont disponibles dans les règles de sécurité de la base de données en temps réel.

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 :

• Découvrez l'ensemble complet de variables de règles prédéfinies que vous pouvez utiliser pour créer des conditions .
• Rédigez des règles qui répondent à des scénarios courants .
• Renforcez vos connaissances en examinant les situations où vous devez repérer et éviter les règles non sécurisées .
• Découvrez la suite d'émulateurs locaux Firebase et comment vous pouvez l'utiliser pour tester les règles .
• Passez en revue les méthodes disponibles pour déployer des règles .

Fonctionnalités d'apprentissage des règles spécifiques à la base de données en temps réel :

• Apprenez à indexer votre base de données en temps réel .
• Passez en revue l' API REST pour le déploiement des règles .