Как лучше всего реализовать подобную архитектуру?

Question

[muhasa]

Здравствуйте.
Размышляю о том, как лучше реализовать следующую архитектуру (ранее проекты не имели столько разных ролей)
В качестве фреймворка хочу использовать Laravel.
У нас есть в системе админ, модератор, куратор и клиент.
Модератор тот же админ с меньшим количеством прав
Куратор следит за успехами клиента в обучении.

У клиента свои атрибуты (например, где учился и т.д.), у куратора свои (достижения и прочее, чего нет у клиента)
Само собой возникает вопрос, как лучше архитектурно это реализовать?
Сделать несколько моделей - (Client, Curator, Moderator, Admin) и у каждого своя таблица с данными, само собой при авторизации нужно будет обращаться к разным таблицам с поиском логина и пароля. Но преимущество в том, что атрибуты не перемешаются.
Второй вариант - модель User и уже в зависимости от роли связь 1 к 1 с таблицей, имеющие дополнительные атрибуты.
Фактически, таким образом у нас при запросах будет использоваться 1 модель.

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

P.S. Еще момент - если реализовывать по первому формату с 4 моделями, то как сделать единую авторизацию для всех в рамках стандартной аутентификации Ларавела?..

Comments

[Дмитрий]

делайте второй вариант, ну или сделайте какую нибудь базовую модель, где логин и прочее и расширяйте ролями

[xmoonlight]

Дмитрий, делайте уже хоть что-то! ДА!?)

[Дмитрий]

xmoonlight, не понял, ну тут минимум два варианта можно реализовать

Answer 1

[xmoonlight]

Роли - это множества (точнее - "деревья" множеств), содержащие пользователей.

Расписываю подробно на примере:
Есть пользователь User1, у него роль Admin и роль Curator.
Т.е. он имеет в своём личном кабинете 2 пункта меню: Администрирование и Курирование.
Всё что в базе - привязывается только через ID-шник этого пользователя (роли и поля ролей, и т.п.).

Comments

[muhasa]

не очень понятно

[muhasa]

Да, с ролями авторизации примерно понятно.
Выходит, 1 таблица users, там общая логика и таблица, в которой атрибуты этих пользователей (у куратора свои, у клиента свои и т.д., верно?)

[xmoonlight]

muhasa, нет, не верно!
У таблицы users - минимальный унифицированный набор (id, логин, парольный хэш, "соль", ФИО) и всё на этом!
А уже в таблицах ролей - там линковка (к нужному юзеру) и доп. поля, необходимые для этой роли.

[muhasa]

примерно это я имел ввиду, но сформулировал свою мысль так, что сам не понял, когда перечитал :(

[xmoonlight]

muhasa, бывает...

[muhasa]

xmoonlight, с Вашего разрешения подытожу:
4 таблицы
roles
users
role_user
user_profile

И 3 модели, User и Role многие ко многим, User и UserProfile один к одному

[xmoonlight]

muhasa, ну, если удобнее User на две таблицы разнести (кроме удобства - тут не вижу смысла), тогда всё ОК вроде..

[muhasa]

Ну а как по-другому? У куратора есть атрибуты, которых нет у клиента, например, образование, опыт работы, специализация и т.д.
Или лучше эти данные загнать в Json-поле?

[xmoonlight]

muhasa, я не про роли, а про users и user_profile

Answer 2

[ThunderCat]

емнип в ларавеле уже есть готовый RBAC. Или можно открутить от симфони/зенда.
По теме - естественно никаких дополнительных сущностей корме юзера не нужно, они отличаются только связанным свойством роли.

Comments

[JhaoDa]

емнип в ларавеле уже есть готовый RBAC

Нету.

[ThunderCat]

JhaoDa, да, уже глянул, но есть вполне годная статья на хабре, где обсмотернны с десяток разных решений под лару - тыц.

[Златослав Десятников]

ThunderCat, решения под Лару и «в ларе» — две разные вещи.

Answer 3

[Руслан .]

По идее пользователи - отдельно, роли - отдельно.
И один пользователь может иметь несколько ролей, т.е. между пользователями и ролями д.б. таблица связи.
И связи один ко многим.

Итого имеем три таблицы: пользователи, роли, связи.

Comments

[muhasa]

пожалуй, когда двое отвечающих в один голос предлагают оную схему, надо ее брать и активно пробовать!

[Владимир Дементьев]

muhasa, да верно. Я однажды после долгих экспериментов именно к такой схеме и пришёл в своём проектике. А потом понял, это распространённая практика разделения прав.

Answer 4

[Дмитрий]

Сейчас делаю проект с аналогичной структурой.
Путем проб и нескольких ошибок :) выяснил, что лучше всего делать так:
1. Все поля всех ролей сваливаются в одну таблицу (одинаковые поля не дублируются) и делаются nullable
а) либо в users (получается немного неряшливо);
б) либо в profiles (отношение 1к1 с users), просто чтобы отделить котлеты от мух.
2. В исходниках проверяются НЕ РОЛИ, а разрешения, причем на каждое свойство профиля (учеба, достижения) - свое разрешение.
Это позволит вам в любой момент добавить разрешение, например, на "достижения" в роль клиенту и у него появятся соответствующие элементы форм, вьюх и т.д.

Здесь тоже есть одна тонкость: если роль администратора позволяет ему редактировать чужие профили, то желательно показывать ему только те поля, которые разрешены конкретному пользователю (которого редактирует администратор). Это не является проблемой, если ваш модуль RBAC позволяет навешивать колбэки на проверку разрешений.
Вот модуль с колбэками собственного производства: h-rbac
И статья о нем: Laravel 5. Иерархический RBAC для самых маленьких