.Net Mitgliedschaft in nTier App

StackOverflow https://stackoverflow.com/questions/1407742

Frage

Lets sagen, ich habe eine ASP.Net MVC App und diese App (UI) verweist auf eine Business Logic Layer (BLL) und der BLL verweist meine Data Access Layer (DAL).

Ich bin ein benutzerdefinierter Mitgliedschafts- und Rollenanbieter für Autorisierung verwendet.

ich, um zu bestimmen versuchen, welche Schichten benötigen, meine Mitgliedschaft Anbieter verweisen.

In MVC können Sie Berechtigungsprüfungen auf folgende Weise ausgeführt werden: 

[Authorize(Roles = "SomeRoleName")]
public ActionResult Index()
{
//do something
}

Und in meinem BLL kann ich mag überprüfen, um zu sehen, ob ein Benutzer in einer Rolle ist auch: 

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;
   }

hätte ich verweisen und die Mitgliedschaft Klassen in beiden Schichten instanziiert, wenn ich dies tun. Ist dies der richtige Weg, um Architekten einer App wie diese? Scheint, wie viel Redundanz.

Da ich eine BLL habe ich vermeiden, mit den „[autorisieren (Roles =‚SomeRoleName‘)]“ Attribute und stattdessen eine BLL Funktion innerhalb der MVC-Code aufrufen zu überprüfen, ob der Benutzer in einer Rolle ist? Wenn ich diese die MVC tun muss noch einen Verweis auf die Mitgliedschaftsanbieter für die Authentifizierung und solche ohnehin Vorteil der Anmeldung und anderen ASP-Kontrollen zu nehmen, nicht wahr?

Bin ich weg Basis und in die falsche Richtung?

War es hilfreich?

Lösung

Aus meiner Sicht ist dies eine Schwäche der Mitgliedschaft / Rollenentwurf.

So wie ich diese Runde, zum Beispiel bekommen würde haben basierte Rolle Berechtigung sowohl UI und BLL Ebene in einer verteilten n-Tier-Anwendung, wäre einen Dienst in dem BLL Tiere zu machen, die die entsprechenden Bits aussetzt (GetRolesForUser usw.) und durch den Aufruf der Roleprovider auf dem Server implementiert wird.

Dann eine benutzerdefinierte Roleprovider auf dem Client implementieren, die durch den Aufruf des Dienstes durch den BLL ausgesetzt umgesetzt wird.

Auf diese Weise wird die UI-Ebene und BLL Tier beide die gleichen Roleprovider teilen. Das UI Tier Kenntnis des aktuelle Benutzers Rollen verwenden, kann die UI (z Versteck / Deaktivieren UI steuert entsprechend unbefugter Funktion) und die BLL kann zur Verbesserung sicherzustellen, dass Benutzer können nicht ausgeführt werden Business-Logik, für die sie nicht zugelassen.

Andere Tipps

Ausgezeichnete Frage, fragte ich mir die gleiche Sache heute. Einer der Idee, die ich hatte (aber ich bin nicht wirklich sicher, ob es der beste Weg zu gehen) ist eine Schnittstelle zu verwenden (zB: IRoleProvider)., Dass Sie Ihre BLL passieren können Ihren Zugang zu testen 

public static bool IsRoleEditor(User user, IRoleProvider rp)
{
     return (rp.IsUserInRole(user,"ModifyRoles"));
}

Damit Sie noch Ihren Zugang in Ihrem BLL überprüfen Sie einen Mock in Ihren Unit-Tests können Sie Ihre Logik überprüfen und Sie müssen nur eine Klasse (oder implementieren diese in einer Base Klasse) in Ihrer MVC Web-Site erstellen das wird IRoleProvider implementieren und tun die richtige Kontrolle ASP.NET-Berechtigungs-API verwendet wird.

Hope dies dazu beitragen wird.

Erhalten Sie Ihr Benutzerobjekt die IPrincipal Schnittstelle und zu werfen, dass um die Schichten zu implementieren. Dann können Sie noch die eingebaute verwenden in [Autorize] Attribut.

Athough geschrieben mehr als 3 Jahren und über Schloss, diesem Artikel kann helfen. Es beginnt immer in die IPrincipal Sachen auf halbem Weg nach unten.

HTHS
Charles

Warum die Rollen nicht in Ihre BLL geben, so dass Sie keine Abhängigkeit von Mitgliedschaft haben. Oder verwenden Sie eine Schnittstelle wie MartinB vorgeschlagen.

Was passiert in der Zukunft, wenn Sie Ihren Einsatz Inhaber (s) entscheiden, mit einer anderen Form der Authentifizierung zu gehen und Sie nicht mehr arbeiten mit einem Role Objekt?

Beispiel: 

IsRoleEditor(User user, string[] roles)
{
  return roles.Contains("ModifyRoles");
}

Vermissen Sie nicht den Punkt der MVC. MVC spaltet naturaly in Stufen aus. Modell (DAL), Controller (BLL), Anzeigen (Darstellung). Diese können in verschiedenen Projekten gehen, wenn Sie mögen, aber wie der Controller alle Business-Logik hat -. Sie nur die Roleprovider dort zugreifen müssen

Dann Muster anwenden, wie das Repository, Muster etc. weiter spalten, wenn Sie wollen.

Davy

den MVC-Controller 'UI' zu nennen, ist Art und Weise weg von der Markierung .. Die 'C' in MVC ist Teil Ihre BLL, auch wenn es Klassen verweist, die Sie würde die BLL nennen. Aber das ist nicht der Punkt Ihrer Frage.

Ich glaube, ich würde dieses Problem lösen, indem sie die Frage zu stellen, „ist es eine Voraussetzung, um 100% ige Trennung von Ihrem‚UI‘App und Ihrer‚BLL‘?“. Wenn beide Komponenten eine Abhängigkeit von dem Mitglied / Rolle-Anbieter teilen, dann lassen Sie es so sein und arbeiten.

In dem Fall, dass Sie Ihre BLL und Stecker in einem neuen ziehen, vielleicht eine gemeinsame Abhängigkeit von einem .NET-Provider ist etwas, mit denen Sie leben können. Sie wissen, dass ist wahrscheinlich in Ordnung und Ihre Anwendung kann einfach nicht auseinander fallen.

Ich denke, Joe Antwort über viel Sinn macht, wenn ...

Ich denke, was Sie tun, ist in Ordnung.

Die Autorisierung und Authentifizierung sollte innerhalb einer Dienstschicht leben, die vielleicht in Ihre Controller übergeben wird.

Wenn die Steuerung der Haupt- und Identität und Sie dann verwenden, die in der Steuerung durch den Einsatz der MVC-Attribute dann klingt es wie eine gute Idee.

Es wäre schön, Ihren MVC Membership Provider hinter einer Schnittstelle zu verstecken, dass, wie Sie es aus für einen WinForms Membership Provider (zum Beispiel) tauschen können und würden zu Einheit testen Sie Ihre Controller können.

Rollen Zugang sollte normalerweise nicht in der BLL sein. Access ist eine Benutzeroberfläche Verantwortung.

Mit diesem wird gesagt, nutzen die IPrinciple Schnittstelle wie die oben Plakate angegeben haben. Sie haben Zugriff auf IPrinciple auf Thread-Ebene. 

Thread.CurrentPrincipal
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top