.Net Członkostwo w aplikacji nTier

Question

Powiedzmy, że mam aplikację ASP.Net MVC i ta aplikacja (UI) odwołuje się do warstwy logiki biznesowej (BLL), a BLL odwołuje się do mojej warstwy dostępu do danych (DAL).

Korzystam z usługi Custom Membership and Role Provider dla autoryzacji.

Próbuję określić, jakie warstwy muszą odnosić się do mojego dostawcy członkostwa.

w MVC można przeprowadzić kontrole zezwolenia w następujący sposób:

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

I w moim BLL może chcę sprawdzić, czy użytkownik znajduje się w rolę, a także:

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

Będę musiał odwołać i utworzyć instancję klasy Membership w obu warstwach, jeśli to zrobię. Czy to jest właściwy sposób na zaprojektowanie takiej aplikacji? Wydaje się, że dużo redundancji.

Od kiedy mam BLL, czy należy unikać używania atrybutów "[Authorize (Roles =" SomeRoleName ")]] i zamiast tego wywoływać funkcję BLL z kodu MVC, aby sprawdzić, czy użytkownik jest w roli? Jeśli to zrobię, MVC nadal potrzebuje odniesienia do dostawcy członkostwa w celu uwierzytelnienia i tak czy inaczej, aby skorzystać z logowania i innych formantów ASP, prawda?

Czy jestem daleko od bazy i zmierzam w złym kierunku?

Answer 1

Moim zdaniem jest to słabość konstrukcji Członkostwo/rolę.

Sposób, w jaki można to obejść, na przykład mieć autoryzację opartą na rolach na poziomach interfejsu użytkownika i BLL w rozproszonej aplikacji n-warstwowej, polegałby na udostępnieniu usługi w warstwie BLL, która eksponuje odpowiednie bity (GetRolesForUser itp.) I jest realizowany przez wywołanie RoleProvider na serwerze.

Następnie zaimplementuj niestandardowego RoleProvider na kliencie zaimplementowanym przez wywołanie usługi odsłoniętej przez BLL.

W ten sposób warstwy warstwy pośredniej i warstwa BLL współdzielą tę samą rolę RoleProvider. Warstwa interfejsu użytkownika może wykorzystywać wiedzę na temat ról bieżącego użytkownika do ulepszania interfejsu użytkownika (na przykład ukrywanie/wyłączanie kontroli interfejsu użytkownika odpowiadających nieautoryzowanym funkcjom), a BLL może zapewnić, że użytkownicy nie mogą wykonywać logiki biznesowej, dla których nie są uprawnieni.

Answer 2

Pobierz obiekt użytkownika, aby zaimplementować interfejs IPrincipal i wyrzuć go wokół warstw. Wtedy nadal możesz użyć wbudowanego atrybutu [Autoryzuj].

Pomyślnie napisany ponad 3 lata temu o zamku, this article może pomóc. Zaczyna docierać do rzeczy IPrincipala w połowie drogi.

HTHS
Charles

Answer 3

Doskonałe pytanie, zadałem sobie to samo dzisiaj. Jedną z idei, którą miałem (ale nie jestem do końca pewien, czy to najlepszy sposób, aby przejść) jest użycie interfejsu (np. IRoleProvider), który można przekazać do BLL, aby przetestować swój dostęp.

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

Dzięki temu, nadal weryfikacji dostępu w BLL, można użyć mock w badaniach jednostkowych, aby sprawdzić swoją logikę i po prostu trzeba utworzyć klasę (lub zaimplementować to w klasie baseController) w twoja strona internetowa MVC, która zaimplementuje IRoleProvider i zrobi właściwe sprawdzanie za pomocą API autoryzacji ASP.NET.

Mam nadzieję, że to pomoże.

Answer 4

Dostęp do ról zwykle nie powinien być w BLL. Dostęp to odpowiedzialność za interfejs użytkownika.

W ten sposób wykorzystaj interfejs IPrinciple, o czym wspomniały powyższe plakaty. Masz dostęp do IPrinciple na poziomie wątku.

Thread.CurrentPrincipal 

Answer 5

Dlaczego nie przekazać ról do BLL, aby nie mieć żadnej zależności od Członkostwa. Lub użyj interfejsu takiego jak sugerował MartinB.

Co stanie się w przyszłości, gdy interesariusze zdecydują się na inną formę uwierzytelniania i przestaniesz pracować z obiektem Role?

Przykład:

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

Answer 6

Nie brakuje punktu MVC. MVC dzieli naturalność na poziomy. Model (DAL), kontroler (BLL), widok (prezentacja). Mogą one wchodzić w różne projekty, jeśli chcesz, ale ponieważ kontroler ma całą logikę biznesową - potrzebujesz tylko dostępu do roli RoleProvider.

Następnie zastosuj wzorce, takie jak repozytorium, wzór itp., Aby podzielić je dalej, jeśli chcesz.

Davy

Answer 7

Aby połączyć kontroler MVC 'UI' jest sposobem chybione .. The 'C' w MVC jest część Twojego BLL, nawet jeśli odwołuje zajęcia, które ty nazwałbym BLL. Jednak nie o to pytasz.

Myślę, że rozwiązałbym ten problem, zadając pytanie: "czy istnieje rzeczywisty wymóg 100% oddzielenia aplikacji" UI "od" BLL "?". Jeśli oba komponenty współdzielą zależność od dostawców elementów/ról, pozwól, aby tak się stało i zacznij działać.

W przypadku odłączania BLL i podłączania nowego, być może posiadanie współdzielonej zależności od dostawcy .NET jest czymś, z czym można żyć. Wiesz, że to chyba ok, a twoja aplikacja może się nie rozpaść.

myślę nad odpowiedzią Joe sprawia, że ​​wiele sensu, choć ...

Answer 8

myślę co robisz jest w porządku.

Autoryzacja i autoryzacja powinny znajdować się w warstwie usług, która prawdopodobnie jest przekazywana do kontrolerów.

Jeśli kontroler ustawi Principal and Identity, a następnie użyjesz go w kontrolerze za pomocą atrybutów MVC, to brzmi to jak dobry pomysł.

Byłoby miło ukryć dostawcę członkostwa MVC za interfejsem, w ten sposób można go zamienić na dostawcę członkostwa WinForms (na przykład) i byłby w stanie przetestować sterowniki.