Авторизація · Laravel

Окрім вбудованих сервісів автентифікації, Laravel дає простий спосіб авторизувати дії користувача щодо конкретного ресурсу. Наприклад, користувач може бути автентифікований, але не мати права оновлювати чи видаляти певні моделі Eloquent або записи в базі, якими керує ваш застосунок. Можливості авторизації в Laravel дають зручний і впорядкований спосіб керувати такими перевірками.

Laravel пропонує два основні способи авторизації дій: gates і політики. Думайте про gates і політики як про маршрути й контролери. Gates дають простий підхід на основі замикань, а політики, як і контролери, групують логіку навколо конкретної моделі чи ресурсу. У цій документації спершу розглянемо gates, а потім політики.

Обирати щось одне не потрібно. Більшість застосунків містять і gates, і політики, і це нормально. Gates найкраще пасують до дій, не повʼязаних із жодною моделлю чи ресурсом, як-от перегляд адміністративної панелі. Політики ж варто використовувати, коли ви хочете авторизувати дію щодо конкретної моделі або ресурсу.

Gates

Написання gates

Увага Gates добре підходять, щоб вивчити основи авторизації в Laravel; але для серйозних застосунків краще розглянути політики, щоб упорядкувати правила авторизації.

Gate - це просто замикання, яке визначає, чи має користувач право виконати певну дію. Зазвичай gates визначають у методі boot класу App\Providers\AppServiceProvider за допомогою фасаду Gate. Gate завжди отримує екземпляр користувача першим аргументом і може додатково отримувати інші аргументи, наприклад відповідну модель Eloquent.

У цьому прикладі визначимо gate, який перевіряє, чи може користувач оновити конкретну модель App\Models\Post. Gate робить це, порівнюючи id користувача з user_id того, хто створив допис:

use App\Models\Post;
use App\Models\User;
use Illuminate\Support\Facades\Gate;

/**
 * Bootstrap any application services.
 */
public function boot(): void
{
    Gate::define('update-post', function (User $user, Post $post) {
        return $user->id === $post->user_id;
    });
}

Як і контролери, gates можна визначати через масив із класом і методом:

use App\Policies\PostPolicy;
use Illuminate\Support\Facades\Gate;

/**
 * Bootstrap any application services.
 */
public function boot(): void
{
    Gate::define('update-post', [PostPolicy::class, 'update']);
}

Авторизація дій

Щоб авторизувати дію через gate, використовуйте методи allows або denies фасаду Gate. Зверніть увагу: передавати поточного автентифікованого користувача в ці методи не потрібно, Laravel сам передасть його в замикання gate. Зазвичай методи авторизації викликають у контролерах застосунку перед виконанням дії, яка вимагає авторизації:

<?php

namespace App\Http\Controllers;

use App\Models\Post;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Gate;

class PostController extends Controller
{
    /**
     * Update the given post.
     */
    public function update(Request $request, Post $post): RedirectResponse
    {
        if (! Gate::allows('update-post', $post)) {
            abort(403);
        }

        // Оновлюємо допис...

        return redirect('/posts');
    }
}

Якщо потрібно перевірити права не поточного автентифікованого користувача, а іншого, скористайтеся методом forUser фасаду Gate:

if (Gate::forUser($user)->allows('update-post', $post)) {
    // Користувач може оновити допис...
}

if (Gate::forUser($user)->denies('update-post', $post)) {
    // Користувач не може оновити допис...
}

Кілька дій одразу можна авторизувати методами any або none:

if (Gate::any(['update-post', 'delete-post'], $post)) {
    // Користувач може оновити або видалити допис...
}

if (Gate::none(['update-post', 'delete-post'], $post)) {
    // Користувач не може ані оновити, ані видалити допис...
}

Авторизація з викиданням винятку

Якщо ви хочете спробувати авторизувати дію й автоматично викинути Illuminate\Auth\Access\AuthorizationException, коли користувачеві це заборонено, скористайтеся методом authorize фасаду Gate. Екземпляри AuthorizationException Laravel автоматично перетворює на HTTP-відповідь 403:

Gate::authorize('update-post', $post);

// Дію авторизовано...

Передавання додаткового контексту

Методи gate для авторизації дозволів (allows, denies, check, any, none, authorize, can, cannot) і директиви Blade для авторизації (@can, @cannot, @canany) можуть приймати масив другим аргументом. Елементи цього масиву передаються параметрами в замикання gate і можуть слугувати додатковим контекстом для рішення про авторизацію:

use App\Models\Category;
use App\Models\User;
use Illuminate\Support\Facades\Gate;

Gate::define('create-post', function (User $user, Category $category, bool $pinned) {
    if (! $user->canPublishToGroup($category->group)) {
        return false;
    } elseif ($pinned && ! $user->canPinPosts()) {
        return false;
    }

    return true;
});

if (Gate::check('create-post', [$category, $pinned])) {
    // Користувач може створити допис...
}

Відповіді gate

Досі ми розглядали лише gates, які повертають звичайні булеві значення. Іноді ж потрібна докладніша відповідь із повідомленням про помилку. Для цього поверніть із gate обʼєкт Illuminate\Auth\Access\Response:

use App\Models\User;
use Illuminate\Auth\Access\Response;
use Illuminate\Support\Facades\Gate;

Gate::define('edit-settings', function (User $user) {
    return $user->isAdmin
        ? Response::allow()
        : Response::deny('You must be an administrator.');
});

Навіть якщо gate повертає обʼєкт відповіді авторизації, метод Gate::allows все одно поверне просте булеве значення; щоб отримати повну відповідь, скористайтеся методом Gate::inspect:

$response = Gate::inspect('edit-settings');

if ($response->allowed()) {
    // Дію авторизовано...
} else {
    echo $response->message();
}

Коли ви застосовуєте метод Gate::authorize, який викидає AuthorizationException, якщо дію не авторизовано, повідомлення про помилку з відповіді авторизації буде передано в HTTP-відповідь:

Gate::authorize('edit-settings');

// Дію авторизовано...

Налаштування статусу HTTP-відповіді

Коли gate забороняє дію, повертається HTTP-відповідь 403; іноді корисно повернути інший код статусу. Змінити код статусу для невдалої перевірки авторизації можна статичним конструктором denyWithStatus класу Illuminate\Auth\Access\Response:

use App\Models\User;
use Illuminate\Auth\Access\Response;
use Illuminate\Support\Facades\Gate;

Gate::define('edit-settings', function (User $user) {
    return $user->isAdmin
        ? Response::allow()
        : Response::denyWithStatus(404);
});

Оскільки приховування ресурсів через відповідь 404 є доволі поширеним шаблоном для вебзастосунків, для зручності передбачено метод denyAsNotFound:

use App\Models\User;
use Illuminate\Auth\Access\Response;
use Illuminate\Support\Facades\Gate;

Gate::define('edit-settings', function (User $user) {
    return $user->isAdmin
        ? Response::allow()
        : Response::denyAsNotFound();
});

Перехоплення перевірок gate

Іноді потрібно надати конкретному користувачеві всі дозволи. Для цього скористайтеся методом before, щоб визначити замикання, яке виконується перед усіма іншими перевірками авторизації:

use App\Models\User;
use Illuminate\Support\Facades\Gate;

Gate::before(function (User $user, string $ability) {
    if ($user->isAdministrator()) {
        return true;
    }
});

Якщо замикання before повертає значення, відмінне від null, саме воно вважатиметься результатом перевірки авторизації.

Методом after можна визначити замикання, яке виконується після всіх інших перевірок авторизації:

use App\Models\User;

Gate::after(function (User $user, string $ability, bool|null $result, mixed $arguments) {
    if ($user->isAdministrator()) {
        return true;
    }
});

Значення, повернуті замиканнями after, не перевизначають результат перевірки авторизації, якщо тільки gate або політика не повернули null.

Вбудована авторизація

Часом потрібно визначити, чи має поточний автентифікований користувач право виконати дію, не описуючи для цього окремий gate. Laravel дозволяє робити такі «вбудовані» перевірки авторизації через методи Gate::allowIf і Gate::denyIf. Вбудована авторизація не виконує жодних визначених хуків авторизації «before» чи «after»:

use App\Models\User;
use Illuminate\Support\Facades\Gate;

Gate::allowIf(fn (User $user) => $user->isAdministrator());

Gate::denyIf(fn (User $user) => $user->banned());

Якщо дію не авторизовано або жоден користувач наразі не автентифікований, Laravel автоматично викине виняток Illuminate\Auth\Access\AuthorizationException. Екземпляри AuthorizationException обробник винятків Laravel автоматично перетворює на HTTP-відповідь 403.

Створення політик

Генерація політик

Політики - це класи, які впорядковують логіку авторизації навколо конкретної моделі чи ресурсу. Наприклад, якщо ваш застосунок є блогом, у вас може бути модель App\Models\Post і відповідна політика App\Policies\PostPolicy, яка авторизує дії користувача на кшталт створення чи оновлення дописів.

Згенерувати політику можна Artisan-командою make:policy. Створений клас потрапить у теку app/Policies. Якщо такої теки у вашому застосунку немає, Laravel створить її:

php artisan make:policy PostPolicy

Команда make:policy згенерує порожній клас політики. Якщо ви хочете отримати клас із прикладами методів для перегляду, створення, оновлення й видалення ресурсу, передайте опцію --model:

php artisan make:policy PostPolicy --model=Post

Реєстрація політик

Автоматичне виявлення політик

Типово Laravel виявляє політики автоматично, якщо модель і політика дотримуються стандартних угод іменування Laravel. Зокрема, політики мають лежати в теці Policies на рівні теки з моделями або вище. Наприклад, моделі можуть бути в app/Models, а політики в app/Policies. У такій ситуації Laravel шукатиме політики спершу в app/Models/Policies, потім у app/Policies. До того ж імʼя політики має збігатися з іменем моделі та мати суфікс Policy. Отже, моделі User відповідатиме клас політики UserPolicy.

Якщо ви хочете описати власну логіку виявлення політик, зареєструйте власний колбек методом Gate::guessPolicyNamesUsing. Зазвичай цей метод викликають у методі boot класу AppServiceProvider вашого застосунку:

use Illuminate\Support\Facades\Gate;

Gate::guessPolicyNamesUsing(function (string $modelClass) {
    // Повертаємо імʼя класу політики для вказаної моделі...
});

Ручна реєстрація політик

За допомогою фасаду Gate ви можете вручну зареєструвати політики та відповідні їм моделі в методі boot класу AppServiceProvider:

use App\Models\Order;
use App\Policies\OrderPolicy;
use Illuminate\Support\Facades\Gate;

/**
 * Bootstrap any application services.
 */
public function boot(): void
{
    Gate::policy(Order::class, OrderPolicy::class);
}

Або ж можна розмістити атрибут UsePolicy на класі моделі, щоб повідомити Laravel про відповідну політику:

<?php

namespace App\Models;

use App\Policies\OrderPolicy;
use Illuminate\Database\Eloquent\Attributes\UsePolicy;
use Illuminate\Database\Eloquent\Model;

#[UsePolicy(OrderPolicy::class)]
class Order extends Model
{
    //
}

Написання політик

Методи політики

Після реєстрації класу політики можна додавати методи для кожної дії, яку він авторизує. Наприклад, визначимо метод update у нашій PostPolicy, який визначає, чи може конкретний App\Models\User оновити конкретний екземпляр App\Models\Post.

Метод update отримає аргументами екземпляри User і Post і має повернути true або false залежно від того, чи має користувач право оновити цей Post. Отже, у цьому прикладі ми перевіримо, що id користувача збігається з user_id допису:

<?php

namespace App\Policies;

use App\Models\Post;
use App\Models\User;

class PostPolicy
{
    /**
     * Determine if the given post can be updated by the user.
     */
    public function update(User $user, Post $post): bool
    {
        return $user->id === $post->user_id;
    }
}

Ви можете й далі описувати в політиці додаткові методи для різних дій, які вона авторизує. Наприклад, визначити методи view чи delete для різних дій, повʼязаних із Post, але памʼятайте: називати методи політики ви можете як завгодно.

Якщо під час генерації політики через консоль Artisan ви скористалися опцією --model, клас уже міститиме методи для дій viewAny, view, create, update, delete, restore і forceDelete.

Примітка Усі політики розвʼязуються через контейнер сервісів Laravel, тож ви можете вказувати типи потрібних залежностей у конструкторі політики, і вони будуть впроваджені автоматично.

Відповіді політики

Досі ми розглядали лише методи політики, які повертають звичайні булеві значення. Іноді ж потрібна докладніша відповідь із повідомленням про помилку. Для цього поверніть із методу політики екземпляр Illuminate\Auth\Access\Response:

use App\Models\Post;
use App\Models\User;
use Illuminate\Auth\Access\Response;

/**
 * Determine if the given post can be updated by the user.
 */
public function update(User $user, Post $post): Response
{
    return $user->id === $post->user_id
        ? Response::allow()
        : Response::deny('You do not own this post.');
}

Коли політика повертає обʼєкт відповіді авторизації, метод Gate::allows усе одно поверне просте булеве значення; щоб отримати повну відповідь авторизації, скористайтеся методом Gate::inspect:

use Illuminate\Support\Facades\Gate;

$response = Gate::inspect('update', $post);

if ($response->allowed()) {
    // Дію авторизовано...
} else {
    echo $response->message();
}

Коли ви застосовуєте метод Gate::authorize, який викидає AuthorizationException, якщо дію не авторизовано, повідомлення про помилку з відповіді авторизації буде передано в HTTP-відповідь:

Gate::authorize('update', $post);

// Дію авторизовано...

Налаштування статусу HTTP-відповіді

Коли метод політики забороняє дію, повертається HTTP-відповідь 403; іноді корисно повернути інший код статусу. Змінити код статусу для невдалої перевірки авторизації можна статичним конструктором denyWithStatus класу Illuminate\Auth\Access\Response:

use App\Models\Post;
use App\Models\User;
use Illuminate\Auth\Access\Response;

/**
 * Determine if the given post can be updated by the user.
 */
public function update(User $user, Post $post): Response
{
    return $user->id === $post->user_id
        ? Response::allow()
        : Response::denyWithStatus(404);
}

Оскільки приховування ресурсів через відповідь 404 є доволі поширеним шаблоном для вебзастосунків, для зручності передбачено метод denyAsNotFound:

use App\Models\Post;
use App\Models\User;
use Illuminate\Auth\Access\Response;

/**
 * Determine if the given post can be updated by the user.
 */
public function update(User $user, Post $post): Response
{
    return $user->id === $post->user_id
        ? Response::allow()
        : Response::denyAsNotFound();
}

Методи без моделей

Деякі методи політики отримують лише екземпляр поточного автентифікованого користувача. Найчастіше так буває під час авторизації дій create. Наприклад, якщо ви створюєте блог, вам може знадобитися визначити, чи має користувач право взагалі створювати дописи. У таких випадках метод політики має очікувати лише екземпляр користувача:

/**
 * Determine if the given user can create posts.
 */
public function create(User $user): bool
{
    return $user->role == 'writer';
}

Гостьові користувачі

Типово всі gates і політики автоматично повертають false, якщо вхідний HTTP-запит ініціював не автентифікований користувач. Але ви можете пропустити такі перевірки далі, до ваших gates і політик, оголосивши «необовʼязковий» тип або задавши значення null за замовчуванням для аргументу користувача:

<?php

namespace App\Policies;

use App\Models\Post;
use App\Models\User;

class PostPolicy
{
    /**
     * Determine if the given post can be updated by the user.
     */
    public function update(?User $user, Post $post): bool
    {
        return $user?->id === $post->user_id;
    }
}

Фільтри політик

Для певних користувачів може знадобитися авторизувати всі дії в межах політики. Для цього визначте в політиці метод before. Він виконається перед усіма іншими методами політики, даючи змогу авторизувати дію ще до того, як буде викликано потрібний метод. Найчастіше цю можливість застосовують, щоб дозволити адміністраторам застосунку виконувати будь-яку дію:

use App\Models\User;

/**
 * Perform pre-authorization checks.
 */
public function before(User $user, string $ability): bool|null
{
    if ($user->isAdministrator()) {
        return true;
    }

    return null;
}

Якщо ви хочете заборонити всі перевірки авторизації для певного типу користувачів, поверніть із методу before значення false. Якщо повернуто null, перевірка авторизації перейде до відповідного методу політики.

Увага Метод before класу політики не буде викликано, якщо в класі немає методу, імʼя якого збігається з назвою дозволу, що перевіряється.

Авторизація дій за допомогою політик

Через модель User

Модель App\Models\User, що входить до вашого застосунку Laravel, має два корисні методи для авторизації дій: can і cannot. Вони приймають назву дії, яку ви хочете авторизувати, і відповідну модель. Наприклад, визначимо, чи має користувач право оновити конкретну модель App\Models\Post. Зазвичай це роблять у методі контролера:

<?php

namespace App\Http\Controllers;

use App\Models\Post;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;

class PostController extends Controller
{
    /**
     * Update the given post.
     */
    public function update(Request $request, Post $post): RedirectResponse
    {
        if ($request->user()->cannot('update', $post)) {
            abort(403);
        }

        // Оновлюємо допис...

        return redirect('/posts');
    }
}

Якщо для вказаної моделі зареєстровано політику, метод can автоматично викличе потрібний метод політики й поверне булевий результат. Якщо політики для моделі не зареєстровано, метод can спробує викликати gate на основі замикання, назва якого збігається з назвою дії.

Дії, яким не потрібні моделі

Памʼятайте, що деякі дії можуть відповідати методам політики на кшталт create, яким не потрібен екземпляр моделі. У таких випадках передайте в метод can імʼя класу. За ним буде визначено, яку політику використати для авторизації дії:

<?php

namespace App\Http\Controllers;

use App\Models\Post;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;

class PostController extends Controller
{
    /**
     * Create a post.
     */
    public function store(Request $request): RedirectResponse
    {
        if ($request->user()->cannot('create', Post::class)) {
            abort(403);
        }

        // Створюємо допис...

        return redirect('/posts');
    }
}

Через фасад Gate

Крім зручних методів моделі App\Models\User, ви завжди можете авторизувати дії методом authorize фасаду Gate.

Як і can, цей метод приймає назву дії, яку ви хочете авторизувати, і відповідну модель. Якщо дію не авторизовано, метод authorize викине виняток Illuminate\Auth\Access\AuthorizationException, який обробник винятків Laravel автоматично перетворить на HTTP-відповідь зі статусом 403:

<?php

namespace App\Http\Controllers;

use App\Models\Post;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Gate;

class PostController extends Controller
{
    /**
     * Update the given blog post.
     *
     * @throws \Illuminate\Auth\Access\AuthorizationException
     */
    public function update(Request $request, Post $post): RedirectResponse
    {
        Gate::authorize('update', $post);

        // Поточний користувач може оновити допис блогу...

        return redirect('/posts');
    }
}

Дії, яким не потрібні моделі

Як уже згадувалося, деяким методам політики на кшталт create не потрібен екземпляр моделі. У таких випадках передайте в метод authorize імʼя класу. За ним буде визначено, яку політику використати для авторизації дії:

use App\Models\Post;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Gate;

/**
 * Create a new blog post.
 *
 * @throws \Illuminate\Auth\Access\AuthorizationException
 */
public function create(Request $request): RedirectResponse
{
    Gate::authorize('create', Post::class);

    // Поточний користувач може створювати дописи блогу...

    return redirect('/posts');
}

Через middleware

Laravel містить middleware, який може авторизувати дії ще до того, як вхідний запит дійде до ваших маршрутів чи контролерів. Типово middleware Illuminate\Auth\Middleware\Authorize можна приєднати до маршруту через аліас middleware can, який Laravel реєструє автоматично. Розгляньмо приклад із middleware can, щоб авторизувати оновлення допису користувачем:

use App\Models\Post;

Route::put('/post/{post}', function (Post $post) {
    // Поточний користувач може оновити допис...
})->middleware('can:update,post');

У цьому прикладі ми передаємо middleware can два аргументи. Перший - назва дії, яку хочемо авторизувати, другий - параметр маршруту, який хочемо передати в метод політики. Оскільки тут використано неявне привʼязування моделі, у метод політики буде передано модель App\Models\Post. Якщо користувач не має права виконати вказану дію, middleware поверне HTTP-відповідь зі статусом 403.

Для зручності middleware can можна приєднати до маршруту також методом can:

use App\Models\Post;

Route::put('/post/{post}', function (Post $post) {
    // Поточний користувач може оновити допис...
})->can('update', 'post');

Якщо ви користуєтеся атрибутами middleware у контролерах, застосувати middleware can можна через атрибут Authorize:

use Illuminate\Routing\Attributes\Controllers\Authorize;

#[Authorize('update', 'post')]
public function update(Post $post)
{
    // Поточний користувач може оновити допис...
}

Дії, яким не потрібні моделі

Знову ж таки, деяким методам політики на кшталт create не потрібен екземпляр моделі. У таких випадках передайте в middleware імʼя класу. За ним буде визначено, яку політику використати для авторизації дії:

Route::post('/post', function () {
    // Поточний користувач може створювати дописи...
})->middleware('can:create,App\Models\Post');

Вказувати повне імʼя класу в рядковому визначенні middleware буває громіздко. Тому ви можете приєднати middleware can до маршруту методом can:

use App\Models\Post;

Route::post('/post', function () {
    // Поточний користувач може створювати дописи...
})->can('create', Post::class);

Через шаблони Blade

Пишучи шаблони Blade, ви можете захотіти показати частину сторінки лише тоді, коли користувач має право виконати певну дію. Наприклад, показувати форму оновлення допису блогу лише тим, хто справді може його оновити. Для цього знадобляться директиви @can і @cannot:

@can('update', $post)
    <!-- Поточний користувач може оновити допис... -->
@elsecan('create', App\Models\Post::class)
    <!-- Поточний користувач може створювати нові дописи... -->
@else
    <!-- ... -->
@endcan

@cannot('update', $post)
    <!-- Поточний користувач не може оновити допис... -->
@elsecannot('create', App\Models\Post::class)
    <!-- Поточний користувач не може створювати нові дописи... -->
@endcannot

Ці директиви є зручними скороченнями для конструкцій @if і @unless. Наведені вище @can і @cannot рівносильні такому коду:

@if (Auth::user()->can('update', $post))
    <!-- Поточний користувач може оновити допис... -->
@endif

@unless (Auth::user()->can('update', $post))
    <!-- Поточний користувач не може оновити допис... -->
@endunless

Ви також можете визначити, чи має користувач право виконати будь-яку дію з переданого масиву дій. Для цього скористайтеся директивою @canany:

@canany(['update', 'view', 'delete'], $post)
    <!-- Поточний користувач може оновити, переглянути або видалити допис... -->
@elsecanany(['create'], \App\Models\Post::class)
    <!-- Поточний користувач може створити допис... -->
@endcanany

Дії, яким не потрібні моделі

Як і в більшості інших методів авторизації, директивам @can і @cannot можна передати імʼя класу, якщо дія не потребує екземпляра моделі:

@can('create', App\Models\Post::class)
    <!-- Поточний користувач може створювати дописи... -->
@endcan

@cannot('create', App\Models\Post::class)
    <!-- Поточний користувач не може створювати дописи... -->
@endcannot

Передавання додаткового контексту

Під час авторизації дій за допомогою політик ви можете передати масив другим аргументом у різні функції та хелпери авторизації. Перший елемент масиву визначає, яку політику викликати, а решта елементів передаються параметрами в метод політики й можуть слугувати додатковим контекстом для рішення про авторизацію. Розгляньмо, наприклад, таке визначення методу PostPolicy із додатковим параметром $category:

/**
 * Determine if the given post can be updated by the user.
 */
public function update(User $user, Post $post, int $category): bool
{
    return $user->id === $post->user_id &&
           $user->canUpdateCategory($category);
}

Щоб визначити, чи може автентифікований користувач оновити конкретний допис, цей метод політики викликають так:

/**
 * Update the given blog post.
 *
 * @throws \Illuminate\Auth\Access\AuthorizationException
 */
public function update(Request $request, Post $post): RedirectResponse
{
    Gate::authorize('update', [$post, $request->category]);

    // Поточний користувач може оновити допис блогу...

    return redirect('/posts');
}

Авторизація та Inertia

Хоча авторизацію завжди слід виконувати на сервері, часто буває зручно передати фронтенд-застосунку дані про авторизацію, щоб правильно відрендерити інтерфейс. Laravel не визначає обовʼязкової угоди щодо того, як розкривати інформацію про авторизацію фронтенду на Inertia.

Проте якщо ви користуєтеся одним із стартових наборів Laravel на основі Inertia, ваш застосунок уже містить middleware HandleInertiaRequests. У методі share цього middleware ви можете повернути спільні дані, доступні на всіх сторінках Inertia у вашому застосунку. Ці спільні дані є зручним місцем для опису інформації про авторизацію користувача:

<?php

namespace App\Http\Middleware;

use App\Models\Post;
use Illuminate\Http\Request;
use Inertia\Middleware;

class HandleInertiaRequests extends Middleware
{
    // ...

    /**
     * Define the props that are shared by default.
     *
     * @return array<string, mixed>
     */
    public function share(Request $request)
    {
        return [
            ...parent::share($request),
            'auth' => [
                'user' => $request->user(),
                'permissions' => [
                    'post' => [
                        'create' => $request->user()->can('create', Post::class),
                    ],
                ],
            ],
        ];
    }
}