Laravel

Authorization

Authorization

Además de proporcionar servicios de autenticación integrados, Laravel también ofrece una manera sencilla de autorizar acciones de usuario contra un recurso dado. Por ejemplo, aunque un usuario esté autenticado, es posible que no esté autorizado para actualizar o eliminar ciertos modelos Eloquent o registros de base de datos gestionados por tu aplicación.

Laravel proporciona dos métodos principales para autorizar acciones: gates y policies. Piensa en gates y policies como rutas y controladores. Los gates ofrecen un enfoque simple basado en closures para la autorización, mientras que las policies, al igual que los controladores, agrupan la lógica alrededor de un modelo o recurso particular.

No es necesario elegir exclusivamente entre el uso de gates o el uso exclusivo de policies al construir una aplicación. La mayoría de las aplicaciones probablemente contendrán una mezcla de gates y policies, ¡y esto está perfectamente bien! Los gates son más aplicables a acciones que no están relacionadas con ningún modelo o recurso específico, como ver un panel de administrador. En contraste, las policies deben utilizarse cuando deseas autorizar una acción para un modelo o recurso particular.

Gates

Writing Gates

⚠️ Los gates son una excelente manera de aprender los conceptos básicos de las características de autorización de Laravel; sin embargo, al construir aplicaciones robustas en Laravel, deberías considerar utilizar policies para organizar tus reglas de autorización.

Los gates son simplemente closures que determinan si un usuario está autorizado para realizar una acción específica. Normalmente, los gates se definen dentro del método boot de la clase App\Providers\AppServiceProvider utilizando la fachada Gate. Los gates siempre reciben una instancia de User como su primer argumento y opcionalmente pueden recibir argumentos adicionales como un modelo Eloquent relevante.

En este ejemplo, vamos a definir un gate para determinar si un usuario puede actualizar un modelo App\Models\Post dado. El gate logrará esto comparando el id del usuario con el user_id del usuario que creó el post:

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;
    });
}

Al igual que con los controladores, los gates también se pueden definir utilizando un array.

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

Authorizing Actions

Para autorizar una acción utilizando gates, debes utilizar los métodos allows o denies proporcionados por la fachada Gate. Ten en cuenta que no es necesario pasar explícitamente al usuario autenticado a estos métodos. Laravel se encargará automáticamente de pasar el usuario al cierre del gate. Es típico llamar a los métodos de autorización de gate dentro de los controladores de tu aplicación antes de realizar una acción que requiera autorización:

<?php
 
namespace App\Http\Controllers;
 
use App\Http\Controllers\Controller;
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);
        }
        // Update the post...
        return redirect('/posts');
    }
}

Si deseas determinar si un usuario que no es el actualmente autenticado está autorizado para realizar una acción, puedes utilizar el método forUser en la fachada Gate:

if (Gate::forUser($user)->allows('update-post', $post)) {
    // The user can update the post...
}
 
if (Gate::forUser($user)->denies('update-post', $post)) {
    // The user can't update the post...
}

Puedes autorizar múltiples acciones al mismo tiempo utilizando los métodos any o none:

if (Gate::any(['update-post', 'delete-post'], $post)) {
    // The user can update or delete the post...
}
 
if (Gate::none(['update-post', 'delete-post'], $post)) {
    // The user can't update or delete the post...
}

Authorizing or Throwing Exceptions

Si deseas intentar autorizar una acción y automáticamente lanzar una Illuminate\Auth\Access\AuthorizationException si el usuario no está autorizado para realizar la acción dada, puedes usar el método authorize de la fachada Gate. Las instancias de AuthorizationException se convierten automáticamente en una respuesta HTTP 403 por Laravel:

Gate::authorize('update-post', $post);
 
// The action is authorized...

Supplying Additional Context

Los métodos de gate para autorizar capacidades (allows, denies, check, any, none, authorize, can, cannot) y las directivas de Blade de autorización (@can, @cannot, @canany) pueden recibir un array como su segundo argumento. Estos elementos del array se pasan como parámetros al cierre del gate y pueden ser utilizados para proporcionar contexto adicional al tomar decisiones de autorización.

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])) {
    // The user can create the post...
}

Gate Responses

Hasta ahora, solo hemos examinado gates que devuelven valores booleanos simples. Sin embargo, a veces puedes desear devolver una respuesta más detallada, incluyendo un mensaje de error. Para hacerlo, puedes devolver un objeto Illuminate\Auth\Access\Response desde tu gate:

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.');
});

Incluso cuando devuelvas una respuesta de autorización desde tu gate, el método Gate::allows seguirá devolviendo un valor booleano simple; sin embargo, puedes usar el método Gate::inspect para obtener la respuesta completa de autorización devuelta por el gate

$response = Gate::inspect('edit-settings');
 
if ($response->allowed()) {
    // The action is authorized...
} else {
    echo $response->message();
}

Cuando utilizas el método Gate::authorize, que lanza una AuthorizationException si la acción no está autorizada, el mensaje de error proporcionado por la respuesta de autorización se propagará a la respuesta HTTP.

Gate::authorize('edit-settings');
 
// The action is authorized...

Customizing The HTTP Response Status

Cuando una acción es denegada a través de un Gate, se devuelve una respuesta HTTP 403; sin embargo, a veces puede ser útil devolver un código de estado HTTP alternativo. Puedes personalizar el código de estado HTTP devuelto para una comprobación de autorización fallida utilizando el constructor estático denyWithStatus en la clase 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);
});

Debido a que ocultar recursos a través de una respuesta 404 es un patrón tan común en las aplicaciones web, se ofrece el método denyAsNotFound para mayor conveniencia.

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();
});

Intercepting Gate Checks

A veces, es posible que desees otorgar todas los permisos a un usuario específico. Puedes usar el método before para definir un closure que se ejecuta antes de todas las demás comprobaciones de autorización.

use App\Models\User;
use Illuminate\Support\Facades\Gate;
 
Gate::before(function (User $user, string $ability) {
    if ($user->isAdministrator()) {
        return true;
    }
});

Si el closure before devuelve un resultado que no sea nulo, ese resultado se considerará el resultado de la comprobación de autorización.

Puedes usar el método after para definir un cierre que se ejecutará después de todas las demás comprobaciones de autorización.

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

Si el closure after devuelve un resultado que no sea nulo, ese resultado se considerará el resultado de la comprobación de autorización.

Inline Authorization

Es posible que desees determinar si el usuario actualmente autenticado está autorizado para realizar una acción específica sin escribir un gate dedicado que corresponda a esa acción. Laravel te permite realizar este tipo de comprobaciones de autorización “en línea” mediante los métodos Gate::allowIf y Gate::denyIf. Las comprobaciones de autorización en línea no ejecutan ningún hook como “before” o “after”.

use App\Models\User;
use Illuminate\Support\Facades\Gate;
 
Gate::allowIf(fn (User $user) => $user->isAdministrator());
 
Gate::denyIf(fn (User $user) => $user->banned());

Si la acción no está autorizada o si no hay ningún usuario actualmente autenticado, Laravel automáticamente lanzará una excepción Illuminate\Auth\Access\AuthorizationException. Las instancias de AuthorizationException son automáticamente convertidas en una respuesta HTTP 403 por el manejador de excepciones de Laravel

Creating Policies

Las policies son clases que organizan la lógica de autorización alrededor de un modelo o recurso particular. Por ejemplo, si tu aplicación es un blog, podrías tener un modelo App\Models\Post y una correspondiente policy App\Policies\PostPolicy para autorizar acciones de usuario como crear o actualizar posts.

Puedes generar una policy utilizando el comando Artisan make:policy La policy generada se ubicará en el directorio app/Policies. Si este directorio no existe en tu aplicación, Laravel lo creará automáticamente por ti:

php artisan make:policy PostPolicy

El comando make:policy generará una clase de policy vacía. Si deseas generar una clase con métodos de policies de ejemplo relacionados con la visualización, creación, actualización y eliminación del recurso, puedes proporcionar la opción –model al ejecutar el comando:

php artisan make:policy PostPolicy --model=Post

Registering Policies

Policy Discovery

Por defecto, Laravel descubre automáticamente las policies siempre que el modelo y la policy sigan las convenciones de nombres estándar de Laravel. Específicamente, las policies deben estar en un directorio Policies en el mismo nivel o superior al directorio que contiene tus modelos. Por ejemplo, los modelos pueden estar ubicados en el directorio app/Models mientras que las policies pueden estar en el directorio app/Policies. En esta situación, Laravel buscará policies primero en app/Models/Policies y luego en app/Policies. Además, el nombre de la policy debe coincidir con el nombre del modelo y tener un sufijo Policy. Por lo tanto, un modelo User correspondería a una clase de policy UserPolicy.

Si deseas definir tu propia lógica de descubrimiento de políticas, puedes registrar un callback personalizado de descubrimiento de políticas utilizando el método Gate::guessPolicyNamesUsing. Típicamente, este método debería ser llamado desde el método boot de la clase AppServiceProvider de tu aplicación.

use Illuminate\Support\Facades\Gate;
 
Gate::guessPolicyNamesUsing(function (string $modelClass) {
    // Return the name of the policy class for the given model...
});

Manually Registering Policies

Utilizando la fachada Gate, puedes registrar manualmente políticas y sus modelos correspondientes dentro del método boot de AppServiceProvider de tu aplicación.

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);
}

Writing Policies

Policy Methods

Una vez que la clase de política haya sido registrada, puedes agregar métodos para cada acción que autorice. Por ejemplo, vamos a definir un método update en nuestro PostPolicy que determine si un usuario dado (App\Models\User) puede actualizar una instancia dada de App\Models\Post.

El método update recibirá como argumentos una instancia de User y una instancia de Post, y debería devolver true o false indicando si el usuario está autorizado para actualizar el Post dado. En este ejemplo, verificaremos que el ID del usuario coincida con user_id en el post:

<?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;
    }
}

Puedes continuar definiendo métodos adicionales en la política según sea necesario para las diferentes acciones que autoriza. Por ejemplo, podrías definir métodos como view o delete para autorizar diversas acciones relacionadas con Post. Recuerda que tienes la libertad de dar a tus métodos de política cualquier nombre que desees.

Si utilizaste la opción –model al generar tu política a través de la consola Artisan, esta ya contendrá métodos para las acciones viewAny, view, create, update, delete, restore y forceDelete.

⚠️ Todas las políticas se resuelven a través del contenedor de servicios de Laravel, lo que te permite hacer type-hinting de cualquier dependencia necesaria en el constructor de la política para que sean inyectadas automáticamente.

Policy Responses

Hasta ahora, solo hemos examinado métodos de políticas que devuelven valores booleanos simples. Sin embargo, a veces es posible que desee devolver una respuesta más detallada, que incluya un mensaje de error. Para hacerlo, puede devolver una instancia de Illuminate\Auth\Access\Response desde el método de la política.

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.');
}

Al devolver una respuesta de autorización desde su política, el método Gate::allows aún devolverá un valor booleano simple; sin embargo, puede usar el método Gate::inspect para obtener la respuesta completa de autorización devuelta por el Gate

use Illuminate\Support\Facades\Gate;
 
$response = Gate::inspect('update', $post);
 
if ($response->allowed()) {
    // The action is authorized...
} else {
    echo $response->message();
}

Al usar el método Gate::authorize, el cual lanza una AuthorizationException si la acción no está autorizada, el mensaje de error proporcionado por la respuesta de autorización se propagará a la respuesta HTTP.

Gate::authorize('update', $post);
 
// The action is authorized...

Customizing the HTTP Response Status

Cuando una acción es denegada a través de un método de política, se devuelve una respuesta HTTP 403; sin embargo, a veces puede ser útil devolver un código de estado HTTP alternativo. Puede personalizar el código de estado HTTP devuelto por una verificación de autorización fallida utilizando el constructor estático denyWithStatus de la clase 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);
}

Debido a que ocultar recursos mediante una respuesta 404 es un patrón común en las aplicaciones web, se ofrece el método denyAsNotFound para mayor comodidad.

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();
}

Algunos métodos de políticas solo reciben una instancia del usuario actualmente autenticado. Esta situación es más común al autorizar acciones de creación. Por ejemplo, si está creando un blog, es posible que desee determinar si un usuario está autorizado para crear publicaciones en general. En estas situaciones, su método de política solo debe esperar recibir una instancia de usuario.

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

Guest Users

Por defecto, todas las gates y políticas devuelven automáticamente false si la solicitud HTTP entrante no fue iniciada por un usuario autenticado. Sin embargo, puede permitir que estas verificaciones de autorización pasen a sus gates y policies declarando una sugerencia de tipo “opcional” o proporcionando un valor predeterminado null para la definición del argumento user.

<?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;
    }
}

Policy Filters

Para ciertos usuarios, es posible que desee autorizar todas las acciones dentro de una política determinada. Para lograr esto, defina un método before en la política. El método before se ejecutará antes que cualquier otro método en la política, dándole la oportunidad de autorizar la acción antes de que se llame al método de política previsto. Esta característica se utiliza más comúnmente para autorizar a los administradores de la aplicación a realizar cualquier acción.

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

Si desea denegar todas las verificaciones de autorización para un tipo particular de usuario, puede devolver false desde el método before. Si se devuelve null, la verificación de autorización pasará al método de la política.

⚠️ El método before de una clase de policies no será llamado si la clase no contiene un método cuyo nombre coincida con el nombre de la habilidad que se está verificando.

Authorizing Actions Using Policies

Via the User Model

El modelo App\Models\User que se incluye en tu aplicación Laravel incluye dos métodos útiles para autorizar acciones: can y cannot. Los métodos can y cannot reciben el nombre de la acción que deseas autorizar y el modelo relevante. Por ejemplo, vamos a determinar si un usuario está autorizado para actualizar un modelo dado App\Models\Post. Normalmente, esto se hará dentro de un método del controlador.

<?php
 
namespace App\Http\Controllers;
 
use App\Http\Controllers\Controller;
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);
        }
 
        // Update the post...
 
        return redirect('/posts');
    }
}

Si una política está registrada para el modelo dado, el método can llamará automáticamente a la política correspondiente y devolverá el resultado booleano. Si no hay una política registrada para el modelo, el método can intentará llamar al Gate basado en closures que coincida con el nombre de la acción dada.

Actions That Don’t Require Models

Recuerde, algunas acciones pueden corresponder a métodos de políticas como create que no requieren una instancia del modelo. En estas situaciones, puede pasar un nombre de clase al método can. El nombre de la clase se utilizará para determinar qué política usar al autorizar la acción.

<?php
 
namespace App\Http\Controllers;
 
use App\Http\Controllers\Controller;
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);
        }
 
        // Create the post...
 
        return redirect('/posts');
    }
}

Via the Gate Facade

Además de los métodos útiles proporcionados al modelo App\Models\User, siempre puede autorizar acciones a través del método authorize de la fachada Gate.

Al igual que el método can, este método acepta el nombre de la acción que desea autorizar y el modelo relevante. Si la acción no está autorizada, el método authorize lanzará una excepción Illuminate\Auth\Access\AuthorizationException, que el manejador de excepciones de Laravel convertirá automáticamente en una respuesta HTTP con un código de estado 403.

<?php
 
namespace App\Http\Controllers;
 
use App\Http\Controllers\Controller;
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);
 
        // The current user can update the blog post...
 
        return redirect('/posts');
    }
}

Actions That Don’t Require Models

Como se discutió anteriormente, algunos métodos de políticas como create no requieren una instancia del modelo. En estas situaciones, debe pasar un nombre de clase al método authorize. El nombre de la clase se utilizará para determinar qué política usar al autorizar la acción.

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);
 
    // The current user can create blog posts...
 
    return redirect('/posts');
}

Via Middleware

Laravel incluye un middleware que puede autorizar acciones antes de que la solicitud entrante llegue a sus rutas o controladores. Por defecto, el middleware Illuminate\Auth\Middleware\Authorize puede ser adjuntado a una ruta usando el alias de middleware can, el cual es registrado automáticamente por Laravel. Vamos a explorar un ejemplo de cómo usar el middleware can para autorizar que un usuario pueda actualizar una publicación.

use App\Models\Post;
 
Route::put('/post/{post}', function (Post $post) {
    // The current user may update the post...
})->middleware('can:update,post');

En este ejemplo, estamos pasando dos argumentos al middleware can. El primero es el nombre de la acción que deseamos autorizar y el segundo es el parámetro de ruta que deseamos pasar al método de la política. En este caso, dado que estamos utilizando la vinculación implícita de modelos, se pasará un modelo App\Models\Post al método de la política. Si el usuario no está autorizado para realizar la acción dada, el middleware devolverá una respuesta HTTP con un código de estado 403.

Para mayor comodidad, también puede adjuntar el middleware can a su ruta utilizando el método can:

use App\Models\Post;
 
Route::put('/post/{post}', function (Post $post) {
    // The current user may update the post...
})->can('update', 'post');

Actions That Don’t Require Models

Nuevamente, algunos métodos de políticas como create no requieren una instancia del modelo. En estas situaciones, puede pasar un nombre de clase al middleware. El nombre de la clase se utilizará para determinar qué política usar al autorizar la acción.

Route::post('/post', function () {
    // The current user may create posts...
})->middleware('can:create,App\Models\Post');

Especificar el nombre completo de la clase dentro de una definición de middleware en una cadena puede volverse engorroso. Por esa razón, puede optar por adjuntar el middleware can a su ruta y usar Model::class.

use App\Models\Post;
 
Route::post('/post', function () {
    // The current user may create posts...
})->can('create', Post::class);

Via Blade Templates

Cuando escriba plantillas Blade, puede que desee mostrar una parte de la página solo si el usuario está autorizado para realizar una acción determinada. Por ejemplo, puede que desee mostrar un formulario de actualización para una publicación de blog solo si el usuario realmente puede actualizar la publicación. En esta situación, puede usar las directivas @can y @cannot.

@can('update', $post)
    <!-- The current user can update the post... -->
@elsecan('create', App\Models\Post::class)
    <!-- The current user can create new posts... -->
@else
    <!-- ... -->
@endcan
 
@cannot('update', $post)
    <!-- The current user cannot update the post... -->
@elsecannot('create', App\Models\Post::class)
    <!-- The current user cannot create new posts... -->
@endcannot

Estas directivas son atajos convenientes para escribir declaraciones @if y @unless. Las declaraciones @can y @cannot de arriba son equivalentes a las siguientes declaraciones:

@if (Auth::user()->can('update', $post))
    <!-- The current user can update the post... -->
@endif
 
@unless (Auth::user()->can('update', $post))
    <!-- The current user cannot update the post... -->
@endunless

Para determinar si un usuario está autorizado para realizar cualquier acción dentro de un conjunto dado de acciones, puedes utilizar la directiva @canany en Blade. Esta directiva es útil cuando deseas verificar la autorización para varias acciones al mismo tiempo.

@canany(['update', 'view', 'delete'], $post)
    <!-- The current user can update, view, or delete the post... -->
@elsecanany(['create'], \App\Models\Post::class)
    <!-- The current user can create a post... -->
@endcanany

Actions That Don’t Require Models

@can('create', App\Models\Post::class)
    <!-- The current user can create posts... -->
@endcan
 
@cannot('create', App\Models\Post::class)
    <!-- The current user can't create posts... -->
@endcannot

Supplying Additional Context

Cuando autorizas acciones utilizando políticas, puedes pasar un array como segundo argumento a varias funciones y ayudantes de autorización. El primer elemento en el array se utilizará para determinar qué política debe ser invocada, mientras que el resto de los elementos del array se pasan como parámetros al método de la política y pueden ser utilizados para proporcionar contexto adicional al tomar decisiones de autorización. Por ejemplo, considera la siguiente definición del método PostPolicy que contiene un parámetro adicional $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);
}

Cuando intentamos determinar si el usuario autenticado puede actualizar un Post dado, podemos invocar este método de política de la siguiente manera:

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

Authorization & Inertia

Aunque la autorización siempre debe manejarse en el servidor, a menudo es conveniente proporcionar a tu aplicación frontend datos de autorización para renderizar correctamente la interfaz de usuario de tu aplicación. Laravel no define una convención requerida para exponer información de autorización a un frontend impulsado por Inertia.

Sin embargo, si estás utilizando uno de los kits de inicio basados en Inertia de Laravel, tu aplicación ya contiene un middleware HandleInertiaRequests. Dentro del método share de este middleware, puedes devolver datos compartidos que se proporcionarán a todas las páginas de Inertia en tu aplicación. Estos datos compartidos pueden servir como un lugar conveniente para definir la información de autorización para el usuario.

<?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),
                    ],
                ],
            ],
        ];
    }
}