Yii2 AuthClient. Расширение для входа на сайт и регистрации через социальные сервисы
Встроенный механизм Yii2 для проверки подлинности пользователя с помощью сторонних сервисов
Главная
Блог
Yii2 AuthClient. Расширение для входа на сайт и.
Данное расширение добавляет OpenID, OAuth и OAuth2 требующиеся для Yii framework 2.0. Оно нужно, когда хотите добавить возможность входа/регистрации пользователей на вашем проекте с помощью социальных сервисов (Вконтакте, Twitter, Google, Facebook и другие). Удобно использовать вместе с расширением yii2-user (вот наша статья про то расширение).
Установка расширения
Вот описано расширение Yii2 AuthClient на Github. Это встроенный механизм Yii2 для проверки подлинности пользователя с помощью сторонних сервисов, которые используют OpenID, OAuth и OAuth2. Например, человек может зарегистрироваться у вас на сайте, используя свой профиль в Google или Twitter, а не заполнять поля формы регистрации.
Устанавливаем AuthClient, как и положено через composer.
в секцию require вашего composer.json.
После установки расширения надо сделать настройку компонента приложения auth client collection. Для этого добавьте в ваш конфиг (у меня это config/web.php ) в массиве компонентов
Я для класса клиента использую путь расширения yii2-user: dektrium\user\clients\.
Если вы не используете его, то указывайте yii\authclient\clients\GoogleOAuth
Добавляем виджет AuthClient на страницы входа и регистрации
На странице входа, если вы используете расширение Yii2-user, отображает иконки входа через социальные сервисы. Это и есть AuthClient. Но на странице регистрации их пока нет. Это очень просто сделать, используя механизм переопределения видов в Yii2-user.
Для этого в конфиге config/web.php в компоненты добавляем view
Дальше помещаем представление register в нашу папку
чтобы добавим в страницу регистрации виджет AuthConnect и перекрыть своим видом register тот register, который используется в yii2-user. Вот наше содержимое @app/views/user/registration/register.php , мы добаили только виджет Connect, который показывает значки соц сервисов
Теперь на странице регистрации появились значки
Далее
Доступны следующие клиенты
[[\yii\authclient\clients\Facebook|Facebook]].
[[yii\authclient\clients\GitHub|GitHub]].
Google (с помощью [[yii\authclient\clients\Google|OAuth]] и [[yii\authclient\clients\GoogleHybrid|OAuth Hybrid]]).
[[yii\authclient\clients\LinkedIn|LinkedIn]].
[[yii\authclient\clients\Live|Microsoft Live]].
[[yii\authclient\clients\Twitter|Twitter]].
[[yii\authclient\clients\VKontakte|VKontakte]].
[[yii\authclient\clients\Yandex|Yandex]].
Конфигурация для каждого клиента немного отличается. Например, для OAuth нужно обязательно получать ID клиента и секретный ключ сервиса, который Вы собираетесь использовать. Для OpenID всё должно заработать «из коробки».
Расширение это удобное и дорабатывается, поэтому следите за его обновлениями на Github и внедряйте в свои проекты.
Yii2 — подтверждение регистрации на сайте по email.
Описание конечного результата: после заполнении формы на странице регистрации, пользователь перенаправляется на главную страницу, где ему выводится флэш сообщение «Проверьте свою электронную почту для подтверждения регистрации» (тексты по-умолчанию на английском). Пользователю отправляется письмо со ссылкой, перейдя по которой, в базе данных его статус меняется на «активен», после чего он сможет залогиниться на сайте. Таким образом проверяем указанный им, при регистрации, электронный адрес.
Процесс состоит из нескольких простых пунктов и используется для фреймворка yii2 версии advanced.
В файле миграции которая создает таблицу user («из-коробки» находится в console/migrations/m130524_201442_init.php ) меняем значение для поля «status» на ««, что бы, по-умолчанию, пользователь считался не активным:
Создаем новую миграцию – добавляем поле ‘email_confirm_token‘ для хранения токена в таблицу user: При регистрации будет сгенерирована случайная строка и сохранена в это поле. Потом она будет отправлена пользователю на его электронный адрес в ссылке для перехода.
Корректируем «модель» (сущность) User. По-умолчанию в фреймворке версии advanced уже создан файл User.php в common/models . В начале класса добавляем константу: Данный статус будет означать, что пользователь зарегистрировался но еще не подтвердил свой email. Меняем метод rules:
Метод findByUsername меняем на:
Контроллер, действие «signup». По-умолчанию, за регистрацию пользователей отвечает метод actionSignup в frontend/controllers/SiteController.php Меняем данный метод таким образом:
Строкой подключаем класс валидации формы. Далее, пытаемся загрузить данные из POST запроса и если они прошли проверку, то создается объект класса-сервиса, который и будет заниматься регистрацией.
Сервис регистрации. Основную логику касающуюся регистрации пользователей вынесем в отдельный класс. Файл common/services/auth/SignupService.php :
Учтите, что пространства имен для User и SignupForm (сверху для директивы use) у вас будут отличаться. Метод signup будет заниматься созданием нового пользователя в базе данных. Данный метод заменяет одноименный метод из SignupForm (по-умолчанию в frontend\models\SignupForm.php ), поэтому от туда его можно удалить.
Метод sentEmailConfirm отправляет регистрирующемуся пользователю письмо со ссылкой для подтверждения регистрации.
Метод confirmation будет использоваться для проверки токена при переходе пользователя по ссылке подтверждения (ссылка будет содержать данный параметр, который будет найден в базе данных). Если токен верный, то поле email_confirm_token очищается: и пользователь получает статус «акивен»:
Вызовы этих методов сервиса в контроллере обернуты в блок try-catch, и в случае ошибки пользователь увидит соответствующее флэш сообщение, так же ошибки запишутся в логи для администратора.
Письма подтверждения регистрации. Метод sentEmailConfirm класса SignupService отправляет письма пользователю для подтверждения регистрации. При этом используются шаблоны с текстом для html версии — ‘user-signup-comfirm-html‘ и простой текстовой версии – ‘user-signup-comfirm-text‘. Создаем соответствующие файлы:
Пользователь получит такой текст сообщения: Hello Name, Follow the link below to confirm your email: http://example.com/site/signup-confirm?token=SjfUrPihsY2peMqb7XB45_TRfBRvadRu
Сама ссылка может отличаться в зависимости от установленных правил маршрутизации в вашем приложении. Как видим, обрабатывать переход по ней будет SiteController с действием signup-confirm.
Контроллер, действие «signup-confirm». Данное действие использует все тот-же сервис для регистрации, вызывая его метод confirmation.
Контроллер, действие «login». На данном этапе все уже работает, но может возникнуть ситуация, что пользователь будет пытаться залогиниться еще до того, как подтвердит свой email. Если не поправить действие login, то он увидит сообщение «Incorrect username or password.» что не правильно. Вместо этого покажем ему «To complete the registration, confirm your email. Check your email.». Для этого меняем:
Так же в моделе формы – класс LoginForm (по-умолчанию находится в common/models/LoginForm.php ) меняем метод login:
Это все. Не забудьте в контроллере подключить:
Реализация метода «логин под другим юзером» в yii2
Допустим, вы вошли на сайт как администратор, но ваша цель — выдать себя за другого пользователя. Это может быть полезно, если вы хотите узнать, как приложение выглядит и «ведет себя» себя при просмотре другим пользователем.
Вначале работы настройки компонента user (config/web.php) Вашего приложения должны выглядеть примерно так:
Для облегчения работы с пользовательским компонентом переопределим пользовательский класс приложения по умолчанию и поместим в него некоторые полезные методы. Давайте назовем этот класс WebUser, чтобы избежать путаницы между пользователем Active Record и пользователем приложения.
Чтобы залгониться под другим пользователем, нужно создать два отдельных действия внутри UserController. Первое действие — actionImpersonate и оно будет отвечать за переключение на другую личность. Второй — actionStopImpersonating и он отвечает за возвращение к нашей основной личности. Поскольку эти действия касаются конфиденциальной информации и учетных данных, крайне важно установить AccessControl поведение и быть уверенным, что никто, кроме как admin, не сможет переключиться на другую личность.
Когда авторизация выполнена успешно, то мы попадаем на личный кабинет требуемого пользователя. Обычно такая авторизация полезна, когда администратору системы необходимо проверить панель обычного пользователя, для поддержки, отладки или просто для того, чтобы убедиться, что приложение используется правильно.
Как осуществить авторизацию / регистрацию в Yii2 по уникальному никнейму?
25.06.2020, 20:55
Осуществить регистрацию и авторизацию через MySQL Кто может помочь осуществить регистрация и авторизацию через MySQL Проект для Cyberforum! Что.
Как быстро сделать регистрацию/авторизацию Как побыстрому на простом сайте сделать регистрацию и авторизацию? Меня интересует готовый шаблон.
Как сделать регистрацию и авторизацию основанную на сессииях Как сделать регистрацию и авторизацию основанную на сессииях,можете дать код,заpанее благодаpю.
Как создать простейшую регистрацию и авторизацию на сайте Как создать простейшую регистрацию и авторизацию на сайте использую php и mysql?
Интеграция dle+vb: как реализовать регистрацию и авторизацию Здравствуйте, хочу сделать интеграцию dle 9.6 + форум vbulletin нужна регистрация, авторизация.
С регистрацией я разобрался- как сделать по одному username а вот как логиниться по одному юсернейму и если усернейма не существует то добавлять пользователя как нового -+ помогите разобраться пожайлуста с вопросом по созданию поля ии кнопки перевода сумм другим пользователям + отображения транакций для каждого пользователя в этом разделе
Добавлено через 5 часов 58 минут Как авторизовать пользователя по никнейму — если никнейма в базе нет то автоматом создать пользователя с этим никнеймом! Как реализовать
Добавлено через 7 часов 6 минут Можете подсказать?
26.06.2020, 20:22
8
Примерно так, но не знаю на сколько это правильно, не пробовал такое в деле
26.06.2020, 20:22
26.06.2020, 20:22
Как убрать Авторизацию и Регистрацию у Залогиново пользователя? Добрый вечер господа, столкнулся с такой причиной, На странице есть форма «Регистрации и.
Люди! Как в Access сделать авторизацию(с логином и паролем) и регистрацию? Меня попросила девочка сделать дипломную работу(базу) «Онлайн выстовка детских работ». Я сделала.
Как сделать авторизацию и регистрацию без перезагрузки страницы joomla 2.5 Подскажите, пожалуйста, как можно реализовать авторизацию и регистрацию без перезагрузки страницы.
p0vidl0.info
Кодинг, админинг и прочие развлечения
Yii2: Управление пользователями RBAC
Во многих приложениях проблема управления пользователями стоит чуть ли не на первом месте и поэтому в php-фреймворк yii2 включена поддержка управления правами доступа на основе ролей. Но собрать весь имеющийся функционал воедино и дописать недостающие функции — далеко не всегда будет легко и быстро. Здесь на помощь приходит расширение webvimark/module-user-management, имеющее следующие возможности:
Управление пользователями;
RBAC (роли, разрешения и прочее) с веб-интерфейсом;
Регистрация, авторизация, восстановление пароля;
Логи посещений;
Хорошая оптимизация (0 запросов к базе данных при обычном рабочем процессе);
Удобные виджеты, например GhostMenu или GhostHtml::a, которые отображаются только если у пользователя есть соответствующие права.
Установка
Установка не представляет из себя ничего не обычного, она описана в документации расширения. Читать подробнее об установке расширений в yii2.
Настройка
Первый шаг
Добавляем компонент и модуль в файле config/web.php:
Второй шаг
Для функционирования миграции в консоли, добавим соответствующий модуль в файле config/console.php:
Третий шаг
Четвертый шаг
Добавляем поведение в основной контроллер:
Возможные действия
Начало работы
По началу, из этого меню вы сможете увидеть только два пункта — Вход и Выход. А все потому, что у вас недостаточно прав для остальных пунктов меню.
Подобным образом работают и GhostNav::widget() and GhostHtml:a().
Войдите используя superadmin/superadmin;
Перейдите в раздел Permissions;
Перейдите в раздел Roles;
Перейдите в раздел User:
Осознайте, что все работает и расслабьтесь.
Использование
Контроллеры могут иметь два свойства, которые делают весь контроллер или выбранное действие доступными всем:
Полезные хэлперы
Для подробностей — смотрите код соответствующих функций.
Управление ролями и доступом
События
События могут быть получены следующим образом:
Расширенный профиль пользователя
Для создания расширенного профиля пользователя с аватаром, днем рождения и прочими свойствами, нужно самостоятельно разработать профили, не затрагивая данное расширение:
Авторизация ¶
Примечание: этот раздел находится на стадии разработки.
Авторизация — это процесс проверки того, что пользователь имеет достаточно прав, чтобы выполнить какие-то действия. 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\web\User::loginRequired(), который перенаправляет браузер на страницу входа.
Если пользователь авторизован, генерируется исключение yii\web\ForbiddenHttpException.
Вы можете переопределить это поведение, настроив свойство 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 адресам.
verbs: задаёт http метод (например, GET , POST ), соответствующий правилу. Сравнение — регистронезависимо.
matchCallback: задаёт PHP колбек, который вызывается для определения, что правило должно быть применено.
denyCallback: задаёт PHP колбек, который будет вызван, если доступ будет запрещён при вызове этого правила.
Ниже показан пример, показывающий использование опции matchCallback , которая позволяет писать произвольную логику проверки доступа:
Контроль доступа на основе ролей (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 может быть доступен через \Yii::$app->authManager .
Замечание: По умолчанию, yii\rbac\PhpManager сохраняет данные RBAC в файлах в директории @app/rbac/ . Убедитесь что данная директория и файлы в них доступны для записи Web серверу, если иерархия разрешений должна меняться онлайн.
Настройка authManager с помощью DbManager ¶
Следующий код показывает как настроить в конфигурации приложения authManager с использованием класса yii\rbac\DbManager:
DbManager использует четыре таблицы для хранения данных:
itemTable: таблица для хранения авторизационных элементов. По умолчанию «auth_item».
itemChildTable: таблица для хранения иерархии элементов. По умолчанию «auth_item_child».
assignmentTable: таблица для хранения назначений элементов авторизации. По умолчанию «auth_assignment».
ruleTable: таблица для хранения правил. По умолчанию «auth_rule».
Прежде чем вы начнёте использовать этот менеджер, вам нужно создать таблицы в базе данных. Чтобы сделать это, вы можете использовать миграцию хранящуюся в файле @yii/rbac/migrations :
Теперь authManager может быть доступен через \Yii::$app->authManager .
Создание данных авторизации ¶
Для создания данных авторизации нужно выполнить следующие задачи:
определение ролей и разрешений;
установка отношений между ролями и правами доступа;
определение правил;
связывание правил с ролями и разрешениями;
назначение ролей пользователям.
В зависимости от требований к гибкости авторизации перечисленные задачи могут быть выполнены разными путями.
Если иерархия прав не меняется, и количество пользователей зафиксировано, вы можете создать консольную команду, которая будет единожды инициализировать данные через APIs, предоставляемое authManager :
Примечание: Если вы используете шаблон проекта advanced, RbacController необходимо создать в директории console/controllers и сменить пространство имён на console\controllers .
После выполнения команды yii rbac/init мы получим следующую иерархию:
Автор может создавать пост, администратор может обновлять пост и делать всё, что может делать автор.
Если ваше приложение позволяет регистрировать пользователей, то вам необходимо сразу назначать роли этим новым пользователям. Например, для того, чтобы все вошедшие пользователи могли стать авторами в расширенном шаблоне проекта, вы должны изменить frontend\models\SignupForm::signup() как показано ниже:
Для приложений, требующих комплексного контроля доступа с динамически обновляемыми данными авторизации, существуют специальные пользовательские интерфейсы (так называемые админ-панели), которые могут быть разработаны с использованием API, предлагаемого authManager .
Использование правил ¶
Как упомянуто выше, правила добавляют дополнительные ограничения на роли и разрешения. Правила — это классы, расширяющие 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» в таблице пользователей, и каждый пользователь принадлежит к какой-то группе. Если каждая группа может быть сопоставлена роли в модели 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 .
Yii2 – Регистрация. Регистрируем пользователя
19.03.2020
И
Комментариев нет
Общение в Телеграм группе: https://goo.gl/Hb3ezq
Запишись на групповое обучение: https://goo.gl/QWKZDT В группе мы обмениваемся опытом, ищем друзей и развиваемся вместе. Вступай ��
========================================================================== Здесь мы уже регистрируем самого пользователя https://github.com/happyhaha/yii2-registration-example.git vk.com/zhanwiko ▸Сайт: www.marlindev.ru
Рахим Муратов
Программирование сложная профессия? Вокруг куча видео-уроков, IT-сообществ и курсов, однако нет желаемого результата? Уже теряешь моральные силы и кажется что ты уперся в тупик? Не беда! Стена — это та же ступень. Просто надо дорасти до нее. А я, в свою очередь, помогу тебе вырасти. Посредством видео, в которых ты не найдешь пустословия и лишних размышлений, я передам информацию которая на 100% «не запылится» в потемках твоей светлой головы! (c) Rahim M.
Авторизация
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\web\User::loginRequired(), который перенаправляет браузер на страницу входа.
Если пользователь авторизован, генерируется исключение yii\web\ForbiddenHttpException.
Вы можете переопределить это поведение, настроив свойство 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 адресам.
verbs: задаёт http метод (например, GET , POST ), соответствующий правилу. Сравнение — регистронезависимо.
matchCallback: задаёт PHP колбек, который вызывается для определения, что правило должно быть применено.
denyCallback: задаёт PHP колбек, который будет вызван, если доступ будет запрещён при вызове этого правила.
Ниже показан пример, показывающий использование опции matchCallback , которая позволяет писать произвольную логику проверки доступа:
Контроль доступа на основе ролей (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 может быть доступен через \Yii::$app->authManager .
Замечание: По умолчанию, yii\rbac\PhpManager сохраняет данные RBAC в файлах в директории @app/rbac/ . Убедитесь что данная директория и файлы в них доступны для записи Web серверу, если иерархия разрешений должна меняться онлайн.
Настройка authManager с помощью DbManager #
Следующий код показывает как настроить в конфигурации приложения authManager с использованием класса yii\rbac\DbManager:
DbManager использует четыре таблицы для хранения данных:
itemTable: таблица для хранения авторизационных элементов. По умолчанию «auth_item».
itemChildTable: таблица для хранения иерархии элементов. По умолчанию «auth_item_child».
assignmentTable: таблица для хранения назначений элементов авторизации. По умолчанию «auth_assignment».
ruleTable: таблица для хранения правил. По умолчанию «auth_rule».
Прежде чем вы начнёте использовать этот менеджер, вам нужно создать таблицы в базе данных. Чтобы сделать это, вы можете использовать миграцию хранящуюся в файле @yii/rbac/migrations :
Теперь authManager может быть доступен через \Yii::$app->authManager .
Создание данных авторизации #
Для создания данных авторизации нужно выполнить следующие задачи:
определение ролей и разрешений;
установка отношений между ролями и правами доступа;
определение правил;
связывание правил с ролями и разрешениями;
назначение ролей пользователям.
В зависимости от требований к гибкости авторизации перечисленные задачи могут быть выполнены разными путями.
Если иерархия прав не меняется, и количество пользователей зафиксировано, вы можете создать консольную команду, которая будет единожды инициализировать данные через APIs, предоставляемое authManager :
Note: Если вы используете шаблон проекта advanced, RbacController необходимо создать в директории console/controllers и сменить пространство имён на console\controllers .
После выполнения команды yii rbac/init мы получим следующую иерархию:
Автор может создавать пост, администратор может обновлять пост и делать всё, что может делать автор.
Если ваше приложение позволяет регистрировать пользователей, то вам необходимо сразу назначать роли этим новым пользователям. Например, для того, чтобы все вошедшие пользователи могли стать авторами в расширенном шаблоне проекта, вы должны изменить frontend\models\SignupForm::signup() как показано ниже:
Для приложений, требующих комплексного контроля доступа с динамически обновляемыми данными авторизации, существуют специальные пользовательские интерфейсы (так называемые админ-панели), которые могут быть разработаны с использованием API, предлагаемого authManager .
Использование правил #
Как упомянуто выше, правила добавляют дополнительные ограничения на роли и разрешения. Правила — это классы, расширяющие 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» в таблице пользователей, и каждый пользователь принадлежит к какой-то группе. Если каждая группа может быть сопоставлена роли в модели 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 .
Как передать дату и время в БД при регистрации пользователя yii2?
Добрый вечер! Разобрался с регистрацией кое как, вроде все нормально заносится в БД, сейчас вопрос в другом, как передавать еще и время регистрации в БД?
За ранее спасибо за помощь
Вопрос задан более года назад
134 просмотра
ProFM дорогой пользователь, настоятельно рекомендуем еще раз обратить самое пристальное внимание на п. 3.1 регламента работы сервиса (и, в особенности, на его последний абзац). В противном случае, ваши вопросы будут удаляться по причине тег-спама.
Это последняя просьба.
типа потому что нужно или уникальный индекс в таблице или правило валидации в модели
Yii2 Регистрация пользователей с помощью Google
Я использую пользовательский модуль Yii2 для управления пользователями в моем проекте Yii2. Я включил проверку подлинности с помощью Google и Facebook. Я могу войти в систему с Google и Facebook, но не могу зарегистрировать нового пользователя с социальной аутентификацией. Похоже, это было возможно в предыдущих версиях пользователя yii2 в соответствии с этим. (https://code.tutsplus.com/tutorials/how-to-program-with-yii2-google-authentication—cms-24987) Однако в регистрационной форме больше нет ссылок. Разве это невозможно сейчас?
PS У меня есть «dektrium/yii2-user»: «0.9.*@dev», у моего композитора
