Динамическая маршрутизация пользовательских доменов

Динамическая доменная маршрутизация

Еще один способ реализации пользовательских доменов и субдоменов в Ларавел для мультитенантных приложений. Multitenancy — множественная аренда, когда один экземпляр приложения, обслуживает множество тенантов («арендаторов»).

Начальный способ

Первый способ, которым я реализовал пользовательские домены в Laravel, это добавил глобальный паттерн маршрута в RouteServiceProvider, который изменил регулярное выражение для сопоставления субдоменов, чтобы учесть полные домены:

Route::pattern('domain', '[a-z0-9.\]+');

Это позволило использовать функцию доменной маршрутизации следующим образом:

Route::domain('{domain}')->group(function() {
    Route::get('users/{user}', function (Request $request, string $domain, User $user) {
        // здесь ваш код
    });
});

И хотя это замечательно работает, но теперь необходимо ко всем маршрутам добавлять аргумент $domain, даже если для данного маршрута это и не нужно. Тогда мне показалось это приемлемым решением, но я продолжал искать наилучший способ.

Наилучший способ

В новом решении требовалось полностью забыть, что в Laravel есть маршрутизация субдоменов. Вместо этого мы будем использовать мидлвар для поиска подходящего тенанта на основе запроса хоста и добавления данных в объект запроса, чтобы потом их можно было использовать далее в приложении. Самой простой реализацией этого может быть следующий мидлвар-класс:

namespace App\Http\Middleware;

use Closure;
use App\Tenant;

class CustomDomain
{
    /**
     * Обрабатываем входящий запрос
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure  $next
     * @return mixed
     */
    public function handle($request, Closure $next)
    {
        $domain = $request->getHost();
        $tenant = Tenant::where('domain', $domain)->firstOrFail();

        // Добавляем домен и тенанта в объект запроса
        // для дальнейшего использования в приложении
        $request->merge([
            'domain' => $domain,
            'tenant' => $tenant
        ]);

        return $next($request);
    }
}

Здесь я предполагаю, что у вас есть модель Tenant с атрибутом domain, который содержит полное доменное имя, которое вы хотите использовать для данного тенанта.

Теперь в файл app/Http/Kernel.php вы можете добавить мидлварную группу или маршрутный мидлвар, который будет содержать этот новый мидлвар. Мне больше нравится вариант с созданием новой группы для доменной маршрутизации. В дальнейшем она пригодится, если появятся новый мидлвары для кастомной доменной маршрутизации.

protected $middlewareGroups = [
    ...
    'domain' => [
        \App\Http\Middleware\CustomDomain::class,
    ],
    ...
];

Теперь я могу назначить эту мидлварную группу любым маршрутам, которые должны обслуживаться в кастомном домене. Обычно я создаю новый файл routes/tenant.php, а затем, в файл app/Providers/RouteServiceProvider.php, добавляю для него новый метод вместе с пространством имён и префиксом:

public function map()
{
    $this->mapApiRoutes();
    $this->mapWebRoutes();
    $this->mapTenantRoutes();
}

protected function mapTenantRoutes()
{
    Route::middleware(['web', 'auth', 'domain'])
        ->namespace("$this->namespace\Tenant")
        ->name('tenant.')
        ->group(base_path('routes/tenant.php'));
}

Последняя часть головоломки — как получить доступ к информации о тенанте из контроллеров, шаблонов и других частей вашего приложения. В отличие от предыдущего решения, здесь нет необходимости добавлять аргумент $domain к маршрутам. Вместо этого вы можете прочитать информацию о тенанте прямо из объекта запроса. Вот пример контроллера, который делает это:

public function index(Request $request)
{
    $tenant = $request->tenant;

    ...
}

Если вы используете blade-шаблоны, то мидлвар CustomDomain является отличным местом, откуда можно расшарить нужные данные, которые понадобятся в шаблонах, зависящих от тенантов.

namespace App\Http\Middleware;

use Closure;
use App\Tenant;
use Illuminate\Support\Facades\View;

class CustomDomain
{
    /**
     * Обрабатываем входящий запрос
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure  $next
     * @return mixed
     */
    public function handle($request, Closure $next)
    {
        $domain = $request->getHost();
        $tenant = Tenant::where('domain', $domain)->firstOrFail();

        // Добавляем домен и тенанта в объект запроса
        // для дальнейшего использования в приложении
        $request->merge([
            'domain' => $domain,
            'tenant' => $tenant
        ]);

        // Расшариваем данные тенанта 
        // для удобной настройки шаблонов
        View::share('tenantColor', $tenant->color);
        View::share('tenantName', $tenant->name);

        return $next($request);
    }
}

Прочие факторы

Расскажу еще о некоторых вещах, с которыми вы можете столкнуться при использовании этого способа реализации пользовательских доменов.

Аутентификация

Скорее всего, вы захотите, чтобы пользователи вашего приложения могли входить в систему только под тем тенантом, которому они принадлежат. Для этого вы можете сохранить атрибут tenant_id в модели User и изменить свою аутентификацию, чтобы учесть это при входе в систему. Вы можете сделать это, переопределив метод credentials в файле app/Http/Controllers/Auth/LoginController.php. Дефолтный метод (который находится в трейте AuthenticatesUsers ) выглядит так:

protected function credentials(Request $request)
{
    return $request->only($this->username(), 'password');
}

Узнать тенанта так же просто, как изменить его содержимое:

protected function credentials(Request $request)
{
    $credentials = $request->only($this->username(), 'password');

    $credentials['tenant_id'] = optional($request->tenant)->id;

    return $credentials;
}

Теперь пользователи смогут входить только под доменом тенанта, с которым связана их пользовательская модель.

Возможно вам будет интересно, как происходит сопоставление маршрутов аутентификации. По умолчанию эти маршруты добавляются в routes/web.php, но, если вы хотите использовать в них тенантный мидлвар (для настройки или по каким-то другим причинам), то вам лучше создать новый метод в RouteServiceProvider, например так:

protected function mapAuthRoutes()
{
    Route::middleware(['web', 'domain'])
        ->namespace("$this->namespace\Auth")
        ->name('auth.')
        ->group(base_path('routes/auth.php'));
}

Субдомены

Хотя целью всего этого является включение поддержки пользовательских доменов в Laravel, но вы, конечно же, можете обслуживать и субдомены, используя тот же подход, что описан выше. Основное различие между этим решением и встроенной функцией маршрутизации субдоменов заключается в том, что при таком подходе вам нужно будет хранить полный домен для своего тенанта, а не только префикс субдомена.

Корневые и безтенантные домены

В некоторых случаях, вам будет необходимо обслужить что-либо в корневом домене вашего приложения или в домене, у которого нет тенанта. Например панель администратора или какой-либо другой функционал. Один из способов, который здесь можно использовать, это добавить в конфиг настройку нужного домена и добавить проверку на существование тенанта в мидлвар CustomDomain.

namespace App\Http\Middleware;

use Closure;
use App\Tenant;
use Illuminate\Support\Facades\View;

class CustomDomain
{
    /**
     * Обрабатываем входящий запрос
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure  $next
     * @return mixed
     */
    public function handle($request, Closure $next)
    {
        $domain = $request->getHost();
        $tenant = Tenant::where('domain', $domain)->first();

        if (!$tenant) {
            $adminDomain = config('app.admin_domain');

            if ($domain != $adminDomain) {
                abort(404);
            }
        }

        // Добавляем домен и тенанта в объект запроса
        // для дальнейшего использования в приложении
        $request->merge([
            'domain' => $domain,
            'tenant' => $tenant
        ]);

        if ($tenant) {
            View::share('tenantColor', $tenant->color);
            View::share('tenantName', $tenant->name);
        }

        return $next($request);
    }
}

Для данных шаблона, можно добавить резервный вариант непосредственно прямо в мидлвар или, например, в метод boot файла app/Providers/AppServiceProvider.php

public function boot()
{
    ...

    View::share('tenantColor', 'gray');
    View::share('tenantName', 'Admin');

    ...
}

Резюме

На этом всё! В целом, я считаю, что этот способ является наболее чистым методом реализации пользовательских доменов (и даже субдоменов) в Laravel.

Автор: Joe Lennon
Перевод: Demiurge Ash

Наши Телеграм и Вконтакте — следите за выходом новых статей через наши каналы.

Задать вопросы по урокам можно на нашем форуме.