IH
через соц сети
Size: a a a
2020 February 13
AH
Вот я хочу сделать онлайн школу. У меня будут Учителя Студенты Менеджера и Администраторы. Связи между разными ролями свои. Я решил их сделать отдельными таблицами, так как каждый имеет свои фунции. Не разумно как по мне их всех держать в таблице Юзер . Или я ошибаюсь
На мой взгляд роли для этого и придуманы
IH
нам для каждого свои поля и связи с дургими сущностями
IH
если мне нужно что бы студент был счвязан с учителем и методистом и менеджеров
ЕК
Мне нравится следующая система
Для каждой сущности, те же заказы, есть права: просмотр, создание, удаление.
Есть роли, включающие в себя эти права. Я предпочитаю простые роли, содержащие одно право, но кто-то делает, например, роль, содержащую чтение заказов и товаров, например.
Есть профили групп доступа, это набор ролей.
Есть группа доступа, расширяющая профиль. Человек имеет право на чтение заказов, но в группе можно ограничить по полю, например складу.
И в конце юзер имеет много групп доступа.
Сложно в реализации, но зато оче гибко
Для каждой сущности, те же заказы, есть права: просмотр, создание, удаление.
Есть роли, включающие в себя эти права. Я предпочитаю простые роли, содержащие одно право, но кто-то делает, например, роль, содержащую чтение заказов и товаров, например.
Есть профили групп доступа, это набор ролей.
Есть группа доступа, расширяющая профиль. Человек имеет право на чтение заказов, но в группе можно ограничить по полю, например складу.
И в конце юзер имеет много групп доступа.
Сложно в реализации, но зато оче гибко
И
Мне нравится следующая система
Для каждой сущности, те же заказы, есть права: просмотр, создание, удаление.
Есть роли, включающие в себя эти права. Я предпочитаю простые роли, содержащие одно право, но кто-то делает, например, роль, содержащую чтение заказов и товаров, например.
Есть профили групп доступа, это набор ролей.
Есть группа доступа, расширяющая профиль. Человек имеет право на чтение заказов, но в группе можно ограничить по полю, например складу.
И в конце юзер имеет много групп доступа.
Сложно в реализации, но зато оче гибко
Для каждой сущности, те же заказы, есть права: просмотр, создание, удаление.
Есть роли, включающие в себя эти права. Я предпочитаю простые роли, содержащие одно право, но кто-то делает, например, роль, содержащую чтение заказов и товаров, например.
Есть профили групп доступа, это набор ролей.
Есть группа доступа, расширяющая профиль. Человек имеет право на чтение заказов, но в группе можно ограничить по полю, например складу.
И в конце юзер имеет много групп доступа.
Сложно в реализации, но зато оче гибко
Мне кажется ты описал классический RBAC. Роли и разрешения (пермишены)
E
И с внешними ключами приятнее работать
this
ЕК
Мне кажется ты описал классический RBAC. Роли и разрешения (пермишены)
Возможно, надо почитать)
И
Возможно, надо почитать)
Википедию открой)
ЕК
Я уже)
ЕК
ну как бы, да!
ЕК
Но тут есть ещё одна сущность, которая объединяет роли. Т.е. я сказал "менеджер — ето вот такой набор ролей" и сохранил его)
И
Но тут есть ещё одна сущность, которая объединяет роли. Т.е. я сказал "менеджер — ето вот такой набор ролей" и сохранил его)
Там так и есть. Можешь к роли привязать, можешь к id юзера
И
Но не ролей, а разрешений
ЕК
И ещё одна "Менеджеры имеют одинаковые наборы ролей, но этот менеджер видит только заказы магазина А, а этот — заказы магазина Б"
И
для разних таблиц
Вот. Уже костыли пошли...
IH
почему?
ИС
Вот. Уже костыли пошли...
Почему?
И
почему?
Залогиниться через соцсети может пользователь с любой ролью. А они у тебя по разным таблицам сидят.
Предлагаю, что общие методы нужно вынести в сервис, чтобы и там и там это дело логинить.
Предлагаю, что общие методы нужно вынести в сервис, чтобы и там и там это дело логинить.
ИС
У каждого наверняка своя логин форма
Для каждой роли будет отдельный гвард
Все красиво
Для каждой роли будет отдельный гвард
Все красиво