Реализация групп, ролей и прав пользователей в laravel, есть ли такое решение?
Добрый день!
Подскажите пожалуйста, гуглил, не нашел ничего подобного готового.
Необходимо чтобы у пользователя была группа, тогда он может перейти по определенному роуту.
(Роут пропускает только 1 группу, в свою очередь пользователь может иметь членство в нескольких группах)
Далее необходимо чтобы у пользователя была роль по которой будет определено, что будет отображено на странице. Даже этого уже будет достаточно.
Примерная схема
User - id, name, password
1, Petya, qwe
2, Vasya, ewq
3, Kolya, qaz
И получается, что пользователь Petya может перейти на Worker и на Warmir, на Worker он будет Admin, а на Warmir он не имеет роли
Дополню:
Привязка прав к роли не нужна:
User -> hasToMany(Role)
Role -> hasToMany(permission)
Или
User -> hasToMany(Group)
Group -> hasToMany(Role)
НЕОБХОДИМО ВОТ ТАК:
User -> hasToMany(Group)
User ->hasToMany(Role)
Group -> hasToMany(Role)
Вот только не понимаю зачем вам группы... Есть разрешение посещать страницу - посещает, есть разрешение видеть на этой странице что-то специфическое - видит. По-моему разрешений и ролей достаточно.
Начал читать, сразу подумал не то, что мне нужно, там было, что у роли есть права, а у пользователя есть роль.
Потом чуть ниже прочитал, что у пользователя может быть право независимо от роли и роль независимо от права, сначала подумал, во точно то, что мне нужно!
Но сейчас я понимаю, что мне нужен другой вариант.
У пользователя есть роль и несколько прав, но только для этой роли, а если у него есть ещё одна роль, то у него другие права и получается у другого пользователя может быть та же роль что у первого, но с другими правами
Отталкиваюсь от терминов, которые предложены в документации
Возможно, я не вижу способа, как бы я мог этим воспользоваться.
Например у User1 и User2 роль Role1
А права разные именно для User то получается, что в роутах я пишу, что пропустить по роли, а потом или в контроллере или в blade использую права, но тогда получается, что если мне нужна будет роль для другого пользователя совпадающия с правами первого пользователя то пользователь 1 сможет пройти на Role2 и его права защитаются, а мне как раз надо так, чтобы было так role2.право1 role2.право2, role1.право1
ettychel, роль и право это отдельные сущности вы можете их комбинировать как хотите. Пользователь1 = Права1,2,3
Пользователь 2 - Права 4,5,6 и т.п - тоже и с ролями, комбинируйте как хотите
JhaoDa, суть на самом деле такая, что все варианты, которые были предложены будут работать, только если я создам куча ролей с именем в котором будет префикс роли, но идентификатор будет разный, а неплохо иметь роль как префикс и тогда роль1. Право1 будет означать не тоже самое, что роль2.право1, (таблицы через точку)
Итоговый вариант получится такой
Сколько сервисов, столько ролей, а прав всегда одинаково
Это было бы просто, если бы пользователь не мог иметь несколько ролей
А так как сервисов планируется сотни, то вариант с префиксами очень плох, вероятность ошибки очень сильно возрастает
Станислав, пожалуйста прочтите мой следующий комментарий, вроде я там постарался объяснить, что в итоге хочу получить, если мы с вами говорим об одном и том же, то я видимо совсем ничего не понимаю под конец рабочего дня
jazzus, вот смотри что я пытаюсь объяснить
у нас есть 2 страницы
есть 4 пользователя
1 пользователь может смотреть и редактировать 1 страницу и может только смотреть 2 страницу
2 пользователь может смотреть и редактировать 2 страницу и может только смотреть 1 страницу
3 пользователь может смотреть и редактировать обе страницы
4 может только смотреть эти страницы
Теперь вопрос, как это организовать?
Надеюсь теперь понятно объяснил
И я не хочу назвать право как: редактировать 2 страницу
Редактировать 1 страницу
Смотреть 1 страницу
Смотреть 2 страницу
А это должно быть в группе:
Группа 1 имеет доступ к 1 странице
Группа 2 имеет доступ ко 2 странице
А у пользователя может быть право редактировать либо первую страницу, либо вторую, что обозначено для него как право в той или иной группе
Абстрагируйся от ролей, прав и всего остального, можно назвать и группой и правом и ролью, суть цели не изменится
А вот поисковой запрос изменится, вот и прошу направить на путь истинный, который поможет сделать то, что задумал
Нашел самый лучший пример, который точно даст понять что я имею ввиду и чего хочу добиться!
Группы ВК
В одной группе я Админ, в другой Модератор, в третьей Пользователь
это мои права и они стандартно уже все прописаны 1 раз для всех группы, ты просто будучи админом переходишь в настройки группы и назначаешь права в ней, но эти права не распространяются на другие группы. Вот как это сделать? думаю схема будет той же, что мне нужна
ettychel, группа 1 имеет доступ к 1 странице через право доступа к этой странице. Я модули не использую, но скорее всего перечисленные в ответах модули позволят назначать права ролям (группам) и пользователям
ettychel, Как я понимаю необходимо связывать конкретные роуты с ролями конкретного пользователя с конкретной ролью, правильно? К примеру:
- Роут /one/ доступен для чтения роли User, доступен для редактирования роли Admin
- Роут /two/ тоже доступен для чтения роли User, доступен для редактирования роли Admin
- Пользователь John имеет роль User для роута /one/, но для роута /two/ он уже может иметь роль Admin
Я правильно понял? Если да, то вам всего лишь нужен маппинг роутов и ролей для них для каждого юзера. Разумнее всего запилить дефолтную роль User которая будет покрывать базовые права для всех роутов, а дополнительные разрешения маппить только там где надо.
Игорь Воротнёв, в точку, только пользователей у меня 12000 и сервисов около 100, поэтому и ручками на каждом сервисе прописывать не охота, к тому же нужна возможность из админки, через обычные чек боксы к примеру, добавлять и убирать права, ну и группы соответственно, в этом вся и проблема, а вот маппинг ща почитаю
И ещё забыл 5 пользователь вообще может не иметь доступа к роуту /one/ а к роуту /two/ прошу пожалуйста просматривайте
ettychel, Ну, частично хотя бы ручками придется прописывать, без вариантов. А дальше смотреть что можно сделать в форме mass assignment. Смысл в том, чтобы определить наборы ролей и прав, потом определить базовую роль/права, которая будет применяться к подавляющему большинству юзеров и роутов/ресурсов. Это можно назначить массово, программно. А дальше уже делать маппинг для конкретных юзеров - понижать или повышать роль/права для каждого роута/ресурса где они должны отличаться от дефолтных. Таким образом у каждого юзера будет маппинг, но он будет содержать не все роуты/ресурсы, а только те где у него права отличные от дефолтных. Хз, может кто-то предложит более эффективную реализацию. Самому интересно послушать.
Игорь Воротнёв, мой вариант такой
роль - как доступ к роуту
право - состоит из префикса от названия роли и плюс право
в итоге в админке даём роль, а права вытаскиваем по маске в поле slug роль_* ну и добавляем права пользователю, в title права можно вписать статичные admin, moder, autor и т.д., а в slug уже будет с префиксом, но в итоге мракобесие в таблице с правами, феншюем там увы не пахнет(((
Игорь Воротнёв,
Ну как то так уже будет админ панель
синим выделил типо как курсор с чем идёт редактирование
Членство в группе = доступ к роуту и я понимаю, как это проверять через роуты, там нет сложности, но вот права в каждом роуте у пользователя свои
Если что на картинке просто набросок))
в итоге в админке даём роль, а права вытаскиваем по маске в поле slug роль_* ну и добавляем права пользователю, в title права можно вписать статичные admin, moder, autor и т.д., а в slug уже будет с префиксом,
Тут вы меня потеряли... Какое-то усложнение в кубе...
но в итоге мракобесие в таблице с правами, феншюем там увы не пахнет(((
Ну, с таким подходом как выше - не удивительно. Я бы таблицу прав делал thin and long - id, user_id, resource_id (или route), permissions (которые отличны от дефолтных). С нужными индексами на ваших объемах будет прекрасно работать. Удобство работы - можно сразу получить права конкретного юзера для конкретного роута/ресурса. Или вообще при авторизации по его ID (user_id) берем все строки с его user_id из таблицы и кешируем в redis/memcached.
В общем, я так и не смог понять что именно вам так тяжело дается в логике ACL.
Игорь Воротнёв, та не, норм, сделал сегодня утром, прекрасно выбираю права, сразу понятно с каким сервисом работаю, очень даже неплохо получилось)) считаю вопрос закрытым, но всё же без решения первоначального вопроса, 3 прослойки нужно всё таки
Сначала прочитал, где описано, что можно использовать одни и те же роли, но с разными правами для каждого пользователя, т.е. то что мне надо, а потом пример в конце что то вообще не понятный
Игорь Воротнёв, Нашел самый лучший пример, который точно даст понять что я имею ввиду и чего хочу добиться!
Группы ВК
В одной группе я Админ, в другой Модератор, в третьей Пользователь
это мои права и они стандартно уже все прописаны 1 раз для всех группы, ты просто будучи админом переходишь в настройки группы и назначаешь права в ней, но эти права не распространяются на другие группы. Вот как это сделать? думаю схема будет той же, что мне нужна
Может есть в опыте что то подобное?
ettychel, ну так это и есть механизм ACL. Мне кажется вы матчасть решили пропустить и сразу в бой - код писать. Изучите вопрос с теоретической стороны, и все встанет на свои места.
Средний
