# Autorización
El sistema de Backoffice no se encarga de manejar ningún tipo de login / logout / recordar contraseña, delegando toda ésta lógica al propio proyecto en el que se incluye el Backoffice.
Simplemente se encarga de la autorización, es decir, dejar mostrar o no el Backoffice en base a unas reglas.
# Autorización por defecto
Por defecto dejamos que se pueda mostrar el Backoffice en el environment local sin necesidad de ningún tipo de autenticación, siendo útil para desarrollo.
En el environment production sí que se requiere que haya un usuario autenticado.
# Modificar autorización
Las condiciones para autorizar la visualización del Backoffice pueden modificarse en el archivo Backoffice/Authorize.php
.
Por defecto vemos las condiciones planteadas en el apartado anterior:
public static function authorize(Request $request): bool
{
if (app()->environment('local')) {
return true;
}
return Auth::check();
}
Por ejemplo, si necesitamos que sólo accedan al Backoffice los usuarios que tengan el campo is_admin
a 1
:
public static function authorize(Request $request): bool
{
if (app()->environment('local')) {
return true;
}
return Auth::check() && $request->user()->is_admin == 1;
}
# SPA y autenticación para el Backoffice
Si el proyecto es una SPA, los endpoints estarán seguramente definidos en el archivo routes/api.php
, con lo cual están bajo el grupo de Middlewares api
.
Si el endpoint encargado del login de usuario (y quizás devolución de un token) está sobre api
, la autenticación de Laravel no hará efecto sobre el guard web
, que es el encargado de guardar el usuario logueado y por tanto la comprobación de Auth::check()
devolverá false
.
Para solventarlo, necesitamos añadir unos Middlewares adicionales al grupo api
:
EncryptCoookies
, StartSession
y AddQueuedCookiesToResponse
.
// app/Http/Kernel.php
'api' => [
\App\Http\Middleware\EncryptCookies::class,
'throttle:api',
\Illuminate\Routing\Middleware\SubstituteBindings::class,
\Illuminate\Session\Middleware\StartSession::class,
\Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
],
Entonces, desde el proceso de login, podemos usar el guard web
:
public function login(Request $request)
{
$credentials = $request->only(['email', 'password']);
if (Auth::guard('web')->attempt($credentials, true)) {
$user = Auth::guard('web')->user();
$token = $user->createToken('api')->plainTextToken;
return new JsonResource(['token' => $token]);
}
return new JsonResponse(['error' => ['Las credenciales son incorrectas']], 422);
}
De esta manera, proporcionamos un token para SPA y a su vez logueamos el usuario (bajo el guard web
), pudiendo comprobar correctamente el estado del usuario logueado en las condiciones definidas en Backoffice/Authorize.php
.