2013-09-24 3 views
5

Проект, над которым я сейчас работаю, разбивается на консоль администратора и обычный интерфейс. Оба фронта и бэкэнд находятся в одном экземпляре Laravel.Несколько сеансов Auth в Laravel 4

В интерфейсе я пытаюсь создать систему входа пользователя, которая работает исключительно для интерфейса. Он использует другую таблицу и модель, и у нее разные отношения, как и пользовательская модель для администратора.

Я не могу понять, как использовать класс Laravel Auth для обеих систем. Логически Auth использует один единственный файл конфигурации, и более точно, одно имя сеанса.

Одним из решений, которое было выдвинуто, является не использование другой таблицы и модели и использование какой-либо формы acl для разграничения. Но мне не нравится идея смешать интерфейс и бэкэнд таким образом. Тем более, что это означало бы, что мне вдруг пришлось бы дать администратору User model все поля и отношения, ранее уникальные для внешнего пользователя.

Это не похоже на правильный путь. Я мог бы переключиться на другую систему аутентификации или разделить администратор на пакет со своими собственными настройками, но область действия проекта не позволяет таких временных изменений.

Я бы приветствовал любую идею, которую вы могли бы предоставить.

+1

это может быть helful http://stackoverflow.com/questions/18785754/laravel-4-need-to-auth-with-2-different-tables – cyvvilek

ответ

5

Это проблема, с которой я столкнулся в последнее время тоже. Вся отдельная среда была не очень простой, особенно если у вас уже есть среда разработки и производства.

Однако я потратил некоторое время на создание пакета для решения этой проблемы, который вы можете найти на https://github.com/ollieread/multiauth. Сам пакет по существу завод класс для аутентификации, что позволяет использовать несколько экземпляры этого, поэтому доступ к нему так:

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

Я надеюсь, что пакет поможет вам или кому-либо еще ищет такой подход.

2

Я не уверен, но, возможно, это полезно. Почему бы не попытаться создать отдельную среду для администратора. И тогда у вас будет что-то вроде app/config/admin/session.php и app/config/session.php для производства (это среда по умолчанию).

Здесь можно увидеть, как настроить окружение http://andrewelkins.com/programming/php/how-to-set-laravel-4-environments/

Но, как я сказал, что это просто идея, я не совсем уверен в этом :)

+0

Среды, очевидно, путь здесь. Установите admin.yoursite.com и соответствующим образом измените файлы конфигурации. Это предполагает, что вы не добавляете пользовательские методы в свой пользовательский класс, которые зависят от роли. – Makita

1

Похоже, вы должны рассмотреть возможность разбивки приложения на два кодовых раздела, если разные пользовательские объекты редко или никогда не должны видеть один и тот же интерфейс. Очевидно, они все равно будут запрашивать одну и ту же базу данных.

Это не только решит ваши проблемы с автоответчиком, но и упростит обслуживание кода. Например, при нажатии обновлений на консоль администратора вам нужно будет только добавить это приложение в режим обслуживания, сохранив (предположительно) более критический интерфейс и работая.

+0

Это на самом деле очень хороший момент.Мы отклонили идею разделения этих кодовых баз, потому что преимущества перевешиваются опасениями в нашем случае. Тем не менее, точка в отдельных режимах обслуживания может опрокинуть весы. –

Смежные вопросы