Pourquoi devrais-je coder en dur les permissions des utilisateurs dans mes attributs de contrôleur?

Question

J'ai vu un exemple de code qui ressemble à ceci, qui semble parfaitement raisonnable:

[Authorize(Roles = "Admin, User")] 
public class SomeController : Controller 

Mais je l'ai vu aussi plusieurs exemples qui ressemblent à ceci:

[Authorize(Users = "Charles, Linus")] 
public class SomeController : Controller 

Pourquoi voudrais-je faire ce? Je ne peux imaginer aucun scénario où je voudrais construire un système qui connaisse ses noms d'utilisateurs à l'avance.

Answer 1

Il y a quelques utilisations légitimes de ceci, et voici un exemple: Si vous construisez un site vraiment simple, qui a simplement un compte admin et un compte non authentifié, vous pouvez le faire

[Authorize(Users = "Admin")] 

Cela vous évite d'avoir à vous soucier de construire des rôles pour un seul utilisateur. Pensez au style UNIX, où le compte root (uid 0) est spécial plutôt qu'un groupe particulier.

Un autre exemple est simplement une application jetable, où vous testez quelque chose. Il n'y a aucune raison de déranger les rôles si vous voulez juste tester votre page d'authentification ou quelque chose comme ça.

Une raison de plus: tester. Vous pouvez créer un test unitaire juste pour votre authentification sans vouloir tester votre unité basée sur les rôles. (Gardez à l'esprit que tout le monde n'utilise pas le fournisseur d'appartenances par défaut et certains fournisseurs d'appartenances sont assez sophistiqués.) En créant une authentification codée en dur pour un utilisateur de test, vous pouvez contourner le cadre des rôles.

Answer 2

Vous ne voulez pas, les utilisateurs de codage en dur sont une mauvaise odeur. Les rôles existent pour des choses comme ça. Edit: Je crois que, comme lorsque .net 1.0 a frappé avec le web.config entier avec autorisations/refuser, ceux sont (ou au moins DEVRAIENT être seulement) utilisé comme exemple de sauce, même si je suis dans la pile des personnes qui croient que les blogs, les tutoriels et les exemples ne devraient utiliser que les bonnes pratiques.

Answer 3

La seule raison "légitime" à laquelle je puisse penser est de construire une porte arrière - soit pour un usage néfaste, soit pour une "maintenance future". Ce dernier est Bad Juju car il introduit un risque de sécurité. Le premier est Bad Juju bien sûr, bien sûr :)

Answer 4

Quelques raisons pour lesquelles vous pourriez envisager de le faire:

1. L'application doit avoir un cycle de vie très court et sans entretien est nécessaire.
2. L'utilisateur (s) en question ne peuvent pas appartenir à un groupe suffisamment défini (comme dans le cas d'une petite entreprise), et il n'y a pas changements attendus. (encore design très mauvais, mais il ne serait pas du jamais vu)
3. Vous avez peut- plusieurs dans une petite surcharge demande qui nécessitent différents comportements des individus au sein d'un groupe .

Dans tous les cas, il se résume à un mauvais design et vous ne voudriez pas le faire. Mais l'interface est là parce que c'est le niveau de contrôle le plus simple.

Answer 5

Je suis d'accord avec David Pfeffer. En outre, je pense que vous pourriez définir un ensemble d'utilisateurs avec des autorisations et des tâches très spécifiques dans votre application - peut-être tester, peut-être le suivi de la performance ... vous le saurez quand l'exigence frappe la porte;) -.

Il s'agit simplement d'un groupe qui n'est pas censé être contenu dans l'ensemble des utilisateurs valides utilisés par votre application. :) -la manière hardcore-