Как отклонить вход пользователю с определённой ролью на Yii2?

Question

[GONJY MONJY]

Здравствуйте! Я сделал проверку роли пользователя, чтобы запретить вход пользователю, чья почта не подтверждена. Но код слегка не работает. выдаётся такая ошибка:
Object of class app\modules\userAuth\models\User could not be converted to string.

Вот этот код - это метод проверки роли:

public function checkUserRole(){

        $user = User::findOne(['username' => $this->username]);
        $role = Yii::$app->authManager->getRolesByUser($user);

        if($role === "user"){
            return false;
        }
        if($role === "active"){
            return true;
        }
    }

Вот этот код - это actionLogin в контроллере:

public function actionLogin(){

        $model = new LoginForm();
        
        if(!Yii::$app->user->isGuest){
            return $this->goHome();
        }

        if($model->load(Yii::$app->request->post()) && $model->login()){
            if($model->checkUserRole() === true){
                return $this->goHome();
            } else{
                Yii::$app->user->logout();
                Yii::$app->getSession()->setFlash('error','Please, confirm your E-mail!');  
                return $this->goHome();
            }
        }

        $model->password = '';
        
        return $this->render('login', compact('model'));

    }

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

Answer 1

[Максим]

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

Yii::$app->getAuthManager()->checkAccess(32, 'admin')

Данная функция позволит проверять доступ для остальных пользователей. Хорошая практика — использоовать ошибки в виде исключений с ошибкой 403 и сообщением:

public function actionLogin()
{
    $model = new LoginForm();
    $model->password = ''; // перенести в метод rules формы, как default

    if($model->load(Yii::$app->request->post()) && $model->login()){
        $user = User::findOne(['username' => $this->username]);
        if(Yii::$app->getAuthManager()->checkAccess($user->getId(), 'admin')){
            throw new ForbiddenHttpException('Ошибка доступа');
        }

        return $this->goHome();
    }

    return $this->render('login', [
        'model' => $model
    ]);
}

Если же вам нужно использовать проверку для текущего пользователя - это вполне можно вынести в поведения:

public function behaviors()
{
    return [
        'access' => [
            'class' => AccessControl::class,
            'rules' => [
                [
                    'actions' => ['create', 'update'],
                    'allow' => true,
                    'matchCallback' => function ($rule, $action) {
                        /** @var User $identity */
                        $identity = Yii::$app->user->getIdentity();
                        return $identity->isAdmin(); // или другая проверка
                    }
                ],
            ],
        ],
    ];
}

public function behaviors()
{
    return [
        'access' => [
            'class' => AccessControl::class,
            'rules' => [
                [
                    'actions' => ['create', 'update'],
                    'allow' => true,
                    'roles' => ['admin']
                ],
            ],
        ],
    ];
}

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

• Если пользователь гость, вызывается yii\web\User::loginRequired(), который перенаправляет браузер на страницу входа.
  
• Если пользователь авторизован, генерируется исключение yii\web\ForbiddenHttpException.
  

Более сложные правила можно выносить в свои фильтры AccessControl

Ссылки на документацию по теме:

1. yii\web\User
   
2. yii\rbac\ManagerInterface
   
3. yii\rbac\CheckAccessInterface
   

Comments

[GONJY MONJY]

То есть я ничего не могу поделать с функцией checkUserRole()?

+ я немного не понимаю, как устроен этот метод:

Yii::$app->getAuthManager()->checkAccess(32, 'admin');

Что он вообще проверяет?

[Максим]

GONJY MONJY, Можете. Почитайте в документации, что возвращает ваша функция
Yii::$app->authManager->getRolesByUser($user)

Функция работает с интерфейсом CheckAccessInterface

Yii::$app->getAuthManager()->checkAccess(32, 'admin');

[GONJY MONJY]

Максим, спасибо большое, очень выручили

[Максим]

GONJY MONJY, не за что) А вообще если проверка для авторизовнного пользователя можно её осуществлять в behaviors или Yii::$app->user->can('admin'); При это User это yii\web\User, в котором есть метод can()

[Игорь Васильев]

GONJY MONJY, в списке пользователей есть некий статус, у каждого проекта он свой.
Логично в модели пропуска к сайту или к определённым страницам сделать такую проверку:

...
    public function validatePassword($attribute, $params)
    {
        if (!$this->hasErrors()) {
            $user = $this->getUser();
            if (!$user || !$user->validatePassword($this->password)) {
                $this->addError($attribute, Yii::t('users', 'PASSWORDFALSE'));
            } elseif ($user && $user->action == 3) { // если юзер забанен
                $this->addError('email', Yii::t('users', 'LOGINBLOCK', ['url' => Html::a( Yii::t('users', 'More details'), '/info' )])); // ссылка на пояснение, почему забанен
            } elseif ($user && $user->action == 1) { // если юзер не активирован
                $this->addError('password', Yii::t('users', 'ACTIVEACCOUNT'));
            }
        }
    }
...

Блочить определённого пользователя, это нормально, если он ведёт себя неадекватно, нарушает пользовательское соглашение и так далее. Так же хорошая практика со СПАМерами и хулиганами, на этапе регистрации, даже если у вас стоит валидация на СПАМ, юзер может проскочить, так как данный юзер ещё недостаточно хорошо нашкодил, чтобы интернет внёс его в чёрный список. Данное решение позволяет хранить данные о пользователе без удаления, анализ данных (Если вы отслеживаете IP адрес, таким образом отсекается рецедив регистрации по IP - но это так себе защита, однако кое какое решение).
Так вот, данная валидация проверяет и на наличие статуса "не активирован", вы понимаете? Одна цифра решает ВСЁ, она как таможенник, вы - проходите, у вас - не оформлены документы, вам - выезд запрещён. Я реализовал вообще смену статуса юзера по клику.
То есть, если я или модератор, или пользователи видят нарушения, сыплются жалобы, клац и проблема решена. Мне кажется ЭТО ваше решение, не за чем ставить ограничения по ролям, это лишняя нагрузка на проект, тем более, можно потом каждый год к примеру удалять через транзакции всех заблокированных и не активных, и вообще по барабану, какие у него роли, разрешения и уровни доступа. ;-)

[Максим]

Игорь Васильев, ваш пример с валидацией слишком сложный для валидации. В нем включена бизнес логика. Это не совсем правильно. В любой модели при сохранении можно поставить ->save(false)и валидация модели будет исключена. Соотвественно ваше бизнес правило не будет учтено, что является существенным нарушением бизнес логики. Поэтому, валидация - это проверка на более высоком уровне передаваемых данных. Она может дублироваться с бизнес логикой, но расчитывать только на валидацию нельзя.

И не очень понятно, почему вы начали обсуждать блокировку пользователя. Хотя требуется проверка подтверждения. Блокировка - это скорее всего статус. Подтверждение - это confirmToken

Так же хранить статус в виде числа не очень хорошая затея. Вам постоянно придётся помнить что 1-это активен, а 2-заблокирован. Если у вас не высоконагруженная система имеет смысл статусы хранить в виде строки «active», «blocked»... читать такие данные удобнее при запросах и в базе данных.

[Игорь Васильев]

Максим, я вас услышал. Это вы меня не поняли. Статусы хранит не БД, а модель, которая работает с пользователями, для того, чтобы понять, что за что отвечает, заходим в эту модель, и смотрим значение приватных переменных. Я специально не указывал в примере, чтобы не показывать, как в действительности выглядит код у меня, таким образом я могу поменять значение приватных переменных и логика сохранится. Мне не надо "помнить" что значит это переменная, так как её название отражает суть.

В любой модели при сохранении можно поставить ->save(false)

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

Моя бизнес логика написана отдельно от модели, которая работает с пользователями, так же у меня есть отдельная логика для регистрации, смены пароля, смены e-mail, восстановления аккаунта и так далее. Если у вас всё хранится в одной модели или в одном контроллере вместе со всеми иф и эльс, то мне вас жаль.

Почему статусы и доступы у меня отдельно, объясняю:
1) У всех пользователей есть 3 основных статуса
(новый, активированный, заблокированный)
2) Количество ролей может быть сколько угодно
3) Разрешений у конкретной роли может быть сколько угодно

Вывод: Если я создаю роль админа и модератора, я должен добавить как минимум по две роли для каждой роли, и того при создании новой роли активного, я должен добавить по две роли заблокированного и нового. Эту ситуацию предусмотрели, поэтому придуманы разрешения, но их надо вручную добавлять или менять для каждого пользователя, либо писать транзакции и вешать крон, чтобы менять эти самые разрешения для для всех ролей.
Таким образом, давать доступы только через роли и разрешения настоящий геморрой.
И как вы одним запросом получите количество всех статусов не имея статусы???
Таким образом, за каждым пользователем можно закрепить некий статус. Его то можно менять вне зависимости, админ это, модератор или покупатель, или простой пользователь.
Я практикую присвоение роли сразу после регистрации, та что по умолчанию, вы можете давать по умолчанию - любую (по вкусу запаху и цвету).
Я составил бизнес логику так, что вне зависимости от валидации, которую кстати могу цеплять за любой импут, за какой мне вздумается, я могу ограничить доступ любому пользователю, не зависимо от его роли и разрешений. Если он не активировал свой аккаунт по SMS или по e-mail - или всё вместе, он не сможет пользоваться сервисом никак, а это и нужно человеку, который задавал вопрос:

Я сделал проверку роли пользователя, чтобы запретить вход пользователю

- читать вверху, где вопрос.
То есть человек спрашивает вас, как мне запретить вход тем, кто не подтвердил свой электронный адрес. Это тривиальная повседневная задача во всех проектах, проверить, что пользователь реальный. Кому нужны боты и спамеры???

Если у вас не высоконагруженная система имеет смысл статусы хранить в виде строки «active», «blocked»... читать такие данные удобнее при запросах и в базе данных.

Как раз для высоко нагруженных проектов чем меньше обработка байт информации тем лучше, сколько весит int "1" и varchar "blocked" ???
Про приватные переменные или константы - не? не слышали?
Почему помнить должен программист а не программа? Разве не для того изобрели компьютеры, чтобы они а не люди, хранили информацию, обрабатывали информацию, искали информацию. А как же человеческий фактор - устал, забыл, заболел, потерял.
Или вам поднять историю людей, которые работали в архивах и библиотеках?
Может быть вы забыли про bool ??? true | false => аналог 1 / 0
Таким образом ещё быстрее. Впустить или запретить?

<?php 
$solution = ($user) ? 'Впустить' : 'запретить';
?>

Моя ошибка лишь в том, что я не объяснил как этим кодом пользоваться и где вставлять.
Мой пример работает с этой валидацией

[Максим]

Игорь Васильев,

Статусы хранит не БД, а модель, которая работает с пользователями, для того, чтобы понять, что за что отвечает, заходим в эту модель, и смотрим значение приватных переменных.

Вы не внимательный! А я про код и не говорил. Я говорил именно про БД и запросы. Хорошей практикой на нагруженных проектах является разделение записи и чтения данных. При чтении используют SQL или QueryBuilder. Так же с БД вы можете работать и без кода. Администратор баз данных не программист, который знает, что за статус 1. Или в API документации вам придётся писать что значит статус 1, что значит статус 2 или 100. И так далее. Я вам привёл несколько простых типичных примеров, когда вам без доступа к коду не обойтись. Особенно это сложно с использованием разных людей отвечающих за разные вещи. frontend разработчику придётся давать доступ в код или описывать доку по каждому статусу. Да и вам самим будет не удобно искать каждый раз модель и узнавать что значит 1. Дело ваше, но я описал типичные проблемы, которые можно упростить. Не говоря о том, что даже ID в распределительных системах иногда делают не простым числовым а составными и смысловыми, для понимания и чтения. Но сейчас не об этом.

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

Даже если в вашем случае нельзя из-за инкапсуляции, то у вас другая проблема появляется: Тестирование валидации, Нарушение правил SOLID.

Моя бизнес логика написана отдельно от модели, которая работает с пользователями, так же у меня есть отдельная логика для регистрации, смены пароля, смены e-mail, восстановления аккаунта и так далее. Если у вас всё хранится в одной модели или в одном контроллере вместе со всеми иф и эльс, то мне вас жаль.

Что вы имеете ввиду под моделью? Domain Model или модель Yii? Я вам скинул репозиторий доменной модели юзера. Посмотрите) А уж в контроллере у меня точно нет никакой логики и состояния. И не понятно чего ж меня жаль?)

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

Тут я вас вообще не понял и причём тут роли? Я с самого начала не пойму. Вас занесло не туда.

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

Роли это объединение разрешений в группу. Присваиваете роль и присваиваются разрешения. Чтобы не менять для каждого пользователя - используйте роли. А при добавлении разрешения в роль она сразу доступна всем, кто имеет эту роль. Теперь ещё и крон откуда-то. Можете про роли вообще не комментировать. О них речи не шло и даже обсуждать это не хочу.

И как вы одним запросом получите количество всех статусов не имея статусы???

Я говорил что статусы не нужны? Вы вообще смотрели мой код? Там статусы есть или я один вижу?

Я практикую присвоение роли сразу после регистрации, та что по умолчанию, вы можете давать по умолчанию - любую (по вкусу запаху и цвету).

К чему это?

Я составил бизнес логику так, что вне зависимости от валидации, которую кстати могу цеплять за любой импут

К чему это? Вы все решили обсудить?

То есть человек спрашивает вас, как мне запретить вход тем, кто не подтвердил свой электронный адрес. Это тривиальная повседневная задача во всех проектах, проверить, что пользователь реальный. Кому нужны боты и спамеры???

Вот именно «как мне запретить вход тем, кто не подтвердил свой электронный адрес» причём тут роли? В прочем тоже можете не отвечать.

Как раз для высоко нагруженных проектов чем меньше обработка байт информации тем лучше, сколько весит int "1" и varchar "blocked" ???

Вы точно не внимательный. Я и написал:

Если у вас не высоконагруженная система имеет смысл статусы хранить в виде строки «active», «blocked»...

Вы даже сами это процитировали. Беда...

Про приватные переменные или константы - не? не слышали?
Почему помнить должен программист а не программа?

Ответил выше. Про использовании в API и базе данных. Код «не торчит на ружу» для всех!

Вы все в кучу смешали, а по делу ноль. Разве что на верстку не перешли. Где-то не в тему, где-то пытаетесь доказать что не опровергаю, где-то не слышите и не видите. В принципе так было и в других ваших комментариях. Я не удивлён. Вы даже ссылку указали не на официальную доку, а копию. Не умеете пользоваться официальной? Или когда-то была проблема с русским, тогда удивлю - есть перевод на русском.

Сразу видно ваш уровень. А ещё не так давно вы задавали вопрос на который я вам давал ответ, который вы с удивлением прокомментировали, где вы не знаете о простых вещах

Я не знал, что консольные запросы можно тащить через контроллер прямо на сайте и получать результат!!! Фантастика!

. Поэтому нет смысла что-то доказывать мне.

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

[Игорь Васильев]

Максим, эта платформа создана для решения вопросов по программированию, а не для выяснения отношений, если у вас личная неприязнь ко мне, разбирайтесь лично со мной а не сорите в комментариях, это отвлекает людей от решения задачи.