Как правильно использовать RBAC с разными моделями?
Доброго времени суток! Имеется проект, используется шаблон advanced. В backend авторизация проходит по таблице employee, во frontend авторизация по customers. Допустим, сейчас я делаю RBAC на основе employee и делаю там роли manager и admin. Но, если заказчику приспичит добавить роли и клиентам, то как можно будет выбраться из этой ситуации?
Yii использую недавно (около полугода) и с rbac до этого не работал, но если я правильно понял из документации, то из коробки нельзя организовать хранение роли в каждой из таблиц, например в employee - role = admin || manager. Там или в файлах хранится, или в бд. Помогите разобраться, меня прям в ступор вводит rbac.
Хранилище RBAC - PHP или DB, но в их собственных таблицах (не customers и не employee)
Permissions - для каждой сущности по create, view, edit, delete.
Roles - admin, manager, customer (это не таблицы, а просто имена)
User-Role - можно хардкодом сопоставить. Или всем юзерам назначить все роли в default roles, но для каждой role сделать rule, возвращающую true/false после проверки по вашим таблицам customers или employee)
Максим, я правда не вижу в этом решения. Я написал, что для backend и frontend используются разные таблицы. Мне предлагают сделать users, но я не могу совместить клиентов и администратора в одну таблицу.
bezdealnick что такое frontend и backend? Это по сути одна система(подсистема) с разным UI интерфейсами работающая с одними и теми же данными. Судя по всему у вас какая-то CRM. Поэтому, вас не должны смущать разные приложения.
Мне предлагают сделать users, но я не могу совместить клиентов и администратора в одну таблицу.
С точки здравого смысла да, не можете. Вам никто и не предлагает это сделать. Вам предлагают следовать правилу SOLID. Так как сотрудники у вас имеют две функции: отвечать за аутентификацию и существовать в системе, то логично, что клиенты не могут быть сотрудниками с разделением по роли. Поэтому у вас несколько вариантов:
1. Логин, пароль, роль, приватный ключ... вынести в таблицу users. А employees имеет связь с user по id. Так же как и customer имеет связь с user по id.
В итоге у вас клиентская информация хранится в customer, информация о сотрудниках в employees, а логин и пароль в users.
2. Переименовать таблицу employees в users.
3. Оставить все как есть и использовать employees как users. Вариант подходит только для самых отбитых)
Ваша таблица employee не может быть базовой для пользователей. Пользователи != сотрудники. Сотрудник может существовать без логина и пароля. Клиент может существовать без логина и пароля.
В вашем случае проще создавать таблицу users и роли создавать там. В этой таблице хранить информацию об аутентификации. Придётся часть данных из Employee перенести в User. Можно переименовать таблицу employees в users и добавить роли. Но тут уже вам решать как лучше. С точки зрения системы хранить все три сущности раздельно хорошая практика.
То что вы выбрали employees как пользователей не совсем верно. Если у вас только сотрудники и все сотрудники пользуются системой, то такой вариант может подойти. Но, как правило, сотрудники могут существовать и без логина и пароля.
bezdealnick, просто забегая вперёд может случиться история того, когда вам потребуется создать сотрудника без логина и пароля. Тут вы вспомните мои слова. Если же сотрудники всегда с логином и паролем, то можете переименовать таблицу сотрудников в пользователи. Ну или оставить так, а разделять клиентов в таблице сотрудников по роли. Что не очень, конечно логично. В любом случае для системы лучше все три таблицы.
Максим, ну не может быть сотрудник без логина и пароля) Я никогда не встречался с сайтами, где администраторы входили на сайт без пароля. Да и просто моделью я не дам создать кого-то без пароля или логина.
Но даже если я переименую таблицу в users, то разве это поменяет суть? Ведь клиенты то все равно будут хранится в другой таблице.
bezdealnick, глупости вы говорите. Я вижу вы большой знаток всех в мире систем)
1. Вы этого могли и не заметить.
2. Да, сотрудники которые являются пользователями системы имеют логин и пароль. Логично. Но есть сотрудники которые не пользуются системой, но нужны для работы системы.
Например: доставщик, уборщица, дворник. И так далее. Зачем им пользоваться нашей системой? При этом мы можем их как-то использовать в нашей системе. Уборщица и дворник могут фигурировать в графике работ, в расчёте зарплаты и так далее. Но им логин и пароль не нужен.
bezdealnick, клиенты будут иметь логин и пароль в users, а данные о клиенте будут храниться в customers. customersбудет иметь связь с user по user_id по которому клиент получает доступ в систему и связывает логин пароль с клиента.
Максим, и я не писал, что я знаток всех в мире систем. Я написал, что я не встречался с такими сайтами. Вы любитель поязвить в ответах не по делу, видимо.
bezdealnick, ваши администраторы и менеджеры ОБА являются ПОЛЬЗОВАТЕЛЯМИ. Я вам привёл пример, когда сотрудники могут быть в таблице employees, но не иметь логина и пароля.
bezdealnick, вам написали два человека с полным разъяснением и вы до сих пор стоите на своём. Ваша ситуация простая для всех кроме вас. И дело не в том, что кто-то язвит. Я вам все пояснил. Если не доходит - есть вариант перечитать и погуглить. Если найдёте какой-то особый вариант, который вам не предложили, то считайте себя либо гением, либо очередным человеком, который изобрёл костыль.
Подсказка на будущее... Правильный вариант это только три таблицы.
Максим, причем тут гений я или нет...
Есть таблица customers из бд какой-то системы локальной под виндой, там 270к клиентов. Она перенесена в mysql и по ней люди авторизуются во front. Даже если я переименую employee в users, разве это для меня что-то поменяет, если заказчику приспичит сделать роли и для их клиентов?
bezdealnick, для единой системы вам логично иметь логин и пароль в users.
Если у вас есть в employees и в customers свои логины/пароли и вы не хотите их объединить в одной users, то можете пойти противоположным путём. И использовать два приложения как независимые со своими логинами и паролями в каждом.
В backend пользователи employees, во frontend customers. Тогда вам придётся делать два Rbac и не будет единого пользователя и единых прав доступа между этими приложениями. Они будут автономны.
В таком случае роли помещайте в каждой из этих таблиц. Для customers у вас будут свои 4 таблицы от rbac, а для employees 4 таблицы от rbac.
Максим, сейчас прочел ваше сообщение и понимаю, что вы не поняли о чем идет речь в вопросе. И как раз описали то, что мне нужно во втором абзаце. frontend и backend разные приложения, имеющие только общие классы и бд, не более. Сотрудники не могут авторизоваться во frontend, а клиенты могут и соответственно наоборот. Никаких единых прав доступа и не нужно между backend и frontend, нигде об этом я не писал. Права в backend - admin и manager, во frontend прав нет.
Вопрос как раз и состоит в том, что если заказчику приспичит добавить роли клиентам, то мне нужно будет дополнительно заводить rbac таблицы в дб, вместо добавления в существующие?
Я то вас как раз понял. Это вы не поняли ни меня, ни другой ответ.
Вопрос как раз и состоит в том, что если заказчику приспичит добавить роли клиентам, то мне нужно будет дополнительно заводить rbac таблицы в дб, вместо добавления в существующие?
Об этом и речь!)) А если заказчику приспичит и там и там ввести двухтактную авторизацию - вам придётся делать её в обоих местах. А если заказчику понадобиться сделать возможность логиниться под Различными сом сетями - вам опять придётся делать это в двух приложениях ну так далее по списку.
Если с rbac ещё можно пойти так, так как это будет разделение ответственностей, то двухфакторная авторизация не относится ни к клиентам, ни к сотрудникам. У вас в приложении будет:
Rbac может быть общий, может быть помещён в Auth, а может быть на каждую независимую часть приложения свой. И это не обязательно может быть Yii Rbac.
Это у вас сейчас система из двух приложений. Вам просто сделать и там и там. А если у вас завтра появится какой-нибудь склад, потом приложение lk потом вообще мобильное приложение. Как ты будете это связывать? Что в каждое приложение будете дублировать логику? Или будете из frontent брать одно из backend другое?
Я вам говорю, что ваш способ это единая таблица User. А если сомневаетесь, то вот вам целый сервис, который отвечает за пользователей. И теперь посмотрите готовы ли такую логику в будущем при необходимости помещать к каждой сущности.
Максим, сделал как вы посоветовали, user - таблица хранящая id и hash для авторизации, employee и customer хранящие свои данные. Но есть проблема в том, что для авторизации администратор использует login - которого нет у клиента, клиенты для авторизации используют id, который берется из уже существующей таблицы с 270к записями. И я в любом случае упираюсь в то, что если делаю, например мобильное приложение или склад, то логику буду дублировать. Я правильно понимаю?
Таблица auth_users имеет не только id и хэш. Она так же имеет логин и пароль. Или другие данные для аутенфикации.
- id
- login
- password
- status
....
В таблице crm_employees
- id
- user_id
- name
- gender
...
В таблице crm_clients
- id
- user_id
- name
- passport
- gender
....
Максим, и мне нужно заполнять auth_users всеми лишними id по которым авторизуются клиенты даже тем, кому они не нужны, получается? Администраторам, например. Потому что по id своей таблицы auth_users, я не могу проводить, слишком большое различие. Если по passport клиенту проводить авторизацию, то его переносим тоже в auth_users, даже если он не нужен другим категориям пользователей?
bezdealnick, в auth_users у вас хранится только те, кто пользуются системой. Если у кого-то ещё нет данных, то он регистрируется или регистрируете его вы.
Подозреваю вы меня не поняли видимо. Auth Users это единая система для авторизации.
Все остальное это информационные таблицы для работы системы.
Авторизовывать клиента по паспорту очень странно) Как минимум это персональные данные.
Максим, да нет, это вы меня не поняли, возможно. Уже не знаю как объяснить, чтобы все поняли, что мне нужно от yii :(
Для всех 270к обязательно должны быть сгенерированы логины и пароли и без разницы будут они пользоваться сайтом или нет.
Авторизация у клиентов происходит посредством id (номер договора), которые не совпадают с моими id в auth_users. Мне номер договора нужно указывать в auth_users или все-таки в crm_clients? И тоже самое с логинами, которыми авторизуется администраторы. Мне логин добавлять в auth_users или crm_employees? Клиентам букво-циферный логин при этом не нужен, но администраторам не нужен номер договора.
Паспорт, я привел вам как пример того, что для авторизации могут использоваться разные данные для клиентов и администраторов.
bezdealnick, причем тут Yii если вы сами не можете разобраться как организовать данные?
Для всех 270к
зачем мне эта информация? Вы постоянно о ней говорите. 7, 70 270к, миллион. На архитектуру таблиц это не особо как влияет.
обязательно должны быть сгенерированы логины и пароли и без разницы будут они пользоваться сайтом или нет.
Зачем генерировать всем тем, кто не будет пользоваться? Глупо. К тому же сгенерированные данные и введенные пользователем куда приятнее. Пользователь сам может решить какой у него будет логин и пароль, а ваша задача связать данные ему в личный кабинет из CRM
Мне номер договора нужно указывать в auth_users или все-таки в crm_clients?
и там и там, если вы хотите авторизовывать клиента несколькими способами: логин, договор, нетворки и так далее. AUTH это все что касается Аутентификации. Если для Аутентификации вы используете email, то где этот email вам указывать? и там и там. Если используете Аутентификацию по phone то где указывать телефон? И там и там. При авторизации у вас будет три поля: метод Аутентификации, логин (телефон, договор, email), пароль. Можно существовать и без метода аутенфикации, но придется искать по всем полям.
Мне логин добавлять в auth_users или crm_employees?
Ответьте себе на вопрос сами! Задайте вопрос - "Логин для чего нужен? Где используется?" Для аутентификации, в аутенфикации. Зачем вам в CRM логин клиета? Вам вообще не важно как он авторизуется. Это задача системы Auth. В CRM вам важно сколько он купил, какие у него контакты, контактов может быть много ну и так далее.
Клиентам букво-циферный логин при этом не нужен, но администраторам не нужен номер договора.
логин по идее нужен всем. Просто кто-то может его не использовать при авторизации, а кто-то может.
Зачем генерировать всем тем, кто не будет пользоваться? Глупо.
Сгенерировать надо для всех. Глупо или не глупо, дело не моё - это хотелки заказчика. Они собираются внести всех клиентов и разослать по смс номера договоров и пароли для входа.
В CRM вам важно сколько он купил, какие у него контакты, контактов может быть много ну и так далее.
Я не уверен что это crm, это просто личный кабинет для клиентов с информацией о текущем статусе их заявок (которые сейчас они узнают по телефону или в офисе) и тикетами. Не более.
Сгенерировать надо для всех. Глупо или не глупо, дело не моё - это хотелки заказчика. Они собираются внести всех клиентов и разослать по смс номера договоров и пароли для входа.
Теперь понял. Но все равно логичнее не всем рассылать, а обратился - выслал. А если он телефон уже давно не использует. А вы ему высылаете доступ. Или ребенку отдали на пользование. Но это дело Ваше)
Я не уверен что это crm, это просто личный кабинет для клиентов с информацией о текущем статусе их заявок (которые сейчас они узнают по телефону или в офисе) и тикетами. Не более.
А что это? Блог?
CRM - Customer Relationship Management - система управления взаимоотношениями с клиентами.
Средний
