permet de dire que j'ai une application ASP.NET MVC et cette application (UI) références d'une couche logique commerciale (BLL) et de la BLL références de la couche d'accès aux données (DAL).
J'utilise une adhésion et un rôle personnalisé fournisseur d'autorisation. P>
J'essaie de déterminer quelles calques doivent référencer mon fournisseur de membres. P>
en MVC Vous pouvez effectuer des contrôles d'autorisation de la manière suivante: P>
public static bool IsRoleEditor(User user, Role userRole)
{
bool retValue = false;
if (user.Application.AppID == UserRole.Application.AppID)
{
if (Roles.IsUserInRole("ModifyRoles"))
{
retValue = true;
}
return retValue;
}
8 Réponses :
Obtenez votre objet d'utilisateur pour implémenter l'interface Iprincipal et lancer cela autour des couches. Ensuite, vous pouvez toujours utiliser l'attribut [Autorize] intégré.
ce qu'il y a plus de 3 ans il y a plus de 3 ans et à propos du château, Cet article < / a> peut aider. Cela commence à entrer dans le truc iprincipal à mi-chemin.
hTHS
Charles
Utilisez définitivement l'attribut Authorize en MVC. Vous n'avez pas besoin de vérifier manuellement les isinroles.
Le problème est que je dois traiter une logique commerciale supplémentaire en plus de "Isinrocle" ou "Autoriser" que je pensais toujours être dans la BLL. Je pourrais passer l'objet utilisateur partout, mais pourquoi ne pas simplement laisser l'autorisation et utiliser uniquement le BLL.
Excellente question, je me suis demandé la même chose aujourd'hui. Une des idées que j'avais (mais je ne suis pas vraiment sûre si c'est la meilleure façon d'aller) est d'utiliser une interface (EX: IroleProvider) que vous pouvez transmettre à votre BLL pour tester votre accès.
public static bool IsRoleEditor(User user, IRoleProvider rp)
{
return (rp.IsUserInRole(user,"ModifyRoles"));
}
L'accès des rôles normalement ne devrait pas être dans la BLL. L'accès est une responsabilité d'interface utilisateur.
avec qui dit, tirez parti de l'interface IprinCipe comme les affiches ci-dessus ont indiqué. Vous avez accès à Iprincipe au niveau du fil. P>
Thread.CurrentPrincipal
Charles, Thx pour la réponse. Comme vous pouvez le constater, je devais traiter une certaine logique professionnelle, autrement que la vérification des rôles de base, afin de déterminer afin de déterminer les utilisateurs véritables sécurité. J'ai pensé que tout BL devrait être dans la BLL, c'est pourquoi je prévoyais d'encapsuler la sécurité là-bas. Dis-vous qu'il est préférable que "l'isrocédent" ci-dessus réside dans ma couche d'interface utilisateur et non dans une BLL?
-1 Je suis en désaccord: l'autorisation (que ce soit le rôle d'Acccess ou un autre mécanisme) est très responsable de la responsabilité de la LLL. Le niveau de l'UI peut être exécuté sur le client (par exemple Winforms) afin de pouvoir être compromis.
Cela dépend vraiment de la façon dont vous concevez cette application. Donnez-nous un exemple de votre solution, de simples noms de projet et de la façon dont ils se réfèrent.
@Joe je suis en désaccord avec vous. Mettre l'autorisation dans la BLL Pidgon Trous dans l'utilisation de cette mise en œuvre de l'autorisation dans l'ensemble de l'application et de ses points de vue. Une hypothèse est faite que des services Web, des formulaires gagnent, des formulaires Web, des API de repos, etc. Tous doivent avoir la même autorisation. Cette idée est envisage avec des problèmes. Pensez à utiliser AD (Active Directory). L'annonce fonctionne bien avec Winforms, mais ne fonctionne pas bien avec quoi que ce soit sur le Web. Si l'autorisation doit être utilisée dans le BLL, je l'entourais dans une abstraction, probablement le modèle de fournisseur.
Charles a du sens ici. Vous ne pouvez pas vous attendre à ce que le BLL ait tout par magie. L'application est toutes ces composants et chaque composant a ses propres exigences de sécurité. Y compris l'interface utilisateur, le «BLL», la base de données, le serveur et tous les services Web que vous appelez.
Pourquoi ne pas transmettre les rôles dans votre BLL afin de ne pas avoir de dépendance à l'adhésion. Ou utilisez une interface comme Martinb suggérées.
Que se passe-t-il à l'avenir lorsque votre titulaire de pieuse (s) décidera (s) d'aller avec une autre forme d'authentification et que vous ne travaillez plus avec un objet / p>
Exemple:
À mon avis, il s'agit d'une faiblesse de la conception d'adhésion / de rôle.
La façon dont je voudrais aborder cela, par exemple pour avoir une autorisation basée sur des rôles sur les niveaux d'interface utilisateur et globale dans une application Distributed N-Tier, serait d'exposer un service dans le niveau de la BLL qui expose les bits pertinents (GetRolesforuser etc) et est mis en œuvre en appelant le rôle provenant sur le serveur.
Ensuite, implémentez un domaine de rôle personnalisé sur le client mis en œuvre en appelant le service exposé par le BLL.
De cette façon, le niveau de l'interface utilisateur et le numéro BLL partagent le même rôle. Le niveau de l'interface utilisateur peut utiliser la connaissance des rôles de l'utilisateur actuels pour améliorer l'interface utilisateur (par exemple, la cachette / désactivation des contrôles d'interface utilisateur correspondant à des fonctionnalités non autorisées), et la BLL peut s'assurer que les utilisateurs ne peuvent pas exécuter logique commerciale pour laquelle ils ne sont pas autorisés.
Ne vous manquez pas le point de MVC. MVC se sépare naturellement dans des niveaux. Modèle (dal), contrôleur (BLL), vue (présentation). Ceux-ci peuvent aller dans différents projets si vous le souhaitez, mais comme le contrôleur dispose de toute la logique commerciale - il vous suffit d'accéder au rôle provisoire.
Appliquez ensuite des motifs tels que le référentiel, le motif, etc. pour diviser plus loin si vous le souhaitez.
Davy
Je comprends le concept de MVC, mais si je configurais le BLL pour contenir la validation du rôle, alors pourquoi "[Autoriser (Rôles =" Somerolename ")]" Capacité de l'interface utilisateur?
@jay L'attribut Authorize est utilisé dans le contrôleur, selon Davy, indiquait que la couche d'entreprise serait la couche d'entreprise. Je pense que ce qu'il conduit est que vous semblez ignorer le fait que les "couches" ont déjà été divisées par le modèle MVC. Je pense que tout dépend de la structuration de cette solution Jay, pourriez-vous faire un diagramme pour nous montrer comment vous concevez cela?
Un diagramme aiderait. Voulez-vous dire la capacité de l'UI comme dans la vue? Si vous le faites, je pense que c'est bien de simplement avoir dube HTML, mais vous avez une vue d'avis où vous souhaitez montrer quelque chose en fonction de rôles comme une «case à cocher autorisée» que seuls les superviseurs peuvent voir dans une vue partagée autrement. Donc, pouvoir rôles d'accès ici est utile à mon avis.
Appeler le contrôleur MVC 'UI' est loin de la marque .. Le «C» en MVC est partie de votre BLL, même s'il fait référence à des classes qui vous appellerait la BLL. Cependant, ce n'est pas le point de votre question.
Je pense que je résoudrais ce problème en posant la question, "Y a-t-il une réelle exigence pour 100% de séparation de votre application" UI "et de votre" BLL "?". Si les deux composantes partagent une dépendance vis-à-vis des fournisseurs de membres / Fournisseurs, alors laissez-le le faire et d'arriver au travail.
Dans le cas où vous débranchez votre BLL et connectez-vous une nouvelle, une dépendance partagée sur un fournisseur de .NET est peut-être quelque chose que vous pouvez vivre. Vous savez que c'est probablement ok et votre application peut ne pas se séparer.
Je pense que la réponse de Joe ci-dessus a beaucoup de sens si ...
Je ne sais pas que le contrôleur fait partie de votre BLL, en général, je pense qu'il ne doit contenir aucune logique commerciale, juste l'orchestration entre vos objets de domaine.
Wtf est la logique commerciale quand même? L'application entière est la logique métier, composée de divers éléments de la logique métier .. la partie de l'interface utilisateur de la logique, la partie MVC de la logique .. ayant votre code correctement architecturée et Abstraite est le but, ne pas appliquer les noms génériques pour les composants complexes . L'idée de ces couches linéaires droites et linéaires est stupide. Un diagramme de solution est une carte complexe d'objets, et le problème de la croix est notre problème de travail - Jay's's Problème est un bon, traiter avec une croix sur des dépendances sera une tâche amusante. Je pense toujours que la réponse de Joe a le plus de sens et maintenant Je suis juste rodomontades.
Je pense que ce que vous faites va bien.
L'autorisation et l'authentification doivent vivre dans une couche de services, qui est peut-être transmise à vos contrôleurs.
Si le contrôleur définit le capital et l'identité et que vous l'utilisez ensuite dans le contrôleur via l'utilisation des attributs MVC, il ressemble à une bonne idée.
Il serait agréable de cacher votre fournisseur d'adhésion MVC derrière une interface, de cette façon, vous pouvez l'échanger pour un fournisseur d'adhésion WinForms (par exemple) et serait en mesure de tester vos contrôleurs.