Quel est le meilleur moyen d'implémenter différentes vues pour un site Web en fonction de son rôle?

Question

Dans ASP.NET, quelle est la meilleure façon de procéder:

1. Afficher certains contrôles en fonction de vos droits?
2. Pour un contrôle gridview, comment afficher certaines colonnes en fonction de votre rôle?

Je pense au numéro 2, les données proviennent d'une vue spécifique à un rôle dans la base de données.

Answer 1

Au lieu d'utiliser des rôles pour masquer / afficher certains contrôles, je suggère de disposer d'une autre couche d'autorisations pour chaque rôle et d'afficher / masquer en fonction de celles-ci.

Ainsi, vous pourrez redéfinir les autorisations dont dispose un rôle sans avoir à modifier votre code.

De plus, cela vous permet de créer de nouveaux rôles à l'avenir et d'attribuer simplement un ensemble d'autorisations au rôle.

En ce qui concerne les contrôles, oui ... je voudrais simplement définir la propriété Visible sur le contrôle en fonction de la valeur user.IsInRole ("permissionname").

Pour les grilles, je referais la même chose ... définissez la visibilité des colonnes sur la valeur booléenne IsInRole.

//Delete Icon Column
gridViewContacts.Columns[0].Visible = user.IsInRole("DeleteAnyContact"); 

Je ferais en sorte que vos autorisations soient créées de manière très granulaire.

• ViewAnyContact
• ViewOwnContact
• EditOwnContact
• EditAnyContact
• AddAnyContact
• DeleteOwnContact
• DeleteAnyContact
• Etc ...

Answer 2

Si vous choisissez la route basée sur les rôles, ASP.NET (depuis la version 2.0) dispose de plusieurs contrôles d’appartenance disponibles qui pourraient vous aider dans ce scénario. En supposant (et cela pourrait bien être une hypothèse erronée) que vous utilisez le fournisseur d'appartenance intégré, vous pouvez réellement utiliser le contrôle LoginView pour obtenir le traitement n ° 1.

La façon dont cela fonctionne est que LoginView peut utiliser RoleGroups et leur ContentTemplates associé pour personnaliser la vue de l'utilisateur en fonction de son rôle. Cela fonctionne de manière transparente avec le fournisseur d'adhésion intégré. Je pense que si vous construisez votre propre fournisseur d'adhésion basé sur la technologie de Microsoft, cela fonctionnera également. (Je n'ai pas fait cette dernière étape.)

Il est concevable que vous puissiez l'utiliser pour le n ° 2, mais que le code et les efforts seraient dupliqués, ce qui n'est pas ma préférence personnelle. Je pense que votre choix d'utiliser des vues SQL spécifiques à un rôle pour piloter cette table est peut-être meilleur que cette option. (Il existe bien sûr d’autres options qui pourraient être meilleures.)

J'appuierai la recommandation d'Elijah Manor d'utiliser des autorisations au lieu de rôles. Généralement, c'est aussi ma préférence. (Et j'ai été surpris de découvrir que la technologie du fournisseur d'adhésion n'allait pas à ce niveau.) Dans tous les scénarios centrés sur les autorisations, vous devrez essentiellement tout faire vous-même. (Je l'ai fait et, même s'il est très flexible, le code permettant de sécuriser une page donnée peut devenir poilu.)

EDIT: je m'excuse; Je voulais inclure un lien pour le contrôle LoginView. DotNetJunkies a un tutoriel à ce sujet.