2010-12-14 66 views
4

Je développe une application de type CMS utilisant MVC 3 (RC2) et je suis à la croisée des chemins à ce stade. Je suis incapable de me convaincre si l'approche que je propose est appropriée ou non. Je suppose que c'est parce que je suis conscient que j'essaie de couper quelques coins qui me coûteront lourdement plus tard sur toute la ligne.Logique d'application (endroit approprié pour l'authentification/l'autorisation)

Je vais aller droit vers le bas pour décrire mon problème:

1) J'ai une ressource (permet de l'appeler A) qui doit être éditables.

2) J'ai un système d'autorisation personnalisé mis en œuvre qui a 2 (de plusieurs) autorisations:

  • peut éditer ses propres ressources
  • Can Modifier autres ressources

3) Créateur de ressources A est libre de l'éditer s'il a l'autorisation 'Can Edit Own Resource'.

4) Un utilisateur distinct ne pouvez modifier A si elles ont la permission « Can Modifier autres ressources »

Maintenant que l'exigence est décrite, laissez-moi vous dire mon approche jusqu'à présent:

1) I un contrôleur appelé 'ResourceController'

2) J'ai une action appelée 'Edit'

3) L'action a un attribut sur elle: [CustomerAuthorize (Perm.CanEditOwnResource, Perm.CanEditOtherResource, Any = true) ]

4) J'ai une classe de service qui s'occupe de la validation de domaine.

Ainsi, un utilisateur appelle la méthode d'action s'il dispose de l'autorisation 'Can Edit Own Resource' ou 'Can Edit Other Resource'. Comment puis-je décider (et où prendre cette décision) si l'utilisateur a la bonne autorisation ou non (selon qu'il possède ou non la ressource?) Devrait-il être dans l'action du contrôleur, dans la classe de service de ressources , dans une classe de service distincte?

En attendant d'entendre différents points de vue ...

Répondre

2

En raison de la nature de MVC, vous voudrez avoir vos vérifications d'authentification à une variété de points. Par exemple, vous devez être en mesure d'afficher des repères visuels sur l'interface utilisateur (c'est-à-dire afficher le bouton d'édition ou ne pas l'afficher), de sorte que la logique doit être mise à la disposition de vos vues.

Bien sûr, c'est uniquement à des fins d'interface utilisateur. Vous aurez également besoin d'une authentification/autorisation sur les actions de votre contrôleur, au cas où quelqu'un contournerait votre interface utilisateur pour y accéder.

Enfin, l'endroit le plus sûr pour authentifier et autoriser une action est juste avant l'exécuter. Si vous avez un gestionnaire, par exemple, j'y placerais une logique d'autorisation. Vous voulez vous assurer que personne ne peut écrire autour de votre logique de sécurité en appelant le service depuis un autre endroit, et ne sachant pas qu'il y avait des restrictions sur ce service. Cela contribue à rendre les options de sécurité plus précises.

+0

Mais n'est-ce pas la duplication de la logique? Avoir les mêmes contrôles répétés plusieurs fois? Mais je comprends votre inquiétude. Je me demande si je pourrais voir quelques projets OSS pour apprendre le modèle. – kidoman

+0

@ KiD0M4N: Dans certains cas, il est beaucoup plus facile de répéter une certaine logique (y compris des considérations de maintenance à long terme) que de ne pas le répéter. C'est-à-dire que, parfois, des contraintes technologiques ou des décisions de conception existantes rendent déraisonnablement difficile la poursuite pure et simple de «ne pas répéter». –

0

Une façon d'approcher est d'avoir 2 actions, au lieu que « Modifier », vous avez « EditOwnResource » et « EditOtherResource ». Vous pouvez ensuite placer une seule autorisation sur chacun d'eux. Ensuite, si vous utilisez le modèle MVVM, vous pouvez lier la disponibilité de ces actions à savoir s'il s'agit d'une ressource propre ou d'une autre ressource. Le réglage de ces valeurs est effectué dans le modèle de vue.

+0

J'utilise ASP.NET MVC. Les bits MVVM ne s'appliquent donc pas. Mais je vais penser à avoir deux actions de front distinctes. Mais ce ne sera probablement pas possible dans mon cas particulier – kidoman