Allow et Deny

Aparté 8.5

Traduction complétée à

Au programme de ce chapitre :

  • En savoir plus à propos des callbacks Allow et Deny.
  • Comprendre dans quel ordre les callbacks sont appelés.
  • Le système de sécurité de Meteor nous permet de contrôler les modifications de la base de données sans avoir à définir des Méthodes à chaque fois que l'on fait des changements.

    Parce que nous avions besoin de réaliser des tâches auxiliaires comme décorer l'article avec des propriétés supplémentaires et décider d'une action spéciale quand l'URL de l'article était déjà été postée, utiliser une Méthode post spécifique quand un article est créé était tout à fait sensé.

    D'un autre côté, nous n'avions pas vraiment eu besoin de créer de nouvelles Méthodes pour mettre à jour ou supprimer des articles. Nous avions juste besoin de vérifier si l'utilisateur avait la permission de réaliser ces actions, et cela fut facilité par les callbacks allow et deny.

    Utiliser ces callbacks nous laisse être plus déclaratif à propos des modifications de la base de données, et dire quels types de mises à jour peuvent être utilisées. Le fait qu'ils s'intègrent avec le système de comptes est un bonus.

    Multiples callbacks

    Nous pouvons définir autant de callbacks allow que nécessaires. Nous avons juste besoin qu’au moins l'un d'entre eux retourne true durant le changement qui est en train de s'opérer. Donc quand Posts.insert est appelé dans un navigateur (peu importe si c'est depuis le code côté client de votre application ou depuis la console), le serveur va faire à son tour toutes les vérifications allowed-insert qu'il peut jusqu'à ce qu'il en trouve une qui retourne true. S'il n'en trouve aucune, il n'autorisera pas le insert, et retournera une erreur 403 au client.

    De la même façon, nous pouvons définir un ou plusieurs callbacks deny. Si un de ces callbacks retourne true, le changement sera annulé et une erreur 403 sera retourné. La logique de tout cela signifie que pour un insert réussi, un ou plusieurs callbacks allow insert aussi bien que chaque callback deny insert seront exécutés.

    Note: n/e est l'abréviation de Not Executed
    Note: n/e est l'abréviation de Not Executed

    En d'autres mots, Meteor descend la liste de callback en partant du premier avec deny, puis avec allow, et exécute chaque callback jusqu'à ce que l'un d'entre eux retourne true.

    Un exemple pratique de ce pattern serait d'avoir deux callbacks allow(), l'un qui vérifie si un article appartient à l'utilisateur courant, et un second qui vérifie si l'utilisateur courant a les droits d'administration. Si l'utilisateur courant est un administrateur, cela assure qu'il sera capable de mettre à jour n'importe quel article, puisqu'au moins l'un de ces callback retournera true.

    Compensation de latence

    Souvenez-vous que ces Méthodes de mutation de base de données (telles que .update()) sont compensé en latence, comme toutes les autres méthodes. Donc par exemple, si vous essayez de supprimer un article qui ne vous appartient pas via la console du navigateur, vous verrez l'article brièvement disparaître au moment où votre collection locale perd le document, puis réapparaître lorsque le serveur l'informe que, non, en fait le document n'a pas été supprimé.

    Bien sûr ce comportement n'est pas un problème quand il est déclenché depuis la console (après tout, si les utilisateurs essaient de bidouiller avec les données dans la console, ce qui se passe dans leur navigateur n'est pas vraiment votre problème). Cependant, vous devez vous assurer que cela n'arrive pas dans l'interface utilisateur. Par exemple, vous devez vous donner du mal pour vous assurer que vous ne montrez pas les boutons supprimer lorsqu'ils ne sont pas autorisés à supprimer.

    Heureusement, puisque vous pouvez partager le code de permissions entre client et serveur (par exemple, vous pourriez écrire une fonction bibliothèque canDeletePost(user, post) et la mettre dans le répertoire lib partagé), cela ne requiert habituellement pas beaucoup de code supplémentaire.

    Permissions côté serveur

    Souvenez-vous que le système de permissions s'applique seulement sur les mutations de base de données initiées par le client. Sur le serveur, Meteor assume que toutes les opérations sont permises.

    Ceci signifie que dans le cas où vous écririez une Méthode Meteor côté serveur deletePost qui pourrait être appelée par le client, n'importe qui serait capable de supprimer chaque article. Vous ne voulez donc probablement pas faire cela à moins que vous ayez également vérifié les permissions à l'intérieur de cette Méthode.