Разработаваю сервис по доставке еды, сервис работает в разных городах, с разными ресторанами.
Есть следующая структура
Таблицы
Есть следующие типы пользователей
Администратор
Супервайзер
Принципал
Оператор
Клиент
Есть админка реализованная как модуль, в ней соответсвенно контроллеры и тд.
Необходимо разделить права, на редактирование некоторых функций, просмотр и тд.
Администратор может всё (добавлять города, кухни, пользователй любого типа)
Супервайзер может всё по городу.
Принципал может работать только со своей кухней и привязан к городу (может редактировать меню, смотреть заказы).
Оператор может работать с заказами по городу (может обрабатывать заказы).
Клинет доступа в админку вообще не имеет, и просто пользуется сервисом (создаёт заказы).
Посоветуйте по огранизации уровней доступа? Куда смотреть? в сторону RBAC ?
Я так понял лучше каждого пользователя сразу в базе привязывать к городу, ресторану. А как потом удобнее проверять показывать ли ему в меню какой нить раздел, ну и конечно саму возможность выполнить конкретное действие?
Создадите 5 ролей, задачи и операции, а потом в нужных местах достаточно будет вставить checkAccess(). Элементы авторизации лучше хранить в бд, а в админке сделать возможность присвоить тому или иному пользователю некоторую роль с соответствующими правами.
Но т.к. мне, например, в своем приложении надо было просто один раз задать роли и операции, а потом лишь сделать возможность назначить тому или иному пользователю стандартную роль, то большой необходимости в таком расширении не возникало
Единственное замечание в схеме БД. Они не очень готова к дальнейшему масштабированию. Если вдруг потом будут добавляться новые сущности, будет "пухнуть" таблица profiles. Если, масштабирование нужно, то стиот завести таблицу, которая будет глобально раздавать идентификаторы сущностями. В таком случае в profile держать FK вообще будет не нужно. Но при этом необходимо завести таблицу в которую будет помещаться id пользователя и id сущности в соотношении 1:M. Если дальнейшее расширение схемы не требуется, то можно оставить все как есть.
Да, это оно. Правда остался ещё один мелкий момент. У вас таблица пользователи и таблица профили сейчас судя по ERD связана в соотношении 1:M. Мне кажется что вы на самом деле хотели бы 1:1 . Поэтому можно смело убирать поле user_id из таблица профилей, а id делать одновременно FK и PK, убрав AUTOINCREMENT (если он есть). Ведь по логике 1 пользователь = 1 профиль.
Ну да, вы правы, на самом деле 1 пользователь 1 профиль. Я просто привык почти во всех таблицах делай первым полем id autoincrement PK. Здесь лучше его самому назначать.
