Многие люди спрашивают: “как я могу добавить множественную аутентификацию в Laravel Fortify?” но я не смог найти никакого решения в Интернете, и подумал, что было бы хорошей идеей поделиться своим подходом со всеми вами.
Прежде всего, я использую новую установку Laravel 8 с предустановкой Laravel Livewire, созданной установщиком.
В качестве примера я возьму административный бэкэнд (так как мне пришлось создать его самому с помощью Fortify).
Я сделаю админку на поддомене вместо пути /admin. Поэтому сначала я создал новые конфигурационные переменные:
В config/app.php:
'base_url' => env('APP_BASEURL', 'localhost'), // NEW
'url' => env('APP_URL', 'http://localhost'),
'asset_url' => env('ASSET_URL', null),
'admin_subdomain' => env('APP_ADMIN_SUBDOMAIN', 'admin'), // NEW
Я добавил “base_url”и ” admin_subdomain”. Они используются для построения домена, чтобы настроить Fortify.
Затем я добавил helpers.php:
<?php
if (! function_exists('baseUrl')) {
function baseUrl() {
return config('app.base_url');
}
}
if (! function_exists('adminUrl')) {
function adminUrl() {
return config('app.admin_subdomain') . '.' . baseUrl();
}
}
Эти два помощника инкапсулируют “логику” для построения доменов.
Теперь мы добавляем макрос к запросу,чтобы легко проверить, был ли запрос сделан в админку.
В AppServiceProvider:
class AppServiceProvider extends ServiceProvider
{
/**
* Register any application services.
*
* @return void
*/
public function register()
{
Request::macro('isAdmin', function () {
return $this->getHost() === adminUrl();
});
}
/**
* Bootstrap any application services.
*
* @return void
*/
public function boot()
{
//
}
}
Макрос был создан в методе “register”, потому что он нужен нам в FortifyServiceProvider в методе” register”, так как” boot ” будет слишком поздно.
Так что теперь нам нужен новый guard. Я лично использовал “calebporzio/parental” пакет Калеба Порцио, поэтому у меня есть модель “пользователь” по умолчанию и производная модель “администратор”, но вы можете сделать это другим способом, если хотите.
В config/auth.php добавить нового gurd’а и провайдера:
'guards' => [
'web' => [
'driver' => 'session',
'provider' => 'users',
],
'admin' => [
'driver' => 'session',
'provider' => 'admins',
],
'api' => [
'driver' => 'token',
'provider' => 'users',
'hash' => false,
],
],
'providers' => [
'users' => [
'driver' => 'eloquent',
'model' => App\Models\User::class,
],
'admins' => [
'driver' => 'eloquent',
'model' => App\Models\Admin::class,
],
],
Давайте перейдем к FortifySericeProvider. Единственное, что нам нужно настроить, чтобы заставить Fortify работать:
fortify.domain
fortify.guard
С “fortify.domain” мы можем проинструктировать Fortify, на каком домене он регистрирует свои маршруты и с помощью “fortify.guard ” мы говорим Fortify, какой guard он должен использовать для аутентификации:
class FortifyServiceProvider extends ServiceProvider
{
/**
* Register any application services.
*
* @return void
*/
public function register()
{
if (request()->isAdmin()) {
config(['fortify.domain' => adminUrl()]);
config(['fortify.guard' => 'admin']);
}
}
/**
* Bootstrap any application services.
*
* @return void
*/
public function boot()
{
// Fortify actions registration
....
Fortify::loginView(function () {
if (request()->isAdmin()) {
return view('admin.auth.login');
}
return view('frontend.auth.login');
});
}
}
В рамках метода загрузки мы можем изменить представление входа, используемое Fortify. Примечание: Я разделил свои представления frontend и admin на разные папки.
И это все!
Теперь у нас есть рабочий логин администратора на поддомене с помощью простого Fortify!