Est-ce que l'utilisation de conditions de sécurité est une violation de MVC?

10

Souvent, ce qui est affiché à un utilisateur (par exemple sur une page Web) sera basé en partie sur des contrôles de sécurité. Je considère généralement que la sécurité au niveau utilisateur / ACL fait partie de la logique métier d'un système. Si une vue vérifie explicitement la sécurité pour afficher conditionnellement des éléments d'interface utilisateur, viole-t-elle MVC en contenant la logique métier?

— Matt S
source

Quelle serait l'alternative?

1

Vous utilisez ce qui vous donne la meilleure sécurité même si elle est considérée comme anti-modèle par certains.

— zxcdw

6

Il peut y avoir deux types de conditions de sécurité, l'une sur le modèle et l'autre sur la vue. La vue contrôle l'affichage des éléments pertinents en fonction des autorisations de l'utilisateur actuel, mais le modèle contrôle l'accès aux données sous-jacentes. Tant que le modèle possède toutes les bonnes vérifications / validations, même si la vue fait défaut, il y a toujours de la sécurité.

Habituellement, vous devez avoir les deux, car la vue doit changer pour différents niveaux / rôles. Le contrôleur envoie les données pertinentes qui changeraient la vue, mais la vue doit encore faire quelque chose avec ces données pour masquer / afficher le contenu au bon utilisateur.

C'est pourquoi la plupart des frameworks de modèles ont des éléments conditionnels ( exemple de guidon ):

{{#if isCurrentUserAdmin}}
    ....
{{/if}

Cela signifie donc que ce n'est pas une violation, tant que les pièces appropriées sont au bon endroit.

— connuasilya
source

4

Oui et non.

Si la décision de sécurité réelle est prise par la vue, alors oui, vous violez MVC. Si, cependant, la vue délègue la décision réelle au modèle, alors tout va bien. Il n'y a rien de mal à ce qu'une vue prenne des décisions sur les éléments à afficher, sur la base des informations du modèle.

Par exemple, si vous disposez d'un bouton "modifier" qui n'est visible que pour les utilisateurs disposant des autorisations "éditeur", la vue peut demander au modèle qui est l'utilisateur actuel et s'il dispose de l'autorisation "éditeur", puis utiliser ces informations pour décider d'afficher ou non le bouton. Si, cependant, la vue devait faire la logique d'authentification et d'autorisation elle-même, vous violeriez MVC.

— tdammers
source

2

Je dirais non .

Mais pour une raison différente de celle de @rvcoutinho (bien qu'il cite wikipedia qui me fait me sentir mal dans ma pensée)

Je dirais que tout problème de sécurité pertinent devrait être partagé par le modèle donné à la vue (en fonction du nombre de combinaisons que vous souhaiterez peut-être utiliser un ViewModel pour cette raison), en ce sens que vous pourriez avoir des commutateurs pour les bits de sécurité.

Cela permet la validation de la sécurité à deux couches: au niveau de la couche d'interface utilisateur, donc une publication est subvertie pour le cas normal, ainsi qu'au niveau du serveur pour les mauvais acteurs où le modèle conserve les connaissances en matière de sécurité à l'intérieur de lui-même afin que le contrôleur transmette les informations à le modèle qui le jette immédiatement.

La sécurité à deux couches comme celle-ci est la norme dans l'industrie, et de cette façon, votre logique de sécurité ne doit exister qu'à deux endroits, c'est donc un bonus, dès que vous placez une logique de sécurité dans votre contrôleur, vous la mettez là, et dans le Interface utilisateur et dans le modèle (le modèle en a besoin car c'est la dernière ligne de défense et particulièrement important pour toute utilisation en dehors de cette application Web MVC comme un client de bureau ou tout outil de gestion de serveur)

— Jimmy Hoffa
source

L'affirmation de Wikipédia selon laquelle "un contrôleur peut envoyer des commandes à sa vue associée pour modifier la présentation de la vue du modèle" semble plus appropriée à Model-View-Presenter , car le modèle interactif que la phrase semble décrire est possible là-bas, alors que dans MVC, une fois la vue est rendue, aucune autre action n'a lieu entre la vue et le contrôleur.

— Robert Harvey

1

@RobertHarvey Je serais d'accord que cette affirmation ne correspond pas à ma définition de MVC, mais nous avons la chance de travailler dans une industrie où l'exactitude est décidée par une pluralité d'accords plutôt que par une quelconque prouvabilité car ces définitions flottent juste comme si de l'éther avec une fondation en constante évolution permettant à chacun de faire ses propres plats à emporter. Ou en termes plus simples, je me trompe probablement autant que tout le monde ici.

— Jimmy Hoffa

3

C'est pourquoi je pense que les gens sont beaucoup trop pédants à propos de ce genre de chose de toute façon.

— Robert Harvey

1

@rvcoutinho Je ne dirais pas du tout que j'étais littéral; vous avez des références de votre côté, tout ce que j'ai, c'est mon opinion, donc dans mon esprit, cela signifie que je me trompe probablement, c'est pourquoi je l'ai mentionné. Je pense que mon opinion est suffisamment plausible pour mériter d'être partagée même si je n'ai pas de références, donc je l'ai fait de toute façon, même si comme je l'ai dit, je me trompe probablement.

— Jimmy Hoffa

1

@rvcoutinho: En fait, je faisais référence à la question du PO. :) Il n'y a rien de mal avec les règles, à moins que les règles n'empêchent de faire quelque chose.

— Robert Harvey

2

Je dirais non .

Habituellement, ce type de contrôle de sécurité sera effectué par le contrôleur.

Comme sur Wikipedia :

Un contrôleur peut envoyer des commandes à sa vue associée pour modifier la présentation de la vue du modèle

Et je ne pense pas que cela devrait être fait directement dans la vue. Si cela se fait via javascript, par exemple, cela pourrait être un problème de sécurité (on pourrait désactiver javascript et accéder aux données privilégiées).

Encore une fois, à partir de Wikipedia :

Une vue demande au modèle les informations dont il a besoin pour générer une représentation de sortie .

— rvcoutinho
source

1

Dans de nombreux systèmes logiciels, l' affichage d'un élément dépend du niveau de sécurité d'un utilisateur. Bien que vous puissiez empêcher l'affichage d'un élément de données en le définissant sur zéro ou null dans le modèle d'affichage, le nom ou la description de l'élément de données sera toujours affiché. Le seul endroit où vous pouvez empêcher l'affichage de la description de l'élément de données (de manière pratique) est dans la vue.

— Robert Harvey du

J'ai tendance à être en désaccord. Je dirais que la vue demanderait les données, le contrôleur manipulerait le modèle et la vue, encore une fois, le représenterait. La vue doit être responsable de la représentation de la sortie uniquement.

— rvcoutinho

C'est pourquoi la vue doit masquer les éléments visuels que l'utilisateur n'a pas besoin de voir. Le contrôleur n'est pas responsable de la création de la représentation visuelle des données; la vue est. Bien sûr, si ce que vous affichez est si sensible qu'il ne peut même pas être dans la vue / source, ce que le contrôleur doit faire est de renvoyer une vue différente .

— Robert Harvey

1

C'est mon point. La vue devrait être différente. Pour autant que je comprends, il semble que la vue ne devrait prendre en charge que la représentation des données. Par représentation, je veux dire comment montrer quelque chose, pas quand le montrer. Pourtant, vos commentaires sont tout à fait pertinents.

— rvcoutinho

Eh bien, je pense que nous pourrions simplement utiliser la même expression pour deux choses différentes. Qu'est-ce qu'une vue différente de toute façon? Mais je pense que nous sommes d'accord sur la question la plus importante: si elle est sensible à la sécurité, elle ne devrait pas être traitée par la vue.

— rvcoutinho

1

Il y a plusieurs problèmes impliqués dans cette question.

L'authentification (c'est cet utilisateur qu'il prétend être) ne devrait pas être une préoccupation de la vue.
Autorisation (L'utilisateur actuel autorisé à faire cela ) est une préoccupation de la vue, car elle peut affecter ce qui sera présenté à l'utilisateur. Ainsi, le code pour afficher un bouton d'édition peut être entouré d'un conditionnel if model.userCanEdit() ... endif.
La détermination des attributs d'autorisation dont dispose un utilisateur, c'est-à-dire la logique métier et doit être placée dans le modèle. (Par exemple, le privilège "modifier" vous oblige à avoir 2000 points de réputation; ou vous devez être l'auteur ou un modérateur)

— Bart van Ingen Schenau
source

0

S'il ne s'agit que d'afficher l'élément d'interface utilisateur, je pense que c'est ok (comment le feriez-vous de toute façon?). S'il y avait des données dans ces éléments, le modèle aurait dû s'assurer que les conteneurs sont vides. Et bien sûr, le code pour obtenir les données d'autorisation aurait dû être traité avant la vue, il n'y a donc pas d'accès actif au modèle ici.

— thorsten müller
source

0

Si une vue vérifie explicitement la sécurité pour afficher conditionnellement des éléments d'interface utilisateur, viole-t-elle MVC en contenant la logique métier?

Oui, c'est une violation de MVC.

La vue n'est là que pour afficher les éléments, et la logique doit être dans le modèle. En faisant faire quelque chose à la vue (dans votre cas, vérifiez la sécurité), vous y placez la logique.

— BЈовић
source

Comment la vue pourrait-elle alors afficher ou non quelque chose comme un bouton d'édition?

— Matt S

@MattS Le présentateur appelle une fonction dans la vue pour afficher ou masquer ce bouton (en fonction d'un état dans le modèle).

— BЈовић