@SNPAC ну, если вкратце, вражеский сервер должен разрешать лазить к нему. Покопайтесь на сайте с описанием их АПИ, где-то должна быть информация.
Если ничего такого нет, проще всего делать аякс-запрос на свой серверный скрипт, который уже будет запрашивать удаленный сервер через банальный curl и отдавать Вам требуемые результаты.
Лично я rbac недолюбливаю за некий мерзский оверхед при контроле.
Вот, смотрите: по "классике" нам необходимо провести проверку на уровне пре-фильтра (а вдруг пользователь не имеет доступа к экшну?), потом уже в экшне на уровне записи (а вдруг чужая?), причем вторая проверка проводится уже после того, как запись нашли. Собственно, попытка решения этой проблемы приводится в статье habrahabr.ru/post/177873 (начиная со слов "аспектно-ориентированный"), но даже в простейшем случае со связанными записями мы либо скатываемся обратно к checkAccess, либо изобретаем какой-нибудь не менее извращенный способ.
Итогом этого является структура типа
- Проверить доступ к экшну
- Найти запись
- Не нашли - эксепшн 404
- Проверить права доступа к записи
- Не имеем права - эксепшн 403
- Если сохраняем - найти родительскую запись. Проверить права доступа к ней.
- Не имеем права - обана, а это 403 или ошибка сохранения? :)
Честно говоря, порой хочется взять и вынести весь этот цирк в модель, и контролировать уже на основе сценариев валидации. Ну или в какой-то промежуточный сервис, как в свое время предлагал на форуме Dan Schmidt.
PS. да, я знаю, как правильно пишется "мерзский".
PPS. Кстати, а может на форум переместиться? тема-то благодатная.
@zelenin мой пост о "готовке" в итоге отправился в официальную документацию, так что я бы не сказал, что прямо "не умею".
По поводу конкретных примеров - начнем с простого. Как выглядит контроллер (в местах, относящихся непосредственно к вопросу) в достаточно распространенном случае: редактирование записи Child, которая belongs_to Parent (с проверкой принадлежности юзеру)
PS. Я-то сложностью RBAC не пугаю, это автор пугается, см. исходный топик: "Я нахожу rbac сложным". Мой заглавный камент сводится к тому, что в простых случаях можно легко обойтись без RBAC.
@zelenin может и не слишком затратно, только бессмысленно.
Фишка вот в чем: чаще всего RBAC пытаются воткнуть с самого начала, если верят, что проект в дальнейшем получит развитие (и действительно потребуется гибкое разделение по ролям + управление ролями из админки).
Только вот в чем загвоздка: если уж городить огород, то непременно полный: с проверками на доступ к действию, на доступ к конкретной записи, к связанным с ней записям (чтобы не было возможности прилепить свой контент к чужому) и так далее. Ну, иначе все равно же код переписывать придется. Особо доставляет контроль за принадлежностью записи другому пользователю, поскольку эта задача в RBAC решается через задницу.
В итоге простое if ($record && $record->delete()) обрастает огромным количеством checkAccess, и я почти уверен в том, что топикстартеру это не нужно.
Все вот эти примеры из документации RBAC (canReadNews, canCreateNews, canUpdateNews, canDeleteNews) - они притянуты за уши из некоторого идеального сферического энтерпрайз-мирка, поэтому несколько пугают народ. Вот когда Вы последний раз видели у пользователя права на редактирование без прав на удаление?
А самое обидное бывает, написав крутейший набор rbac-правил, обнаружить, что пользователи системы все равно под одним логином сидят, потому что им так удобнее.
@ruslite ну да, а как еще. Callback для этого в плагине есть.
Докрутили до конца (на самом деле, чуть раньше, чем до конца) - выстрелил коллбек, запросил аяксом данные с сервера, выдал их на страницу.
@nepster09 все отличие от Вашего "времени изучения" в наличии магического метода. \Yii::$app->user->identity == \Yii::$app->user->getIdentity(), и эта штука - обычный геттер для приватной переменной. (нижнее подчеркивание по традиции используется для private-свойств).
@0neS not null во всех полях - это либо косяк (MyISAM такое спокойно жрал, поскольку не проверяет целостность), либо это поле действительно никогда не должно быть пустым (соответственно выставляется constraint типа on delete cascade).
0 в поле - именно то, о чем Вы сказали. Попытается найти ряд с PK == 0 и обломается. Собственно, оно и пытается Вам об этом сказать своей ошибкой :)
@another_dream зависит от того, что конкретно Вы городить хотите, можно вот так еще:
private $_db = null; + метод, возвращающий $this->_db !== null ? $this->_db : ...новое соединение.
Так удобнее в том смысле, что можно в любой части приложения вызвать метод, к примеру, getDbConnection и не париться, был уже коннект или нет.
Если ничего такого нет, проще всего делать аякс-запрос на свой серверный скрипт, который уже будет запрашивать удаленный сервер через банальный curl и отдавать Вам требуемые результаты.
Подробнее тут: ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B0%D0%B2%D0%...