08s-allow-and-deny.md.erb

---
title: Allow et Deny
slug: allow-and-deny
date: 0008/01/02
number: 8.5
points: 5
sidebar: true
photoUrl: http://www.flickr.com/photos/ikewinski/9475104376/
photoAuthor: Mike Lewinski
contents: En savoir plus à propos des callbacks Allow et Deny.|Comprendre dans quel ordre les callbacks sont appelés.
paragraphs: 16
---

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.

<%= diagram "allow_deny", "Note: n/e est l'abbré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.

### Utiliser un deny comme callback

Finalement, une astuce que vous pouvez faire avec `deny` est de l'utiliser comme un callback "onX". Par exemple, vous pouvez achever un horodate `lastModified` avec le code suivant :

~~~js
Posts.deny({
  update: function(userId, doc, fields, modifier) {
    doc.lastModified = +(new Date());
    return false;
  },
  transform: null
});
~~~

Comme les callbacks `deny` sont exécutés pour *chaque* `update` avec succès, nous savons que ce callback sera exécuté et peut faire des changements du document d'une manière structurée.

Certes, cette technique est un peu un hack, donc vous pourriez vouloir effectuer des mises à jour en préférant l'utilisation d'une Méthode. Cependant, c'est encore utile à savoir, et dans le futur nous pouvons espérer que ce type de callback `beforeUpdate` deviendra disponible.