В CMS 1C-Bitrix вниманию разработчикам представлено четыре системных компонента для реализации функционалов авторизации, смены пароля и регистрации рядовых пользователей системы (system.auth.*), но отсутствует официальная документация оных. В этой статье вы узнаете ограничения и недостатки использования этих компонентов, почему следует использовать именно их, каким образом лучше их использовать и, возможно, сделаете некоторые выводы о том, почему документации нет.
Принцип работы
По умолчанию для авторизации и регистрации используются старые компоненты 1.0, использование которых нежелательно. Исправить это можно, отметив галку «Использовать Компоненты 2.0 для авторизации и регистрации» в настройках главного модуля или однократно выполнив код:COption::SetOptionString("main", "auth_comp2", "Y");
Ознакомившись с описанием порядка выполнения страницы мы видим, что на шаге 1.13 (еще до вывода header.php из шаблона сайта) идет проверка прав доступа уровня 1 и если она не пройдена, то выводится форма авторизации. Разберем это подробнее.
Под вызовом формы регистрации подразумеваются следующие действия:
- порядок выполнения страницы продолжает выполнятся без изменений вплоть до пункта 3 «Тело страницы», включая выполнение header.php,
- вместо «Тела страницы» в зависимости от переданных в $_REQUEST переменных подключается один из системных компонентов system.auth.* (конкретно system.auth.authorize если $_REQUEST пустой), в который передаются особые параметры (об этом ниже),
- порядок выполнения страницы продолжает выполнятся без изменений, включая выполнение footer.php.
Это позволяет реализовать собственный дизайн (шаблон) для компонента system.auth.authorize, органично вписывающийся в шаблон сайта между шапкой и подвалом.
Проверка прав доступа «уровня 1» инициирует вызов формы авторизации в следующих случаях:
- если глобальная константа NEED_AUTH определена и равна true,
- если у пользователя (в том числе незарегистрированного) недостаточно прав для чтения запрошенного им файла.
Права на чтение файлов и разделов для разных групп пользователей формируются при редактировании оных административной панелью в служебных файлах.access.php. Каждый файл описывает уровни доступа к файлам и каталогам, расположенным на одном с ним уровне. Возможно создание файла.access.php для каждого каталога в публичной части сайта, каждый последующий такой файл дополняет правила доступа по цепочке каталогов. Пример такого файла в корне сайта:
Такое распределение прав позволяет буквально «на месте» запрашивать логин и пароль пользователя в случаях когда он переходит без активной авторизации в каталог, функционал которого требует авторизацию. Такое часто случается, если пользователь держит в избранном ссылку не на корень сайта, а на конкретный раздел, с которым больше всего работает. В результате пользователь вводит логин и пароль не уходя с целевой страницы, те отправляются на ее URL, вместо страницы отрабатывает системный компонент обрабатывая полученные данные либо сыпет ошибку либо авторизует и перезагружает страницу. Пользователь доволен, ему не надо совершать лишний клик для перехода в нужный раздел. Программист доволен, ему не нужно думать о редиректах на /auth/ и $backurl.
Использовать же глобальную константу NEED_AUTH рекомендую только в специфических случаях, одним из которых является непосредственно страница авторизации в стандартной поставке демо-сайта по адресу /auth/index.php:
SetTitle(GetMessage("AUTH_TITLE"));
?>
">
Этот скрипт передает управление ядру Битрикса, определив перед этим константу NEED_AUTH. Битрикс, в случае если пользователь не авторизован, подключает шапку + системный компонент (авторизации) + подвал и умирает, не позволяя скрипту выполняться дальше второй строчки. В случае же если пользователь авторизован - ему выводится приветственное сообщение и ссылка на корень сайта.
Прочие системные компоненты
Напомню что при инициации авторизации вместо «Тела страницы» компонент system.auth.authorize подключится ядром Битрикса только в случае, если пользователь явно не запросил какой-нибудь другой системный компонент из списка:- ?forgot_password=yes подключит system.auth.forgotpasswd (отправка контрольного слова для смены пароля),
- ?change_password=yes подключит system.auth.changepasswd (смена пароля по контрольному слову),
- ?register=yes подключит system.auth.registration (регистрация),
- ?confirm_registration=yes подключит system.auth.confirmation (подтверждение регистрации).
Такой подход позволяет пользователю восстановить пароль или даже зарегистрировать аккаунт, не уходя с целевой страницы. Вы можете манипулировать доступным набором этих ссылок в своих шаблонах системных компонентов, но запретить их вызов при переходе по этим ссылкам нельзя, и это жирный минус.
Использование компонента авторизации внутри тела страницы
Иногда требуется встроить форму авторизации не вместо тела страницы, а внутрь тела страницы, например по адресу /about/index.php посреди контента. И тут возникает нюанс : оказывается системный компонент system.auth.authorize не делает совершенно ничего в отношении непосредственной авторизации, и поэтому сам ничего не знает о результате авторизации. Поэтому если мы подключим компонент без параметров, он будет корректно авторизовывать пользователей, но не будет отображать ошибки авторизации. На самом деле механизм авторизации происходит где-то глубоко в недрах ядра, после чего ядро подключает компонент, передавая в него параметр «AUTH_RESULT» устанавливая значение из $APPLICATION->arAuthResult, что мы вынуждены повторять на своих страницах:SetTitle("О сайте"); ?> ... IsAuthorized()): ?> IncludeComponent("bitrix:system.auth.authorize", "", array("AUTH_RESULT" => $APPLICATION->arAuthResult)); ?> ...
Если же необходимость в авторизации возникает во время выполнения компонента, следует вызвать форму авторизации методом CMain::AuthForm(), что позволит пользователю авторизоваться не только не покидая целевой страницы, но и сохранить все параметры в URL:
$APPLICATION->AuthForm(array("MESSAGE" => "Для работы с... требуется авторизация.", "TYPE" => "OK",));
Создание собственных шаблонов
Для того чтобы настроить внешний вид системных форм авторизации, регистрации, запроса смены пароля и смены пароля по контрольной строке, вам следует скопировать существующие шаблоны этих компонентов (/bitrix/components/bitrix/system.auth.*/templates/.default) в шаблон сайта (/bitrix/templates/<шаблон_сайта>/components/bitrix/system.auth.*/.default), после чего работать с ними. Вы не можете изменять названия передаваемых полей в этих формах, но можете добавлять любые другие поля, например «телефон» в регистрацию, правда на данном этапе системный компонент не поймет чего вы от него хотите этими новыми полями. Так же вы можете полностью изменить дизайн и регулировать отображение ссылок на соседние системные компоненты. При переработке этих шаблонов обратите внимание на вывод сообщений глобальной функцией ShowMessage, принимающей на вход строку или массив. Можно избавиться от ее использования, но лучше переопределить шаблон компонента system.show_message.Расширение функционала регистрации
К сожалению сегодня системные компоненты реализованы в процедурном стиле, что не позволяет наследовать собственные компоненты от них, переопределяя и дополняя функциональность, поэтому для решения таких задач приходится использовать события Битрикса. Два наиболее интересных события, генерируемых при регистрации пользователя это: OnBeforeUserRegister и OnAfterUserAdd . В идеале обработчики этих событий регистрируются при установке модуля, удаляются при удалении модуля, например:// при установке модуля: RegisterModuleDependences("main", "OnAfterUserAdd", $this->MODULE_ID, "CWBroker", "OnAfterUserAdd"); RegisterModuleDependences("main", "OnBeforeUserRegister", $this->MODULE_ID, "CWBroker", "OnBeforeUserRegister"); // при удалении модуля: UnRegisterModuleDependences("main", "OnAfterUserAdd", $this->MODULE_ID, "CWBroker", "OnAfterUserAdd"); UnRegisterModuleDependences("main", "OnBeforeUserRegister", $this->MODULE_ID, "CWBroker", "OnBeforeUserRegister");
Событие OnBeforeUserRegister примечательно тем, что не вызывается при обычном добавлении пользователя, будь то вызов API или ручное добавление в административной части, что позволяет изменить логику именно регистрации пользователя-гостя, накладывая дополнительные ограничения на поля или обрабатывая дополнительные поля, например контроль за цифрами в телефоне, контроль за наличием данных в имени и фамилии.
class CWBroker { // ... public static function OnBeforeUserRegister(&$arArgs) { global $APPLICATION; $_REQUEST["USER_PERSONAL_PHONE"] = preg_replace("#[^0-9]#", "", $_REQUEST["USER_PERSONAL_PHONE"]); $arArgs["LOGIN"] = $arArgs["EMAIL"]; $arArgs["CONFIRM_PASSWORD"] = $arArgs["PASSWORD"]; $arArgs["PERSONAL_PHONE"] = $_REQUEST["USER_PERSONAL_PHONE"]; $arArgs["PERSONAL_STATE"] = $_REQUEST["USER_PERSONAL_STATE"]; if (empty($arArgs["NAME"])) { $APPLICATION->ThrowException("Не указано имя"); return false; } if (empty($arArgs["LAST_NAME"])) { $APPLICATION->ThrowException("Не указана фамилия"); return false; } if (empty($arArgs["PERSONAL_PHONE"])) { $APPLICATION->ThrowException("Не указан мобильный телефон"); return false; } if (empty($arArgs["PERSONAL_STATE"])) { $APPLICATION->ThrowException("Не указан регион"); return false; } if ($_REQUEST["USER_AGREE_TERMS"] <> "Y" || $_REQUEST["USER_AGREE_PHONE"] <> "Y" || $_REQUEST["USER_AGREE_EMAIL"] <> "Y") { $APPLICATION->ThrowException("Необходимо принять все условия"); return false; } return $arArgs; } // ... }
Задача обработчика события - скорректировать входящий массив данных $arArgs или объявить об ошибке методом CMain::ThrowException(), вернув false вместо массива данных. К сожалению добиться того чтобы интересующие нас поля передавались через $arArgs невозможно, поэтому приходится анализировать $_REQUEST. Листинг можно улучшить, сгруппировав найденные ошибки, но к сожалению даже если обработчик успешно отработает, в дальнейшем в процессе регистрации в ядре могут возникнуть другие ошибки, влиять на которые мы не можем. Пользователь не доволен, получая разные ошибки в процессе регистрации. Программист ищет альтернативы.
Событие OnAfterUserAdd вызывается не только после успешной самостоятельной регистрации пользователя, но и при вызовах API или добавлении пользователя в административной части, но передаваемый в обработчики этого события массив данных ни на что не влияет кроме самих обработчиков, поэтому генерировать исключения здесь практически бесполезно, но зато вместо этого можно выполнить некоторую общую для всех новых пользователей логику, как то: добавить пользователя в лист рассылки, создать для него бюджет в интернет-магазине или присвоить какое-либо пользовательское свойство.
class CWBroker {
// ...
public static function OnAfterUserAdd(&$arFields) {
if (CModule::IncludeModule("inquiries")) {
$CUser = new CUser();
$CUser->Update($arFields["ID"], array("UF_TARIFF" => 1));
}
if (CModule::IncludeModule("sale")) {
$sale_account = CSaleUserAccount::GetByUserID($arFields["ID"], "RUB");
if (empty($sale_account)) {
CSaleUserAccount::Add(array("USER_ID" => $arFields["ID"],
"CURRENT_BUDGET" => 0,
"CURRENCY" => "RUB",));
}
}
if (CModule::IncludeModule("subscribe")) {
$CDBResult = CRubric::GetList(array("SORT" => "ASC"), array("ACTIVE" => "Y"));
$rubrics = array();
while ($rubric = $CDBResult->Fetch()) {
$rubrics = $rubric["ID"];
}
$CSubscription = new CSubscription();
$CSubscription->Add(array("USER_ID" => $arFields["ID"],
"EMAIL" => $arFields["EMAIL"],
"FORMAT" => "html",
"CONFIRMED" => "Y",
"SEND_CONFIRM" => "N",
"RUB_ID" => $rubrics,));
}
}
// ...
}
Альтернативы
Если набраться смелости и залезть в исходный код системных компонентов (авторизации), то у вас резко пропадет любое желание работы с ними. Как очевидный альтернативный вариант на ум в первую очередь приходит создание собственных компонентов авторизации, регистрации и прочего. Благо API позволяет реализовать все тоже самое. Однако в этой альтернативе я вижу следующие жирные минусы:- затраты на повторную реализацию логики (в одном лишь компоненте авторизации: проверочная капча, безопасная авторизация по ключу и авторизация через внешние сервисы),
- отказ от обновлений рассматриваемых системных компонентов, что особенно актуально с постепенным переходом ядра на D7 ,
- невозможность подключить собственный компонент авторизации на целевую страницу пользователя в случае когда ему недостаточно прав для просмотра страницы, вместо этого приходится реализовывать свою логику доступности тех или иных страниц и разделов.
Другой альтернативой можно считать компонент bitrix:main.register , обладающий широким спектром параметров. Однако для того чтобы именно этот компонент отображался и отрабатывал на целевой странице пользователя, программисту приходится идти на ухищрение: вставлять вызов этого компонента в шаблон системного компонента регистрации (bitrix:system.auth.register), что влечет за собой следующие недостатки:
- один и тот же набор параметров компонента хранится как минимум в двух местах: в публичной части на странице авторизации и в шаблоне сайта,
- при вызове bitrix:main.register через шаблон компонента bitrix:system.auth.register код последнего отрабатывает впустую.
В заключение
Не секрет что платформа Битрикс далека от идеала. Каждый раз когда я встречаю подобные вещи, искажающие мой покерфейс, я сперва называю из странными , затем пытаюсь разобраться и понять почему же было сделано именно так и в большинстве случаев нахожу приемлемый ответ. Но в этом случае ответа я не нашел, поэтому решил записать все соображения по поводу. Надеюсь, кому-нибудь пригодится.Laravel позволяет сделать аутентификацию очень простой. Фактически, почти всё уже готово к использованию «из коробки». Настройки аутентификации находятся в файле config/auth.php , который содержит несколько хорошо документированных опций для настройки механизма аутентификации.
Настройки базы данных
По умолчанию Laravel использует модель App\User Eloquent в каталоге app . Эта модель может использоваться вместе с драйвером аутентификации на базе Eloquent. Если ваше приложение не использует Eloquent, вы можете применить драйвер аутентификации database , который использует Laravel Query Builder.
При создании схемы базы данных для модели App\User убедитесь, что поле пароля имеет минимальную длину в 60 символов.
Также вы должны убедиться, что ваша таблица users (или её эквивалент) содержит строковое nullable поле remember_token длиной в 100 символов. Это поле используется для хранения токена сессии, если ваше приложение предоставляет функциональность «запомнить меня». Создать такое поле можно с помощью $table->rememberToken(); в миграции.
Быстрый старт
Laravel оснащён двумя контроллерами аутентификации «из коробки». Они находятся в пространстве имён App\Http\Controllers\Auth . AuthController обрабатывает регистрацию и аутентификацию пользователей, а PasswordController содержит логику для сброса паролей существующих пользователей. Каждый из этих контроллеров использует трейты для включения необходимых методов. Для многих приложений вам не понадобится редактировать эти контроллеры.
Routing
Views
Хотя контроллеры аутентификации включены в фреймворк, вам всё равно придётся создать шаблоны , которые эти контроллеры будут отображать. Они должны находиться в каталоге resources/views/auth . Вы можете изменять их, как пожелаете. Шаблон страницы входа должен быть расположен в resources/views/auth/login.blade.php , а шаблон регистрации - в resources/views/auth/register.blade.php .
Пример формы аутентификации
Пример формы регистрации
Аутентификация
Теперь, когда у вас есть роуты и шаблоны, вы можете регистрировать и аутентифицировать пользователей вашего приложения. Контроллеры аутентификации уже содержат логику (через трейты) для аутентификации существующих пользователей и создания новых в вашей базе данных.
При успешной аутентфикации пользователь попадает на страницу /home , для которой вы должны создать роут. Вы можете изменить путь редиректа после аутентификации при помощи свойства redirectTo у AuthController:
Дополнительная настройка
Для изменения полей формы, обязательных к заполнению при регистрации пользователей, или для изменения способа создания пользователей в базе данных вы можете править класс AuthController . Этот класс отвечает за валидацию и создание новых пользователей вашего приложения.
Метод validator класса AuthController содержит в себе правила валидации формы регистрации новых пользователей. Вы можете изменять его, как пожелаете.
Метод create класса AuthController отвечает за создание новых App\User записей в вашей базе данных, используя Eloquent ORM . Вы также можете изменять его под требования вашего приложения.
Получение аутентифицированного пользователя
Вы можете получить аутентифицированного пользователя при помощи фасада Auth:
$user = Auth::user();
То же самое вы можете сделать при помощи экземпляра Illuminate\Http\Request:
user()) { // $request->user() возвращает экземпляр аутентифицированного пользователя } } }
Проверка пользователя на аутентифицированность в приложении
Для проверки текущего пользователя на аутентифицированность в вашем приложении вы можете использовать метод check фасада Auth , который возвращает true , если пользователь аутентифицирован:
If (Auth::check()) { // Пользователь аутентифицирован }
Однако, вы также можете использовать посредников (middleware) для проверки аутентификации пользователя перед доступом к конкретным роутам / контроллерам.
Ограничение доступа к роутам
Ручная аутентификация пользователей
Конечно же, вы не обязаны использовать контроллеры аутентификации, включённые в Laravel. Если вы удалите эти контроллеры, нужно будет управлять аутентификацией пользователей при помощи классов аутентификации Laravel. Не волнуйтесь, это просто!
Доступ к сервисам аутентификации Laravel осуществляется при помощи фасада Auth , поэтому нужно убедиться, что вы импортировали его перед вашим классом. Далее давайте рассмотрим метод attempt:
$email, "password" => $password])) { // Аутентификация прошла успешно return redirect()->intended("dashboard"); } } }
Метод attempt принимает массив пар «ключ - значение» первым аргументом. Значения в этом массиве будут использованы для поиска пользователя в базе данных. Таким образом, в этом примере пользователь ищется по полю email . Если пользователь найден, хеш пароля из базы данных сравнится с хешем указанного пароля в массиве. Если хеши совпадут, то сессия аутентификации стартует для пользователя.
Метод attempt возвратит true , если аутентификация прошла успешно. Иначе - false .
Метод intended редиректора переместит пользователя на URL, на который он хотел попасть до прохождения аутентификации. Запасной URL указывается в параметре и будет использован, если путь, куда хотел перейти пользователь, недоступен.
Если хотите, вы также можете добавить дополнительные условия прохождения аутентификации в дополнение к E-mail и паролю. Например, вы можете проверять, активен ли пользователь:
If (Auth::attempt(["email" => $email, "password" => $password, "active" => 1])) { // Пользователь активен, существует и ввёл верный пароль }
Для осуществления выхода пользователя из приложения можно воспользоваться методом logout фасада Auth . Это очистит информацию об аутентификации из сессии пользователя:
Auth::logout();
Обратите внимание: В этих примерах поле email не обязательно должно использоваться для поиска пользователя, оно выбрано для примера. Вы можете использовать любое поле для поиска пользователя, которое является уникальным в таблице пользователей вашей базы данных.
Запоминание пользователей
Если вы хотите реализовать в вашем приложении функциональность «запомнить меня», можно указать булево значение вторым аргументом методу attempt . Это аутентифицирует пользователя на неограниченное время или пока он не выйдет из приложения. Само собой, ваша таблица users должна содержать поле remember_token , которое будет использоваться для сохранения токена «запомнить меня».
If (Auth::attempt(["email" => $email, "password" => $password], $remember)) { // Пользователь запомнен }
Если вы «запоминаете» пользователей, можете использовать метод viaRemember для определения того, аутентифицировался ли пользователь с помощью куки «запомнить меня»:
If (Auth::viaRemember()) { // }
Другие методы аутентификации
Аутентификация экземпляра пользователя
Если вам нужно аутентифицировать существующего пользователя в ваше приложение, вы можете вызвать метод login на экземпляре этого пользователя. Этот экземпляр должен реализовать контракт Illuminate\Contracts\Auth\Authenticatable . Модель App\User , используемая Laravel по умолчанию, уже реализует этот интерфейс:
Auth::login($user);
Аутентификация по ID пользователя
Для аутентификации пользователя по его ID вы можете использовать метод loginUsingId . Этот метод принимает ID пользователя аргументом:
Auth::loginUsingId(1);
Аутентификация пользователя на один запрос
Вы также можете использовать метод once для аутентификации пользователя в вашем приложении на один запрос. Ни сессии, ни куки не будут созданы, что может быть использовано для создания stateless API. Метод once работает по тому же принципу, что и attempt:
If (Auth::once($credentials)) { // }
Аутентификация HTTP Basic
Stateless HTTP Basic Аутентификация
Вы также можете использовать HTTP Basic аутентификацию без установки куки идентификации пользователя в сессии, что может быть полезно при создании API аутентификации. Для этого создайте посредника , который будет вызывать метод onceBasic . Если onceBasic ничего не возвратит, запрос пойдёт дальше в приложение.
Сброс пароля
Настройка базы данных
Большинство веб-приложений предоставляют пользователю возможность сбрасывать свой пароль. Для того, чтобы вам не приходилось реализовывать это в каждом приложении, Laravel предоставляет простой способ отправки «напоминателей» паролей и осуществления сброса пароля.
Для начала проверьте, реализует ли ваша модель App\User контракт Illuminate\Contracts\Auth\CanResetPassword . По умолчанию она это делает и использует трейт Illuminate\Auth\Passwords\CanResetPassword , который предоставляет необходимые методы для сброса пароля.
Создание миграции таблицы токенов сброса паролей
Дальше вам необходимо создать таблицу, в которой будут храниться токены сброса паролей. Эта миграция по умолчанию уже включена в Laravel в каталог database/migrations . Поэтому вам остаётся только мигрировать базу данных:
Php artisan migrate
Routing
Laravel предоставляет класс Auth\PasswordController , в котором содержится вся необходимая логика для сброса паролей. Тем не менее, вам нужно будет создать роуты к этому контроллеру:
// Роуты запроса ссылки для сброса пароля Route::get("password/email", "Auth\PasswordController@getEmail"); Route::post("password/email", "Auth\PasswordController@postEmail"); // Роуты сброса пароля Route::get("password/reset/{token}", "Auth\PasswordController@getReset"); Route::post("password/reset", "Auth\PasswordController@postReset");
Views
В дополнение к определению роутов к PasswordController вы должны создать шаблоны, которые будет отображать ваш контроллер. Не беспокойтесь, ниже предоставлены примеры таких шаблонов. Вы вольны стилизировать их под свои нужды.
Пример формы запроса ссылки сброса пароля
Вам нужно создать HTML шаблон формы запроса сброса пароля. Этот шаблон должен находиться в resources/views/auth/password.blade.php . Форма содержит единственное поле E-mail адреса, позволяющее запросить ссылку сброса пароля:
Когда пользователь отправит запрос на сброс пароля, он получит E-mail со ссылкой на роут, который ведёт к методу getReset (обычно это /password/reset) контроллера PasswordController . Вам нужно будет создать шаблон письма в resources/views/emails/password.blade.php . Этот шаблон получает переменную $token , содержащую токен сброса пароля для пользователя, который запросил его. Пример такого шаблона:
Click here to reset your password: {{ url("password/reset/".$token) }}
Пример формы сброса пароля
Пример формы сброса пароля:
Действия после сброса пароля
После того, как вы определили роуты и шаблоны для сброса паролей, можете проверить их в браузере. Класс PasswordController включён в фреймворк по умолчанию и содержит всю необходимую логику для отправки писем и сброса паролей в базе данных.
После сброса пароля пользователь автоматически аутентифицируется в вашем приложении и редиректится на страницу /home . Вы можете изменить этот путь, создав свойство redirectTo у PasswordController
Protected $redirectTo = "/dashboard";
Обратите внимание: По умолчанию токен сброса пароля существует 1 час. Вы можете изменить это в конфигурационном файле config/auth.php с помощью опции reminder.expire .
Аутентификация через социальные сети
В дополнение к аутентификации, основанной на формах, Laravel предоставляет простой и удобный способ аутентификации на основе OAuth при помощи Laravel Socialite . Socialite на данный момент поддерживает аутентификацию при помощи Facebook, Twitter, Google, GitHub и Bitbucket.
Для установки Socialite добавьте его как зависимость в composer.json:
Composer require laravel/socialite
Настройка
После установки Socialite зарегистрируйте сервис-провайдер Laravel\Socialite\SocialiteServiceProvider в конфигурационном файле config/app.php:
"providers" => [ // Другие сервис-провайдеры Laravel\Socialite\SocialiteServiceProvider::class, ],
Также добавьте фасад Socialite в массив aliases конфигурации:
"Socialite" => Laravel\Socialite\Facades\Socialite::class,
Далее вам необходимо указать параметры для того сервиса OAuth, который вы используете. Это можно сделать в файле config/services.php . Пока доступно четыре сервиса: facebook , twitter , google и github . Пример:
"github" => [ "client_id" => "your-github-app-id", "client_secret" => "your-github-app-secret", "redirect" => "http://your-callback-url", ],
Базовое использование
Теперь вы готовы к аутентификации пользователей! Вам нужно создать два роута: один для редиректа пользователя к провайдеру OAuth, и ещё один для получения callback от провайдера после аутентификации. Доступ к Socialite можно получить при помощи фасада Socialite:
redirect(); } /** * Obtain the user information from GitHub. * * @return Response */ public function handleProviderCallback() { $user = Socialite::driver("github")->user(); // $user->token; } }
Метод redirect заботится об отправке пользователя к OAuth провайдеру, а метод user читает приходящий ответ и получает информацию о пользователе от провайдера. Перед редиректом пользователя вы также можете указать «scopes» (права доступа) запроса при помощи метода scope . Этот метод перезапишет существующие scopes:
Return Socialite::driver("github") ->scopes(["scope1", "scope2"])->redirect();
Получение деталей о пользователе
После получения экземпляра пользователя вы можете получить дополнительные данные о нём:
$user = Socialite::driver("github")->user(); // OAuth Two Providers $token = $user->token; // OAuth One Providers $token = $user->token; $tokenSecret = $user->tokenSecret; // All Providers $user->getId(); $user->getNickname(); $user->getName(); $user->getEmail(); $user->getAvatar();
Добавление драйвера аутентификации
Если вы не используете традиционные реляционные базы данных для хранения пользователей, вам нужно расширить Laravel собственным драйвером аутентификации. Для этого используйте метод extend фасада Auth для определения своего драйвера. Вы должны поместить extend в сервис-провайдере :
После добавления драйвера с помощью метода extend вы можете переключиться на него в вашем файле конфигурации config/auth.php .
Контракт User Provider
Реализации контракта Illuminate\Contracts\Auth\UserProvider ответственны только за получение реализации контракта Illuminate\Contracts\Auth\Authenticatable из хранилища данных, такого, например, как MySQL, Riak и тд. Эти два интерфейса позволяют Laravel использовать механизмы аутентификации независимо от того, как хранятся данные приложения.
Давайте посмотрим на контракт Illuminate\Contracts\Auth\UserProvider:
Метод retrieveById служит для получения пользователя из базы данных по его ID. Реализация класса Authenticatable должна быть возвращена в ответ методом.
Метод retrieveByToken получает пользователя по его ID и токену «запомнить меня», который хранится в поле remember_token . Как и в предыдущем методе, должна быть возвращена реализация класса Authenticatable .
Метод updateRememberToken обновляет токен пользователя. Новый токен может быть как снова созданным при аутентификации пользователя, так и null - при выходе пользователя.
Метод retrieveByCredentials получает массив данных, указанных в методе Auth::attempt , при аутентификации в приложении. Этот метод должен искать пользователя по указанным данных в хранилище данных. Обычно он ищет по полю username . Он должен возвращать реализацию интерфейса UserInterface . Этот метод не должен проверять пароль пользователя или аутентифицировать его.
Метод validateCredentials должен проверять правильность данных пользователя. Например, этот метод может сравнивать строку $user->getAuthPassword() с Hash::make из $credentials["password"] . Этот метод должен проверять данные пользователя и возвращать булево значение.
Контракт Authenticatable
Теперь, когда мы рассмотрели все методы UserProvider , давайте взглянем на Authenticatable . Помните, провайдер должен возвращать реализацию этого интерфейса из методов retrieveById и retrieveByCredentials:
Интерфейс прост. Метод getAuthIdentifier должен возвращать «primary key» пользователя. В MySQl, например, это уникальный первичный ключ. Метод getAuthPassword должен возвращать хеш пароля пользователя. Этот интерфейс позволяет системе аутентификации работать с любым классом User независимо от используемой ORM или базы данных. По умолчанию Laravel включает в себя класс User в папке app , который реализует этот интерфейс, поэтому вы можете использовать его, как пример.
Не используйте в качестве логина адрес электронной почты (e-mail)! Правильный читаемый логин должен формироваться следующим образом и может содержать только следующие символы: при создании логина могут использоваться только символы латинского (английского) алфавита (от A до Z - как малые, так и заглавные), цифры 0..9, а также знаки дефис ("-") и подчеркивание ("_") - это все! Никакие другие символы (включая пробелы) в вашем логине участвовать не могут!
Внимание! Регистрируясь на сайте www.сайт/ (интернет-журнал РуАвтор) и нажимая на кнопку "Отправить", вы тем самым даете свое согласие на обработку ваших персональных данных в соответствии с Федеральным законом «О персональных данных» №152-ФЗ от 27 июля 2006 года, а также подтверждаете, что ознакомились с Правилами проекта и с Отказом от гарантий и безоговорочно принимаете их, а также нижеприведенное Пользовательское Соглашение об обработке персональных данных . В противном случае (в случае вашего несогласия с любым пунктом Правил или Отказа от гарантий или Пользовательского Соглашения об обработке персональных данных) вам не следует регистрироваться на сайте www.сайт/.
Пользовательское Соглашение об обработке персональных данных
Условия и цели обработки персональных данных
Администрация интернет-журнала РуАвтор (то же, что и Администрация Сайта www.сайт/) осуществляет обработку персональных данных Пользователей с целью предоставления Пользователям (зарегистрированным авторам) услуг сайта (см. Правила - www..html). В силу статьи 6 Федерального закона от 27.07.2006 № 152-ФЗ «О персональных данных» отдельное согласие пользователя на обработку его персональных данных не требуется. В силу п.п. 2 п. 2 статьи 22 указанного закона Администрация Сайта вправе осуществлять обработку персональных данных без уведомления уполномоченного органа по защите прав субъектов персональных данных.
Сбор персональных данных
Сбор персональных данных Пользователей (авторов, зарегистрированных на Сайте) осуществляется на Сайте при их Регистрации, а также в дальнейшем при внесении Пользователем по своей инициативе дополнительных сведений о себе с помощью сервисов Сайта. Персональные данные предоставляются Пользователем и являются необходимыми при Регистрации и выполнении своей деятельности на Сайте.
Передача персональных данных
Персональные данные Пользователей не передаются Администрацией интернет-журнала РуАвтор каким-либо третьим лицам, за исключением предоставления Персональных данных Пользователей в целях исполнения настоящего Соглашения, а также по запросу компетентных государственных органов (Прокуратуры, Полиции, Суда и иных) в целях соблюдения норм действующего законодательства РФ.