2013-09-24 24 views
5

Projekt, nad którym obecnie pracuję, jest podzielony na konsolę administracyjną i normalny interfejs. Zarówno front, jak i backend znajdują się w tej samej instancji Laravel.Wiele sesji Auth w Laravel 4

W interfejsie staram się stworzyć system logowania użytkownika, który działa wyłącznie na frontend. Używa innej tabeli i modelu i ma różne relacje w stosunku do modelu użytkownika dla administratora.

Czego nie mogę zrozumieć, jest sposobem na użycie klasy Laravel Auth dla obu systemów. Logicznie Auth używa jednego pliku konfiguracyjnego, a więcej do punktu, jednej nazwy sesji.

Jednym z rozwiązań, które zostało przedstawione, nie jest użycie innej tabeli i modelu oraz użycie jakiejś formy akl dla rozróżnienia. Ale nie podoba mi się pomysł mieszania frontendu i backendu w ten sposób. Zwłaszcza, ponieważ oznaczałoby to, że nagle musiałbym nadać administratorowi model użytkownika wszystkie pola i relacje, które wcześniej były unikalne dla użytkownika frontendu.

To po prostu nie wydaje się właściwym sposobem robienia rzeczy. Mógłbym przełączyć się na inny system uwierzytelniania lub oddzielić administratora do pakietu z jego własnymi konfiguracjami, ale zakres projektu nie pozwala na takie zmiany czasowe.

Chciałbym powitać każdy pomysł, jaki możesz podać.

+1

może to być pomocni http://stackoverflow.com/questions/18785754/laravel-4-need-to-auth-with-2-different-tables – cyvvilek

Odpowiedz

5

To jest problem, że natknąłem się ostatnio zbyt. Całe oddzielne środowisko nie było łatwe, szczególnie jeśli masz już środowiska programistyczne i produkcyjne.

Zrobiłem jednak trochę czasu, tworząc pakiet, aby rozwiązać ten problem, który można znaleźć na https://github.com/ollieread/multiauth. Samo opakowanie jest zasadniczo klasa fabrycznym Auth, który pozwala na korzystanie z wielu wystąpień z nim, dzięki czemu dostęp do niego tak:

Auth::admin()->check(); 
Auth::user()->check(); 
Auth::whatever()->check(); 

Mam nadzieję, że pakiet pomaga ani nikogo innego, patrząc na tego podejścia.

2

Nie jestem pewien, ale może jest przydatny. Dlaczego nie spróbować stworzyć oddzielnego środowiska dla administratora. A potem będziesz miał coś takiego jak app/config/admin/session.php i app/config/session.php do produkcji (co jest domyślnym środowiskiem).

Widać tutaj jak środowisk http://andrewelkins.com/programming/php/how-to-set-laravel-4-environments/

setup Ale jak powiedziałem, że to tylko pomysł, nie jestem całkiem pewien :)

+0

Środowiska są wyraźnie do zrobienia tutaj. Skonfiguruj admin.twojawitryna.com i odpowiednio zmień pliki konfiguracyjne. Zakłada to, że nie dodajesz niestandardowych metod do klasy użytkownika, które są specyficzne dla ról. – Makita

1

Wygląda na to, że należy podzielić aplikację na dwie bazy kodów, jeśli różne podmioty rzadko lub wcale nie muszą widzieć tego samego interfejsu. Wciąż oczywiście będą przesyłać zapytania do tej samej bazy danych.

Nie tylko rozwiąże to twoje problemy z auth, ale także znacznie ułatwi utrzymanie kodu. Na przykład, przesyłając aktualizacje do konsoli administracyjnej, wystarczy umieścić tę aplikację w trybie konserwacji, zachowując jednocześnie (prawdopodobnie) bardziej krytyczną nakładkę.

+0

To naprawdę bardzo dobry punkt.Odrzuciliśmy pomysł dzielenia tych baz kodów, ponieważ korzyści są przeważają w wyniku obaw w naszym przypadku. Jednak punkt dotyczący odrębnych trybów konserwacji może przechylić skalę. –