Yii framework как зайти в админку

Обновлено: 03.07.2024

Установка не представляет из себя ничего не обычного, она описана в документации расширения. Читать подробнее об установке расширений в yii2.

Первый шаг

Добавляем компонент и модуль в файле config/web.php:

Второй шаг

Для функционирования миграции в консоли, добавим соответствующий модуль в файле config/console.php:

Третий шаг

Четвертый шаг

Добавляем поведение в основной контроллер:

Подобным образом работают и GhostNav::widget() and GhostHtml:a().

Войдите используя superadmin/superadmin;
Перейдите в раздел Permissions;
Перейдите в раздел Roles;
Перейдите в раздел User:
Осознайте, что все работает и расслабьтесь.

Контроллеры могут иметь два свойства, которые делают весь контроллер или выбранное действие доступными всем:

Полезные хэлперы

Управление ролями и доступом

События

События могут быть получены следующим образом:

Расширенный профиль пользователя

Для создания расширенного профиля пользователя с аватаром, днем рождения и прочими свойствами, нужно самостоятельно разработать профили, не затрагивая данное расширение:

Создать таблицу и модель для профиля, включая связь по полю user_id с таблицей user;
Проверить работу AuthController::actionRegistration();
Объявить свой layout для регистрации (пример есть в AuthHelper::layoutHandler()). Использовать темизацию для изменения файла registration.php.
Объявить свой класс UserManagementModule::$registrationFormClass. В этом классе реализовать валидацию и сохранение профиля;
Создать свой контроллер для отображения информации профиля пользователя.

5 thoughts on “ Yii2: Управление пользователями RBAC ”

А для yii2 advanced в какой файл добавлять компонент и модуль ? в какую папку frontend или common?

Всё установил, всё работает, но.
Со всем разобрался, но как быть с правами? В yii1 я пользовался кажется плагином rights и всё было ок. Там находились автоматом все экшены. А тут создал право и что дальше, по роутам видно что здесь только экшены самого плагина и всякий хлам (//crud, /asset/compress, /migrate/create и д.п.), а как быть с экшенами из других модулей и тем же siteController. Я что-то не так установил?

не пойму куда капать, шаблон advanced открывается доступ в админку по не существующим адресам. куда копать.

Как настроить управление пользователями и правами доступа в Yii2 с нуля.

Будем использовать приложение Yii2 Advanced, подключим модули "yii2-user" и "yii2-admin".

Если у вас уже есть готовое приложение, шаги с 1 по 5 можно пропустить.

1. Создаём проект по шаблону Advanced.

Здесь предполагается, что вы уже настроили Composer. Если нет, см. документацию к шаблону.

composer create-project --prefer-dist yiisoft/yii2-app-advanced yii2-user-combo.local

cd yii2-user-combo.local
init
0
yes

2. Удаляем миграцию стандартных юзеров, она нам не нужна: " console/migrations/m130524_201442_init.php ".

3. Добавляем файлы ".htaccess" в папки "/frontend/web", "/backend/web", а также в корень проекта.

В моём примере, фронтенд будет доступен по адресу "http://yii2-user-combo.local".

Бэкенд по адресу "http://yii2-user-combo.local/admin".

4. Создаём БД, указываем её в конфиге "common/config/main-local.php".

5. Настраиваем конфиги.

backend/config/main.php
'components' => [
'request' => [
.
'baseUrl'=>'/admin',
],

common/config/main.php
'language' => 'ru-RU',
.
'components' => [
.
'urlManager' => [
'enablePrettyUrl' => true,
'showScriptName' => false,
],

frontend/config/main.php
'components' => [
'request' => [
// Избавляемся от /frontend/web
'baseUrl' => '',
.
],

6. Ставим "yii2-user".

composer require dektrium/yii2-user

7. Убираем из конфига компонент "user", вместо него подключаем дектриумовский модуль.

Настройку модуля пользователей сделаем только для бэкенда. Для фронтенда настройки будут аналогичные.

backend/config/main.php
'modules' => [
// ID модуля должен обязательно быть "user", иначе модуль не загрузится.
'user' => [
'class' => 'dektrium\user\Module',
'admins' => ['MegaAdmin'], // Хардкод для админского пользователя. После настройки прав доступа, нужно удалить эту строку.
],
],

8. Подключаем консольные команды.

console/config/main.php
'modules' => [
'user' => [
'class' => 'dektrium\user\Module',
],
],

9. Создаём таблицы для пользователей.

yii migrate --migrationPath=@vendor/dektrium/yii2-user/migrations

10. Убираем неиспользуемые действия из контроллеров.

Приводим "behaviors" к такому виду.

public function behaviors()
<
return [
'access' => [
'class' => AccessControl::className(),
'rules' => [
[
'actions' => ['error'],
'allow' => true,
],
[
'actions' => ['index'],
'allow' => true,
'roles' => ['@'],
],
],
],
];
>

Убираем лишние действия.
public function actionLogin()
public function actionLogout()

11. Удаляем файл представления
/backend/views/site/login.php

12. Меняем в файле
/backend/views/layouts/main.php

/site/login на /user/security/login

/site/logout на /user/security/logout

13. Ставим расширение "yii2-admin".

composer require mdmsoft/yii2-admin

14. Настраиваем конфиги.

backend/config/main.php
'bootstrap' => [
.
'users-admin',
],
.
'modules' => [
.
// ID модуля может быть любой.
'users-admin' => [
'class' => 'mdm\admin\Module',
// Отключаем шаблон модуля,
// используем шаблон нашей админки.
'layout' => null,
]
],
.
'as access' => [
'class' => 'mdm\admin\classes\AccessControl',
// Маршруты, открытые по умолчанию всегда.
// Открываем только для начальной разработки.
// Как только основные данные о ролях заполнены,
// убираем отсюда всё лишнее.
'allowActions' => [
// Маршруты модуля пользователей.
// Логин и так разрешён, но разлогиниться
// без этой настройки и без настроенных ролей не получится.
'user/*',
'site/*',
'users-admin/*',
'debug/*',
]
],

common/config/main.php
'components' => [
'authManager' => [
'class' => 'yii\rbac\DbManager',
],

15. Добавляем ассет для корректного отображения админки в нашем шаблоне.

backend\assets\AppAsset.php
public $depends = [
.
'dee\adminlte\AdminlteAsset',
];

16. Применяем миграции для использования RBAC.

yii migrate --migrationPath=@yii/rbac/migrations

17. Применяем миграции для редактирования меню.

yii migrate --migrationPath=@mdm/admin/migrations

18. Всё готово.

P.S. Можно подключать расширение "dektrium/yii2-rbac" для управления правами доступа.

Но расширение "mdmsoft/yii2-admin" удобнее.

Оба расширения позволяют полноценно настраивать права доступа.

Преимущества "yii2-admin":

Примечание: этот раздел находится на стадии разработки.

Авторизация это процесс проверки того, что пользователь имеет достаточно прав чтобы что-то сделать. Yii обеспечивает два метода авторизации: Фильтры контроля доступа (ACF) и контроль доступа основанный на ролях (RBAC).

Фильтры контроля доступа

Фильтры контроля доступа (ACF) являются простым методом, который лучше всего использовать в приложениях с простым контролем доступа. Как указывает его название, ACF это фильтры, который может присоединяться к контроллеру или модулю как поведение. ACF проверяет набор [[yii\filters\AccessControl::rules|правил доступа]], чтоб убедится, что пользователь имеет доступ к запрошенной операции.

Код ниже показывает как использовать ACF реализованный в [[yii\filters\AccessControl]]:

Код выше показывает ACF связанный с контроллером site через поведение. Это типичный способ использования фильтров действий. Параметр only указывает, что фильтр ACF нужно применять только к действиям login , logout и signup . Параметр rules задаёт [[yii\filters\AccessRule|правила доступа]], которые означают следующее:

Разрешить всем гостям (ещё не прошедшим авторизацию) доступ к действиям login и signup . Опция roles содержит знак вопроса ? , это специальный токен обозначающий "гостя".
Разрешить аутентифицированным пользователям доступ к действию logout . Символ @ это другой специальный токен обозначающий аутентифицированного пользователя.

Когда ACF проводит проверку авторизации, он проверяет правила по одному сверху вниз пока не найдёт совпадение. Значение опции allow выбранного правила указывает авторизовывать пользователя или нет. Если ни одно из правил не совпало, то пользователь считается НЕ авторизованным и ACF останавливает дальнейшее выполнение действия.

По умолчанию, ACF, когда у пользователя отсутствует доступ к текущему действию, делает следующее:

Вы можете переопределить это поведение, настроив свойство [[yii\filters\AccessControl::denyCallback]]:

[[yii\filters\AccessRule|Правила доступа]] поддерживают набор свойств. Ниже краткое описание поддерживаемых опций. Вы также можете расширить [[yii\filters\AccessRule]], чтоб создать свой собственный класс правил доступа.

[[yii\filters\AccessRule::allow|allow]]: задаёт какое это правило, "allow" или "deny".

[[yii\filters\AccessRule::actions|actions]]: задаёт действия соответствующие этому правилу. Значение должно быть массивом идентификаторов действий. Сравнение регисрозависимо. Если свойство пустое или не задано, то правило применяется ко всем действиям.

[[yii\filters\AccessRule::controllers|controllers]]: задаёт контроллеры, которым соответствует правило. Значение должно быть массивом с идентификаторами контроллеров. Сравнение регисрозависимо. Если свойство пустое или не задано, то правило применяется ко всем действиям.

[[yii\filters\AccessRule::roles|roles]]: задаёт роли пользователей соответствующих этому правилу. Распознаются две специальные роли, которые проверяются с помощью [[yii\web\User::isGuest]]:

? : соответствует гостевому пользователю (не аутентифицирован)
@ : соответствует аутентифицированному пользователю

Использование других имён ролей будет приводить к вызову метода [[yii\web\User::can()]], который требует включения RBAC (будет описано дальше). Если свойство пустое или не задано, то правило применяется ко всем ролям.

[[yii\filters\AccessRule::ips|ips]]: задаёт [[yii\web\Request::userIP|IP адреса пользователей]], для которых применяется это правило. IP адрес может содержать * в конце, так чтобы он соответствовал IP адресу с таким же префиксом. Для примера, '192.168.*' соответствует всем IP адресам в сегменте '192.168.'. Если свойство пустое или не задано, то правило применяется ко всем IP адресам.

[[yii\filters\AccessRule::matchCallback|matchCallback]]: задаёт PHP колбек, который вызывается для определения, что правило должно быть применено.

[[yii\filters\AccessRule::denyCallback|denyCallback]]: задаёт PHP колбек, который будет вызван если доступ будет запрещён при вызове этого правила.

Ниже показан пример, показывающий использование опции matchCallback , которая позволяет писать произвольную логику проверки доступа:

Контроль доступа на основе ролей (RBAC)

Управление доступом на основе ролей (RBAC) обеспечивает простой, но мощный централизованный контроль доступа. Пожалуйста обратитесь к Wikipedia для получения более подробного сравнения RBAC с другими, более традиционными, системами контроля доступа.

Yii реализует общую иерархическую RBAC, следуя NIST RBAC model. Обеспечивается функциональность RBAC через компонент приложения [[yii\rbac\ManagerInterface|authManager]].

Использование RBAC состоит из двух частей. Первая часть - это создание RBAC данных авторизации, и вторая часть - это использование данных авторизации для проверки доступа в том месте, где это нужно.

Для облегчения последующего описания, мы сначала введём некоторые основные понятия RBAC.

Основные концепции

С каждой ролью или разрешением может быть связано правило (rule). Правило представляет собой кусок кода, который будет выполняться в ходе проверки доступа для определения может ли быть применена соответствующая роль или разрешение к текущему пользователю. Например, разрешение "обновление поста" может иметь правило, которое проверяет является ли текущий пользователь автором поста. Во время проверки доступа, если пользователь не является автором поста, он/она будет считаться не имеющими разрешения "обновление поста".

И роли и разрешения могут быть организованы в иерархию. В частности роль может содержать другие роли или разрешения; и разрешения могут содержать другие разрешения. Yii реализует частично упорядоченную иерархию, которая включает в себя специальные деревья иерархии. Роль может содержать разрешение, но обратное не верно.

Настройка RBAC Manager

Перед определением авторизационных данных и проверкой прав доступа, мы должны настроить компонент приложения [[yii\base\Application::authManager|authManager]]. Yii предоставляет два типа менеджеров авторизации: [[yii\rbac\PhpManager]] и [[yii\rbac\DbManager]]. Первый использует файл с PHP скриптом для хранения данных авторизации, второй сохраняет данные в базе данных. Вы можете использовать первый если ваше приложение не требует слишком динамичного управления ролями и разрешениями.

настройка authManager с помощью PhpManager

Следующий код показывает как настроить в конфигурации приложения authManager с использованием класса [[yii\rbac\PhpManager]]:

Теперь authManager может быть доступен через \Yii::$app->authManager .

Замечание: По умолчанию, [[yii\rbac\PhpManager]] сохраняет данные RBAC в файлах в директории @app/rbac/ . Убедитесь что данная директория и файлы в них доступны для записи Web серверу, если иерархия разрешений должна меняться онлайн.

настройка authManager с помощью DbManager

Следующий код показывает как настроить в конфигурации приложения authManager с использованием класса [[yii\rbac\DbManager]]:

DbManager использует четыре таблицы для хранения данных:

- [[yii\rbac\DbManager::$itemTable	itemTable]]: таблица для хранения авторизационных элементов. По умолчанию "auth_item".
- [[yii\rbac\DbManager::$assignmentTable	assignmentTable]]: таблица для хранения назначений элементов авторизации. По умолчанию "auth_assignment".
- [[yii\rbac\DbManager::$ruleTable	ruleTable]]: таблица для хранения правил. По умолчанию "auth_rule".

Прежде чем вы начнёте использовать этот менеджер, вам нужно создать таблицы в базе данных. Чтобы сделать это, вы можете использовать миграцию хранящуюся в файле @yii/rbac/migrations :

yii migrate --migrationPath=@yii/rbac/migrations

Теперь authManager может быть доступен через \Yii::$app->authManager .

Создание данных авторизации

Для создания данных авторизации нужно выполнить следующие задачи:

определение ролей и разрешений;
установка отношений между ролями и правами доступа;
определение правил;
связывание правил с ролями и разрешениями;
назначение ролей пользователям.

В зависимости от требований к гибкости авторизации перечисленные задачи могут быть выполнены разными путями.

Если иерархия прав не меняется и количество пользователей зафиксировано, вы можете создать консольную команду, которая будет единожды инициализировать данные через APIs предоставляемое authManager :

После выполнения команды yii rbac/init мы получим следующую иерархию:

Автор может создавать пост, администратор может обновлять пост и делать всё, что может делать автор.

Если ваше приложение позволяет регистрировать пользователей, то вам необходимо сразу назначать роли этим новым пользователям. Например, для того, чтобы все вошедшие пользователи могли стать авторами в расширенном шаблоне проекта, вы должны изменить frontend\models\SignupForm::signup() как показано ниже:

Для приложений, требующих комплексного контроля доступа с динамически обновляемыми данными авторизации, существуют специальные пользовательские интерфейсы (так называемые админ-панели), которые могут быть разработаны с использованием API, предлагаемого authManager

Использование правил

Как упомянуто выше, правила добавляют дополнительные ограничения на роли и разрешения. Правила это классы, расширяющие [[yii\rbac\Rule]]. Они должны реализовывать метод [[yii\rbac\Rule::execute()|execute()]]. В иерархии, созданной нами ранее, автор не можете редактировать свой пост. Давайте исправим это. Во-первых, мы должны создать правило проверяющее, что пользователь является автором поста:

Правило выше проверяет, что post был создан $user . Мы создадим специальное разрешение updateOwnPost в команде, которую мы использовали раньше:

Теперь мы имеем следующую иерархию:

Проверка доступа

С готовыми авторизационными данными, проверка доступа - это просто вызов метода [[yii\rbac\ManagerInterface::checkAccess()]]. Так как большинство проверок доступа относятся к текущему пользователю, для удобства Yii предоставляет сокращённый метод [[yii\web\User::can()]], который можно использовать как показано ниже:

Если текущий пользователь Jane с мы начнём с createPost и попробуем добраться до Jane :

Для того чтоб проверить может ли пользователь обновить пост, нам надо передать дополнительный параметр, необходимый для правила AuthorRule , описанного ранее:

Вот что происходит если текущим пользователем является John:

Мы начинаем с updatePost и переходим к updateOwnPost . Для того чтоб это произошло, правило AuthorRule должно вернуть true при вызове метода execute . Метод получает $params переданный при вызове метода can , значение которого равно ['post' => $post] . Если всё правильно мы увидим, что author привязан к John.

В случае Jane это немного проще, потому что она admin:

Использование роли по умолчанию

Роль по умолчанию - это роль, которая неявно присваивается всем пользователям. Вызов метода [[yii\rbac\ManagerInterface::assign()]] не требуется, и авторизационные данные не содержат информации о назначении.

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

Роли по умолчанию обычно используются в приложениях, которые уже имеют какое-то описание ролей. Для примера, приложение может иметь столбец "group" в таблице пользователей, и каждый пользователь принадлежит к какой-то группе. Если каждая группа может быть сопоставлена роли в модели RBAC, вы можете использовать роль по умолчанию для автоматического назначения каждому пользователю роли RBAC. Давайте используем пример, чтобы понять как это можно сделать.

Предположим что в таблице пользователей у вас есть столбец group , в котором значение 1 представляет группу "администратор", а 2 - группу "автор". Вы планируете иметь две RBAC роли admin и author , представляющие разрешения для двух соответствующих групп. Вы можете настроить данные роли как показано ниже.

Обратите внимание, так как "author" добавлен как дочерняя роль к "admin", следовательно в реализации метода execute() класса правила вы должны учитывать эту иерархию. Именно по этому для роли "author" метод execute() вернёт истину, если пользователь принадлежит к группам 1 или 2 (это означает, что пользователь находится в группе администраторов или авторов)

Далее, настроим authManager с помощью перечисления ролей в свойстве [[yii\rbac\BaseManager::$defaultRoles]]:

Теперь, если вы выполните проверку доступа, для обоих ролей admin и author будет выполнена проверка правила асоциированного с ними. Если правило вернёт истину, это будет означать что роль применяется к текущему пользователю. На основании правила, реализованного выше, если пользователь входит в группу 1 пользователю будет назначена роль admin ; и если значение group равно 2 будет применена роль author .

Note: этот раздел находится на стадии разработки.

Авторизация — это процесс проверки того, что пользователь имеет достаточно прав, чтобы выполнить какие-то действия. Yii предоставляет два метода авторизации: фильтры контроля доступа (ACF) и контроль доступа на основе ролей (RBAC).

Фильтры контроля доступа (ACF) являются простым методом, который лучше всего использовать в приложениях с простым контролем доступа. Как видно из их названия, ACF — это фильтры, которые могут присоединяться к контроллеру или модулю как поведение. ACF проверяет набор правил доступа, чтобы убедиться, что пользователь имеет доступ к запрошенному действию.

Код ниже показывает, как использовать ACF фильтр, реализованный в yii\filters\AccessControl:

Код выше показывает ACF фильтр, связанный с контроллером site через поведение. Это типичный способ использования фильтров действий. Параметр only указывает, что фильтр ACF нужно применять только к действиям login , logout и signup . Параметр rules задаёт правила доступа, которые означают следующее:

Разрешить всем гостям (ещё не прошедшим авторизацию) доступ к действиям login и signup . Опция roles содержит знак вопроса ? , это специальный токен обозначающий "гостя".
Разрешить аутентифицированным пользователям доступ к действию logout . Символ @ — это другой специальный токен, обозначающий аутентифицированного пользователя.

Когда фильтр 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) обеспечивает простой, но мощный централизованный контроль доступа. Пожалуйста, обратитесь к Wikipedia для получения информации о сравнении RBAC с другими, более традиционными, системами контроля доступа.

Yii реализует общую иерархическую RBAC, следуя NIST RBAC model. Обеспечивается функциональность RBAC через компонент приложения authManager.

Использование RBAC состоит из двух частей. Первая часть — это создание RBAC данных авторизации, и вторая часть — это использование данных авторизации для проверки доступа в том месте, где это нужно.

Для облегчения последующего описания, мы сначала введём некоторые основные понятия RBAC.

И роли, и разрешения могут быть организованы в иерархию. В частности, роль может содержать другие роли или разрешения; и разрешения могут содержать другие разрешения. Yii реализует частично упорядоченную иерархию, которая включает в себя специальные деревья иерархии. Роль может содержать разрешение, но обратное не верно.

Перед определением авторизационных данных и проверкой прав доступа, мы должны настроить компонент приложения authManager. Yii предоставляет два типа менеджеров авторизации: yii\rbac\PhpManager и yii\rbac\DbManager. Первый использует файл с PHP скриптом для хранения данных авторизации, второй сохраняет данные в базе данных. Вы можете использовать первый, если ваше приложение не требует слишком динамичного управления ролями и разрешениями.

Следующий код показывает как настроить в конфигурации приложения authManager с использованием класса yii\rbac\PhpManager:

Теперь authManager может быть доступен через \Yii::$app->authManager .

Замечание: По умолчанию, yii\rbac\PhpManager сохраняет данные RBAC в файлах в директории @app/rbac/ . Убедитесь что данная директория и файлы в них доступны для записи Web серверу, если иерархия разрешений должна меняться онлайн.

Следующий код показывает как настроить в конфигурации приложения authManager с использованием класса yii\rbac\DbManager:

Примечание: Если вы используете шаблон проекта basic, компонент authManager необходимо настроить как в config/web.php , так и в конфигурации консольного приложения config/console.php . При использовании шаблона проекта advanced authManager достаточно настроить единожды в common/config/main.php .

DbManager использует четыре таблицы для хранения данных:

: таблица для хранения авторизационных элементов. По умолчанию "auth_item". : таблица для хранения иерархии элементов. По умолчанию "auth_item_child". : таблица для хранения назначений элементов авторизации. По умолчанию "auth_assignment". : таблица для хранения правил. По умолчанию "auth_rule".

yii migrate --migrationPath=@yii/rbac/migrations

Теперь authManager может быть доступен через \Yii::$app->authManager .

Для создания данных авторизации нужно выполнить следующие задачи:

определение ролей и разрешений;
установка отношений между ролями и правами доступа;
определение правил;
связывание правил с ролями и разрешениями;
назначение ролей пользователям.

Если иерархия прав не меняется, и количество пользователей зафиксировано, вы можете создать консольную команду, которая будет единожды инициализировать данные через APIs, предоставляемое authManager :

Note: Если вы используете шаблон проекта advanced, RbacController необходимо создать в директории console/controllers и сменить пространство имён на console\controllers .

После выполнения команды yii rbac/init мы получим следующую иерархию:

Автор может создавать пост, администратор может обновлять пост и делать всё, что может делать автор.

Как упомянуто выше, правила добавляют дополнительные ограничения на роли и разрешения. Правила — это классы, расширяющие yii\rbac\Rule. Они должны реализовывать метод execute(). В иерархии, созданной нами ранее, автор не может редактировать свой пост. Давайте исправим это. Сначала мы должны создать правило, проверяющее что пользователь является автором поста:

Правило выше проверяет, что post был создан $user . Мы создадим специальное разрешение updateOwnPost в команде, которую мы использовали ранее:

Теперь мы имеем следующую иерархию:

С готовыми авторизационными данными проверка доступа — это просто вызов метода yii\rbac\ManagerInterface::checkAccess(). Так как большинство проверок доступа относятся к текущему пользователю, для удобства Yii предоставляет сокращённый метод yii\web\User::can(), который можно использовать как показано ниже:

Если текущий пользователь Jane с мы начнём с createPost и попробуем добраться до Jane :

Для того чтобы проверить, может ли пользователь обновить пост, нам надо передать дополнительный параметр, необходимый для правила AuthorRule , описанного ранее:

Вот что происходит если текущим пользователем является John:

Мы начинаем с updatePost и переходим к updateOwnPost . Для того чтобы это произошло, правило AuthorRule должно вернуть true при вызове метода execute . Метод получает $params , переданный при вызове метода can , значение которого равно ['post' => $post] . Если всё правильно, мы увидим, что author привязан к John.

В случае Jane это немного проще, потому что она admin:

Есть несколько способов реализовать авторизацию в контроллере. Если вам необходимы отдельные права на добавление и удаление, то проверку стоит делать в каждом действии. Вы можете либо использовать условие выше в каждом методе действия, либо использовать yii\filters\AccessControl:

Если права на все CRUD операции выдаются вместе, то лучшее решение в этом случае — завести одно разрешение вроде managePost и проверять его в yii\web\Controller::beforeAction().

Роль по умолчанию — это роль, которая неявно присваивается всем пользователям. Вызов метода yii\rbac\ManagerInterface::assign() не требуется, и авторизационные данные не содержат информации о назначении.

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

Предположим что в таблице пользователей у вас есть столбец group , в котором значение 1 представляет группу "администратор", а 2 — группу "автор". Вы планируете иметь две RBAC роли: admin и author , представляющие разрешения для двух соответствующих групп. Вы можете настроить данные роли как показано ниже.

Обратите внимание, так как "author" добавлен как дочерняя роль к "admin", следовательно, в реализации метода execute() класса правила вы должны учитывать эту иерархию. Именно поэтому для роли "author" метод execute() вернёт истину, если пользователь принадлежит к группам 1 или 2 (это означает, что пользователь находится в группе администраторов или авторов)

Далее настроим authManager с помощью перечисления ролей в свойстве yii\rbac\BaseManager::$defaultRoles:

Теперь, если вы выполните проверку доступа, для обоих ролей admin и author будет выполнена проверка правила, асоциированного с ними. Если правило вернёт истину, это будет означать, что роль применяется к текущему пользователю. На основании правила, реализованного выше: если пользователь входит в группу 1, пользователю будет назначена роль admin ; и если значение group равно 2, будет применена роль author .

Читайте также: