- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Золото, меха, бриллианты: как мы продвигали элитные товары и увеличили количество заказов в 30 раз
Сайт — нулевой, без трафика, в месяц — 29 посещений. Но кто сказал, что мы боимся трудностей
Сергей Шабуров

Вышла новая версия Telegram c 11-ю новыми фишками
Она уже доступна всем пользователям iOS
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Есть веб-приложение. Много юзверей, много разных видов объектов. Нужно проверять право юзверя совершать те или иные действия над объектом.
В общем-то такой сущности как "роли" по большому счету нет кроме роли "администратор" у которого есть права на все. Обычно юзверь имеет права доступа к "своим" объектам, а кроме того есть конкретные списки или правила, по которым есть права доступа к чужим объектам. Потому RBAC тулить вроде бы не очень обоснованно.
Вопрос состоит в том, в каком месте приложения лучше втулить код, который фактически проверяет право доступа. Вижу такие варианты.
1. В класс user:
user.has_permission(object, op_name);
2. В класс-контроллер объекта с которым производится действие:
object.has_permission(user, op_name);
3. Создать отдельный класс проверяющий права доступа, глобальный инстанс которого инициализируется по необходимости.
perm_controller.check_permission(object, user, op_name);
Вопрос к тем кто сталкивается с разработкой архитектуры приложений - как лучше?
Solmyr, сделать 3 вариантом, но правила расписать в других Voter классах, чтобы не раздувать этот глобальный инстанс методами, нап. его можно назвать "Security". Сделав таким образом, вы в любом классе можете добавить метод has_permission, который будет вызывать методы Security.
Потому RBAC тулить вроде бы не очень обоснованно.
Почему нет если:
Нужно проверять право юзверя совершать те или иные действия над объектом.
RBAC же как раз и служит для управления возможностями ролей.
Тем более если набор "тех или иных действий над объектом" будет разный для родей/юзеров. Но тогда надо еще этим действиями надо задавать capabilities.
perm_controller.check_permission(object, user, op_name);
Ну.. только не контроллер =)
Вообще, мне логичным кажется подход (можно пробежаться по реализации RBAC в современных фреймворках)
А логику прятать в некий Gate/AuthManager
А случаи с ownPost и прочими "своё-чужое" реализовывать через правила вроде:
Yii2 - https://www.yiiframework.com/doc/guide/2.0/ru/security-authorization#ispolzovanie-pravil
или: (laravel)
Фильтровать можно как в базовом контроллере, так и непосредственно в action-е.
В общем-то такой сущности как "роли"
Значит, надо сделать. И получится – в варианте 2 проверка варианта 1.
Значит, надо сделать. И получится – в варианте 2 проверка варианта 1.
На самом деле, они есть.. Даже если явно не обозначены.. Как минимум...
- администратор
- авторизованный пользователь
- гость
Просто перейти от проверки вроде
к более абстрактному и расширяемому..
Solmyr, на самом деле, можно любым из вариантов (и их комбинацией) к чему-то интересному прийти.. Главное - начать.. ))
На самом деле, они есть.. Даже если явно не обозначены.. Как минимум...
- администратор
- авторизованный пользователь
- гость
Ну всем же понятно, что роли – это более широкий диапазон. Хотя, конечно, разница только в количестве градаций. И с этой точки зрения - вроде как стандартная ситуация, реализованная 100500 раз.
Solmyr, на самом деле, можно любым из вариантов (и их комбинацией) к чему-то интересному прийти.. Главное - начать.. ))
Начато уже давно и давно работает. По третьему методу. Вот именно так как Gerga, говорит, с вспомогательными классами. Но вот при очередных расширениях функционала, стали меня терзать сомнения что это не совсем верно. Сейчас склоняюсь в пользу второго варианта, но пока еще не склонился окончательно. Продумываю разные сценарии. А комбинации и зоопарки методов - это не хорошо. Потом баги стадами ходить будут.
---------- Добавлено 13.10.2019 в 22:53 ----------
Почему нет если:
Потому что фактически один юзер - одна роль. Для каждого юзверя список объектов к которым есть доступ - разный. Причем даже не только просто юзер имеет доступ к своим объектам, а к своим "плюс" - где плюс просто разный список для разных юзеров.
Сейчас склоняюсь в пользу второго варианта, но пока еще не склонился окончательно.
Сделав вариантом 2, у вас получатся огромные классы-контроллеры с бизнес-логикой, это плохо. В хорошей архитектуре контроллеры должны быть тонкими и должны использовать методы Services-классов (3 вариант).
---------- Добавлено 13.10.2019 в 23:06 ----------
Но вот при очередных расширениях функционала, стали меня терзать сомнения что это не совсем верно.
Что именно?
А комбинации и зоопарки методов - это не хорошо. Потом баги стадами ходить будут.
Под комбинацией имел в виду, что логика
реализуется путём чего-то похожего на:
Первое более логично.. второе - суть.
Потому что фактически один юзер - одна роль. Для каждого юзверя список объектов к которым есть доступ - разный.
Да ладно! Это ничего не меняет, по сути. Список объектов - это и есть список ролей, фактически. Бахаем в БД для каждого юзера сериализованный объект или массив, например, – а при выяснении прав на совершение действий проверяем наличие необходимого элемента.