Ich habe die folgende ntier App: MVC & gt; Dienstleistungen & gt; Repository & gt; Domain. Ich verwende die Formularauthentifizierung. Ist es sicher, Thread.CurrentPrincipal außerhalb meiner MVC-Ebene zu verwenden, um den aktuell angemeldeten Benutzer meiner Anwendung zu erhalten, oder sollte ich HttpContext.Current.User verwenden?
Der Grund, warum ich frage, ist, dass es Probleme mit Thread.CurrentPrincipal gibt, aber ich bin vorsichtig, einen Verweis auf System.Web außerhalb meiner MVC-Ebene hinzuzufügen, falls ich in der Zukunft ein nicht webbasiertes Fontende bereitstellen muss .
Aktualisieren
Ich habe den bis jetzt erhaltenen Rat befolgt, den Benutzernamen als Teil der Parameter an die aufgerufene Methode in den Dienst zu übergeben, und dies hat zu einer Verfeinerung meiner ursprünglichen Frage geführt. Ich muss überprüfen können, ob der Benutzer in einer bestimmten Rolle in einer Anzahl meiner Service- und Domain-Methoden ist. Es scheint ein paar Lösungen zu geben, die sich fragen, welcher der beste Weg ist, um fortzufahren:
Wie würden Sie vorschlagen, ich fahre fort?
Ich würde das auch nicht tun, HttpContext.Current.User ist spezifisch für Ihre Webschicht.
Warum nicht den Benutzernamen in Ihre Service-Ebene einfügen?
Sie sollten Ihre Benutzerinformationen so abstrahieren, dass sie nicht von Thread.CurrentPrincipal oder HttpContext.Current.User abhängt.
Sie könnten beispielsweise einen Konstruktor oder einen Methodenparameter hinzufügen, der einen Benutzernamen akzeptiert.
Hier ist ein übermäßig vereinfachtes Beispiel für einen Konstruktorparameter:
%Vor%Ich bevorzuge Option Nummer 2 (verwende Thread.CurrentPrincipal außerhalb der Web Tier). Da dies nicht Ihre Service-Tier polieren & amp; Daten Tier Methoden. mit Boni: Sie können Ihre Rollen und zusätzliche Informationen im benutzerdefinierten Prinzipal speichern;
Stellen Sie sicher, dass Thread.CurrentPrincipal in Ihrer Service- und Datenebene mit Ihrer Webebene übereinstimmt. Sie können Ihren HttpContext.Current.User (Context.User) in Global.asax (Application_AuthenticateRequest) festlegen. Andere alternative Orte, an denen Sie dies einstellen können, werden unten hinzugefügt.
Beispielcode:
%Vor%Natürlich müssen Sie zuerst Ihr Login-Formular implementieren, um Autorisierungs-Cookies zu erstellen, die Ihren benutzerdefinierten Prinzipal enthalten.
Application_AuthenticateRequest wird für jede Anfrage an den Server ausgeführt (CSS-Dateien, Javascript-Dateien, Bilddateien usw.). Um diese Funktionalität nur auf die Controller-Aktion zu beschränken, können Sie versuchen, den benutzerdefinierten Prinzipal in ActionFilter zu setzen (ich habe das nicht versucht). Was ich versucht habe, ist das Setzen dieser Funktionalität in einem Interceptor für Controller (ich benutze Castle Windsor für meine Dependency Injection und Aspect Oriented Programming).
Ich glaube, dass Sie auf dieses Problem stoßen, weil Sie die Verantwortlichkeit Ihrer Domains weiter einschränken müssen. Es sollte nicht in der Verantwortung Ihres Dienstes oder Ihres Dokuments liegen, die Autorisierung zu übernehmen. Diese Verantwortung sollte von Ihrer MVC-Schicht übernommen werden, da der aktuelle Benutzer in Ihrer Web-App und nicht in Ihrer Domäne angemeldet ist.
Wenn Sie versuchen, den aktuellen Benutzer von Ihrem Dienst oder Dokument aus zu suchen, führen Sie die Überprüfung in Ihrer MVC-App aus. Sie erhalten dann etwa Folgendes:
%Vor% Das ist sauber, leicht zu lesen und ermöglicht es Ihnen, Ihre Dienste und Domain-Klassen von Autorisierungsbedenken freizuhalten. Sie können Roles.IsUserInRole("DocumentEditorRole") immer noch Ihrem Ansichtsmodell zuordnen. Das einzige, was Sie verlieren, ist die CurrentUserCanEdit-Methode für Ihre Document-Klasse. Wenn Sie jedoch an Ihr Domänenmodell denken, das reale Objekte darstellt, gehört diese Methode ohnehin nicht zum Dokument. Sie könnten es sich als Methode für ein Domain-Benutzerobjekt vorstellen ( user.CanEditDocument(doc) ), aber alles in allem denke ich, dass Sie glücklicher sein werden, wenn Sie Ihre Berechtigung nicht in Ihrer Domain-Ebene behalten.
Tags und Links asp.net-mvc asp.net-mvc-3 authentication forms-authentication iprincipal