Множественные драйверы защиты авторизации (включая API) в Laravel 5.2

Статистика: Символов — 5 632/4 767 без пробелов (4 429/3 786 без кода):, слов — 644
Разметка: Wiki
Давайте снова посмотрим на новые возможности 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 как создать собственный провайдер пользователя)).

== Заключение ==
Это всё. Наслаждайтесь.