Yii2 rbac что это
Как настроить RBAC в Yii2
Без моих пояснений понятно, что каждому пользователю назначается роль (role)/много ролей/разрешения (permissions)/правила (rules)… Роль может включать какие то разрешения. Она может наследовать разрешения от другой роли или нескольких ролей и т.д. Уверен, вы это уже миллион раз перечитали, пережевали… И всё равно вам непонятно, как же это работает, и как всё таки заставить в своем проекте работать этот «непонятный» RBAC.
Почему так всё запутано?
Так как работает RBAC в Yii2?
Я глубоко не изучал, как работает RBAC в Yii1, потому что использовал модули yii-user и rights. Но уверен, что в Yii2 изменилось немного.
Разрешения, роли, назначения можно хранить в базе данных, а можно и в файлах. Ниже я буду описывать вариант хранения данных в БД.
Ближе к коду…
Базовые шаги, которые необходимо пройти:
Это создаст 4 таблицы в БД:
Сейчас эти таблицы пустые.
Сделаем первоначальную инициализацию с помощью консольного скрипта: в корне проекта по следущей вложенности создаем файл console/controllers/MyRbacController.php (для basic шаблона файл должен быть commands/MyRbacController.php )
Теперь выполним этот скрипт
php yii my-rbac/init
Если выполнилось без ошибок, то в таблицах БД вы увидите результат работы. Он просто добавил туда записи. По мере добавления новых экшенов, возможно вам придется создавать для них новые разрешения и назначать ролям или пользователям.
Вы можете вручную вносить новые записи ролей/разрешений через ваш менеджер баз данных. Так же можно установить расширение, которое для этих четырех таблиц реализует визуальный интерфейс. Оно называется yii2-rbac-plus. Правда в composer файле этого расширения не указано, что оно требует виджеты от kartik-v и их придется установить заранее.
Как быть с новыми пользователями, которые добавляются в систему динамически?
Если у вас в проекте присутствует автоматическая регистрация пользователей или админ вносит юзеров через админку, то в модели юзера, после сохранения новой записи можно выполнить назначение новому юзера роли:
Вот в принципе и вся суть. Ниже я распишу, как создать правила с параметрами, например для того, что бы проверить, является ли пользователь автором новости или нет.
Правила / RBAC Rules
RBAC дает возможность очень гибко работать с разрешениями и ролями с помощью правил. Правила добавляют ролям и разрешениям дополнительные ограничения. В RBAC Yii1 эти правила хранились непосредственно в разрешениях и назывались Business rules.
Таким образом, мы проверяем, что поле createdBy у новости совпадает или нет с user id. Файл правила мы создали. Теперь его нужно добавть в RBAC. Для этого мы модернизируем наш инициализатор MyRbacController и выполним его еще раз. Старые данные сотрем:
Теперь, что бы вызвать проверку прав на редактирование собственной новости, в экшене редактирования производим проверку:
Здесь мы вызываем проверку updateOwnNews и передаем в правило этого разрешения параметр news (модель новости) в виде ассоциативного массива.
Использование проверки в фильтре доступа AccessControl
Использовать проверку в фильтре доступа AccessControl выгодно по причине того, что, если пользователь не авторизован и не имеет разрешения, то yii перекинет его на страницу авторизации. А если пользователь был авторизован и не имеет разрешения, то получает страницу ошибки. Пример ниже проверяет разрешение viewAdminModule для всех экшенов контроллера:
Здесь параметру roles передается массив ролей или разрешений, что в свою очередь в недрах системы вызывает проверку Yii::$app->user->can(‘viewAdminModule’)).
Имейте в виду, что если роль админа наследует роль редактора новостей, то для админа Yii::$app->user->can(‘editor’)) вернет true.
Доступ к сайту на основе ролей (RBAC) в Yii2.
RBAC же позволяет разделить авторизованных пользователей на отдельные группы, давая каждой из них отдельные права. Названия и количество таких групп не ограничено.
В данной статье рассмотрим PhpManager, представляющий собой диспетчер авторизации Yii2 хранящий данные о ролях и правилах в файлах.
Данный менеджер является одним из стандартных механизмов компонента приложения ‘authManager‘ и рекомендуется для использования если приложение не требует слишком динамичного управления ролями и разрешениями, то есть для большинства приложений.
Создание доступа.
Создадим, для примера, 3 группы пользователей:
Если роли не нужны и кроме админа никого не нужно авторизовывать, то можно на этом и остановиться, но «Шурик, это не наш метод» 🙂
Функциональность RBAC обеспечивает компонент приложения AuthManager, настроим его.
Генерирование файлов разрешений.
Теперь открываем консоль, переходим в основную папку yii нашего проекта. И выполняем команду, которая вызовет наш созданный контроллер Rbac и экшен Init.
где rbac – название консольного контроллера, а init – название действия.
На самом деле, контроллер не обязательно создавать в консоли, можно создать его в backend или frontend, просто тогда придется вызывать действие напрямую в адресной строке или делать ссылку на него, также, возможно, придется создавать подходящее правило UrlManager(). Кроме того, выполняя код данного класса каждый раз будет перезаписываться файл rules.php из папки rbac, что не очень хорошо. А выполнив его единожды из консоли избежим описанных проблем.
В папке rbac должно появиться 3 файла. В одном из них (items.php) можно просмотреть структуру созданных ролей.
Файл rules.php создался пустым, т.к. на данном этапе не созданы правила проверки прав. Пример создание правил будет дан ниже.
Файл assignments.php создался пустым, т.к. на данный момент у нас еще не привязаны роли к пользователям. Исправим это. Разумеется, у вас уже должна быть таблица User в базе данных, к элементам которой будут привязываться роли. Поэтому выполните миграцию (если еще не выполняли) по созданию данной таблицы, а так же создайте хотя бы одного пользователя, со значением поля username, например с «admin».
Теперь создадим другой консольный контроллер для привязки ролей к пользователям, т.к. на данном этапе пользователь с именем «admin» ничем не отличается от любого другого пользователя кроме названия.
Файл console/controllers/RolesController.php :
В действиях данного контроллера применяются консольные методы для взаимодействия с пользователем (prompt, select, stdout).
Запустим действие привязки ролей:
На запрос консоли нужно будет ввести название пользователя и далее выбрать одну из ролей, которую необходимо привязать к данному пользователю.
В данном случае была привязана роль admin к одноименному пользователю. После этого в файл assignments.php попадет информация связывающая id данного пользователя с ролью.
Изменив, немного, метод findModel() можно сделать, чтобы вместо имени пользователей, при привязывании к ним ролей, можно было указывать id данных пользователей.
Если нужно, можно привязать к пользователю сразу несколько ролей.
Метод actionRevoke() служит для отвязки ролей от пользователей, т.е. он просто удаляет выбранную роль или сразу все для определенного пользователя.
Контроллер RolesController создан с целью удобства и наглядности привязки ролей. Т.е. вы вполне можете его не создавать, а заполнить массив в файле assignments.php вручную, указав роли для пользователей.
Так же, можно динамически назначить роли пользователям. Например присвоим роль «admin» текущему пользователю:
Привязка роли делается только 1 раз, повторно выполнить данную команду не получится, т.к. данные уже будут сохранены в файле assignments.php.
Поэтому привязку лучше всего делать при заведении пользователя.
Выше указана стандартная схема работы с RBAC с использованием компонента PhpManager. Как видно, все данные сохраняются в файлах, а база данных используется исключительно для аутентификации пользователей (перечня существующих пользователей к которым можно привязать роли). Исходя из этого можно сделать вывод, что создание роли для каждого пользователя (используя PhpManager) создает в файле дополнительный ассоциативный массив, а то и не один, если ролей привязывается сразу несколько. Если пользователей не много, это не проблема. В противном случае данный файл слишком разрастется, а кроме того не очень удобно работать с присвоением/удалением ролей. Поэтому, часто, немного модифицируют работу с компонентом PhpManager, откажемся от хранения информации о привязанных ролях в данном файле, о чем и поговорим.
Такой подход является промежуточным между PhpManager (согласно которому данные хранятся в файлах) и DbManager (который сохраняет всё в таблицах в базе данных).
Данный подход использует установку параметра defaultRoles (роли по-умолчанию) для компонента приложения authManager. Роль по умолчанию — это роль, которая неявно присваивается всем пользователям. Вызов метода [[yii\rbac\ManagerInterface::assign()]] не требуется, и авторизационные данные не содержат информации о назначении. Роль по умолчанию, обычно, связывают с правилом, определяющим к какой роли принадлежит каждый пользователь.
Далее установим названия ролей в виде констант модели User:
Далее переделаем консольный контролле создающий роли.
Файл console\controllers\RbacController.php:
Видим, что в данном коде создается объект класса правил:
идентификатор (название) которого потом сохраняется для каждой роли:
Создаем данный класс данных правил, который, в обязательном порядке, наследуется от класса Rule, должен содержать уникальное имя в переменной $name и реализовывать метод execute().
Файл common/components/rbac/UserRoleRule.php :
Тут можно увидеть, что для получения доступа по роли ‘admin’ необходимо, чтобы у текущего пользователя в поле role базы данных был вписан идентификатор полученный вызовом User::ROLE_ADMIN. А вот для доступа по роли ‘user’ достаточно любого из 3-х идентификаторов.
Теперь файл assignments.php, созданный при выполнении метода консольного контроллера RbacController, содержит пустой массив и он не используется для определения роли текущего пользователя, а вместо него используется проверка из созданного класса правил.
При таком изменении стандартной работы PhpManager не будут работать getRolesByUser(), assign() и некоторые другие системные методы. Если вы их собираетесь использовать, то необходимо доработать PhpManager на получение роли из этого поля (вместо файла assignments.php). Но в большинстве случаев в этом нет необходимости.
Если вместо указания название роли в поле role вы все же предпочли использовать числовой идентификатор, то нужно всего лишь изменить значения констант в модели User:
const ROLE_USER = 1;
const ROLE_MODER = 5;
const ROLE_ADMIN = 10;
Соответственно для роли пользователя в поле role базы данных должно находиться значение 1, для модератора 5 и тд.
На этом создание ролей и правил завершено, осталось научиться их использовать.
Использование (проверка доступа).
Способ 1. В методе контроллера, в файле-представлении и тд.:
Нужно учесть, что если текущий пользователь имеет права админа, то проверка на ‘moder’ и ‘user’ даст TRUE, т.к. admin включает в себя их права.
Так же можно проверить разрешение на выполнение определенного действия:
Способ 3. Создание массива access в методе behaviors() нужного контроллера с указанием к каким действиям нужно ограничить доступ и для кого он разрешен или запрещен:
В данном примере доступ к действиям ‘index’ и ‘contact’ разрешен только для пользователя с ролью «admin» (значение константы из модели User).
подключим в нужном контроллере:
Вот и все, пользователи созданы, роли им заданы, далее можно использовать для предоставления доступа вышеприведенными способами, например, к админке сайта на Yii2, отдельным страницам и тд.
RBAC, роли и пользователи в Yii2
Вопросы про RBAC, роли, авторизацию и связку ролей — одни из самых часто задаваемых на русскоязычном форуме Yii. Попробую ка я объяснить суть RBAC в Yii2.
RBAC бывает 2-типов: основанный на файлах или в БД. Я буду описывать тот, что хранит свои данные в БД, тк он дает больше возможностей динамически добавлять и менять роли.
Настройка authManager
В конфиге нужно прописать тип authManager-а
а в базе создать необходимые таблицы. Создавать их просто, достаточно применить миграцию:
Настройка ролей и прав
Теперь нужно создать роль и сохранить ее в RBAC
Делать это нужно всего 1 раз. Повторно сохранить роль с одним и тем же именем RBAC не даст. Теперь у нас есть роль админ и юзер. На что они имеют право? Пока ни на что, но можно указать права с привязкой к роли в контроллере
Теперь доступ к actionAdminka доступен только пользователю с ролью admin. Но пользователя с такой ролью у нас пока нет. Пока есть только роль.
Что еще важно: создавать можно не только роли, но и отдельные «права». Создаются они так же как и роли:
Yii не проверяет сам права. Имя «deleteUser» — просто строка, она никак не соотносится с action и другими сущностями Yii. Проверять, имеет ли право юзер на действия вы должны сами
Роли и права можно наследовать. Причем без ограничений что от чего наследуется.
Те наследовать можно:
Пример: роль админа наследует все права от роли пользователя (что разрешено пользователю становится доступно админу).
Уровень вложенности наследуемых прав не ограничен. Главное не перемудрить и самому не запутаться
Привязка ролей к пользователю
Многих вводит в заблуждение поле role в таблице User. Человек меняет значение в поле и надеется на то, что Yii правильно обработает роль. А этого не происходит. Забудьте про поле role в таблице User. К RBAC оно отношения не имеет.
Назначение роли так же делается через authManager
И делается 1 раз. RBAC сохранит данные в auth_assignment и будет подхватывать роль автоматически при авторизации пользователя. Поэтому привязку лучше всего делать при заведении пользователя.
Важно то, что привязывать к пользователю можно не только роль, но и право.
У пользователя может быть несколько ролей. Получить их всех можно вот так:
Гибкое управление ролями в Yii2 и проверка прав «на лету»
Если вам не хочется вникать в RBAC и писать свой велосипед, можете воспользоваться моим готовым расширением. Скачать его можно с github.
Установив мой модуль вы получите:
Настраивать права с таким модулем сможет каждый, даже тот кто не понимает принципов работы RBAC в Yii2.
А если у вас остались вопросы — задавайте их в комментариях.
PS: по многочисленным просьбам в модуль добавлена страница для привязки роли к юзеру. Спасибо всем за внимание, замечания и вопросы. Жду новых пожеланий 🙂
Авторизация ¶
Примечание: этот раздел находится на стадии разработки.
Авторизация — это процесс проверки того, что пользователь имеет достаточно прав, чтобы выполнить какие-то действия. Yii предоставляет два метода авторизации: фильтры контроля доступа (ACF) и контроль доступа на основе ролей (RBAC).
Фильтры контроля доступа ¶
Фильтры контроля доступа (ACF) являются простым методом, который лучше всего использовать в приложениях с простым контролем доступа. Как видно из их названия, ACF — это фильтры, которые могут присоединяться к контроллеру или модулю как поведение. ACF проверяет набор правил доступа, чтобы убедиться, что пользователь имеет доступ к запрошенному действию.
Код ниже показывает, как использовать ACF фильтр, реализованный в yii\filters\AccessControl:
Когда фильтр ACF проводит проверку авторизации, он проверяет правила по одному сверху вниз, пока не найдёт совпадение. Значение опции allow выбранного правила указывает, авторизовывать пользователя или нет. Если ни одно из правил не совпало, то пользователь считается НЕавторизованным, и фильтр ACF останавливает дальнейшее выполнение действия.
По умолчанию, когда у пользователя отсутствует доступ к текущему действию, ACF делает следующее:
Вы можете переопределить это поведение, настроив свойство yii\filters\AccessControl::$denyCallback:
Правила доступа поддерживают набор свойств. Ниже дано краткое описание поддерживаемых опций. Вы также можете расширить yii\filters\AccessRule, чтобы создать свой собственный класс правил доступа.
allow: задаёт какое это правило, «allow» или «deny».
actions: задаёт действия, соответствующие этому правилу. Значение должно быть массивом идентификаторов действий. Сравнение — регистрозависимо. Если свойство пустое или не задано, то правило применяется ко всем действиям.
controllers: задаёт контроллеры, которым соответствует правило. Значение должно быть массивом с идентификаторами контроллеров. Сравнение регистрозависимо. Если свойство пустое или не задано, то правило применяется ко всем контроллерам.
roles: задаёт роли пользователей, соответствующих этому правилу. Распознаются две специальные роли, которые проверяются с помощью yii\web\User::$isGuest:
Использование других имён ролей будет приводить к вызову метода yii\web\User::can(), который требует включения RBAC (будет описано дальше). Если свойство пустое или не задано, то правило применяется ко всем ролям.
ips: задаёт IP адреса пользователей, для которых применяется это правило. IP адрес может содержать * в конце, так чтобы он соответствовал IP адресу с таким же префиксом. Для примера, ‘192.168.*’ соответствует всем IP адресам в сегменте ‘192.168.’. Если свойство пустое или не задано, то правило применяется ко всем IP адресам.
matchCallback: задаёт PHP колбек, который вызывается для определения, что правило должно быть применено.
denyCallback: задаёт PHP колбек, который будет вызван, если доступ будет запрещён при вызове этого правила.
Контроль доступа на основе ролей (RBAC) ¶
Управление доступом на основе ролей (RBAC) обеспечивает простой, но мощный централизованный контроль доступа. Пожалуйста, обратитесь к Wikipedia для получения информации о сравнении RBAC с другими, более традиционными, системами контроля доступа.
Yii реализует общую иерархическую RBAC, следуя NIST RBAC model. Обеспечивается функциональность RBAC через компонент приложения authManager.
Использование RBAC состоит из двух частей. Первая часть — это создание RBAC данных авторизации, и вторая часть — это использование данных авторизации для проверки доступа в том месте, где это нужно.
Для облегчения последующего описания, мы сначала введём некоторые основные понятия RBAC.
Основные концепции ¶
Роль представляет собой набор разрешений (permissions) (например, создание сообщения, обновление сообщения). Роль может быть назначена на одного или многих пользователей. Чтобы проверить, имеет ли пользователь указанные разрешения, мы должны проверить, назначена ли пользователю роль, которая содержит данное разрешение.
С каждой ролью или разрешением может быть связано правило (rule). Правило представляет собой кусок кода, который будет выполняться в ходе проверки доступа для определения может ли быть применена соответствующая роль или разрешение к текущему пользователю. Например, разрешение «обновление поста» может иметь правило, которое проверяет является ли текущий пользователь автором поста. Во время проверки доступа, если пользователь не является автором поста, он/она будет считаться не имеющими разрешения «обновление поста».
И роли, и разрешения могут быть организованы в иерархию. В частности, роль может содержать другие роли или разрешения; и разрешения могут содержать другие разрешения. Yii реализует частично упорядоченную иерархию, которая включает в себя специальные деревья иерархии. Роль может содержать разрешение, но обратное не верно.
Настройка RBAC Manager ¶
Перед определением авторизационных данных и проверкой прав доступа, мы должны настроить компонент приложения authManager. Yii предоставляет два типа менеджеров авторизации: yii\rbac\PhpManager и yii\rbac\DbManager. Первый использует файл с PHP скриптом для хранения данных авторизации, второй сохраняет данные в базе данных. Вы можете использовать первый, если ваше приложение не требует слишком динамичного управления ролями и разрешениями.
Настройка authManager с помощью PhpManager ¶
Следующий код показывает как настроить в конфигурации приложения authManager с использованием класса yii\rbac\PhpManager:
Настройка authManager с помощью DbManager ¶
Следующий код показывает как настроить в конфигурации приложения authManager с использованием класса yii\rbac\DbManager:
DbManager использует четыре таблицы для хранения данных:
Прежде чем вы начнёте использовать этот менеджер, вам нужно создать таблицы в базе данных. Чтобы сделать это, вы можете использовать миграцию хранящуюся в файле @yii/rbac/migrations :
Создание данных авторизации ¶
Для создания данных авторизации нужно выполнить следующие задачи:
В зависимости от требований к гибкости авторизации перечисленные задачи могут быть выполнены разными путями.
Если иерархия прав не меняется, и количество пользователей зафиксировано, вы можете создать консольную команду, которая будет единожды инициализировать данные через APIs, предоставляемое authManager :
После выполнения команды yii rbac/init мы получим следующую иерархию:
Автор может создавать пост, администратор может обновлять пост и делать всё, что может делать автор.
Если ваше приложение позволяет регистрировать пользователей, то вам необходимо сразу назначать роли этим новым пользователям. Например, для того, чтобы все вошедшие пользователи могли стать авторами в расширенном шаблоне проекта, вы должны изменить frontend\models\SignupForm::signup() как показано ниже:
Использование правил ¶
Как упомянуто выше, правила добавляют дополнительные ограничения на роли и разрешения. Правила — это классы, расширяющие yii\rbac\Rule. Они должны реализовывать метод execute(). В иерархии, созданной нами ранее, автор не может редактировать свой пост. Давайте исправим это. Сначала мы должны создать правило, проверяющее что пользователь является автором поста:
Теперь мы имеем следующую иерархию:
Проверка доступа ¶
С готовыми авторизационными данными проверка доступа — это просто вызов метода yii\rbac\ManagerInterface::checkAccess(). Так как большинство проверок доступа относятся к текущему пользователю, для удобства Yii предоставляет сокращённый метод yii\web\User::can(), который можно использовать как показано ниже:
Если текущий пользователь Jane с мы начнём с createPost и попробуем добраться до Jane :
Вот что происходит если текущим пользователем является John:
В случае Jane это немного проще, потому что она admin:
Есть несколько способов реализовать авторизацию в контроллере. Если вам необходимы отдельные права на добавление и удаление, то проверку стоит делать в каждом действии. Вы можете либо использовать условие выше в каждом методе действия, либо использовать yii\filters\AccessControl:
Если права на все CRUD операции выдаются вместе, то лучшее решение в этом случае — завести одно разрешение вроде managePost и проверять его в yii\web\Controller::beforeAction().
Использование роли по умолчанию ¶
Роль по умолчанию — это роль, которая неявно присваивается всем пользователям. Вызов метода yii\rbac\ManagerInterface::assign() не требуется, и авторизационные данные не содержат информации о назначении.
Роль по умолчанию обычно связывают с правилом, определяющим к какой роли принадлежит каждый пользователь.
Роли по умолчанию обычно используются в приложениях, которые уже имеют какое-то описание ролей. Для примера, приложение может иметь столбец «group» в таблице пользователей, и каждый пользователь принадлежит к какой-то группе. Если каждая группа может быть сопоставлена роли в модели RBAC, вы можете использовать роль по умолчанию для автоматического назначения каждому пользователю роли RBAC. Давайте используем пример, чтобы понять как это можно сделать.
Обратите внимание, так как «author» добавлен как дочерняя роль к «admin», следовательно, в реализации метода execute() класса правила вы должны учитывать эту иерархию. Именно поэтому для роли «author» метод execute() вернёт истину, если пользователь принадлежит к группам 1 или 2 (это означает, что пользователь находится в группе администраторов или авторов)
Далее настроим authManager с помощью перечисления ролей в свойстве yii\rbac\BaseManager::$defaultRoles: