2013-09-07 4 views
7

Я создаю приложение Laravel 4, для которого требуется аутентификация для 3 типов сущностей: Coach, Student & Admin, все с отдельными пользовательскими интерфейсами. Хотя я мог использовать пакет, такой как Sentry 2, и одну таблицу пользователей БД с пользовательскими типами для достижения этого, что-то о потенциальных шаблонах проектирования полиморфных БД и головных болях, которые могут произойти по дорожке, не подходят мне. Рассмотрев полиморфные проблемы в прошлом с предыдущими приложениями и горе, которое он может создать, когда вы хотите нормализовать структуру БД и т. Д., Имеющие отдельные таблицы БД для каждого типа сущности, кажется лучшим способом.Laravel 4 Многопользовательская аутентификация

Как бы вы решили эту проблему дизайна?

Laravel 4 аутентификации использует в основном следующие файлы:

  • auth.php (фасад)
  • AuthManager.php
  • AuthServiceProvider.php
  • Guard.php
  • auth.php (config)
  • User.php (эколокт-модель)

Я играл с дублированием этих файлов, чтобы создать в основном независимый auth для объекта-тренера, который работает, регистрируя фасад и поставщика услуг в файле app.php, а также внося необходимые изменения в config для использовать тренер красноречивую модель для аутентификации:

  • AuthCoach.php (фасад)
  • AuthCoachManager.php
  • AuthCoachServiceProvider.php
  • Guard.php
  • authcoach.php (конфигурация)
  • Coach.php (красноречивая модель)

Я до сих пор использую Guard.php от стандартного Laravel 4 AUTH, но Guard может быть легко расширена, если возникает необходимость настроить методы Guard для аутентификации тренера путем создания Файл GuardCoach.php.

Если у меня будет отдельный auth для каждого типа сущности, вы думаете, что это хороший способ достичь этого?

Вы видите потенциальные проблемы или знаете лучший способ сделать это?

+0

Я ответил здесь подобный вопрос: http://stackoverflow.com/questions/18785754/laravel-4-need-to-auth-with -2-different-tables/19139889 # 19139889 Не уверен, что это поможет ... – Xethron

+0

Вы когда-нибудь решали это? – ollieread

ответ

3

Возможно, я плохо понимаю ваш контекст, но почему вы просто не используете базовую концепцию управления доступом на основе ролей и не создаете разные вещи для разных ролей? Если это недостаточно сложно, вы можете использовать политики аутентификации на основе атрибутов для грануляции разрешений. Каковы причины, по которым вы хотите дублировать (трижды это) auth-logic? Не упоминание факта избыточных данных db (отдельная таблица пользователей для отдельного типа пользователя? Yuk!)?

Если вы не удовлетворены Sentry (лично я не использую эту библиотеку), я могу порекомендовать Zizaco/Confide + Zizaco/Entrust как чистое и элегантное решение для управления правами пользователя/роли/разрешения. Посмотрите здесь Zizaco GitHub.

Беглый общая идея:

  • использовать один чистый механизм аутентификации для всего приложения
  • гранулят доступа с ролями или роли + Права доступа
  • отделить администратора логики в отдельные контроллеры (AdminUserController, AdminCoachController, что угодно ..)
  • Я не вижу трудностей с составлением соответствующей структуры шаблонов лезвий, чтобы все было хорошо сделано и хорошо организовано

Каковы ваши полиморфные проблемы?

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

Надеюсь, это поможет вам, если бы я хорошо понял вашу проблему.

3

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

Вот как я столкнулся с той же проблемой:

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

  • Я использовал Sentry 2, который позволяет легко управлять средствами аутентификации.

  • Использование миграции по умолчанию, предоставляемой Sentry 2, я добавил роль столбца в таблицу «пользователей», которая отличает 3 типа пользователей.

  • Для каждого типа пользователя я создал таблицу с определенными полями.

  • Когда пользователь аутентифицировался, я бы взял свою «роль» из таблицы «пользователей», запустил несколько операторов if и знал, какой вид их обслуживать.

И комар был полностью мертв.

Onto твое:

  • В принципе, обе наши подходы совпадают - так как каждый тип пользователя имеет отдельную таблицу для полей они не все доли (за исключением имени, последний имя, адрес электронной почты, пароль, последний вход и т. д.).

  • Ваш подход позволит пользователю принадлежать к трем объектам, что логически неверно. Мой не будет - что логически ...

  • Вы боитесь «полиморфных проблем», но я не думаю, что нам с этим нужно иметь дело. Все, что мы могли бы сделать, это определить в наших моделях, что тренер, например, belongsTo пользователь. И пользователь hasOne тренер.

  • Но на самом деле нам даже не нужно определять отношения. Потому что при аутентификации нам нужно запускать операторы if. Таким образом, используя пользовательский объект, возвращенный из проверки подлинности, мы узнаем две вещи: какую таблицу затем перейдите к пользовательской информации типа, и какой вид служит для аутентифицированного пользователя.

Не бойся, сын

+0

Какой идентификатор вы могли бы использовать в качестве FK (внешний ключ) для каждого типа пользователя в остальной части БД? Идентификатор таблицы авторизации или идентификатор таблицы конкретного пользователя? – Ben

+0

Я бы использовал идентификатор пользователя, потому что знаю, что он уникален для каждого пользователя. Если вы используете идентификатор типа пользователя, он не будет уникальным, так как каждый пользовательский тип имеет отдельную таблицу (тренер, студент, администратор). Вам не нужно беспокоиться о трех таблицах, имеющих внешние ключи, поскольку они только дополняют таблицу пользователей. Таблица пользователей - это «босс». – kJamesy

+0

Хорошо круто. Так что, учитывая эту схему, если у вас есть таблица уроков, как бы вы записывали, какой тренер и ученик имеет отношение к уроку, учитывая, что оба типа пользователей имеют FK user_id? Здесь также может работать один идентификатор отношения, имеющий таблицу user_parent_child (id, parent_id (coach user_id), child_id (student user_id)) и запись user_parent_child_id в качестве FK в таблице уроков. Это кажется действительно грязным, хотя. – Ben

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