Auf welcher Ebene meiner ASP.NET MVC-Anwendung sollte ich Mitgliedschaftsinformationen prüfen?

8

Ich habe eine MVC-Anwendung, die die (vereinfachte) Struktur wie folgt hat (von links nach rechts):

Benutzeroberfläche - & gt; Controller - & gt; LEISTUNGEN - & gt; ERWERBER - & gt; DATENBANK

Wir haben versucht, jede Ebene von der nächsten zu entkoppeln. Wir verwenden .NET-Mitgliedschaft, um die Sicherheit zu verwalten, und wir haben eine berechtigungsbasierte Funktion, sagen wir "Zeige mir alle Dokumente für meinen Benutzertyp" .

Sollte:

  1. Die Services-Ebene hat keine Kenntnis von unserem .NET-Mitgliedschaftsanbieter. Wir hätten dann Service-Layer-Methoden, die wie "GetDocumentsByUserType (int UserTypeId) {..}" aussehen?

  2. Die Methode GetDocumentsByUserType () muss wissen, dass wir .NET-Mitgliedschaft verwenden, Mitgliedschaftsmethoden verwenden, um den aktuellen Benutzertyp abzurufen, und die relevanten Dokumente zurückgeben?

Auch:

  • Macht # 1 meine Services-Schicht weniger sicher, wie meine Controller-Schicht
    könnte alles als UserType übergeben?
  • Macht # 2 meine Services-Schicht zu abhängig von einer bestimmten Technologie, nämlich .NET Mitgliedschaft? Gibt es einen anderen Weg, hier zu überlegen?

Ich hoffe, ich habe genug Details zur Verfügung gestellt. Bitte schreit wenn nicht und ich füge hinzu.

Danke.

    
christofr 06.10.2011, 11:17
quelle

1 Antwort

7

Sie sollten alle Elemente der Mitgliedschaft in der Präsentations- (Controller) Ebene behalten. Angenommen, Sie möchten jemals eine andere Präsentationsebene hinzufügen (oder Änderungen an der vorhandenen Ebene vornehmen), wird es Ihnen schwerfallen, dies zu beheben. Außerdem duplizieren Sie Code zwischen Ihrer Präsentationsebene und Ihrer Servicesbene, was nie eine gute Idee ist.

Nachdem dies gesagt wurde, gibt es keinen Grund, keine Sicherheitsüberprüfungen in Ihrer Services-Schicht durchzuführen, aber Sie können dies tun, ohne die Mitgliedschaftsklassen zu verwenden. Zunächst einmal ist der aktuell authentifizierte Benutzer von Thread.CurrentPrincipal verfügbar (innerhalb Ihrer Service-Layer-Methoden). Sie können diese IPrincipal Sicherheitsüberprüfungen durchführen.

Zweitens können Sie das PrincipalPermissionAttribute erzwingen Sicherheitsregeln für Ihre Service-Layer-Methoden oder -Klassen. Zum Beispiel:

%Vor%

Damit die Rolle funktioniert, müssen Sie auch ein verwenden RoleProvider Implementierung.

UPDATE : Wie Wyatt Barnett in einem Kommentar erklärt, hat die Verwendung von PrincipalPermission einige Nachteile. Zunächst einmal wird das Testen Ihres Codes schwieriger. Ein weiterer (größerer) Nachteil besteht darin, dass Sie die Rollennamen in Ihrem Code fest codieren. Diese Namen gehören normalerweise nicht dem Entwickler.

    
Ronald Wildenberg 06.10.2011, 11:35
quelle