Dans quelle couche les autorisations doivent-elles être appliquées dans MVC?

Question

À quelle couche (Modèle, Vue, Contrôleur) de MVC la logique d'autorisation doit-elle être gérée? Permettez-moi de clarifier cela un peu. Il est évident que l'interface utilisateur (View et Controller) doit pouvoir accéder aux autorisations pour afficher/masquer les composants et gérer le scénario d'autorisation refusée. Il semble également évident que les autorisations doivent être conservées dans la base de données par la couche Modèle. Mais qu'en est-il des règles d'autorisation "complexes" comme celle-ci?
Dans un système wiki/CMS que je développe, chaque utilisateur dispose d'un ensemble d'autorisations par page (voir, modifier, renommer, etc.). Pour les pages existantes, ces autorisations sont extraites de la base de données. Pour une nouvelle page, l'utilisateur est supposé avoir toutes les permissions possibles (au fur et à mesure de sa création/modification).

Un autre exemple serait la liste des pages:
L'utilisateur actuel ne devrait voir que les pages sur lesquelles il a l'autorisation de visionner dans la liste des pages.

Le contrôleur doit-il gérer cette logique? Ou est-ce que le contrôleur devrait seulement être responsable de l'appel d'une méthode GetPermissions() (ou GetPageList), et toute la logique pour le remplir est gérée dans le modèle?

Answer 1

Le contrôle de l'accès aux entités de domaine de problème appartient au modèle. C'est l'endroit approprié car (1) le contrôle d'accès aux entités de domaine est étroitement lié aux entités elles-mêmes, et (2) c'est le seul endroit où vous pouvez vous assurer qu'aucun contrôleur n'autorise des politiques d'accès différentes aux mêmes objets.

Les facteurs suivants ajoutent une certaine confusion:

1. L'authentification se produit au niveau du contrôleur
2. Certains outils et démos sont disponibles pour appliquer facilement le contrôle d'accès - à la couche de commande, par exemple this, this ou that.

Cependant, il appartient toujours au modèle.

Answer 2

Le modèle doit disposer des informations sur les autorisations autorisées/refusées pour l'utilisateur connecté. Ensuite, le contrôleur doit autoriser/bloquer les actions en fonction du modèle. Dans le même temps, la vue doit uniquement peindre les liens correspondant aux actions que l'utilisateur sera autorisé à exécuter. La vue saura s'il faut peindre ou non un certain lien demandant le modèle (encore une fois).

Vous devez utiliser la programmation défensive: si vous ne contrôlez pas l'accès à l'action sur le contrôleur, ne pas peindre un lien pour un utilisateur donné, permet toujours à cet utilisateur d'exécuter une action. D'autre part, peindre un lien d'une action qui va planter (si seulement vérifier les autorisations sur le contrôleur) va ennuyer vos utilisateurs.