Как лучше организовать регистрацию/авторизацию и 3 роли (Yii)?

Question

[Looking]

Доброе время суток.

Нужно ли реализовывать RBAC, если мне нужны "гость", "авторизованный", "админ", или можно обойтись какой-то более простой архитектурой?

Я нахожу rbac сложным и до конца не понимаю деталей его реализации (читал habrahabr.ru/post/177873 и документацию yii). Просто я не понимаю, зачем 3 таблицы в базе для такой тривиальной задачи.

И еще (простите за второй вопрос), регистрация и авторизация должны работать через одну модель?

Answer 1

[Yuri Morozov]

Эти роли легко реализуются при помощи обычного accessFilter, только не забудьте проконтролировать доступ пользователей к "чужому" контенту.

Можете сделать, к примеру, три части:
1. общая часть, для всех
2. модуль для пользователей (создание/редактирование контента)
3. модуль для админа (администрирование всего этого цирка)

Модуль для пользователей прикрыт фильтром accessControl с настройкой 'users' => array('@'), а при редактировании записи делайте проверку на owner_id. Для удобства можете вынести это в named scope, чтобы можно было делать что-нибудь вроде
$record = MyModel::model()->active()->ownedBy(Yii::app()->user->id)->findByPk($id); if (!$record) {кинуть 404}
или вообще $record = MyModel::model()->active()->own()->findByPk($id); (криво с точки зрения MVC, но удобно)

Модуль для админов прикрыт accessRules с настройкой 'expression' => '$user->isAdmin()',

Comments

[Александр Зеленин]

для этого существует rbac

[Yuri Morozov]

@zelenin Нет.
Надо помнить о том, что RBAC - довольно затратная фигня, и даже в официальной документации по этому поводу есть пометка (Avoiding too much RBAC)
https://github.com/yiisoft/yii2/blob/master/docs/g...

[Александр Зеленин]

@metamorph в данном случае будет конфиг из трех ролей - не затратно.

[Yuri Morozov]

@zelenin может и не слишком затратно, только бессмысленно.

Фишка вот в чем: чаще всего RBAC пытаются воткнуть с самого начала, если верят, что проект в дальнейшем получит развитие (и действительно потребуется гибкое разделение по ролям + управление ролями из админки).

Только вот в чем загвоздка: если уж городить огород, то непременно полный: с проверками на доступ к действию, на доступ к конкретной записи, к связанным с ней записям (чтобы не было возможности прилепить свой контент к чужому) и так далее. Ну, иначе все равно же код переписывать придется. Особо доставляет контроль за принадлежностью записи другому пользователю, поскольку эта задача в RBAC решается через задницу.

В итоге простое if ($record && $record->delete()) обрастает огромным количеством checkAccess, и я почти уверен в том, что топикстартеру это не нужно.

Все вот эти примеры из документации RBAC (canReadNews, canCreateNews, canUpdateNews, canDeleteNews) - они притянуты за уши из некоторого идеального сферического энтерпрайз-мирка, поэтому несколько пугают народ. Вот когда Вы последний раз видели у пользователя права на редактирование без прав на удаление?

А самое обидное бывает, написав крутейший набор rbac-правил, обнаружить, что пользователи системы все равно под одним логином сидят, потому что им так удобнее.

Всё тлен.

[Сергей Протько]

@metamorph, позавчера добавлял именно это разделение прав. Возможность редактировать основную информацию заказа для группы пользователей, без возможности удаления. Так же есть разделение на регионы и т.д. До этого где-то месяца 4 назад на другом проекте схожее разделение прав понадобилось, причем изначально не предполагалось.

[Александр Зеленин]

@metamorph мне кажется, вы просто не умеете его готовить, т.к. самое сложное - это составить правила в конфиге, а дальше это описанные access в behaviors и checkAccess, где необходимо.
Без огорода.
Хотя может быть вы какие-то сложные примеры приведете.
И еще одно: вы пугаете сложностью rbac'а, хотя автору rbac идеально подойдет, т.к. у него все очень просто.

[Yuri Morozov]

@zelenin мой пост о "готовке" в итоге отправился в официальную документацию, так что я бы не сказал, что прямо "не умею".

По поводу конкретных примеров - начнем с простого. Как выглядит контроллер (в местах, относящихся непосредственно к вопросу) в достаточно распространенном случае: редактирование записи Child, которая belongs_to Parent (с проверкой принадлежности юзеру)

PS. Я-то сложностью RBAC не пугаю, это автор пугается, см. исходный топик: "Я нахожу rbac сложным". Мой заглавный камент сводится к тому, что в простых случаях можно легко обойтись без RBAC.

[Александр Зеленин]

@metamorph он находит сложным, потому что видит сложный пример с какими-то 3-мя таблицами, хотя в его случае...
Мое мнение: rbac нужен всегда, когда нужны права доступа, но проверять какие-то моменты можно и без участия rbac (https://github.com/yiisoft/yii2/blob/master/docs/g... - в этом доке именно об этом и идет речь, не к одной же проверке сводится здесь речь)

[Yuri Morozov]

@zelenin ну фиг знает, каждому свое.

Лично я rbac недолюбливаю за некий мерзский оверхед при контроле.

Вот, смотрите: по "классике" нам необходимо провести проверку на уровне пре-фильтра (а вдруг пользователь не имеет доступа к экшну?), потом уже в экшне на уровне записи (а вдруг чужая?), причем вторая проверка проводится уже после того, как запись нашли. Собственно, попытка решения этой проблемы приводится в статье habrahabr.ru/post/177873 (начиная со слов "аспектно-ориентированный"), но даже в простейшем случае со связанными записями мы либо скатываемся обратно к checkAccess, либо изобретаем какой-нибудь не менее извращенный способ.

Итогом этого является структура типа
- Проверить доступ к экшну
- Найти запись
- Не нашли - эксепшн 404
- Проверить права доступа к записи
- Не имеем права - эксепшн 403
- Если сохраняем - найти родительскую запись. Проверить права доступа к ней.
- Не имеем права - обана, а это 403 или ошибка сохранения? :)

Честно говоря, порой хочется взять и вынести весь этот цирк в модель, и контролировать уже на основе сценариев валидации. Ну или в какой-то промежуточный сервис, как в свое время предлагал на форуме Dan Schmidt.

PS. да, я знаю, как правильно пишется "мерзский".

PPS. Кстати, а может на форум переместиться? тема-то благодатная.

[Сергей Протько]

Только в промежуточный сервис и нужно выносить. В модели проверкам на доступ делать нечего. Ровно так же как в модели нечего делать и валидации... но это же yii...

А то что в контроллере за счет этого вырастает количество скучного и тупого хлама дублирующегося, так они для того и нужны. Но выносить проверки может ли пользователь делать то-то или то-то однозначно стоит вынести в сервисный слой.

[Александр Зеленин]

@metamorph давайте переместимся)
@Fesor дайте пример реализации, если есть на yii преценденты

[Сергей Протько]

@zelenin, если честно даже не знаю что вам показывать. Обычный RBAC из рецептов в wiki yii, разве что все роли имели иерархию и собирались при инициализации. Это собственно единственное отличие от других примеров. А так все стандартно.

p.s. на yii это все было года полтора назад, я на нем сейчас активно уже и не пишу. Только один проект на суппорте остался, а так только symfony и в последнее время все больше silex.

Answer 2

[Сергей Протько]

Действительно, три таблицы для 3 групп пользователей не нужны. Во всяком случае для гостей таблицу - это глупо. Настройки прав могут храниться в конфиге, так что тут тоже проще... По сути я не вижу ничего

Мое мнение RBAC нужно реализовывать, ибо это более гибкий вариант. Да и зачем изобретать велосипед?

Comments

[Looking]

насчет трех таблиц это я про что-то вроде authassignment, authitem, authitemchild как в rights. Но как я понимаю ту же инфу можно хранить в auth конфиге, если правильно конечно понимаю.

[Александр Зеленин]

@Looking праивльно понимаете

Answer 3

[Александр Зеленин]

советую посмотреть yii2-app-advanced в официльном репозитории - там есть и регистрация и логин.
rbac реализовать через конфиг-файл, реализация простейшая.