Laravel 4 Multi User Authentication

Question

Buduję aplikację Laravel 4, która wymaga uwierzytelnienia logowania dla 3 typów jednostek: Coach, Student & Admin, wszystkie z osobnymi interfejsami użytkownika. Chociaż mógłbym użyć pakietu takiego jak Sentry 2 i jednej tabeli użytkowników DB z typami użytkowników, aby osiągnąć ten cel, coś o potencjalnych polimorficznych wzorach projektów DB i bólach głowy, które mogą pojawić się na torze, nie pasują do mnie. Mając do czynienia z problemami polimorficznymi w przeszłości z poprzednimi aplikacjami i żałobą, jaką może stworzyć, gdy chcesz znormalizować strukturę DB, itp. Posiadanie oddzielnych tabel DB dla każdego typu jednostki wydaje się lepszym rozwiązaniem.

Jak rozwiązać ten problem z projektowaniem?

laravel 4 auth wykorzystuje zasadniczo następujące pliki:

• Auth.php (fasada)
• AuthManager.php
• AuthServiceProvider.php
• Guard.php
• auth.php (config)
• User.php (model elokwentny)

Odtwarzałem duplikację tych plików, aby uzyskać głównie niezależny autorytet dla podmiotu, który działa, rejestrując fasadę i dostawcę usług w pliku app.php, a także wprowadzając niezbędne zmiany w konfiguracji skorzystać z autokarów wymowne model uwierzytelniania:

• AuthCoach.php (fasada)
• AuthCoachManager.php
• AuthCoachServiceProvider.php
• Guard.php
• authcoach.php (config)
• Coach.php (wymowny modelu)

nadal używam Guard.php ze standardowego laravel 4 auth, ale Gwardia można łatwo rozszerzyć, jeśli zajdzie taka potrzeba, aby dostosować metody uwierzytelniania straży trenera poprzez tworzenie Plik GuardCoach.php.

Jeśli mam mieć oddzielne uwierzytelnienie dla każdego typu jednostki, czy uważasz, że jest to dobry sposób na osiągnięcie tego?

Czy widzisz potencjalne problemy lub znasz lepszy sposób na zrobienie tego?

Answer 1

Może nie rozumiem twojego kontekstu, ale dlaczego nie używasz po prostu podstawowej koncepcji kontroli dostępu opartej na rolach i renderujesz różne rzeczy dla różnych ról? Jeśli to nie wystarczy, możesz użyć zasad auth opartych na atrybutach, aby uzyskać granularne uprawnienia. Jakie są powody, dla których chcesz zduplikować (potrójne) auth-logic? Nie wspominając o fakcie nadmiarowych danych db (osobna tabela użytkownika dla oddzielnego typu użytkownika? Yuk!)?

Jeśli nie jesteś usatysfakcjonowany Sentry (osobiście, nie korzystam z tej biblioteki) Mogę polecić Zizaco/Confide + Zizaco/Entrust jako czyste i eleganckie rozwiązanie do zarządzania użytkownikami/rolami/uprawnieniami. Sprawdź to tutaj Zizaco GitHub.

Szybkie ogólna idea:

• używać jednego czystego mechanizmu uwierzytelnienia dla całej aplikacji
• granulat dostęp z rolami lub ról + Uprawnienia
• oddzielić logikę administratora na osobne kontrolery (AdminUserController, AdminCoachController, cokolwiek ..)
• Nie widzę trudności w komponowaniu odpowiedniej struktury szablonu ostrza, aby wszystko było ładnie wykonane i dobrze zorganizowane

Jakie są twoje problemy polimorficzne?

Jeśli martwisz się, że Twój stół użytkownika zostanie zagracony, zostaw jako miejsce przechowywania informacji o autorze i umieść wszystkie inne niezbędne (nieautentyczne) dane użytkownika w innej tabeli.

Mam nadzieję, że to pomoże, jeśli tylko dobrze zrozumiałem twój problem.

Answer 2

Myślę, że próbujesz skrobać komara za pomocą młotka.

Oto jak rozwiązać ten sam problem:

• chciałem się upewnić, że uwierzytelnianie każdego użytkownika (nazwa użytkownika, hasło) są przechowywane w tej samej tabeli. Zasadniczo miałem trzy rodzaje użytkowników.

• Użyłem Sentry 2, dzięki któremu można łatwo zarządzać uwierzytelnianiem.

• Korzystając z domyślnych migracji udostępnionych przez Sentry 2, dodałem kolumnę "rola" do tabeli "Użytkownicy" - która rozróżnia 3 typy użytkowników.

• Dla każdego typu użytkownika utworzyłem tabelę z określonymi polami.

• Po uwierzytelnieniu użytkownika przechwyciłbym jego "rolę" z tabeli "Użytkownicy", uruchomiłam kilka instrukcji if i wiedział, który widok będzie im służył.

A komar był całkowicie martwy.

Onto Twoja:

• Zasadniczo oba nasze metody są takie same - ponieważ każdy typ użytkownika ma osobną tabelę dla pól oni nie wszyscy (z wyjątkiem pierwszego imienia, ostatni nazwisko, adres e-mail, hasło, ostatnie logowanie itp.).

• Twoje podejście umożliwi użytkownikowi przynależność do trzech podmiotów - co jest logicznie niepoprawne. Mój nie będzie - co logicznie ...

• Boisz się "problemów polimorficznych", ale nie sądzę, że mamy tu wiele do zrobienia. Wszystko, co chcielibyśmy zrobić, to zdefiniować w naszych modelach, że trener, na przykład, belongsTo użytkownika. I trener użytkownika hasOne.

• Ale w rzeczywistości nie musimy nawet definiować relacji. Ponieważ podczas uwierzytelniania musimy mimo wszystko wykonywać polecenia if. Tak więc, używając obiektu użytkownika zwróconego z uwierzytelniania, będziemy wiedzieć dwie rzeczy: która tabela następnie przejść do informacji specyficznych dla typu użytkownika i który widok służyć uwierzytelnionemu użytkownikowi.

Nie bój się, synu