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:
El middlewareVerifyCsrfToken, 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:
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.
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.
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.
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:
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:
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.
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.
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:
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.
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.
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:
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.
Styde usa cookies para guardar tus preferencias y para seguimiento anónimo AceptarLeer más
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.