Давайте снова посмотрим на новые возможности Laravel 5.2. В этой версии значительно доработана вся система авторизации, в том числе стало намного проще использовать сразу несколько "защитников". Это одна из статей о новых функциях Laravel 5.2. Скоро будут ещё, не пропустите. {{Cut}} 1. ((https://laravel.ru/posts/354 Проверка массива формы в Laravel 5.2)) 2. ((https://laravel.ru/posts/372 Неявная привязка модели маршрута в Laravel 5.2)) 3. ((https://laravel.ru/posts/379 Ограничение скорости запросов API в Laravel 5.2)) 4. ((https://laravel.ru/posts/380 Заготовка авторизации в Laravel 5.2)) 5. ((https://laravel.ru/posts/381 Множественные драйверы защиты авторизации (включая API) в Laravel 5.2)) == Зачем вам это? == В Laravel до версии 5.2 защитником авторизации по умолчанию (который теперь называется %%(t)web%% защитник) был обычный слой авторизации веб-приложения: имя и пароль передаются в контроллер, который проверяет их и выполняет перенаправление, когда они неверны, а когда верны - информация пользователя сохраняется в сессию. Не всегда точь в точь, но в целом это работало так. А если вам нужен API, который должен работать в том же приложении и работать с JSON веб-токенами (или с каким-нибудь другим механизмом авторизации на основе отдельных запросов, а не сессии)? Раньше вам пришлось бы изрядно потрудиться, чтобы заставить работать сразу несколько драйверов авторизации. == Защитники авторизации по умолчанию в Laravel 5.2 == В версии 5.2 заставить работать сразу несколько драйверов авторизации не то чтобы просто, здесь это работает прямо из коробки. Если заглянуть в %%(t)config/auth.php%%, то можно увидеть два набора защитников прямо из коробки: %%(t)web%% - классический слой авторизации Laravel, и %%(t)api%% - драйвер на основе токенов и отдельных запросов (не использующий память сессии). Но, как видите, используется тот же "провайдер": <[ Провайдеры авторизации тоже настраиваемы. Они определяют то, как система должна хранить и получать информацию о ваших пользователях. Каждый определяется как экземпляр %%(t)Illuminate\Contracts\Auth\UserProvider%%. ]> %% 'guards' => [ 'web' => [ 'driver' => 'session', 'provider' => 'users', ], 'api' => [ 'driver' => 'token', 'provider' => 'users', ], ], %% А выше в %%(t)config/auth.php%% видно, что защитником авторизации по умолчанию будет "web". Это значит, что при каждом использовании функций, посредников или фасадов авторизации в вашем приложении они по умолчанию будут обработаны защитником %%(t)web%%, если вы явно не указали другое. == Знакомство с драйвером авторизации %%(t)token%% == Итак, если %%(t)web%% использует классический драйвер %%(t)session%%, то что это за новый драйвер %%(t)token%%, который используется в защитнике %%(t)api%%? Якоб Бэннет уже написал фантастическую статью о нём: ((https://gistlog.co/JacobBennett/090369fbab0b31130b51 Авторизация API Token в Laravel 5.2)). Прочитайте эту статью, чтобы подробно изучить работу драйвера, а мы рассмотрим его вкратце: * Добавьте поле %%(t)api_token%% в свою таблицу %%(t)users%%. Строка длиной 60 символов, уникальная. * В определении маршрутов вместо посредника %%(t)auth%% используйте посредник %%(t)auth:api%%. * В маршрутах API используйте для получения пользователя %%Auth::guard('api')->user()%% вместо %%Auth::user()%%. Как видите, нам надо хранить %%(t)api_token%% для каждого пользователя, и каждому входящему запросу, который проходит через защитника %%(t)api%% на основе токенов, будет необходим параметр %%(t)api_token%% с верным API-токеном для авторизации данного пользователя. А поскольку используются отдельные запросы, то каждый из них должен иметь этот API-токен. Один успешный запрос не значит, что следующий тоже будет успешен. <[ Авторизация на основе токенов работает так: подключающееся приложение (например, iOS-приложение) по запросу получит и сохранит токен для авторизации пользователя, и будет создавать API-вызовы, используя этот известный токен как часть URL. Например, если iOS-приложение захочет получить список друзей пользователя, то когда пользователь авторизуется в вашем приложении через веб-сайт/API, оно получит токен и сохранит его. И далее будет генерировать такие URL: %%(t)http://yourapp.com/api/friends?api_token=СОХРАНЁННЫЙ_ТОКЕН_ТУТ%% ]> == Использование драйверов не по умолчанию == Как вы заметили, в этом примере использования токенов два основных места, где мы будем использовать драйверы не по умолчанию: в посреднике защиты авторизации, и когда мы используем в коде такие удобные функции как %%Auth::check()%% и %%Auth::user()%%. Вы можете указать защитника для своих маршрутов, добавив двоеточие и название защитника после %%auth%% в ключе посредника (например, %%Route::get('whatever', ['middleware' => 'auth:api'])%%). Вы можете указать защитника для ручного вызова в коде, сделав %%guard('guardname')%% первым вызовом в текучей цепочке при каждом использовании фасада Auth (например, %%Auth::guard('api')->check()%%). == Создание своих защитников и драйверов == Создавать своих защитников просто, потому что каждый защитник - просто ключ (%%(t)web%%, %%(t)api%%), указывающий на определённую конфигурацию драйвера (%%(t)session%%, %%(t)token%%) и провайдера (%%(t)users%%). Они настраиваются в файле %%(t)config/auth.php%%: %% 'guards' => [ 'web' => [ 'driver' => 'session', 'provider' => 'users', ], 'api' => [ 'driver' => 'token', 'provider' => 'users', ], 'matts-fancy-api-guard' => [ 'driver' => 'token', 'provider' => 'users', ], ], %% Но вы можете возразить, что это не сильно повлияет на что-либо, пока вы не измените драйвер или провайдер. Создать драйвер не так просто, как защитника. В документации есть раздел о ((https://laravel.com/docs/5.2/authentication#adding-custom-guards создании своего драйвера авторизации)), вам будет необходимо создать собственную реализацию %%(t)Illuminate\Contracts\Auth\Guard%%, а затем зарегистрировать её в качестве драйвера где-нибудь в сервис-провайдере. Также в документации описано ((https://laravel.com/docs/5.2/authentication#adding-custom-user-providers как создать собственный провайдер пользователя)). == Заключение == Это всё. Наслаждайтесь.