- Introducción
- Primeros pasos con la validación
- Validación con Form Request
- Creando validadores manualmente
- Trabajando con la entrada validada
- Trabajando con mensajes de error
- Reglas de validación disponibles
- Agregando reglas condicionalmente
- Validando arrays
- Validando archivos
- Validando contraseñas
- Reglas de validación personalizadas
#Introducción
Laravel ofrece varias formas diferentes para validar los datos entrantes de su aplicación. Lo más común es usar el método validate disponible en todas las solicitudes HTTP entrantes. Sin embargo, también discutiremos otros enfoques para la validación.
Laravel incluye una amplia variedad de reglas de validación convenientes que puede aplicar a los datos, incluso proporcionando la capacidad de validar si los valores son únicos en una tabla de base de datos dada. Cubriremos cada una de estas reglas de validación en detalle para que esté familiarizado con todas las características de validación de Laravel.
#Primeros pasos con la validación
Para aprender sobre las potentes características de validación de Laravel, veamos un ejemplo completo de cómo validar un formulario y mostrar los mensajes de error al usuario. Al leer esta visión general, podrá obtener una buena comprensión general de cómo validar los datos entrantes de una solicitud usando Laravel:
#Definiendo las rutas
Primero, supongamos que tenemos las siguientes rutas definidas en nuestro archivo routes/web.php:
use App\Http\Controllers\PostController;
Route::get('/post/create', [PostController::class, 'create']);
Route::post('/post', [PostController::class, 'store']);
La ruta GET mostrará un formulario para que el usuario cree una nueva publicación de blog, mientras que la ruta POST almacenará la nueva publicación en la base de datos.
#Creando el controlador
A continuación, veamos un controlador simple que maneja las solicitudes entrantes a estas rutas. Dejaremos el método store vacío por ahora:
<?php
namespace App\Http\Controllers;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;
use Illuminate\View\View;
class PostController extends Controller
{
/**
* Mostrar el formulario para crear una nueva publicación de blog.
*/
public function create(): View
{
return view('post.create');
}
/**
* Almacenar una nueva publicación de blog.
*/
public function store(Request $request): RedirectResponse
{
// Validar y almacenar la publicación de blog...
$post = /** ... */
return to_route('post.show', ['post' => $post->id]);
}
}
#Escribiendo la lógica de validación
Ahora estamos listos para completar nuestro método store con la lógica para validar la nueva publicación de blog. Para hacer esto, usaremos el método validate proporcionado por el objeto Illuminate\Http\Request. Si las reglas de validación pasan, su código continuará ejecutándose normalmente; sin embargo, si la validación falla, se lanzará una excepción Illuminate\Validation\ValidationException y la respuesta de error adecuada se enviará automáticamente al usuario.
Si la validación falla durante una solicitud HTTP tradicional, se generará una respuesta de redirección a la URL anterior. Si la solicitud entrante es una solicitud XHR, se devolverá una respuesta JSON que contiene los mensajes de error de validación.
Para entender mejor el método validate, volvamos al método store:
/**
* Almacenar una nueva publicación de blog.
*/
public function store(Request $request): RedirectResponse
{
$validated = $request->validate([
'title' => 'required|unique:posts|max:255',
'body' => 'required',
]);
// La publicación de blog es válida...
return redirect('/posts');
}
Como puede ver, las reglas de validación se pasan al método validate. No se preocupe: todas las reglas de validación disponibles están documentadas. Nuevamente, si la validación falla, la respuesta adecuada se generará automáticamente. Si la validación pasa, nuestro controlador continuará ejecutándose normalmente.
Alternativamente, las reglas de validación pueden especificarse como arrays de reglas en lugar de una cadena delimitada por |:
$validatedData = $request->validate([
'title' => ['required', 'unique:posts', 'max:255'],
'body' => ['required'],
]);
Además, puede usar el método validateWithBag para validar una solicitud y almacenar cualquier mensaje de error dentro de una bolsa de errores nombrada:
$validatedData = $request->validateWithBag('post', [
'title' => ['required', 'unique:posts', 'max:255'],
'body' => ['required'],
]);
#Detenerse en el primer fallo de validación
A veces puede desear detener la ejecución de las reglas de validación en un atributo después del primer fallo de validación. Para hacerlo, asigne la regla bail al atributo:
$request->validate([
'title' => 'bail|required|unique:posts|max:255',
'body' => 'required',
]);
En este ejemplo, si la regla unique en el atributo title falla, la regla max no se verificará. Las reglas se validan en el orden en que se asignan.
#Una nota sobre atributos anidados
Si la solicitud HTTP entrante contiene datos de campos "anidados", puede especificar estos campos en sus reglas de validación usando la sintaxis de "puntos":
$request->validate([
'title' => 'required|unique:posts|max:255',
'author.name' => 'required',
'author.description' => 'required',
]);
Por otro lado, si el nombre de su campo contiene un punto literal, puede evitar explícitamente que esto se interprete como sintaxis de "puntos" escapando el punto con una barra invertida:
$request->validate([
'title' => 'required|unique:posts|max:255',
'v1\.0' => 'required',
]);
#Mostrando los errores de validación
Entonces, ¿qué sucede si los campos de la solicitud entrante no pasan las reglas de validación dadas? Como se mencionó anteriormente, Laravel redirigirá automáticamente al usuario a su ubicación anterior. Además, todos los errores de validación y la entrada de la solicitud se guardarán automáticamente en la sesión.
Una variable $errors se comparte con todas las vistas de su aplicación mediante el middleware Illuminate\View\Middleware\ShareErrorsFromSession, que es proporcionado por el grupo de middleware web. Cuando se aplica este middleware, una variable $errors siempre estará disponible en sus vistas, permitiéndole asumir cómodamente que la variable $errors siempre está definida y puede usarse de forma segura. La variable $errors será una instancia de Illuminate\Support\MessageBag. Para más información sobre cómo trabajar con este objeto, consulte su documentación.
Así que, en nuestro ejemplo, el usuario será redirigido al método create de nuestro controlador cuando la validación falle, permitiéndonos mostrar los mensajes de error en la vista:
<!-- /resources/views/post/create.blade.php -->
<h1>Create Post</h1>
@if ($errors->any())
<div class="alert alert-danger">
<ul>
@foreach ($errors->all() as $error)
<li>{{ $error }}</li>
@endforeach
</ul>
</div>
@endif
<!-- Formulario para crear publicación -->
#Personalizando los mensajes de error
Las reglas de validación integradas de Laravel tienen cada una un mensaje de error que se encuentra en el archivo lang/en/validation.php de su aplicación. Si su aplicación no tiene un directorio lang, puede indicarle a Laravel que lo cree usando el comando Artisan lang:publish.
Dentro del archivo lang/en/validation.php, encontrará una entrada de traducción para cada regla de validación. Puede cambiar o modificar estos mensajes según las necesidades de su aplicación.
Además, puede copiar este archivo a otro directorio de idioma para traducir los mensajes al idioma de su aplicación. Para aprender más sobre la localización en Laravel, consulte la completa documentación de localización.
Por defecto, el esqueleto de la aplicación Laravel no incluye el directorio lang. Si desea personalizar los archivos de idioma de Laravel, puede publicarlos mediante el comando Artisan lang:publish.
#Solicitudes XHR y validación
En este ejemplo, usamos un formulario tradicional para enviar datos a la aplicación. Sin embargo, muchas aplicaciones reciben solicitudes XHR desde un frontend impulsado por JavaScript. Al usar el método validate durante una solicitud XHR, Laravel no generará una respuesta de redirección. En su lugar, Laravel genera una respuesta JSON que contiene todos los errores de validación. Esta respuesta JSON se enviará con un código de estado HTTP 422.
#La directiva @error
Puede usar la directiva @error de Blade para determinar rápidamente si existen mensajes de error de validación para un atributo dado. Dentro de una directiva @error, puede mostrar la variable $message para mostrar el mensaje de error:
<!-- /resources/views/post/create.blade.php -->
<label for="title">Post Title</label>
<input id="title"
type="text"
name="title"
class="@error('title') is-invalid @enderror">
@error('title')
<div class="alert alert-danger">{{ $message }}</div>
@enderror
Si está usando bolsas de errores nombradas, puede pasar el nombre de la bolsa de errores como segundo argumento a la directiva @error:
<input ... class="@error('title', 'post') is-invalid @enderror">
#Rellenando formularios
Cuando Laravel genera una respuesta de redirección debido a un error de validación, el framework automáticamente guarda toda la entrada de la solicitud en la sesión. Esto se hace para que pueda acceder cómodamente a la entrada durante la siguiente solicitud y rellenar el formulario que el usuario intentó enviar.
Para recuperar la entrada guardada de la solicitud anterior, invoque el método old en una instancia de Illuminate\Http\Request. El método old extraerá los datos de entrada previamente guardados de la sesión:
$title = $request->old('title');
Laravel también proporciona un helper global old. Si está mostrando entrada antigua dentro de una plantilla Blade, es más conveniente usar el helper old para rellenar el formulario. Si no existe entrada antigua para el campo dado, se devolverá null:
<input type="text" name="title" value="{{ old('title') }}">
#Una nota sobre campos opcionales
Por defecto, Laravel incluye los middleware TrimStrings y ConvertEmptyStringsToNull en la pila global de middleware de su aplicación. Estos middleware están listados en la pila por la clase App\Http\Kernel. Debido a esto, a menudo necesitará marcar sus campos "opcionales" en la solicitud como nullable si no desea que el validador considere los valores null como inválidos. Por ejemplo:
$request->validate([
'title' => 'required|unique:posts|max:255',
'body' => 'required',
'publish_at' => 'nullable|date',
]);
En este ejemplo, especificamos que el campo publish_at puede ser null o una representación válida de fecha. Si no se agrega el modificador nullable a la definición de la regla, el validador consideraría null como una fecha inválida.
#Formato de respuesta de error de validación
Cuando su aplicación lanza una excepción Illuminate\Validation\ValidationException y la solicitud HTTP entrante espera una respuesta JSON, Laravel formateará automáticamente los mensajes de error y devolverá una respuesta HTTP 422 Unprocessable Entity.
A continuación, puede revisar un ejemplo del formato de respuesta JSON para errores de validación. Note que las claves de error anidadas se aplanan en formato de notación "punto":
{
"message": "The team name must be a string. (and 4 more errors)",
"errors": {
"team_name": [
"The team name must be a string.",
"The team name must be at least 1 characters."
],
"authorization.role": [
"The selected authorization.role is invalid."
],
"users.0.email": [
"The users.0.email field is required."
],
"users.2.email": [
"The users.2.email must be a valid email address."
]
}
}
#Validación con Form Request
#Creando Form Requests
Para escenarios de validación más complejos, puede que desee crear un "form request". Los form requests son clases de solicitud personalizadas que encapsulan su propia lógica de validación y autorización. Para crear una clase de form request, puede usar el comando Artisan CLI make:request:
php artisan make:request StorePostRequest
La clase de form request generada se colocará en el directorio app/Http/Requests. Si este directorio no existe, se creará cuando ejecute el comando make:request. Cada form request generado por Laravel tiene dos métodos: authorize y rules.
Como habrá adivinado, el método authorize es responsable de determinar si el usuario autenticado actualmente puede realizar la acción representada por la solicitud, mientras que el método rules devuelve las reglas de validación que deben aplicarse a los datos de la solicitud:
/**
* Obtener las reglas de validación que se aplican a la solicitud.
*
* @return array<string, \Illuminate\Contracts\Validation\Rule|array|string>
*/
public function rules(): array
{
return [
'title' => 'required|unique:posts|max:255',
'body' => 'required',
];
}
Puede indicar cualquier dependencia que necesite en la firma del método rules. Estas se resolverán automáticamente a través del contenedor de servicios de Laravel.
Entonces, ¿cómo se evalúan las reglas de validación? Solo necesita indicar el tipo de la solicitud en el método de su controlador. El form request entrante se valida antes de que se llame al método del controlador, lo que significa que no necesita saturar su controlador con lógica de validación:
/**
* Almacenar una nueva publicación de blog.
*/
public function store(StorePostRequest $request): RedirectResponse
{
// La solicitud entrante es válida...
// Recuperar los datos validados...
$validated = $request->validated();
// Recuperar una parte de los datos validados...
$validated = $request->safe()->only(['name', 'email']);
$validated = $request->safe()->except(['name', 'email']);
// Almacenar la publicación de blog...
return redirect('/posts');
}
Si la validación falla, se generará una respuesta de redirección para enviar al usuario de vuelta a su ubicación anterior. Los errores también se guardarán en la sesión para que estén disponibles para mostrar. Si la solicitud fue una solicitud XHR, se devolverá una respuesta HTTP con código 422 al usuario que incluirá una representación JSON de los errores de validación.
¿Necesita agregar validación en tiempo real de form requests a su frontend Laravel potenciado por Inertia? Consulte Laravel Precognition.
#Realizando validaciones adicionales
A veces necesita realizar validaciones adicionales después de que su validación inicial haya terminado. Puede lograr esto usando el método after del form request.
El método after debe devolver un array de callables o closures que se invocarán después de que la validación haya finalizado. Los callables dados recibirán una instancia de Illuminate\Validation\Validator, lo que le permite generar mensajes de error adicionales si es necesario:
use Illuminate\Validation\Validator;
/**
* Obtener los callables "after" para la validación de la solicitud.
*/
public function after(): array
{
return [
function (Validator $validator) {
if ($this->somethingElseIsInvalid()) {
$validator->errors()->add(
'field',
'¡Algo está mal con este campo!'
);
}
}
];
}
Como se indicó, el array devuelto por el método after también puede contener clases invocables. El método __invoke de estas clases recibirá una instancia de Illuminate\Validation\Validator:
use App\Validation\ValidateShippingTime;
use App\Validation\ValidateUserStatus;
use Illuminate\Validation\Validator;
/**
* Obtener los callables "after" para la validación de la solicitud.
*/
public function after(): array
{
return [
new ValidateUserStatus,
new ValidateShippingTime,
function (Validator $validator) {
//
}
];
}
#Detenerse en el primer fallo de validación
Al agregar una propiedad stopOnFirstFailure a su clase de solicitud, puede informar al validador que debe detener la validación de todos los atributos una vez que ocurra un solo fallo de validación:
/**
* Indica si el validador debe detenerse en la primera falla de regla.
*
* @var bool
*/
protected $stopOnFirstFailure = true;
#Personalizando la ubicación de redirección
Como se discutió anteriormente, se generará una respuesta de redirección para enviar al usuario de vuelta a su ubicación anterior cuando falle la validación del form request. Sin embargo, puede personalizar este comportamiento. Para hacerlo, defina una propiedad $redirect en su form request:
/**
* La URI a la que los usuarios deben ser redirigidos si la validación falla.
*
* @var string
*/
protected $redirect = '/dashboard';
O, si desea redirigir a los usuarios a una ruta nombrada, puede definir una propiedad $redirectRoute en su lugar:
/**
* La ruta a la que los usuarios deben ser redirigidos si la validación falla.
*
* @var string
*/
protected $redirectRoute = 'dashboard';
#Autorizando Form Requests
La clase de form request también contiene un método authorize. Dentro de este método, puede determinar si el usuario autenticado realmente tiene la autoridad para actualizar un recurso dado. Por ejemplo, puede determinar si un usuario realmente es dueño de un comentario de blog que intenta actualizar. Lo más probable es que interactúe con sus gates y policies de autorización dentro de este método:
use App\Models\Comment;
/**
* Determinar si el usuario está autorizado para hacer esta solicitud.
*/
public function authorize(): bool
{
$comment = Comment::find($this->route('comment'));
return $comment && $this->user()->can('update', $comment);
}
Dado que todos los form requests extienden la clase base de solicitud de Laravel, podemos usar el método user para acceder al usuario autenticado actualmente. Además, observe la llamada al método route en el ejemplo anterior. Este método le da acceso a los parámetros URI definidos en la ruta que se está llamando, como el parámetro {comment} en el ejemplo a continuación:
Route::post('/comment/{comment}');
Por lo tanto, si su aplicación está aprovechando el route model binding, su código puede ser aún más conciso accediendo al modelo resuelto como una propiedad de la solicitud:
return $this->user()->can('update', $this->comment);
Si el método authorize devuelve false, se devolverá automáticamente una respuesta HTTP con código 403 y el método de su controlador no se ejecutará.
Si planea manejar la lógica de autorización para la solicitud en otra parte de su aplicación, puede eliminar completamente el método authorize o simplemente devolver true:
/**
* Determinar si el usuario está autorizado para hacer esta solicitud.
*/
public function authorize(): bool
{
return true;
}
Puede indicar cualquier dependencia que necesite en la firma del método authorize. Estas se resolverán automáticamente a través del contenedor de servicios de Laravel.
#Personalizando los mensajes de error
Puede personalizar los mensajes de error usados por el form request sobrescribiendo el método messages. Este método debe devolver un array de pares atributo / regla y sus mensajes de error correspondientes:
/**
* Obtener los mensajes de error para las reglas de validación definidas.
*
* @return array<string, string>
*/
public function messages(): array
{
return [
'title.required' => 'Se requiere un título',
'body.required' => 'Se requiere un mensaje',
];
}
#Personalizando los atributos de validación
Muchos de los mensajes de error de las reglas de validación integradas de Laravel contienen un marcador de posición :attribute. Si desea que el marcador :attribute de su mensaje de validación sea reemplazado por un nombre de atributo personalizado, puede especificar los nombres personalizados sobrescribiendo el método attributes. Este método debe devolver un array de pares atributo / nombre:
/**
* Obtener atributos personalizados para los errores del validador.
*
* @return array<string, string>
*/
public function attributes(): array
{
return [
'email' => 'dirección de correo electrónico',
];
}
#Preparando la entrada para validación
Si necesita preparar o sanitizar algún dato de la solicitud antes de aplicar sus reglas de validación, puede usar el método prepareForValidation:
use Illuminate\Support\Str;
/**
* Preparar los datos para la validación.
*/
protected function prepareForValidation(): void
{
$this->merge([
'slug' => Str::slug($this->slug),
]);
}
De igual forma, si necesita normalizar algún dato de la solicitud después de que la validación haya finalizado, puede usar el método passedValidation:
/**
* Manejar un intento de validación exitoso.
*/
protected function passedValidation(): void
{
$this->replace(['name' => 'Taylor']);
}
#Creando validadores manualmente
Si no desea usar el método validate en la solicitud, puede crear una instancia de validador manualmente usando el facade Validator. El método make del facade genera una nueva instancia de validador:
<?php
namespace App\Http\Controllers;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Validator;
class PostController extends Controller
{
/**
* Almacenar una nueva publicación de blog.
*/
public function store(Request $request): RedirectResponse
{
$validator = Validator::make($request->all(), [
'title' => 'required|unique:posts|max:255',
'body' => 'required',
]);
if ($validator->fails()) {
return redirect('post/create')
->withErrors($validator)
->withInput();
}
// Recuperar la entrada validada...
$validated = $validator->validated();
// Recuperar una parte de la entrada validada...
$validated = $validator->safe()->only(['name', 'email']);
$validated = $validator->safe()->except(['name', 'email']);
// Almacenar la publicación de blog...
return redirect('/posts');
}
}
El primer argumento pasado al método make es la información que se va a validar. El segundo argumento es un array con las reglas de validación que se deben aplicar a los datos.
Después de determinar si la validación de la solicitud falló, puede usar el método withErrors para guardar los mensajes de error en la sesión. Al usar este método, la variable $errors se compartirá automáticamente con sus vistas después de la redirección, lo que le permite mostrarlos fácilmente al usuario. El método withErrors acepta un validador, un MessageBag o un array de PHP.
#Detenerse en el primer fallo de validación
El método stopOnFirstFailure indicará al validador que debe dejar de validar todos los atributos una vez que ocurra un solo fallo de validación:
if ($validator->stopOnFirstFailure()->fails()) {
// ...
}
#Redirección automática
Si desea crear una instancia de validador manualmente pero aún aprovechar la redirección automática que ofrece el método validate de la solicitud HTTP, puede llamar al método validate en una instancia de validador existente. Si la validación falla, el usuario será redirigido automáticamente o, en el caso de una solicitud XHR, se devolverá una respuesta JSON:
Validator::make($request->all(), [
'title' => 'required|unique:posts|max:255',
'body' => 'required',
])->validate();
Puede usar el método validateWithBag para almacenar los mensajes de error en una bolsa de errores nombrada si la validación falla:
Validator::make($request->all(), [
'title' => 'required|unique:posts|max:255',
'body' => 'required',
])->validateWithBag('post');
#Bolsas de errores nombradas
Si tiene múltiples formularios en una sola página, puede querer nombrar el MessageBag que contiene los errores de validación, lo que le permitirá recuperar los mensajes de error para un formulario específico. Para lograr esto, pase un nombre como segundo argumento a withErrors:
return redirect('register')->withErrors($validator, 'login');
Luego puede acceder a la instancia nombrada de MessageBag desde la variable $errors:
{{ $errors->login->first('email') }}
#Personalizando los mensajes de error
Si es necesario, puede proporcionar mensajes de error personalizados que una instancia de validador debe usar en lugar de los mensajes predeterminados proporcionados por Laravel. Hay varias formas de especificar mensajes personalizados. Primero, puede pasar los mensajes personalizados como el tercer argumento al método Validator::make:
$validator = Validator::make($input, $rules, $messages = [
'required' => 'El campo :attribute es obligatorio.',
]);
En este ejemplo, el marcador :attribute será reemplazado por el nombre real del campo que se está validando. También puede utilizar otros marcadores en los mensajes de validación. Por ejemplo:
$messages = [
'same' => 'El campo :attribute y :other deben coincidir.',
'size' => 'El campo :attribute debe tener exactamente :size.',
'between' => 'El valor :input del campo :attribute no está entre :min y :max.',
'in' => 'El campo :attribute debe ser uno de los siguientes tipos: :values',
];
#Especificar un mensaje personalizado para un atributo dado
A veces puede querer especificar un mensaje de error personalizado solo para un atributo específico. Puede hacerlo usando la notación de "punto". Primero especifique el nombre del atributo, seguido de la regla:
$messages = [
'email.required' => '¡Necesitamos conocer su dirección de correo electrónico!',
];
#Especificar valores personalizados para atributos
Muchos de los mensajes de error incorporados en Laravel incluyen un marcador :attribute que se reemplaza con el nombre del campo o atributo que se está validando. Para personalizar los valores usados para reemplazar estos marcadores para campos específicos, puede pasar un array de atributos personalizados como el cuarto argumento al método Validator::make:
$validator = Validator::make($input, $rules, $messages, [
'email' => 'dirección de correo electrónico',
]);
#Realizando validaciones adicionales
A veces necesita realizar validaciones adicionales después de que su validación inicial haya finalizado. Puede lograr esto usando el método after del validador. El método after acepta un closure o un array de callables que se invocarán después de que la validación haya terminado. Los callables recibidos obtendrán una instancia de Illuminate\Validation\Validator, lo que le permite generar mensajes de error adicionales si es necesario:
use Illuminate\Support\Facades\Validator;
$validator = Validator::make(/* ... */);
$validator->after(function ($validator) {
if ($this->somethingElseIsInvalid()) {
$validator->errors()->add(
'field', '¡Algo está mal con este campo!'
);
}
});
if ($validator->fails()) {
// ...
}
Como se mencionó, el método after también acepta un array de callables, lo cual es particularmente conveniente si su lógica de "validación posterior" está encapsulada en clases invocables, que recibirán una instancia de Illuminate\Validation\Validator a través de su método __invoke:
use App\Validation\ValidateShippingTime;
use App\Validation\ValidateUserStatus;
$validator->after([
new ValidateUserStatus,
new ValidateShippingTime,
function ($validator) {
// ...
},
]);
#Trabajando con datos validados
Después de validar los datos entrantes de una solicitud usando un form request o una instancia de validador creada manualmente, puede que desee recuperar los datos de la solicitud que realmente fueron validados. Esto se puede lograr de varias maneras. Primero, puede llamar al método validated en un form request o instancia de validador. Este método devuelve un array con los datos que fueron validados:
$validated = $request->validated();
$validated = $validator->validated();
Alternativamente, puede llamar al método safe en un form request o instancia de validador. Este método devuelve una instancia de Illuminate\Support\ValidatedInput. Este objeto expone los métodos only, except y all para recuperar un subconjunto de los datos validados o todo el array de datos validados:
$validated = $request->safe()->only(['name', 'email']);
$validated = $request->safe()->except(['name', 'email']);
$validated = $request->safe()->all();
Además, la instancia de Illuminate\Support\ValidatedInput puede ser iterada y accedida como un array:
// Los datos validados pueden ser iterados...
foreach ($request->safe() as $key => $value) {
// ...
}
// Los datos validados pueden ser accedidos como un array...
$validated = $request->safe();
$email = $validated['email'];
Si desea agregar campos adicionales a los datos validados, puede llamar al método merge:
$validated = $request->safe()->merge(['name' => 'Taylor Otwell']);
Si desea recuperar los datos validados como una instancia de colección, puede llamar al método collect:
$collection = $request->safe()->collect();
#Trabajando con mensajes de error
Después de llamar al método errors en una instancia de Validator, recibirá una instancia de Illuminate\Support\MessageBag, que tiene varios métodos convenientes para trabajar con mensajes de error. La variable $errors que se pone automáticamente a disposición en todas las vistas también es una instancia de la clase MessageBag.
#Recuperar el primer mensaje de error para un campo
Para recuperar el primer mensaje de error para un campo dado, use el método first:
$errors = $validator->errors();
echo $errors->first('email');
#Recuperar todos los mensajes de error para un campo
Si necesita recuperar un array con todos los mensajes para un campo dado, use el método get:
foreach ($errors->get('email') as $message) {
// ...
}
Si está validando un campo de formulario que es un array, puede recuperar todos los mensajes para cada uno de los elementos del array usando el carácter *:
foreach ($errors->get('attachments.*') as $message) {
// ...
}
#Recuperar todos los mensajes de error para todos los campos
Para recuperar un array con todos los mensajes para todos los campos, use el método all:
foreach ($errors->all() as $message) {
// ...
}
#Determinar si existen mensajes para un campo
El método has puede usarse para determinar si existen mensajes de error para un campo dado:
if ($errors->has('email')) {
// ...
}
#Especificar mensajes personalizados en archivos de idioma
Las reglas de validación integradas de Laravel tienen cada una un mensaje de error ubicado en el archivo lang/en/validation.php de su aplicación. Si su aplicación no tiene un directorio lang, puede indicarle a Laravel que lo cree usando el comando Artisan lang:publish.
Dentro del archivo lang/en/validation.php, encontrará una entrada de traducción para cada regla de validación. Puede cambiar o modificar estos mensajes según las necesidades de su aplicación.
Además, puede copiar este archivo a otro directorio de idioma para traducir los mensajes al idioma de su aplicación. Para aprender más sobre la localización en Laravel, consulte la documentación completa de localización.
Por defecto, el esqueleto de la aplicación Laravel no incluye el directorio lang. Si desea personalizar los archivos de idioma de Laravel, puede publicarlos mediante el comando Artisan lang:publish.
#Mensajes personalizados para atributos específicos
Puede personalizar los mensajes de error usados para combinaciones específicas de atributo y regla dentro de los archivos de idioma de validación de su aplicación. Para hacerlo, agregue sus personalizaciones de mensajes al array custom del archivo de idioma lang/xx/validation.php de su aplicación:
'custom' => [
'email' => [
'required' => '¡Necesitamos conocer su dirección de correo electrónico!',
'max' => '¡Su dirección de correo electrónico es demasiado larga!'
],
],
#Especificar atributos en archivos de idioma
Muchos de los mensajes de error integrados en Laravel incluyen un marcador :attribute que se reemplaza con el nombre del campo o atributo que se está validando. Si desea que la parte :attribute de su mensaje de validación sea reemplazada por un valor personalizado, puede especificar el nombre personalizado del atributo en el array attributes del archivo de idioma lang/xx/validation.php:
'attributes' => [
'email' => 'dirección de correo electrónico',
],
Por defecto, el esqueleto de la aplicación Laravel no incluye el directorio lang. Si desea personalizar los archivos de idioma de Laravel, puede publicarlos mediante el comando Artisan lang:publish.
#Especificar valores en archivos de idioma
Algunos mensajes de error de reglas de validación integradas en Laravel contienen un marcador :value que se reemplaza con el valor actual del atributo de la solicitud. Sin embargo, ocasionalmente puede necesitar que la parte :value de su mensaje de validación sea reemplazada por una representación personalizada del valor. Por ejemplo, considere la siguiente regla que especifica que un número de tarjeta de crédito es obligatorio si el payment_type tiene un valor de cc:
Validator::make($request->all(), [
'credit_card_number' => 'required_if:payment_type,cc'
]);
Si esta regla de validación falla, producirá el siguiente mensaje de error:
The credit card number field is required when payment type is cc.
En lugar de mostrar cc como el valor del tipo de pago, puede especificar una representación más amigable para el usuario en su archivo de idioma lang/xx/validation.php definiendo un array values:
'values' => [
'payment_type' => [
'cc' => 'tarjeta de crédito'
],
],
Por defecto, el esqueleto de la aplicación Laravel no incluye el directorio lang. Si desea personalizar los archivos de idioma de Laravel, puede publicarlos mediante el comando Artisan lang:publish.
Después de definir este valor, la regla de validación producirá el siguiente mensaje de error:
The credit card number field is required when payment type is credit card.
#Reglas de validación disponibles
A continuación se muestra una lista de todas las reglas de validación disponibles y su función:
<style> .collection-method-list > p { columns: 10.8em 3; -moz-columns: 10.8em 3; -webkit-columns: 10.8em 3; } .collection-method-list a { display: block; overflow: hidden; text-overflow: ellipsis; white-space: nowrap; } </style>Accepted Accepted If Active URL After (Date) After Or Equal (Date) Alpha Alpha Dash Alpha Numeric Array Ascii Bail Before (Date) Before Or Equal (Date) Between Boolean Confirmed Current Password Date Date Equals Date Format Decimal Declined Declined If Different Digits Digits Between Dimensions (Image Files) Distinct Doesnt Start With Doesnt End With Email Ends With Enum Exclude Exclude If Exclude Unless Exclude With Exclude Without Exists (Database) Extensions File Filled Greater Than Greater Than Or Equal Hex Color Image (File) In In Array Integer IP Address JSON Less Than Less Than Or Equal Lowercase MAC Address Max Max Digits MIME Types MIME Type By File Extension Min Min Digits Missing Missing If Missing Unless Missing With Missing With All Multiple Of Not In Not Regex Nullable Numeric Present Present If Present Unless Present With Present With All Prohibited Prohibited If Prohibited Unless Prohibits Regular Expression Required Required If Required If Accepted Required Unless Required With Required With All Required Without Required Without All Required Array Keys Same Size Sometimes Starts With String Timezone Unique (Database) Uppercase URL ULID UUID
#accepted
El campo que se está validando debe ser "yes", "on", 1, "1", true o "true". Esto es útil para validar la aceptación de "Términos de Servicio" o campos similares.
#accepted_if:anotherfield,value,...
El campo que se está validando debe ser "yes", "on", 1, "1", true o "true" si otro campo que se está validando es igual a un valor especificado. Esto es útil para validar la aceptación de "Términos de Servicio" o campos similares.
#active_url
El campo que se está validando debe tener un registro A o AAAA válido según la función PHP dns_get_record. El nombre de host de la URL proporcionada se extrae usando la función PHP parse_url antes de pasarlo a dns_get_record.
#after:date
El campo que se está validando debe ser un valor posterior a una fecha dada. Las fechas se pasarán a la función PHP strtotime para ser convertidas en una instancia válida de DateTime:
'start_date' => 'required|date|after:tomorrow'
En lugar de pasar una cadena de fecha para ser evaluada por strtotime, puede especificar otro campo para comparar con la fecha:
'finish_date' => 'required|date|after:start_date'
#after_or_equal:date
El campo que se está validando debe ser un valor posterior o igual a la fecha dada. Para más información, consulte la regla after.
#alpha
El campo que se está validando debe contener únicamente caracteres alfabéticos Unicode contenidos en \p{L} y \p{M}.
Para restringir esta regla de validación a caracteres en el rango ASCII (a-z y A-Z), puede proporcionar la opción ascii a la regla de validación:
'username' => 'alpha:ascii',
#alpha_dash
El campo que se está validando debe contener únicamente caracteres alfanuméricos Unicode contenidos en \p{L}, \p{M}, \p{N}, así como guiones ASCII (-) y guiones bajos ASCII (_).
Para restringir esta regla de validación a caracteres en el rango ASCII (a-z y A-Z), puede proporcionar la opción ascii a la regla de validación:
'username' => 'alpha_dash:ascii',
#alpha_num
El campo que se está validando debe contener únicamente caracteres alfanuméricos Unicode contenidos en \p{L}, \p{M}, y \p{N}.
Para restringir esta regla de validación a caracteres en el rango ASCII (a-z y A-Z), puede proporcionar la opción ascii a la regla de validación:
'username' => 'alpha_num:ascii',
#array
El campo que se está validando debe ser un array de PHP.
Cuando se proporcionan valores adicionales a la regla array, cada clave en el array de entrada debe estar presente dentro de la lista de valores proporcionados a la regla. En el siguiente ejemplo, la clave admin en el array de entrada es inválida ya que no está contenida en la lista de valores proporcionados a la regla array:
use Illuminate\Support\Facades\Validator;
$input = [
'user' => [
'name' => 'Taylor Otwell',
'username' => 'taylorotwell',
'admin' => true,
],
];
Validator::make($input, [
'user' => 'array:name,username',
]);
En general, siempre debe especificar las claves del array que están permitidas dentro de su array.
#ascii
El campo que se está validando debe contener únicamente caracteres ASCII de 7 bits.
#bail
Detener la ejecución de las reglas de validación para el campo después del primer fallo de validación.
Mientras que la regla bail solo detendrá la validación de un campo específico cuando encuentre un fallo de validación, el método stopOnFirstFailure indicará al validador que debe dejar de validar todos los atributos una vez que ocurra un solo fallo de validación:
if ($validator->stopOnFirstFailure()->fails()) {
// ...
}
#before:date
El campo que se está validando debe ser un valor anterior a la fecha dada. Las fechas se pasarán a la función PHP strtotime para ser convertidas en una instancia válida de DateTime. Además, al igual que la regla after, puede suministrarse el nombre de otro campo que se está validando como valor de date.
#before_or_equal:date
El campo que se está validando debe ser un valor anterior o igual a la fecha dada. Las fechas se pasarán a la función PHP strtotime para ser convertidas en una instancia válida de DateTime. Además, al igual que la regla after, puede suministrarse el nombre de otro campo que se está validando como valor de date.
#between:min,max
El campo que se está validando debe tener un tamaño entre el min y max dados (inclusive). Las cadenas, valores numéricos, arrays y archivos se evalúan de la misma manera que la regla size.
#boolean
El campo que se está validando debe poder ser convertido a booleano. Los valores aceptados son true, false, 1, 0, "1" y "0".
#confirmed
El campo que se está validando debe tener un campo coincidente llamado {field}_confirmation. Por ejemplo, si el campo que se está validando es password, debe existir un campo password_confirmation en la entrada.
#current_password
El campo que se está validando debe coincidir con la contraseña del usuario autenticado. Puede especificar un guard de autenticación usando el primer parámetro de la regla:
'password' => 'current_password:api'
#date
El campo que se está validando debe ser una fecha válida y no relativa según la función PHP strtotime.
#date_equals:date
El campo que se está validando debe ser igual a la fecha dada. Las fechas se pasarán a la función PHP strtotime para ser convertidas en una instancia válida de DateTime.
#date_format:format,...
El campo que se está validando debe coincidir con uno de los formatos dados. Debe usar o date o date_format al validar un campo, no ambos. Esta regla de validación soporta todos los formatos soportados por la clase DateTime de PHP.
#decimal:min,max
El campo que se está validando debe ser numérico y debe contener el número especificado de decimales:
// Debe tener exactamente dos decimales (9.99)...
'price' => 'decimal:2'
// Debe tener entre 2 y 4 decimales...
'price' => 'decimal:2,4'
#declined
El campo que se está validando debe ser "no", "off", 0, "0", false o "false".
#declined_if:anotherfield,value,...
El campo que se está validando debe ser "no", "off", 0, "0", false o "false" si otro campo que se está validando es igual a un valor especificado.
#different:field
El campo que se está validando debe tener un valor diferente al de field.
#digits:value
El entero que se está validando debe tener una longitud exacta de value.
#digits_between:min,max
La validación del entero debe tener una longitud entre el min y max dados.
#dimensions
El archivo que se está validando debe ser una imagen que cumpla con las restricciones de dimensiones especificadas por los parámetros de la regla:
'avatar' => 'dimensions:min_width=100,min_height=200'
Las restricciones disponibles son: min_width, max_width, min_height, max_height, width, height, ratio.
Una restricción ratio debe representarse como ancho dividido por alto. Esto puede especificarse ya sea como una fracción como 3/2 o un número flotante como 1.5:
'avatar' => 'dimensions:ratio=3/2'
Dado que esta regla requiere varios argumentos, puede usar el método Rule::dimensions para construir la regla de forma fluida:
use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;
Validator::make($data, [
'avatar' => [
'required',
Rule::dimensions()->maxWidth(1000)->maxHeight(500)->ratio(3 / 2),
],
]);
#distinct
Al validar arrays, el campo que se está validando no debe tener valores duplicados:
'foo.*.id' => 'distinct'
Distinct usa comparaciones laxas de variables por defecto. Para usar comparaciones estrictas, puede agregar el parámetro strict a la definición de su regla de validación:
'foo.*.id' => 'distinct:strict'
Puede agregar ignore_case a los argumentos de la regla de validación para que la regla ignore diferencias de mayúsculas y minúsculas:
'foo.*.id' => 'distinct:ignore_case'
#doesnt_start_with:foo,bar,...
El campo que se está validando no debe comenzar con uno de los valores dados.
#doesnt_end_with:foo,bar,...
El campo que se está validando no debe terminar con uno de los valores dados.
El campo bajo validación debe tener el formato de una dirección de correo electrónico. Esta regla de validación utiliza el paquete egulias/email-validator para validar la dirección de correo electrónico. Por defecto, se aplica el validador RFCValidation, pero también puede aplicar otros estilos de validación:
'email' => 'email:rfc,dns'
El ejemplo anterior aplicará las validaciones RFCValidation y DNSCheckValidation. Aquí tiene una lista completa de estilos de validación que puede aplicar:
rfc:RFCValidationstrict:NoRFCWarningsValidationdns:DNSCheckValidationspoof:SpoofCheckValidationfilter:FilterEmailValidationfilter_unicode:FilterEmailValidation::unicode()
El validador filter, que utiliza la función filter_var de PHP, viene incluido con Laravel y fue el comportamiento predeterminado de validación de correo electrónico en Laravel antes de la versión 5.8.
Los validadores dns y spoof requieren la extensión PHP intl.
#ends_with:foo,bar,...
El campo bajo validación debe terminar con uno de los valores dados.
#enum
La regla Enum es una regla basada en clase que valida si el campo bajo validación contiene un valor válido de enum. La regla Enum acepta el nombre del enum como su único argumento en el constructor. Al validar valores primitivos, se debe proporcionar un Enum respaldado a la regla Enum:
use App\Enums\ServerStatus;
use Illuminate\Validation\Rule;
$request->validate([
'status' => [Rule::enum(ServerStatus::class)],
]);
Los métodos only y except de la regla Enum pueden usarse para limitar qué casos del enum deben considerarse válidos:
Rule::enum(ServerStatus::class)
->only([ServerStatus::Pending, ServerStatus::Active]);
Rule::enum(ServerStatus::class)
->except([ServerStatus::Pending, ServerStatus::Active]);
El método when puede usarse para modificar condicionalmente la regla Enum:
use Illuminate\Support\Facades\Auth;
use Illuminate\Validation\Rule;
Rule::enum(ServerStatus::class)
->when(
Auth::user()->isAdmin(),
fn ($rule) => $rule->only(...),
fn ($rule) => $rule->only(...),
);
#exclude
El campo bajo validación será excluido de los datos de la solicitud devueltos por los métodos validate y validated.
#exclude_if:anotherfield,value
El campo bajo validación será excluido de los datos de la solicitud devueltos por los métodos validate y validated si el campo anotherfield es igual a value.
Si se requiere una lógica compleja de exclusión condicional, puede utilizar el método Rule::excludeIf. Este método acepta un booleano o un closure. Cuando se le pasa un closure, este debe devolver true o false para indicar si el campo bajo validación debe ser excluido:
use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;
Validator::make($request->all(), [
'role_id' => Rule::excludeIf($request->user()->is_admin),
]);
Validator::make($request->all(), [
'role_id' => Rule::excludeIf(fn () => $request->user()->is_admin),
]);
#exclude_unless:anotherfield,value
El campo bajo validación será excluido de los datos de la solicitud devueltos por los métodos validate y validated a menos que el campo anotherfield sea igual a value. Si value es null (exclude_unless:name,null), el campo bajo validación será excluido a menos que el campo de comparación sea null o que el campo de comparación falte en los datos de la solicitud.
#exclude_with:anotherfield
El campo bajo validación será excluido de los datos de la solicitud devueltos por los métodos validate y validated si el campo anotherfield está presente.
#exclude_without:anotherfield
El campo bajo validación será excluido de los datos de la solicitud devueltos por los métodos validate y validated si el campo anotherfield no está presente.
#exists:table,column
El campo bajo validación debe existir en una tabla de base de datos dada.
#Uso básico de la regla Exists
'state' => 'exists:states'
Si no se especifica la opción column, se usará el nombre del campo. Por lo tanto, en este caso, la regla validará que la tabla states de la base de datos contenga un registro con un valor en la columna state que coincida con el valor del atributo state de la solicitud.
#Especificar un nombre de columna personalizado
Puede especificar explícitamente el nombre de la columna de base de datos que debe usar la regla de validación colocándolo después del nombre de la tabla:
'state' => 'exists:states,abbreviation'
Ocasionalmente, puede necesitar especificar una conexión de base de datos específica para la consulta exists. Puede lograr esto anteponiendo el nombre de la conexión al nombre de la tabla:
'email' => 'exists:connection.staff,email'
En lugar de especificar directamente el nombre de la tabla, puede especificar el modelo Eloquent que debe usarse para determinar el nombre de la tabla:
'user_id' => 'exists:App\Models\User,id'
Si desea personalizar la consulta ejecutada por la regla de validación, puede usar la clase Rule para definir la regla de forma fluida. En este ejemplo, también especificaremos las reglas de validación como un array en lugar de usar el carácter | para delimitarlas:
use Illuminate\Database\Query\Builder;
use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;
Validator::make($data, [
'email' => [
'required',
Rule::exists('staff')->where(function (Builder $query) {
return $query->where('account_id', 1);
}),
],
]);
Puede especificar explícitamente el nombre de la columna de base de datos que debe usar la regla exists generada por el método Rule::exists proporcionando el nombre de la columna como segundo argumento del método exists:
'state' => Rule::exists('states', 'abbreviation'),
#extensions:foo,bar,...
El archivo bajo validación debe tener una extensión asignada por el usuario que corresponda a una de las extensiones listadas:
'photo' => ['required', 'extensions:jpg,png'],
#file
El campo bajo validación debe ser un archivo subido correctamente.
#filled
El campo bajo validación no debe estar vacío cuando está presente.
#gt:field
El campo bajo validación debe ser mayor que el field o value dado. Los dos campos deben ser del mismo tipo. Las cadenas, valores numéricos, arrays y archivos se evalúan usando las mismas convenciones que la regla size.
#gte:field
El campo bajo validación debe ser mayor o igual que el field o value dado. Los dos campos deben ser del mismo tipo. Las cadenas, valores numéricos, arrays y archivos se evalúan usando las mismas convenciones que la regla size.
#hex_color
El campo bajo validación debe contener un valor de color válido en formato hexadecimal.
#image
El archivo bajo validación debe ser una imagen (jpg, jpeg, png, bmp, gif, svg o webp).
#in:foo,bar,...
El campo bajo validación debe estar incluido en la lista dada de valores. Dado que esta regla a menudo requiere que haga un implode de un array, el método Rule::in puede usarse para construir la regla de forma fluida:
use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;
Validator::make($data, [
'zones' => [
'required',
Rule::in(['first-zone', 'second-zone']),
],
]);
Cuando la regla in se combina con la regla array, cada valor en el array de entrada debe estar presente dentro de la lista de valores proporcionada a la regla in. En el siguiente ejemplo, el código de aeropuerto LAS en el array de entrada es inválido porque no está contenido en la lista de aeropuertos proporcionada a la regla in:
use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;
$input = [
'airports' => ['NYC', 'LAS'],
];
Validator::make($input, [
'airports' => [
'required',
'array',
],
'airports.*' => Rule::in(['NYC', 'LIT']),
]);
#in_array:anotherfield.*
El campo bajo validación debe existir en los valores de anotherfield.
#integer
El campo bajo validación debe ser un entero.
Esta regla de validación no verifica que la entrada sea del tipo de variable "integer", solo que la entrada sea de un tipo aceptado por la regla FILTER_VALIDATE_INT de PHP. Si necesita validar que la entrada sea un número, utilice esta regla en combinación con la regla de validación numeric.
#ip
El campo bajo validación debe ser una dirección IP.
#ipv4
El campo bajo validación debe ser una dirección IPv4.
#ipv6
El campo bajo validación debe ser una dirección IPv6.
#json
El campo bajo validación debe ser una cadena JSON válida.
#lt:field
El campo bajo validación debe ser menor que el field dado. Los dos campos deben ser del mismo tipo. Las cadenas, valores numéricos, arrays y archivos se evalúan usando las mismas convenciones que la regla size.
#lte:field
El campo bajo validación debe ser menor o igual que el field dado. Los dos campos deben ser del mismo tipo. Las cadenas, valores numéricos, arrays y archivos se evalúan usando las mismas convenciones que la regla size.
#lowercase
El campo bajo validación debe estar en minúsculas.
#mac_address
El campo bajo validación debe ser una dirección MAC.
#max:value
El campo bajo validación debe ser menor o igual a un valor máximo value. Las cadenas, valores numéricos, arrays y archivos se evalúan de la misma manera que la regla size.
#max_digits:value
El entero bajo validación debe tener una longitud máxima de value.
#mimetypes:text/plain,...
El archivo bajo validación debe coincidir con uno de los tipos MIME dados:
'video' => 'mimetypes:video/avi,video/mpeg,video/quicktime'
Para determinar el tipo MIME del archivo subido, se leerá el contenido del archivo y el framework intentará adivinar el tipo MIME, que puede ser diferente del tipo MIME proporcionado por el cliente.
#mimes:foo,bar,...
El archivo bajo validación debe tener un tipo MIME correspondiente a una de las extensiones listadas:
'photo' => 'mimes:jpg,bmp,png'
Aunque solo necesita especificar las extensiones, esta regla en realidad valida el tipo MIME del archivo leyendo el contenido del archivo y adivinando su tipo MIME. Puede encontrar una lista completa de tipos MIME y sus extensiones correspondientes en la siguiente ubicación:
https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types
#Tipos MIME y Extensiones
Esta regla de validación no verifica la concordancia entre el tipo MIME y la extensión que el usuario asignó al archivo. Por ejemplo, la regla de validación mimes:png consideraría un archivo que contiene contenido PNG válido como una imagen PNG válida, incluso si el archivo se llama photo.txt. Si desea validar la extensión asignada por el usuario al archivo, puede usar la regla extensions.
#min:value
El campo bajo validación debe tener un valor mínimo value. Las cadenas, valores numéricos, arrays y archivos se evalúan de la misma manera que la regla size.
#min_digits:value
El entero bajo validación debe tener una longitud mínima de value.
#multiple_of:value
El campo bajo validación debe ser un múltiplo de value.
#missing
El campo bajo validación no debe estar presente en los datos de entrada.
#missing_if:anotherfield,value,...
El campo bajo validación no debe estar presente si el campo anotherfield es igual a cualquiera de los valores value.
#missing_unless:anotherfield,value
El campo bajo validación no debe estar presente a menos que el campo anotherfield sea igual a cualquiera de los valores value.
#missing_with:foo,bar,...
El campo bajo validación no debe estar presente solo si alguno de los otros campos especificados está presente.
#missing_with_all:foo,bar,...
El campo bajo validación no debe estar presente solo si todos los otros campos especificados están presentes.
#not_in:foo,bar,...
El campo bajo validación no debe estar incluido en la lista dada de valores. El método Rule::notIn puede usarse para construir la regla de forma fluida:
use Illuminate\Validation\Rule;
Validator::make($data, [
'toppings' => [
'required',
Rule::notIn(['sprinkles', 'cherries']),
],
]);
#not_regex:pattern
El campo bajo validación no debe coincidir con la expresión regular dada.
Internamente, esta regla usa la función preg_match de PHP. El patrón especificado debe obedecer el mismo formato requerido por preg_match e incluir delimitadores válidos. Por ejemplo: 'email' => 'not_regex:/^.+$/i'.
Al usar los patrones regex / not_regex, puede ser necesario especificar las reglas de validación usando un array en lugar de delimitadores |, especialmente si la expresión regular contiene un carácter |.
#nullable
El campo bajo validación puede ser null.
#numeric
El campo bajo validación debe ser numérico.
#present
El campo bajo validación debe existir en los datos de entrada.
#present_if:anotherfield,value,...
El campo bajo validación debe estar presente si el campo anotherfield es igual a cualquiera de los valores value.
#present_unless:anotherfield,value
El campo bajo validación debe estar presente a menos que el campo anotherfield sea igual a cualquiera de los valores value.
#present_with:foo,bar,...
El campo bajo validación debe estar presente solo si alguno de los otros campos especificados está presente.
#present_with_all:foo,bar,...
El campo bajo validación debe estar presente solo si todos los otros campos especificados están presentes.
#prohibited
El campo bajo validación debe estar ausente o vacío. Un campo se considera "vacío" si cumple uno de los siguientes criterios:
- El valor es
null. - El valor es una cadena vacía.
- El valor es un array vacío o un objeto
Countablevacío. - El valor es un archivo subido con una ruta vacía.
#prohibited_if:anotherfield,value,...
El campo bajo validación debe estar ausente o vacío si el campo anotherfield es igual a cualquiera de los valores value. Un campo se considera "vacío" si cumple uno de los siguientes criterios:
- El valor es
null. - El valor es una cadena vacía.
- El valor es un array vacío o un objeto
Countablevacío. - El valor es un archivo subido con una ruta vacía.
Si se requiere una lógica compleja de prohibición condicional, puede utilizar el método Rule::prohibitedIf. Este método acepta un booleano o un closure. Cuando se le pasa un closure, este debe devolver true o false para indicar si el campo bajo validación debe ser prohibido:
use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;
Validator::make($request->all(), [
'role_id' => Rule::prohibitedIf($request->user()->is_admin),
]);
Validator::make($request->all(), [
'role_id' => Rule::prohibitedIf(fn () => $request->user()->is_admin),
]);
#prohibited_unless:anotherfield,value,...
El campo bajo validación debe estar ausente o vacío a menos que el campo anotherfield sea igual a cualquiera de los valores value. Un campo se considera "vacío" si cumple uno de los siguientes criterios:
- El valor es
null. - El valor es una cadena vacía.
- El valor es un array vacío o un objeto
Countablevacío. - El valor es un archivo subido con una ruta vacía.
#prohibits:anotherfield,...
Si el campo bajo validación no está ausente ni vacío, todos los campos en anotherfield deben estar ausentes o vacíos. Un campo se considera "vacío" si cumple uno de los siguientes criterios:
- El valor es
null. - El valor es una cadena vacía.
- El valor es un array vacío o un objeto
Countablevacío. - El valor es un archivo subido con una ruta vacía.
#regex:pattern
El campo bajo validación debe coincidir con la expresión regular dada.
Internamente, esta regla usa la función preg_match de PHP. El patrón especificado debe obedecer el mismo formato requerido por preg_match e incluir delimitadores válidos. Por ejemplo: 'email' => 'regex:/^.+@.+$/i'.
Al usar los patrones regex / not_regex, puede ser necesario especificar las reglas en un array en lugar de usar delimitadores |, especialmente si la expresión regular contiene un carácter |.
#required
El campo bajo validación debe estar presente en los datos de entrada y no estar vacío. Un campo se considera "vacío" si cumple uno de los siguientes criterios:
- El valor es
null. - El valor es una cadena vacía.
- El valor es un array vacío o un objeto
Countablevacío. - El valor es un archivo subido sin ruta.
#required_if:anotherfield,value,...
El campo bajo validación debe estar presente y no estar vacío si el campo anotherfield es igual a cualquiera de los valores value.
Si desea construir una condición más compleja para la regla required_if, puede usar el método Rule::requiredIf. Este método acepta un booleano o un closure. Cuando se le pasa un closure, este debe devolver true o false para indicar si el campo bajo validación es obligatorio:
use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;
Validator::make($request->all(), [
'role_id' => Rule::requiredIf($request->user()->is_admin),
]);
Validator::make($request->all(), [
'role_id' => Rule::requiredIf(fn () => $request->user()->is_admin),
]);
#required_if_accepted:anotherfield,...
El campo bajo validación debe estar presente y no estar vacío si el campo anotherfield es igual a "yes", "on", 1, "1", true o "true".
#required_unless:anotherfield,value,...
El campo bajo validación debe estar presente y no estar vacío a menos que el campo anotherfield sea igual a cualquiera de los valores value. Esto también significa que anotherfield debe estar presente en los datos de la solicitud a menos que value sea null. Si value es null (required_unless:name,null), el campo bajo validación será obligatorio a menos que el campo de comparación sea null o que el campo de comparación falte en los datos de la solicitud.
#required_with:foo,bar,...
El campo bajo validación debe estar presente y no estar vacío solo si alguno de los otros campos especificados está presente y no está vacío.
#required_with_all:foo,bar,...
El campo bajo validación debe estar presente y no estar vacío solo si todos los otros campos especificados están presentes y no están vacíos.
#required_without:foo,bar,...
El campo bajo validación debe estar presente y no estar vacío solo cuando alguno de los otros campos especificados está vacío o no está presente.
#required_without_all:foo,bar,...
El campo bajo validación debe estar presente y no estar vacío solo cuando todos los otros campos especificados están vacíos o no están presentes.
#required_array_keys:foo,bar,...
El campo bajo validación debe ser un array y debe contener al menos las claves especificadas.
#same:field
El field dado debe coincidir con el campo bajo validación.
#size:value
El campo bajo validación debe tener un tamaño que coincida con el value dado. Para datos de tipo cadena, value corresponde al número de caracteres. Para datos numéricos, value corresponde a un valor entero dado (el atributo también debe tener la regla numeric o integer). Para un array, size corresponde al count del array. Para archivos, size corresponde al tamaño del archivo en kilobytes. Veamos algunos ejemplos:
// Validar que una cadena tenga exactamente 12 caracteres...
'title' => 'size:12';
// Validar que un entero proporcionado sea igual a 10...
'seats' => 'integer|size:10';
// Validar que un array tenga exactamente 5 elementos...
'tags' => 'array|size:5';
// Validar que un archivo subido tenga exactamente 512 kilobytes...
'image' => 'file|size:512';
#starts_with:foo,bar,...
El campo bajo validación debe comenzar con uno de los valores dados.
#string
El campo bajo validación debe ser una cadena. Si desea permitir que el campo también sea null, debe asignar la regla nullable al campo.
#timezone
El campo bajo validación debe ser un identificador de zona horaria válido según el método DateTimeZone::listIdentifiers.
Los argumentos aceptados por el método DateTimeZone::listIdentifiers también pueden proporcionarse a esta regla de validación:
'timezone' => 'required|timezone:all';
'timezone' => 'required|timezone:Africa';
'timezone' => 'required|timezone:per_country,US';
#unique:table,column
El campo bajo validación no debe existir en la tabla de base de datos dada.
Especificar un nombre personalizado de tabla / columna:
En lugar de especificar directamente el nombre de la tabla, puede especificar el modelo Eloquent que debe usarse para determinar el nombre de la tabla:
'email' => 'unique:App\Models\User,email_address'
La opción column puede usarse para especificar la columna de base de datos correspondiente al campo. Si no se especifica la opción column, se usará el nombre del campo bajo validación.
'email' => 'unique:users,email_address'
Especificar una conexión de base de datos personalizada
Ocasionalmente, puede necesitar establecer una conexión personalizada para las consultas de base de datos realizadas por el Validator. Para lograr esto, puede anteponer el nombre de la conexión al nombre de la tabla:
'email' => 'unique:connection.users,email_address'
Forzar que una regla Unique ignore un ID dado:
A veces, puede desear ignorar un ID dado durante la validación única. Por ejemplo, considere una pantalla de "actualizar perfil" que incluye el nombre del usuario, la dirección de correo electrónico y la ubicación. Probablemente querrá verificar que la dirección de correo electrónico sea única. Sin embargo, si el usuario solo cambia el campo de nombre y no el de correo electrónico, no desea que se genere un error de validación porque el usuario ya es el propietario de la dirección de correo electrónico en cuestión.
Para indicarle al validador que ignore el ID del usuario, usaremos la clase Rule para definir la regla de forma fluida. En este ejemplo, también especificaremos las reglas de validación como un array en lugar de usar el carácter | para delimitarlas:
use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;
Validator::make($data, [
'email' => [
'required',
Rule::unique('users')->ignore($user->id),
],
]);
Nunca debe pasar ninguna entrada de solicitud controlada por el usuario al método ignore. En su lugar, solo debe pasar un ID único generado por el sistema, como un ID autoincremental o UUID de una instancia de modelo Eloquent. De lo contrario, su aplicación será vulnerable a un ataque de inyección SQL.
En lugar de pasar el valor de la clave del modelo al método ignore, también puede pasar la instancia completa del modelo. Laravel extraerá automáticamente la clave del modelo:
Rule::unique('users')->ignore($user)
Si su tabla usa un nombre de columna de clave primaria distinto de id, puede especificar el nombre de la columna al llamar al método ignore:
Rule::unique('users')->ignore($user->id, 'user_id')
Por defecto, la regla unique verificará la unicidad de la columna que coincide con el nombre del atributo que se está validando. Sin embargo, puede pasar un nombre de columna diferente como segundo argumento al método unique:
Rule::unique('users', 'email_address')->ignore($user->id)
Agregar cláusulas Where adicionales:
Puede especificar condiciones adicionales en la consulta personalizando la consulta usando el método where. Por ejemplo, agreguemos una condición que limite la consulta para buscar solo registros que tengan un valor en la columna account_id igual a 1:
'email' => Rule::unique('users')->where(fn (Builder $query) => $query->where('account_id', 1))
#uppercase
El campo bajo validación debe estar en mayúsculas.
#url
El campo bajo validación debe ser una URL válida.
Si desea especificar los protocolos de URL que deben considerarse válidos, puede pasar los protocolos como parámetros de la regla de validación:
'url' => 'url:http,https',
'game' => 'url:minecraft,steam',
#ulid
El campo bajo validación debe ser un Identificador Universalmente Único y Lexicográficamente Ordenable (ULID) válido.
#uuid
El campo bajo validación debe ser un identificador único universal (UUID) válido según RFC 4122 (versión 1, 3, 4 o 5).
#Añadiendo reglas condicionalmente
#Omitir la validación cuando los campos tienen ciertos valores
En ocasiones, puede que desee no validar un campo dado si otro campo tiene un valor específico. Puede lograr esto usando la regla de validación exclude_if. En este ejemplo, los campos appointment_date y doctor_name no serán validados si el campo has_appointment tiene un valor de false:
use Illuminate\Support\Facades\Validator;
$validator = Validator::make($data, [
'has_appointment' => 'required|boolean',
'appointment_date' => 'exclude_if:has_appointment,false|required|date',
'doctor_name' => 'exclude_if:has_appointment,false|required|string',
]);
Alternativamente, puede usar la regla exclude_unless para no validar un campo dado a menos que otro campo tenga un valor específico:
$validator = Validator::make($data, [
'has_appointment' => 'required|boolean',
'appointment_date' => 'exclude_unless:has_appointment,true|required|date',
'doctor_name' => 'exclude_unless:has_appointment,true|required|string',
]);
#Validar solo cuando está presente
En algunas situaciones, puede que desee ejecutar las comprobaciones de validación sobre un campo solo si ese campo está presente en los datos que se están validando. Para lograr esto rápidamente, agregue la regla sometimes a su lista de reglas:
$v = Validator::make($data, [
'email' => 'sometimes|required|email',
]);
En el ejemplo anterior, el campo email solo será validado si está presente en el arreglo $data.
Si está intentando validar un campo que siempre debería estar presente pero puede estar vacío, consulte esta nota sobre campos opcionales.
#Validación condicional compleja
A veces puede que desee agregar reglas de validación basadas en lógica condicional más compleja. Por ejemplo, puede que quiera requerir un campo dado solo si otro campo tiene un valor mayor que 100. O puede que necesite que dos campos tengan un valor específico solo cuando otro campo esté presente. Agregar estas reglas de validación no tiene por qué ser complicado. Primero, cree una instancia de Validator con sus reglas estáticas que nunca cambian:
use Illuminate\Support\Facades\Validator;
$validator = Validator::make($request->all(), [
'email' => 'required|email',
'games' => 'required|numeric',
]);
Supongamos que nuestra aplicación web es para coleccionistas de juegos. Si un coleccionista se registra en nuestra aplicación y posee más de 100 juegos, queremos que explique por qué tiene tantos juegos. Por ejemplo, tal vez tenga una tienda de reventa de juegos, o simplemente disfrute coleccionarlos. Para agregar esta condición, podemos usar el método sometimes en la instancia de Validator.
use Illuminate\Support\Fluent;
$validator->sometimes('reason', 'required|max:500', function (Fluent $input) {
return $input->games >= 100;
});
El primer argumento pasado al método sometimes es el nombre del campo que estamos validando condicionalmente. El segundo argumento es una lista de las reglas que queremos agregar. Si el closure pasado como tercer argumento devuelve true, las reglas serán añadidas. Este método facilita la creación de validaciones condicionales complejas. Incluso puede agregar validaciones condicionales para varios campos a la vez:
$validator->sometimes(['reason', 'cost'], 'required', function (Fluent $input) {
return $input->games >= 100;
});
El parámetro $input pasado a su closure será una instancia de Illuminate\Support\Fluent y puede usarse para acceder a sus datos y archivos bajo validación.
#Validación condicional compleja en arrays
A veces puede querer validar un campo basado en otro campo dentro del mismo array anidado cuyo índice no conoce. En estas situaciones, puede permitir que su closure reciba un segundo argumento que será el elemento individual actual del array que se está validando:
$input = [
'channels' => [
[
'type' => 'email',
'address' => 'abigail@example.com',
],
[
'type' => 'url',
'address' => 'https://example.com',
],
],
];
$validator->sometimes('channels.*.address', 'email', function (Fluent $input, Fluent $item) {
return $item->type === 'email';
});
$validator->sometimes('channels.*.address', 'url', function (Fluent $input, Fluent $item) {
return $item->type !== 'email';
});
Al igual que el parámetro $input pasado al closure, el parámetro $item es una instancia de Illuminate\Support\Fluent cuando los datos del atributo son un array; de lo contrario, es una cadena.
#Validando arrays
Como se explicó en la documentación de la regla array, la regla array acepta una lista de claves permitidas en el array. Si hay claves adicionales presentes dentro del array, la validación fallará:
use Illuminate\Support\Facades\Validator;
$input = [
'user' => [
'name' => 'Taylor Otwell',
'username' => 'taylorotwell',
'admin' => true,
],
];
Validator::make($input, [
'user' => 'array:name,username',
]);
En general, siempre debe especificar las claves del array que están permitidas dentro de su array. De lo contrario, los métodos validate y validated del validador devolverán todos los datos validados, incluyendo el array y todas sus claves, incluso si esas claves no fueron validadas por otras reglas de validación anidadas.
#Validando entrada de arrays anidados
Validar campos de formulario basados en arrays anidados no tiene por qué ser complicado. Puede usar la "notación de puntos" para validar atributos dentro de un array. Por ejemplo, si la solicitud HTTP entrante contiene un campo photos[profile], puede validarlo así:
use Illuminate\Support\Facades\Validator;
$validator = Validator::make($request->all(), [
'photos.profile' => 'required|image',
]);
También puede validar cada elemento de un array. Por ejemplo, para validar que cada correo electrónico en un campo de entrada de array sea único, puede hacer lo siguiente:
$validator = Validator::make($request->all(), [
'person.*.email' => 'email|unique:users',
'person.*.first_name' => 'required_with:person.*.last_name',
]);
De igual forma, puede usar el carácter * al especificar mensajes de validación personalizados en sus archivos de idioma, facilitando el uso de un solo mensaje de validación para campos basados en arrays:
'custom' => [
'person.*.email' => [
'unique' => 'Cada persona debe tener una dirección de correo electrónico única',
]
],
#Accediendo a datos de arrays anidados
A veces puede necesitar acceder al valor de un elemento dado de un array anidado al asignar reglas de validación al atributo. Puede lograr esto usando el método Rule::forEach. El método forEach acepta un closure que será invocado para cada iteración del atributo array bajo validación y recibirá el valor del atributo y el nombre explícito y completamente expandido del atributo. El closure debe devolver un array de reglas para asignar al elemento del array:
use App\Rules\HasPermission;
use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;
$validator = Validator::make($request->all(), [
'companies.*.id' => Rule::forEach(function (string|null $value, string $attribute) {
return [
Rule::exists(Company::class, 'id'),
new HasPermission('manage-company', $value),
];
}),
]);
#Índices y posiciones en mensajes de error
Al validar arrays, puede que quiera referenciar el índice o la posición de un ítem particular que falló la validación dentro del mensaje de error mostrado por su aplicación. Para lograr esto, puede incluir los marcadores :index (que comienza en 0) y :position (que comienza en 1) dentro de su mensaje de validación personalizado:
use Illuminate\Support\Facades\Validator;
$input = [
'photos' => [
[
'name' => 'BeachVacation.jpg',
'description' => '¡Una foto de mis vacaciones en la playa!',
],
[
'name' => 'GrandCanyon.jpg',
'description' => '',
],
],
];
Validator::validate($input, [
'photos.*.description' => 'required',
], [
'photos.*.description.required' => 'Por favor describa la foto #:position.',
]);
Dado el ejemplo anterior, la validación fallará y al usuario se le mostrará el siguiente error: "Por favor describa la foto #2."
Si es necesario, puede referenciar índices y posiciones más profundamente anidados mediante second-index, second-position, third-index, third-position, etc.
'photos.*.attributes.*.string' => 'Atributo inválido para la foto #:second-position.',
#Validando archivos
Laravel proporciona una variedad de reglas de validación que pueden usarse para validar archivos subidos, como mimes, image, min y max. Aunque puede especificar estas reglas individualmente al validar archivos, Laravel también ofrece un constructor fluido de reglas de validación para archivos que puede encontrar conveniente:
use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rules\File;
Validator::validate($input, [
'attachment' => [
'required',
File::types(['mp3', 'wav'])
->min(1024)
->max(12 * 1024),
],
]);
Si su aplicación acepta imágenes subidas por los usuarios, puede usar el método constructor image de la regla File para indicar que el archivo subido debe ser una imagen. Además, la regla dimensions puede usarse para limitar las dimensiones de la imagen:
use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;
use Illuminate\Validation\Rules\File;
Validator::validate($input, [
'photo' => [
'required',
File::image()
->min(1024)
->max(12 * 1024)
->dimensions(Rule::dimensions()->maxWidth(1000)->maxHeight(500)),
],
]);
Más información sobre la validación de dimensiones de imágenes puede encontrarse en la documentación de la regla dimensions.
#Tamaños de archivo
Para mayor comodidad, los tamaños mínimos y máximos de archivo pueden especificarse como una cadena con un sufijo que indica las unidades de tamaño. Se soportan los sufijos kb, mb, gb y tb:
File::image()
->min('1kb')
->max('10mb')
#Tipos de archivo
Aunque solo necesita especificar las extensiones al invocar el método types, este método en realidad valida el tipo MIME del archivo leyendo su contenido y adivinando su tipo MIME. Una lista completa de tipos MIME y sus extensiones correspondientes puede encontrarse en la siguiente ubicación:
https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types
#Validando contraseñas
Para asegurar que las contraseñas tengan un nivel adecuado de complejidad, puede usar el objeto regla Password de Laravel:
use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rules\Password;
$validator = Validator::make($request->all(), [
'password' => ['required', 'confirmed', Password::min(8)],
]);
El objeto regla Password le permite personalizar fácilmente los requisitos de complejidad de la contraseña para su aplicación, como especificar que las contraseñas requieran al menos una letra, número, símbolo o caracteres con mayúsculas y minúsculas mezcladas:
// Requerir al menos 8 caracteres...
Password::min(8)
// Requerir al menos una letra...
Password::min(8)->letters()
// Requerir al menos una letra mayúscula y una minúscula...
Password::min(8)->mixedCase()
// Requerir al menos un número...
Password::min(8)->numbers()
// Requerir al menos un símbolo...
Password::min(8)->symbols()
Además, puede asegurarse de que una contraseña no haya sido comprometida en una filtración pública de datos de contraseñas usando el método uncompromised:
Password::min(8)->uncompromised()
Internamente, el objeto regla Password usa el modelo de k-Anonymity para determinar si una contraseña ha sido filtrada a través del servicio haveibeenpwned.com sin sacrificar la privacidad o seguridad del usuario.
Por defecto, si una contraseña aparece al menos una vez en una filtración de datos, se considerará comprometida. Puede personalizar este umbral usando el primer argumento del método uncompromised:
// Asegurar que la contraseña aparezca menos de 3 veces en la misma filtración de datos...
Password::min(8)->uncompromised(3);
Por supuesto, puede encadenar todos los métodos en los ejemplos anteriores:
Password::min(8)
->letters()
->mixedCase()
->numbers()
->symbols()
->uncompromised()
#Definiendo reglas predeterminadas para contraseñas
Puede resultar conveniente especificar las reglas predeterminadas de validación para contraseñas en un solo lugar de su aplicación. Puede lograr esto fácilmente usando el método Password::defaults, que acepta un closure. El closure dado al método defaults debe devolver la configuración predeterminada de la regla Password. Normalmente, la regla defaults debe llamarse dentro del método boot de uno de los proveedores de servicios de su aplicación:
use Illuminate\Validation\Rules\Password;
/**
* Inicializar cualquier servicio de la aplicación.
*/
public function boot(): void
{
Password::defaults(function () {
$rule = Password::min(8);
return $this->app->isProduction()
? $rule->mixedCase()->uncompromised()
: $rule;
});
}
Luego, cuando desee aplicar las reglas predeterminadas a una contraseña específica que se está validando, puede invocar el método defaults sin argumentos:
'password' => ['required', Password::defaults()],
Ocasionalmente, puede querer agregar reglas de validación adicionales a sus reglas predeterminadas para contraseñas. Puede usar el método rules para lograr esto:
use App\Rules\ZxcvbnRule;
Password::defaults(function () {
$rule = Password::min(8)->rules([new ZxcvbnRule]);
// ...
});
#Reglas de validación personalizadas
#Usando objetos Rule
Laravel proporciona una variedad de reglas de validación útiles; sin embargo, puede que desee especificar algunas propias. Un método para registrar reglas de validación personalizadas es usando objetos rule. Para generar un nuevo objeto rule, puede usar el comando Artisan make:rule. Usemos este comando para generar una regla que verifique que una cadena esté en mayúsculas. Laravel colocará la nueva regla en el directorio app/Rules. Si este directorio no existe, Laravel lo creará cuando ejecute el comando Artisan para crear su regla:
php artisan make:rule Uppercase
Una vez que la regla ha sido creada, estamos listos para definir su comportamiento. Un objeto regla contiene un único método: validate. Este método recibe el nombre del atributo, su valor y un callback que debe invocarse en caso de fallo con el mensaje de error de validación:
<?php
namespace App\Rules;
use Closure;
use Illuminate\Contracts\Validation\ValidationRule;
class Uppercase implements ValidationRule
{
/**
* Run the validation rule.
*/
public function validate(string $attribute, mixed $value, Closure $fail): void
{
if (strtoupper($value) !== $value) {
$fail('The :attribute must be uppercase.');
}
}
}
Una vez que la regla ha sido definida, puede adjuntarla a un validador pasando una instancia del objeto regla junto con sus otras reglas de validación:
use App\Rules\Uppercase;
$request->validate([
'name' => ['required', 'string', new Uppercase],
]);
Traduciendo mensajes de validación
En lugar de proporcionar un mensaje de error literal al closure $fail, también puede proporcionar una clave de cadena de traducción e indicar a Laravel que traduzca el mensaje de error:
if (strtoupper($value) !== $value) {
$fail('validation.uppercase')->translate();
}
Si es necesario, puede proporcionar reemplazos de marcadores y el idioma preferido como primer y segundo argumento al método translate:
$fail('validation.location')->translate([
'value' => $this->value,
], 'fr')
Accediendo a datos adicionales
Si su clase de regla de validación personalizada necesita acceder a todos los demás datos que se están validando, su clase puede implementar la interfaz Illuminate\Contracts\Validation\DataAwareRule. Esta interfaz requiere que su clase defina un método setData. Este método será invocado automáticamente por Laravel (antes de que proceda la validación) con todos los datos bajo validación:
<?php
namespace App\Rules;
use Illuminate\Contracts\Validation\DataAwareRule;
use Illuminate\Contracts\Validation\ValidationRule;
class Uppercase implements DataAwareRule, ValidationRule
{
/**
* Todos los datos bajo validación.
*
* @var array<string, mixed>
*/
protected $data = [];
// ...
/**
* Establecer los datos bajo validación.
*
* @param array<string, mixed> $data
*/
public function setData(array $data): static
{
$this->data = $data;
return $this;
}
}
O, si su regla de validación requiere acceso a la instancia del validador que realiza la validación, puede implementar la interfaz ValidatorAwareRule:
<?php
namespace App\Rules;
use Illuminate\Contracts\Validation\ValidationRule;
use Illuminate\Contracts\Validation\ValidatorAwareRule;
use Illuminate\Validation\Validator;
class Uppercase implements ValidationRule, ValidatorAwareRule
{
/**
* La instancia del validador.
*
* @var \Illuminate\Validation\Validator
*/
protected $validator;
// ...
/**
* Establecer el validador actual.
*/
public function setValidator(Validator $validator): static
{
$this->validator = $validator;
return $this;
}
}
Usando closures
Si solo necesita la funcionalidad de una regla personalizada una vez en toda su aplicación, puede usar un closure en lugar de un objeto regla. El closure recibe el nombre del atributo, el valor del atributo y un callback $fail que debe llamarse si la validación falla:
use Illuminate\Support\Facades\Validator;
use Closure;
$validator = Validator::make($request->all(), [
'title' => [
'required',
'max:255',
function (string $attribute, mixed $value, Closure $fail) {
if ($value === 'foo') {
$fail("The {$attribute} is invalid.");
}
},
],
]);
Reglas implícitas
Por defecto, cuando un atributo que se está validando no está presente o contiene una cadena vacía, las reglas de validación normales, incluidas las reglas personalizadas, no se ejecutan. Por ejemplo, la regla unique no se ejecutará contra una cadena vacía:
use Illuminate\Support\Facades\Validator;
$rules = ['name' => 'unique:users,name'];
$input = ['name' => ''];
Validator::make($input, $rules)->passes(); // true
Para que una regla personalizada se ejecute incluso cuando un atributo está vacío, la regla debe implicar que el atributo es obligatorio. Para generar rápidamente un nuevo objeto regla implícita, puede usar el comando Artisan make:rule con la opción --implicit:
php artisan make:rule Uppercase --implicit
Una regla "implícita" solo implica que el atributo es obligatorio. Si realmente invalida un atributo ausente o vacío depende de usted.