Protección CSRF – Documentación de Laravel 6

Introducción

Laravel hace que sea fácil proteger tu aplicación de ataques de tipo cross-site request forgery (CSRF). Los ataques de tipo CSRF son un tipo de explotación de vulnerabilidad malicioso por el cual comandos no autorizados son ejecutados en nombre de un usuario autenticado.

Laravel genera automáticamente un «token» CSRF para cada sesión de usuario activa manejada por la aplicación. Este token es usado para verificar que el usuario autenticado es quien en realidad está haciendo la petición a la aplicación.

En cualquier momento que definas un formulario HTML en tu aplicación, debes incluir un campo de token CSRF oculto en el formulario para que el middleware de protección CSRF pueda validar la solicitud. Puedes usar la directiva de Blade @csrf para generar el campo de token:

<form method="POST" action="/profile">
    @csrf
    ...
</form>

El middleware VerifyCsrfToken, el cual es incluido en el grupo de middleware web, verificará automáticamente que el token en el campo de la solicitud coincida con el almacenado en la sesión.

Tokens CSRF & JavaScript

Cuando se crean aplicaciones controladas por JavaScript, es conveniente hacer que tu librería HTTP de JavaScript agregue automáticamente el token CSRF a cada petición saliente. Por defecto, la librería HTTP Axios proporcionada en el archivo resources/js/bootstrap.js automáticamente envía un header X-XSRF-TOKEN usando el valor de la cookie encriptada XSRF-TOKEN. Si no estás usando esta librería, necesitarás configurar de forma manual este comportamiento en tus aplicaciones.

Excluyendo las URIs de la protección CSRF

Algunas veces puedes desear excluir un conjunto de URIs de la protección CSRF. Por ejemplo, si estás usando Stripe para procesar pagos y estás utilizando su sistema webhook, necesitarás excluir tu ruta de manejador webhook de Stripe de la protección CSRF ya que Stripe no sabrá que token CSRF enviar a sus rutas.

Típicamente, deberías colocar este tipo de rutas fuera del grupo de middleware web que el RouteServiceProvider aplica a todas las rutas en el archivo routes/web.php. Sin embargo, también puedes excluir las rutas al añadir sus URIs a la propiedad except del middleware VerifyCsrfToken:

<?php

namespace App\Http\Middleware;

use Illuminate\Foundation\Http\Middleware\VerifyCsrfToken as Middleware;

class VerifyCsrfToken extends Middleware
{
    /**
    * The URIs that should be excluded from CSRF verification.
    *
    * @var array
    */
    protected $except = [
        'stripe/*',
        'http://example.com/foo/bar',
        'http://example.com/foo/*',
    ];
}

El middleware CSRF está deshabilitado automáticamente al ejecutar pruebas.

X-CSRF-TOKEN

Además de comprobar el token CSRF como parámetro POST, el middleware VerifyCsrfToken también comprobará el encabezado de solicitud X-CSRF-TOKEN. Podrías, por ejemplo, almacenar el token en una etiqueta meta de HTML:

<meta name="csrf-token" content="{{ csrf_token() }}">

Entonces, una vez que has creado la etiqueta meta, puedes instruir una biblioteca como jQuery para añadir automáticamente el token a todos los encabezados de las peticiones. Esto proporciona protección CSRF fácil y conveniente para tus aplicaciones basadas en AJAX.

$.ajaxSetup({
    headers: {
        'X-CSRF-TOKEN': $('meta[name="csrf-token"]').attr('content')
    }
});

X-XSRF-TOKEN

Laravel almacena el token CSRF actual en una cookie XSRF-TOKEN encriptada que es incluida con cada respuesta generada por el framework. Puedes usar el valor del cookie para establecer el encabezado de la solicitud X-XSRF-TOKEN.

Esta cookie primeramente es enviada por conveniencia ya que algunos frameworks JavaScript y librerías, como Angular y Axios, colocan automáticamente su valor en el encabezado X-XSRF-TOKEN en las solicitudes de mismo origen.

Por defecto, el archivo resources/js/bootstrap.js incluye la librería HTTP Axios que enviará automáticamente esto por ti.

Middleware – Documentación de Laravel 6

Introducción

Los middleware proporcionan un mecanismo conveniente para filtrar solicitudes HTTP entrantes a tu aplicación. Por ejemplo, Laravel incluye un middleware que verifica si el usuario de tu aplicación está autenticado. Si el usuario no está autenticado, el middleware redireccionará al usuario a la pantalla de inicio de sesión. Sin embargo, si el usuario es autenticado, el middleware permitirá que la solicitud proceda dentro de la aplicación.

Los middleware adicionales pueden ser escritos para realizar una variedad de tareas además de autenticar. Un middleware de CORS podría ser responsable de agregar los encabezados apropiados para todas las respuestas que va dejando tu aplicación. Un middleware de registro podría registrar todas las solicitudes entrantes en tu aplicación.

Hay varios middleware incluidos en el framework Laravel, incluyendo middleware para autenticación y protección CSRF. Todos esos middleware están localizados en el directorio app/Http/Middleware.

Definiendo un middleware

Para crear un nuevo middleware, usa el comando de Artisan: make:middleware:

php artisan make:middleware CheckAge

Este comando ubicará una nueva clase CheckAge dentro de tu directorio app/Http/Middleware. En este middleware, nosotros solo permitiremos el acceso a la ruta si la age (edad) suministrada es mayor que 200. De otra forma, redireccionaremos a los usuarios de vuelta a la URL home:

<?php

namespace App\Http\Middleware;

use Closure;

class CheckAge
{
    /**
     * Handle an incoming request.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure  $next
     * @return mixed
     */
    public function handle($request, Closure $next)
    {
        if ($request->age <= 200) {
            return redirect('home');
        }

        return $next($request);
    }
}

Como puedes ver, si la age (edad) dada es menor o igual a 200, el middleware retornará una redirección HTTP al cliente; de otra forma, la solicitud pasará más adentro de la aplicación. Para pasar la solicitud más profundo dentro de la aplicación (permitiendo al middleware «pasar») llama al callback $next con el $request.

Es mejor visualizar el middleware como una serie de «capas» que deben pasar las solicitudes HTTP antes de que lleguen a tu aplicación. Cada capa puede examinar la solicitud e incluso rechazarla por completo.

Todos los middleware son resueltos a través del contenedor de servicio, de esta forma, puedes declarar el tipo de cualquier dependencia que necesites dentro del constructor del middleware.

Ver post

Rutas – Documentación de Laravel 6

Rutas básicas

Las rutas de Laravel más básicas aceptan una URI y una Closure, proporcionando un método muy fácil y expresivo de definición de rutas:

Route::get('foo', function () {
    return 'Hello World';
});

Los archivos de ruta predeterminados

Todas las rutas de Laravel están definidas en tus archivos de ruta, los cuales están localizados en el directorio routes. Estos archivos son cargados automáticamente por el framework. El archivo routes/web.php define rutas que son para tu interfaz web. Estas rutas son asignadas al grupo de middleware web, el cual proporciona características como estado de sesión y protección CSRF. Las rutas en routes/api.php son independientes de estado y son asignadas al grupo de middleware api.

Para las principales aplicaciones, empezarás definiendo rutas en tu archivo routes/web.php. Las rutas definidas en routes/web.php pueden ser accedidas colocando la URL de la ruta definida en tu navegador. Por ejemplo, puede acceder a la siguiente ruta al navegar a http://your-app.test/user en tu navegador:

Route::get('/user', 'UserController@index');

Las rutas definidas en el archivo routes/api.php son agrupadas dentro de un grupo de ruta por el RouteServiceProvider. Dentro de este grupo, el prefijo de URI /api es aplicado automáticamente de modo que no es necesario aplicarlo manualmente en todas las rutas en el archivo. Puedes modificar el prefijo y otras opciones de grupos de ruta al modificar tu clase RouteServiceProvider.

Métodos disponibles del enrutador

El enrutador permite que registres rutas que responden a cualquier verbo HTTP:

Route::get($uri, $callback);
Route::post($uri, $callback);
Route::put($uri, $callback);
Route::patch($uri, $callback);
Route::delete($uri, $callback);
Route::options($uri, $callback);

Algunas veces puede que necesites registrar una ruta que responda a verbos HTTP múltiples. Puedes hacerlo usando el método match. También, puedes incluso registrar una ruta que responda a todos los verbos HTTP usando el método any:

Route::match(['get', 'post'], '/', function () {
    //
});

Route::any('/', function () {
    //
});

Protección CSRF

Cualquiera de los formularios HTML que apunten a rutas POST, PUT, o DELETE que sean definidas en el archivo de rutas web deberían incluir un campo de token CSRF. De otra manera, la solicitud será rechazada. Puedes leer más sobre protección CSRF en la documentación de CSRF:

<form method="POST" action="/profile">
    @csrf
    ...
</form>

Ver post

Contratos – Documentación de Laravel 6

Introducción

Los Contratos de Laravel son un conjunto de interfaces que definen los servicios principales proporcionados por el framework. Por ejemplo, un contrato Illuminate\Contracts\Queue\Queue define los métodos necesarios para las colas de trabajo, mientras que el contrato Illuminate\Contracts\Mail\Mailer define los métodos necesarios para el envío de correos electrónicos.

Cada contrato tiene una implementación correspondiente provista por el framework. Por ejemplo, Laravel proporciona una implementación de cola con una variedad de conductores (drivers), y una implementación de envío de correo electrónico que funciona con SwiftMailer.

Todos los contratos de Laravel residen en su repositorio de GitHub propio. Esto proporciona un punto de referencia rápido para todos los contratos disponibles, así como un paquete único y desacoplado que puede ser utilizado por los desarrolladores de paquetes.

Ver post

Facades – Documentación de Laravel 6

Introducción

Las Facades proveen una interfaz «estática» a las clases disponibles en el contenedor de servicios de la aplicación. Laravel viene con numerosas facades, las cuales brindan acceso a casi todas las características de Laravel. Las facades de Laravel sirven como «proxies estáticas» a las clases subyacentes en el contenedor de servicios, brindando el beneficio de una sintaxis tersa y expresiva, manteniendo mayor verificabilidad y flexibilidad que los métodos estáticos tradicionales.

Todas las facades de Laravel se definen en el namespace Illuminate\Support\Facades. Entonces, podemos fácilmente acceder a una facade de esta forma:

use Illuminate\Support\Facades\Cache;

Route::get('/cache', function () {
    return Cache::get('key');
});

A través de la documentación de Laravel, muchos de los ejemplos usarán facades para demostrar varias características del framework.

Cuándo usar facades

Las Facades tienen múltiples beneficios. Brindan una sintaxis tersa y memorizable que permite utilizar las características de Laravel sin tener que recordar nombres de clase largos que deben ser inyectados o configurados manualmente. Además, debido a su uso único de los métodos dinámicos PHP, son fáciles de probar.

Sin embargo, deben guardarse ciertas precauciones al hacer uso de facades. El peligro principal de las facades es la corrupción de alcance de clases. Como las facades son tan fáciles de usar y no requieren inyección, puede resultar fácil dejar que tus clases sigan creciendo y usar muchas facades en una sola clase. Usando inyección de dependencias, este potencial es mitigado por la retroalimentación visual que un constructor grande te da cuando tu clase está creciendo demasiado. Entonces, al usar facades, pon especial atención al tamaño de tu clase para que su alcance de responsabilidades permanezca limitado.

Cuando se construye un paquete de terceros que interactúa con Laravel, es mejor inyectar contratos de Laravel en vez de usar facades. Como los paquetes son construidos fuera de Laravel, no tendrás acceso a las funciones (helpers) de testing para facades de Laravel.

Ver post

Proveedores de Servicios – Documentación de Laravel 6

Introducción

Los proveedores de servicios son la parte central del inicio básico de una aplicación Laravel (bootstrapping). Tu propia aplicación, así como todos los servicios principales de Laravel son iniciados rápidamente usando proveedores de servicios.

Pero, ¿qué queremos decir por «inicio básico (bootstrapped)»? En general, nos referimos a registrar cosas, incluyendo registrar enlaces de contenedores de servicios, listeners de eventos, middleware e incluso rutas. Los proveedores de servicios son el lugar principal para configurar tu aplicación.

Si abres el archivo config/app.php incluido con Laravel, verás un arreglo providers. Estas son todas las clases de proveedores de servicios que serán cargados por tu aplicación. Observa que muchos de éstos son proveedores «diferidos», lo que significa que no serán cargados en cada solicitud, sino sólo cuando los servicios que proporcionan sean necesarios.

En este resumen aprenderás a escribir tus propios proveedores de servicio y registrarlos en tu aplicación de Laravel.

Escribiendo proveedores de servicios

Todos los proveedores de servicios extienden de la clase Illuminate\Support\ServiceProvider. La mayoría de los proveedores de servicio contienen un método register y boot. Dentro del método register, debes enlazar cosas sólo al contenedor de servicios. Nunca debes tratar de registrar ningún listener de eventos, rutas o cualquier otra pieza de funcionalidad dentro del método register.

La línea de comandos Artisan puede generar un nuevo proveedor mediante el comando make:provider:

php artisan make:provider RiakServiceProvider

Ver post

Contenedor de servicios – Documentación de Laravel 6

Introducción

El contenedor de servicios de Laravel es una herramienta poderosa para administrar dependencias de clases y realizar inyección de dependencias. La inyección de dependencias es una frase bonita para básicamente decir: las dependencias de clases son «inyectadas» en la clase mediante el constructor o, en algunos casos, métodos «setter».

Demos un vistazo a un ejemplo sencillo:

<?php

namespace App\Http\Controllers;

use App\Http\Controllers\Controller;
use App\Repositories\UserRepository;
use App\User;

class UserController extends Controller
{
    /**
    * The user repository implementation.
    *
    * @var UserRepository
    */
    protected $users;

    /**
    * Create a new controller instance.
    *
    * @param  UserRepository  $users
    * @return void
    */
    public function __construct(UserRepository $users)
    {
        $this->users = $users;
    }

    /**
    * Show the profile for the given user.
    *
    * @param  int  $id
    * @return Response
    */
    public function show($id)
    {
        $user = $this->users->find($id);

        return view('user.profile', ['user' => $user]);
    }
}

En este ejemplo, UserController necesita retornar usuarios desde un origen de datos. Así que, inyectaremos un servicio que sea capaz de retornar los usuarios. En este contexto, nuestro UserRepository probablemente use Eloquent para retornar la información de los usuarios desde la base de datos. Sin embargo, dado que el repositorio es inyectado, seremos capaces de cambiarlo fácilmente con otra implementación. También seremos capaces de «simular» o crear una implementación de ejemplo de UserRepository al probar nuestra aplicación.

Un conocimiento profundo del contenedor de servicios de Laravel es esencial para construir aplicaciones grandes y poderosas así como también contribuir al núcleo de Laravel.

Enlaces

Ver post

Ciclo de vida de la solicitud – Documentación de Laravel 6

Introducción

Al usar cualquier herramienta en el «mundo real», te sientes más cómodo si entiendes cómo funciona esa herramienta. El desarrollo de aplicaciones no es diferente. Cuando entiendes cómo funcionan tus herramientas de desarrollo, te sientes más cómodo y seguro usándolas.

El objetivo de este documento es darte un buen resumen sobre cómo funciona el framework Laravel. Al conocer mejor el framework, todo lo demás se siente menos «mágico» y te sentirás más cómodo construyendo tus aplicaciones. Si no entiendes todos los términos de una sola vez, ¡no te desesperes! Sólo trata de obtener una comprensión básica de lo que está sucediendo y tus conocimientos crecerán a medida que explores otras secciones de la documentación.

Resumen del ciclo de vida

Lo primero

El punto de entrada para todas las solicitudes a una aplicación de Laravel es el archivo public/index.php. Todas las solicitudes son dirigidas a este archivo por la configuración de tu servidor web (Apache / Nginx). El archivo index.php no contiene mucho código. En su lugar, es un punto de partida para cargar el resto del framework.

El archivo index.php carga la definición de autocarga generada por Composer, y luego retorna una instancia de la aplicación de Laravel desde el script bootstrap/app.php. La primera acción tomada por Laravel es crear una instancia de la aplicación / contenedor de servicios.

Ver post

Despliegue – Documentación de Laravel 6

Introducción

Una vez que estés listo para hacer deploy de tu aplicación de Laravel a producción, deberías considerar algunos aspectos importantes para hacer que tu aplicación se ejecute de la forma más eficientemente posible. En este documento, vamos a cubrir muy buenos puntos para hacer que tu aplicación de Laravel sea desplegada correctamente.

Configuración del servidor

Nginx

Si estás haciendo deploy de tu aplicación hacia un servidor que está ejecutando Nginx, puedes utilizar el siguiente archivo de configuración como punto de inicio para configurar tu servidor web. Principalmente, este archivo tendrá que ser personalizado dependiendo de la configuración de tu servidor. Si deseas asistencia en la administración de tu servidor, considera utilizar un servicio como Laravel Forge:

server {
    listen 80;
    server_name example.com;
    root /example.com/public;

    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Content-Type-Options "nosniff";

    index index.html index.htm index.php;

    charset utf-8;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location = /favicon.ico { access_log off; log_not_found off; }
    location = /robots.txt  { access_log off; log_not_found off; }

    error_page 404 /index.php;

    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        include fastcgi_params;
    }

    location ~ /\.(?!well-known).* {
        deny all;
    }
}

Optimización

Ver post

Estructura de Directorios – Documentación de Laravel 6

Introducción

La estructura por defecto de aplicación de Laravel está pensada para proporcionar un buen punto de inicio para aplicaciones grandes y pequeñas. Pero, eres libre de organizar tu aplicación como quieras. Laravel no impone casi ninguna restricción sobre dónde una clase es ubicada – siempre y cuando Composer pueda cargar automáticamente la clase.

¿Donde está el directorio de modelos?

Al comenzar con Laravel, muchos desarrolladores son confundidos por la falta de un directorio models. Sin embargo, la falta de dicho directorio es intencional. Encontramos la palabra «models» ambigua dado que significa muchas cosas diferentes para muchas personas. Algunos desarrolladores se refieren al «modelo» de una aplicación como la totalidad de toda su lógica de negocio, mientras que otros se refieren a los «modelos» como clases que interactúan con una base de datos relacional.

Por esta razón, elegimos ubicar los modelos de Eloquent por defecto en el directorio app y permitir al desarrollar ubicarlos en algún otro sitio si así lo eligen.

Directorio Raíz

Directorio App

El directorio app contiene el código principal de tu aplicación. Exploraremos este directorio con más detalle pronto; sin embargo, casi todas las clases en tu aplicación estarán en este directorio.

Directorio Bootstrap

El directorio bootstrap contiene el archivo app.php que maqueta el framework. Este directorio también almacena un directorio cache que contiene archivos generados por el framework para optimización de rendimiento como los archivos de caché de rutas y servicios.

Directorio Config

El directorio config, como el nombre implica, contiene todos los archivos de configuración de tu aplicación. Es una buena idea leer todos estos archivos y familiarizarte con todas las opciones disponibles para ti.

Directorio Database

El directorio database contiene las migraciones de tu base de datos, model factories y seeders. Si lo deseas, puedes también usar este directorio para almacenar una base de datos SQLite.

Directorio Public

El directorio public contiene el archivo index.php, el cual es el punto de acceso para todas las solicitudes que llegan a tu aplicación y configura la autocarga. Este directorio también almacena tus assets, tales como imágenes, JavaScript y CSS.

Directorio Resources

El directorio resources contiene tus vistas así como también tus assets sin compilar tales como LESS, Sass o JavaScript. Este directorio también almacena todos tus archivos de idiomas.

Directorio Routes

El directorio routes contiene todas las definiciones de rutas para tu aplicación. Por defecto, algunos archivos de rutas son incluidos con Laravel: web.php, api.php, console.php y channels.php.

El archivo web.php contiene rutas que RouteServiceProvider coloca en el grupo de middleware web, que proporciona estado de sesión, protección CSRF y encriptación de cookies. Si tu aplicación no ofrece una API sin estado, todas tus rutas probablemente serán definidas en el archivo web.php.

El archivo api.php contiene rutas que RouteServiceProvider coloca en el grupo de middleware api, que proporcionan limitación de velocidad. Estas rutas están pensadas para no tener estado, así que las solicitudes que llegan a la aplicación a través de estas rutas están pensadas para ser autenticadas mediante tokens y no tendrán acceso al estado de sesión.

El archivo console.php es donde puedes definir todos los comandos de consola basados en Closures de tu aplicación. Cada Closure está enlazado a una instancia de comando permitiendo una forma simple de interactuar con los métodos de entrada y salida de cada comando. Aunque este archivo no define ninguna ruta HTTP, sí define puntos de entrada en consola (rutas) a tu aplicación.

El archivo channels.php es donde puedes registrar todos los canales de transmisión de eventos que tu aplicación soporta.

Directorio Storage

El directorio storage contiene tus plantillas compiladas de Blade, sesiones basadas en archivos, archivos de caché y otros archivos generados por el framework. Este directorio está segregado en los directorios app, framework y logs. El directorio app puede ser usado para almacenar cualquier archivo generado por tu aplicación. El directorio framework es usado para almacenar archivos generados por el framework y caché. Finalmente, el directorio logs contiene los archivos de registros de tu aplicación.

El directorio storage/app/public puede ser usado para almacenar archivos generados por el usario, tales como imágenes de perfil, que deberían ser accesibles públicamente. Debes crear un enlace simbólico en public/storage que apunte a este directorio. Puedes crear el enlace usando el comando php artisan storage:link.

El Directorio Tests

El directorio tests contiene tus pruebas automatizadas. Una prueba de ejemplo de PHPUnit es proporcionada. Cada clase de prueba debe tener el sufijo Test. Puedes ejecutar tus pruebas usando los comandos phpunit o php vendor/bin/phpunit.

Directorio Vendor

El directorio vendor contiene tus dependencias de Composer.

Directorio App

La mayoría de tu aplicación está almacenada en el directorio app. Por defecto, este directorio está regido por el espacio de nombre App y es cargado automáticamente por Composer usando el estándar de autocarga PSR-4.

El directorio app contiene una variedad de directorios adicionales tales como Console, Http y Providers. Piensa en los directorios Console y Http como si proporcionaran una API al núcleo de tu aplicación, pero no contienen lógica de la aplicación como tal. En otras palabras, son dos formas de emitir comandos a tu aplicación. El directorio Console contiene todos tus comandos de Artisan, mientras que el directorio Http contiene tus controladores, middleware y solicitudes.

Una variedad de otros directorios serán generados dentro del directorio app cuando uses los comandos make de Artisan para generar clases. Así que, por ejemplo, el directorio app/Jobs no existirá hasta que ejecutes el comando de Artisan make:job para generar una clase job.

Muchas de las clases en el directorio app pueden ser generadas por Artisan mediante comandos. Para ver los comandos disponibles, ejecuta el comando php artisan list make en tu terminal.

Directorio Broadcasting

El directorio Broadcasting contiene todas las clases de canales de broadcast de tu aplicación. Estas clases son generadas usando el comando make:channel. Este directorio no existe por defecto, pero será creado para ti cuando crees tu primer canal. Para aprender más sobre canales, revisa la documentación sobre broadcasting de eventos.

El Directorio Console

El directorio Console contiene todos los comandos personalizados de Artisan para tu aplicación. Estos comandos pueden ser generados usando el comando make:command. Este directorio también almacena el kernel de tu consola, que es donde tus comandos personalizados de Artisan son registrados y tus tareas programadas son definidas.

Directorio Events

Este directorio no existe por defecto, pero será creado para ti por los comandos de Artisan event:generate y make:event. El directorio Events almacena clases de eventos. Los eventos pueden ser usados para alertar a otras partes de tu aplicación que una acción dada ha ocurrido, proporcionando una gran cantidad de flexibilidad y desacoplamiento.

Directorio Exceptions

El directorio Exceptions contiene el manejador de excepciones de tu aplicación y también es un buen lugar para colocar cualquier excepción lanzada por tu aplicación. Si te gustaría personalizar cómo las excepciones son mostradas o renderizadas, debes modificar la clase Handler en este directorio.

Directorio Http

El directorio Http contiene tus controladores, middleware y form requests. Casi toda la lógica para manejar las solicitudes que llegan a tu aplicación serán colocadas en este directorio.

Directorio Jobs

Este directorio no existe por defecto, pero será creado para ti si ejecutas el comando de Artisan make:job. El directorio Jobs almacena las colas de trabajos para tu aplicación. Los trabajos pueden ser encolados por tu aplicación o ejecutados sincrónicamente dentro del ciclo de vida actual de la solicitud. Los trabajos que son ejecutados sincrónicamente durante la solicitud actual son algunas veces referidos como «comandos» dado que son una implementación del patrón de comandos.

Directorio Listeners

Este directorio no existe por defecto, pero será creado para ti si ejecutas los comandos de Artisan event:generate o make:listener. El directorio Listeners contiene las clases que manejan tus eventos. Los listeners de eventos reciben una instancia de evento y realizan la lógica en respuesta al evento siendo ejecutado. Por ejemplo, un evento UserRegistered puede ser manejado por un listener SendWelcomeEmail.

Directorio Mail

Este directorio no existe por defecto, pero será creado para ti si ejecutas el comando de Artisan make:mail. El directorio Mail contiene todas tus clases que representan correos electrónicos enviados por tu aplicación. Los objetos de correo te permiten encapsular toda la lógica para construir un correo en una única y sencilla clase, que puede ser enviada usando el método Mail::send.

Directorio Notifications

Este directorio no existe por defecto, pero será creado para ti si ejecutas el comando de Artisan make:notification. El directorio Notifications contiene todas las notificaciones «transaccionales» que son enviadas por tu aplicación, tales como notificaciones sencillas sobre eventos que ocurren dentro de tu aplicación. Las características de notifcaciones de Laravel abstrae el envío de notificaciones sobre una variedad de drivers como email, Slack, SMS o almacenadas en la base de datos.

Directorio Policies

Este directorio no existe por defecto, pero será creado para ti si ejecutas el comando de Artisan make:policy. El directorio Policies contiene las clases de las políticas de autorización de tu aplicación. Las políticas son usadas para determinar si un usuario puede realizar una acción dada contra un recurso. Para más información, revisa la documentación sobre autorización.

Directorio Providers

El directorio Providers contiene todos los proveedores de servicios para tu aplicación. Los proveedores de servicios maquetan tu aplicación al enlazar servicios en el contenedor de servicios, registrando eventos o realizando cualquier otra tarea para preparar tu aplicación para solicitudes entrantes.

En una aplicación de Laravel nueva, este directorio ya contendrá algunos proveedores. Eres libre de agregar tus propios proveedores a este directorio según sea necesario.

Directorio Rules

Este directorio no existe por defecto, pero será creado para ti si ejecutas el comando de Artisan make:rule. El directorio Rules contiene los objetos para las reglas de validación personalizadas de tu aplicación. Las reglas son usadas para encapsular lógica de validación complicada en un simple objeto. Para más información, revisa la documentación sobre validación.

Suscríbete a nuestro boletín

Te enviaremos publicaciones con consejos útiles y múltiples recursos para que sigas aprendiendo.

Suscríbete a nuestro boletín

Recibe consejos útiles, promos y múltiples recursos directamente en tu correo.

Tu nombre y correo serán enviados directamente a MailChimp. No compartiremos tus datos con otras empresas.