PHP - Gdzie umieścić RBAC i Uwierzytelnianie w aplikacji MVC?

Question

pracuję nad aplikacji MVC z tej struktury:

Request 
     V 
FrontController <-> Router 
     V 
    Controller <-> Model 
     V 
    View 

mam dwa inne składniki, które trzeba umieścić w tej strukturze:

• Authentification kłody użytkownikowi w korzystaniu z $_SESSION zmienna globalna;
• RBAC: Rola Kontrola dostępu oparta, które mogą sprawdzić, czy rola ma dostęp przyznanego „Ressource” (Controller metody) .

Każdy użytkownik może mieć dowolną liczbę ról (nie może ich również mieć).

Teraz muszę umieścić te dwa składniki w mojej aplikacji, muszę im być w stanie:

• Jeżeli User nie authed i że Request wymaga authed User do wykonania, klient powinien zostać przekierowany na stronę logowania;
• Jeśli RBAC widzi, że authed User nie posiada rolę, jaką ma dostęp przyznany wymaganej „Ressource” do wykonania Controller „metoda S, a Controller” s metoda powinna być nadal realizowane, ale ze świadomością, że User nie miał na to zgody (Przykład: a User pisze artykuł, ale nie mają prawa do ich publikacji, a więc artykuł jest zapisany jako szkic i User dowiaduje się, że będzie miał Moderator opublikować go).

mam już kilka pomysłów, gdzie zlokalizować Authentification i RBAC ale nie jestem pewien:

• Authentification może pójść w FrontController lub Router;
• RBAC może przejść w FrontController lub Controller.

Widziałem kogoś, kto wstawił RBAC w modelu, ale nie rozumiem, dlaczego.

Chciałbym uzyskać pewien wgląd w ten temat. Gdzie powinienem umieścić komponenty Authentification i RBAC?

Dziękujemy!

Answer 1

W typowej aplikacji MVC sprawdzanie autentyczności (tj. "Jeśli nie auth, następnie zatrzymaj i wyrenderuj stronę logowania") jest wykonywane bardzo wcześnie podczas przetwarzania żądania, podczas gdy logika biznesowa (tj. "Jeśli użytkownik ma to uprawnienie to się dzieje, w przeciwnym razie ") jest obsługiwane w" C "(kontroler).

Większość frameworków ma mechanizm na potrzeby testów, takich jak sprawdzanie autentyczności, które opisują - nazwy są różne, ale często widziałem, że nazywa się to "oprogramowaniem pośredniczącym".

Kontrola dostępu oparta na rolach jest wyłącznie Twoją implementacją.

Answer 2

Z mojego doświadczenia wynika, że ​​logika biznesowa kontroli dostępu zmienia się wraz z dodawaniem nowych funkcji, dlatego opłaca się zaprojektować elastyczność i ruchliwość w systemie kontroli dostępu. W związku z tym zaprojektowałbym uwierzytelnianie i RBAC jako oddzielne cechy, a następnie w razie potrzeby uwzględnilibyśmy te cechy w przestrzeni kontrolera.

Jak opisano, to brzmi jak cecha uwierzytelnienia najlepiej byłoby włączyć do swojej czołowej regulatora: wiesz, że wszystkie kontrolery zależne wymagają uwierzytelnienia, więc zawierają ten czek na wczesnym etapie cyklu życia, aby zwolnić gniazda życzenie. Jeśli twoje wymagania zmienią się, aby niektóre sterowniki zostały skasowane, możesz przenieść tę cechę do konkretnych kontrolerów lub do klasy kontrolera podstawowego.

Jeśli chodzi o RBAC, to może mieć zastosowanie globalnie do wszystkich kontrolerów, a także lokalnie do niektórych kontrolerów. Na przykład Twój FrontController może wysyłać zapytania do RBAC, aby zbudować tabelę routingu, podczas gdy kontroler zależny używałby RBAC do swoich konkretnych potrzeb.

Jedna rzecz do rozważenia, chociaż: możesz mieć także pewne potrzeby RBAC w modelu. Oznacza to, że niektóre role mogą mieć ograniczony dostęp do niektórych pól w niektórych modelach: rola A może uzyskać dostęp do wszystkich modeli X, ale rola B może tylko odczytać pola 1, 2 i 3 modelu X. (Zaufaj mi, widziałem bardzo , bardzo skomplikowane reguły dotyczące ról, które mogą widzieć i działać na jakich polach.)

Inżynieria RBAC jako cecha kontrolera może utrudniać przenoszenie do przestrzeni modelu. Dlatego może okazać się, że lepiej jest opracować RBAC jako delegata usługi i wstrzykiwać go na żądanie. Dzięki dobrze zaopatrzonemu kontenerowi IoC delegat usługi jest tak samo prosty jak narzędzie do kompilacji.

Na koniec dodam, że oba te elementy będą wymagały ciężkiego testu (w końcu są ważne). Cokolwiek wybierzesz, inżynier, aby mogli zostać przetestowani. Moim zdaniem obie cechy i delegaci są łatwe do przetestowania w izolacji i albo będą dobrym wyborem do wdrożenia niezbędnej logiki.