Laravel обработка ошибок валидации

Вступление

Laravel предлагает несколько разных подходов для проверки входящих данных вашего приложения. По умолчанию базовый класс контроллера Laravel использует ValidatesRequestsчерту, которая предоставляет удобный метод для проверки входящего HTTP-запроса с помощью множества мощных правил проверки.

Валидация Быстрый старт

Чтобы узнать о мощных функциях проверки Laravel, давайте рассмотрим полный пример проверки формы и отображения сообщений об ошибках пользователю.

Определение маршрутов

Сначала предположим, что в нашем файле определены следующие маршруты :routes/web.php

Route::get('post/create', 'PostController@create');

Route::post('post', 'PostController@store');

GETМаршрут будет отображать форму для пользователя , чтобы создать новое сообщение в блоге, в то время как POSTмаршрут будет хранить запись в блоге в базе данных.

Создание контроллера

Далее, давайте посмотрим на простой контроллер, который обрабатывает эти маршруты. Мы storeпока оставим метод пустым:

<?php

namespace AppHttpControllers;

use IlluminateHttpRequest;
use AppHttpControllersController;

class PostController extends Controller
{
    /**
     * Show the form to create a new blog post.
     *
     * @return Response
     */
    public function create()
    {
        return view('post.create');
    }

    /**
     * Store a new blog post.
     *
     * @param  Request  $request
     * @return Response
     */
    public function store(Request $request)
    {
        // Validate and store the blog post...
    }
}

Написание логики валидации

Теперь мы готовы заполнить наш storeметод логикой для проверки нового сообщения в блоге. Для этого мы будем использовать validateметод, предоставленный объектом. Если правила проверки пройдут, ваш код будет работать нормально; однако, если проверка не пройдена, будет выдано исключение, и правильный ответ об ошибке будет автоматически отправлен обратно пользователю. В случае традиционного HTTP-запроса будет сгенерирован ответ о перенаправлении, а JSON-ответ будет отправлен для AJAX-запросов.IlluminateHttpRequest

Чтобы лучше понять validateметод, давайте вернемся к storeметоду:

/**
 * Store a new blog post.
 *
 * @param  Request  $request
 * @return Response
 */
public function store(Request $request)
{
    $validatedData = $request->validate([
        'title' => 'required|unique:posts|max:255',
        'body' => 'required',
    ]);

    // The blog post is valid...
}

Как видите, мы передаем в метод нужные правила валидации validate. Опять же, если проверка не пройдена, автоматически генерируется правильный ответ. Если проверка пройдена, наш контроллер продолжит нормально работать.

Остановка при первом сбое проверки

Иногда может потребоваться прекратить запуск правил проверки для атрибута после первого сбоя проверки. Для этого присвойте bailправило атрибуту:

$request->validate([
    'title' => 'bail|required|unique:posts|max:255',
    'body' => 'required',
]);

В этом примере, если uniqueправило для titleатрибута не выполнено, maxправило не будет проверено. Правила будут утверждены в порядке их назначения.

Примечание о вложенных атрибутах

Если ваш HTTP-запрос содержит «вложенные» параметры, вы можете указать их в правилах проверки, используя синтаксис «точка»:

$request->validate([
    'title' => 'required|unique:posts|max:255',
    'author.name' => 'required',
    'author.description' => 'required',
]);

Отображение ошибок валидации

Итак, что если параметры входящего запроса не соответствуют заданным правилам проверки? Как упоминалось ранее, Laravel автоматически перенаправит пользователя обратно на прежнее место. Кроме того, все ошибки проверки автоматически будут мигать в сеансе .

Опять же, обратите внимание, что нам не нужно было явно привязывать сообщения об ошибках к представлению нашего GETмаршрута. Это потому, что Laravel будет проверять ошибки в данных сеанса и автоматически связывать их с представлением, если они доступны. $errorsПеременная будет экземпляром . Для получения дополнительной информации о работе с этим объектом ознакомьтесь с его документацией .IlluminateSupportMessageBag

$errorsПеременная связана с видом со стороны промежуточного программного обеспечения , которое обеспечивается в группе промежуточного программного обеспечения . Когда применяется это промежуточное программное обеспечение, переменная всегда будет доступна в ваших представлениях , что позволяет вам удобно предполагать, что переменная всегда определена и ее можно безопасно использовать.IlluminateViewMiddlewareShareErrorsFromSessionweb$errors$errors

Таким образом, в нашем примере пользователь будет перенаправлен на createметод нашего контроллера при сбое проверки, что позволит нам отображать сообщения об ошибках в представлении:

<!-- /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

<!-- Create Post Form -->

@errorДиректива

Вы также можете использовать директиву @error Blade, чтобы быстро проверить, существуют ли сообщения об ошибках валидации для данного атрибута. Внутри @errorдирективы вы можете вызвать $messageпеременную для отображения сообщения об ошибке:

<!-- /resources/views/post/create.blade.php -->

<label for="title">Post Title</label>

<input id="title" type="text" class="@error('title') is-invalid @enderror">

@error('title')
    <div class="alert alert-danger">{{ $message }}</div>
@enderror

Примечание о необязательных полях

По умолчанию Laravel включает TrimStringsи ConvertEmptyStringsToNullпромежуточное ПО в глобальный стек промежуточного ПО вашего приложения. Эти промежуточные программы перечислены в стеке классом. Из-за этого вам часто нужно помечать ваши «необязательные» поля запроса так, как будто вы не хотите, чтобы валидатор считал значения недействительными. Например:AppHttpKernelnullablenull

$request->validate([
    'title' => 'required|unique:posts|max:255',
    'body' => 'required',
    'publish_at' => 'nullable|date',
]);

В этом примере мы указываем, что publish_atполе может быть либо nullдействительным представлением даты. Если nullableмодификатор не добавлен в определение правила, валидатор будет считать nullнедопустимую дату.

AJAX-запросы и валидация

В этом примере мы использовали традиционную форму для отправки данных в приложение. Однако многие приложения используют запросы AJAX. При использовании validateметода во время запроса AJAX, Laravel не будет генерировать ответ перенаправления. Вместо этого Laravel генерирует ответ JSON, содержащий все ошибки проверки. Этот ответ JSON будет отправлен с кодом состояния 422 HTTP.

Проверка запроса формы

Создание запросов формы

Для более сложных сценариев проверки вы можете создать «запрос формы». Запросы форм — это пользовательские классы запросов, которые содержат логику проверки. Чтобы создать класс запроса формы, используйте команду Artisan CLI:make:request

php artisan make:request StoreBlogPost

Сгенерированный класс будет помещен в каталог. Если этот каталог не существует, он будет создан при запуске команды. Давайте добавим несколько правил проверки в метод:app/Http/Requestsmake:requestrules

/**
 * Get the validation rules that apply to the request.
 *
 * @return array
 */
public function rules()
{
    return [
        'title' => 'required|unique:posts|max:255',
        'body' => 'required',
    ];
}

Вы можете напечатать любые зависимости, которые вам нужны, в rulesсигнатуре метода. Они будут автоматически разрешены через сервисный контейнер Laravel .

Итак, как оцениваются правила валидации? Все, что вам нужно сделать, это напечатать запрос на метод вашего контроллера. Входящий запрос формы проверяется перед вызовом метода контроллера, что означает, что вам не нужно загромождать ваш контроллер какой-либо логикой проверки:

/**
 * Store the incoming blog post.
 *
 * @param  StoreBlogPost  $request
 * @return Response
 */
public function store(StoreBlogPost $request)
{
    // The incoming request is valid...

    // Retrieve the validated input data...
    $validated = $request->validated();
}

Если проверка не пройдена, будет сгенерирован ответ о перенаправлении, чтобы отправить пользователя обратно в его предыдущее местоположение. Ошибки также будут мигать в сеансе, чтобы они были доступны для отображения. Если запрос был запросом AJAX, пользователю будет возвращен HTTP-ответ с кодом состояния 422, включая JSON-представление ошибок проверки.

Добавление после хуков для формирования запросов

Если вы хотите добавить хук «после» к запросу формы, вы можете использовать withValidatorметод. Этот метод получает полностью сконструированный валидатор, позволяющий вам вызвать любой из его методов до того, как правила валидации действительно будут оценены:

/**
 * Configure the validator instance.
 *
 * @param  IlluminateValidationValidator  $validator
 * @return void
 */
public function withValidator($validator)
{
    $validator->after(function ($validator) {
        if ($this->somethingElseIsInvalid()) {
            $validator->errors()->add('field', 'Something is wrong with this field!');
        }
    });
}

Запросы формы авторизации

Класс запроса формы также содержит authorizeметод. В рамках этого метода вы можете проверить, действительно ли аутентифицированный пользователь имеет полномочия на обновление данного ресурса. Например, вы можете определить, действительно ли пользователю принадлежит комментарий в блоге, который он пытается обновить:

/**
 * Determine if the user is authorized to make this request.
 *
 * @return bool
 */
public function authorize()
{
    $comment = Comment::find($this->route('comment'));

    return $comment && $this->user()->can('update', $comment);
}

Поскольку все запросы формы расширяют базовый класс запросов Laravel, мы можем использовать userметод для доступа к аутентифицированному в настоящее время пользователю. Также обратите внимание на вызов routeметода в примере выше. Этот метод предоставляет вам доступ к параметрам URI, определенным на вызываемом маршруте, таким как параметр в примере ниже:{comment}

Route::post('comment/{comment}');

Если authorizeметод возвращается false, HTTP-ответ с кодом состояния 403 будет автоматически возвращен, и ваш метод контроллера не будет выполнен.

Если вы планируете использовать логику авторизации в другой части вашего приложения, вернитесь trueиз authorizeметода:

/**
 * Determine if the user is authorized to make this request.
 *
 * @return bool
 */
public function authorize()
{
    return true;
}

Вы можете напечатать любые зависимости, которые вам нужны, в authorizeсигнатуре метода. Они будут автоматически разрешены через сервисный контейнер Laravel .

Настройка сообщений об ошибках

Вы можете настроить сообщения об ошибках, используемые запросом формы, переопределив messagesметод. Этот метод должен возвращать массив пар атрибут / правило и соответствующие им сообщения об ошибках:

/**
 * Get the error messages for the defined validation rules.
 *
 * @return array
 */
public function messages()
{
    return [
        'title.required' => 'A title is required',
        'body.required'  => 'A message is required',
    ];
}

Настройка атрибутов проверки

Если вы хотите, чтобы :attributeчасть вашего сообщения проверки была заменена именем настраиваемого атрибута, вы можете указать настраиваемые имена, переопределив attributesметод. Этот метод должен возвращать массив пар атрибут / имя:

/**
 * Get custom attributes for validator errors.
 *
 * @return array
 */
public function attributes()
{
    return [
        'email' => 'email address',
    ];
}

Создание валидаторов вручную

Если вы не хотите использовать validateметод в запросе, вы можете создать экземпляр валидатора вручную, используя Validator фасад . makeМетод на фасаде создает новый экземпляр валидатора:

<?php

namespace AppHttpControllers;

use Validator;
use IlluminateHttpRequest;
use AppHttpControllersController;

class PostController extends Controller
{
    /**
     * Store a new blog post.
     *
     * @param  Request  $request
     * @return Response
     */
    public function store(Request $request)
    {
        $validator = Validator::make($request->all(), [
            'title' => 'required|unique:posts|max:255',
            'body' => 'required',
        ]);

        if ($validator->fails()) {
            return redirect('post/create')
                        ->withErrors($validator)
                        ->withInput();
        }

        // Store the blog post...
    }
}

Первым аргументом, переданным makeметоду, являются проверяемые данные. Второй аргумент — это правила проверки, которые должны применяться к данным.

После проверки, не прошла ли проверка запроса, вы можете использовать этот withErrorsметод для отправки сообщений об ошибках в сеанс. При использовании этого метода $errorsпеременная будет автоматически предоставлена ​​вашим представлениям после перенаправления, что позволит вам легко отображать их обратно пользователю. withErrorsМетод принимает валидатор, а MessageBag, или PHP array.

Автоматическое перенаправление

Если вы хотите создать экземпляр валидатора вручную, но все же воспользоваться преимуществами автоматического перенаправления, предлагаемого методом запросов validate, вы можете вызвать validateметод в существующем экземпляре валидатора. Если проверка не пройдена, пользователь будет автоматически перенаправлен или, в случае запроса AJAX, будет возвращен ответ JSON:

Validator::make($request->all(), [
    'title' => 'required|unique:posts|max:255',
    'body' => 'required',
])->validate();

Именованные пакеты с ошибками

Если у вас есть несколько форм на одной странице, вы можете назвать имена MessageBagошибок, что позволит вам получать сообщения об ошибках для конкретной формы. Передайте имя в качестве второго аргумента withErrors:

return redirect('register')
            ->withErrors($validator, 'login');

Затем вы можете получить доступ к именованному MessageBagэкземпляру из $errorsпеременной:

{{ $errors->login->first('email') }}

После проверки крюк

Валидатор также позволяет вам добавлять обратные вызовы, которые будут выполняться после завершения проверки. Это позволяет вам легко выполнять дальнейшую проверку и даже добавлять больше сообщений об ошибках в коллекцию сообщений. Чтобы начать, используйте afterметод на экземпляре валидатора:

$validator = Validator::make(...);

$validator->after(function ($validator) {
    if ($this->somethingElseIsInvalid()) {
        $validator->errors()->add('field', 'Something is wrong with this field!');
    }
});

if ($validator->fails()) {
    //
}

Работа с сообщениями об ошибках

После вызова errorsметода для Validatorэкземпляра вы получите экземпляр, который имеет множество удобных методов для работы с сообщениями об ошибках. Переменная , которая автоматически становится доступной для всех представлений также является экземпляром класса.IlluminateSupportMessageBag$errorsMessageBag

Получение первого сообщения об ошибке для поля

Чтобы получить первое сообщение об ошибке для данного поля, используйте firstметод:

$errors = $validator->errors();

echo $errors->first('email');

Получение всех сообщений об ошибках для поля

Если вам нужно получить массив всех сообщений для данного поля, используйте getметод:

foreach ($errors->get('email') as $message) {
    //
}

Если вы проверяете поле формы массива, вы можете получить все сообщения для каждого из элементов массива, используя *символ:

foreach ($errors->get('attachments.*') as $message) {
    //
}

Получение всех сообщений об ошибках для всех полей

Чтобы получить массив всех сообщений для всех полей, используйте allметод:

foreach ($errors->all() as $message) {
    //
}

Определение наличия сообщений для поля

hasМетод может быть использован , чтобы определить , существуют ли какие — либо сообщения об ошибках для данного поля:

if ($errors->has('email')) {
    //
}

Пользовательские сообщения об ошибках

При необходимости вы можете использовать пользовательские сообщения об ошибках для проверки вместо значений по умолчанию. Есть несколько способов указать пользовательские сообщения. Во-первых, вы можете передать пользовательские сообщения в качестве третьего аргумента методу:Validator::make

$messages = [
    'required' => 'The :attribute field is required.',
];

$validator = Validator::make($input, $rules, $messages);

В этом примере :attributeзаполнитель будет заменен действительным именем проверяемого поля. Вы также можете использовать другие заполнители в сообщениях проверки. Например:

$messages = [
    'same'    => 'The :attribute and :other must match.',
    'size'    => 'The :attribute must be exactly :size.',
    'between' => 'The :attribute value :input is not between :min - :max.',
    'in'      => 'The :attribute must be one of the following types: :values',
];

Указание пользовательского сообщения для данного атрибута

Иногда вам может потребоваться указать пользовательское сообщение об ошибке только для определенного поля. Вы можете сделать это, используя обозначение «точка». Сначала укажите имя атрибута, а затем правило:

$messages = [
    'email.required' => 'We need to know your e-mail address!',
];

Указание пользовательских сообщений в языковых файлах

В большинстве случаев вы, вероятно, будете указывать свои пользовательские сообщения в языковом файле, а не передавать их непосредственно в Validator. Для этого добавьте ваши сообщения в customмассив в языковой файл.resources/lang/xx/validation.php

'custom' => [
    'email' => [
        'required' => 'We need to know your e-mail address!',
    ],
],

Указание пользовательских атрибутов в языковых файлах

Если вы хотите, чтобы :attributeчасть вашего сообщения проверки была заменена именем настраиваемого атрибута, вы можете указать это имя в attributesмассиве вашего языкового файла:resources/lang/xx/validation.php

'attributes' => [
    'email' => 'email address',
],

Указание пользовательских значений в языковых файлах

Иногда вам может понадобиться :valueзаменить часть вашего сообщения для проверки пользовательским представлением значения. Например, рассмотрим следующее правило, которое указывает, что номер кредитной карты требуется, если значение payment_typeимеет cc:

$request->validate([
    'credit_card_number' => 'required_if:payment_type,cc'
]);

Если это правило проверки не выполнено, оно выдаст следующее сообщение об ошибке:

The credit card number field is required when payment type is cc.

Вместо отображения ccв качестве значения типа платежа вы можете указать представление пользовательского значения в вашем validationязыковом файле, определив valuesмассив:

'values' => [
    'payment_type' => [
        'cc' => 'credit card'
    ],
],

Теперь, если правило проверки не выполнено, оно выдаст следующее сообщение:

The credit card number field is required when payment type is credit card.

Доступные правила проверки

Ниже приведен список всех доступных правил проверки и их функции:

• Accepted
• Active URL
• After (Date)
• After Or Equal (Date)
• Alpha
• Alpha Dash
• Alpha Numeric
• Array
• Bail
• Before (Date)
• Before Or Equal (Date)
• Between
• Boolean
• Confirmed
• Date
• Date Equals
• Date Format
• Different
• Digits
• Digits Between
• Dimensions (Image Files)
• Distinct
• E-Mail
• Ends With
• Exists (Database)
• File
• Filled
• Greater Than
• Greater Than Or Equal
• Image (File)
• In
• In Array
• Integer
• IP Address
• JSON
• Less Than
• Less Than Or Equal
• Max
• MIME Types
• MIME Type By File Extension
• Min
• Not In
• Not Regex
• Nullable
• Numeric
• Present
• Regular Expression
• Required
• Required If
• Required Unless
• Required With
• Required With All
• Required Without
• Required Without All
• Same
• Size
• Sometimes
• Starts With
• String
• Timezone
• Unique (Database)
• URL
• UUID

accepted

Проверяемое поле должно быть yes , on , 1 или true . Это полезно для подтверждения принятия «Условий обслуживания».

active_url

Проверяемое поле должно иметь действительную запись A или AAAA в соответствии с dns_get_recordфункцией PHP.

after (Date)

Проверяемое поле должно быть значением после указанной даты. Даты будут переданы в strtotimeфункцию PHP:

'start_date' => 'required|date|after:tomorrow'

Вместо того, чтобы передавать строку даты для оценки strtotime, вы можете указать другое поле для сравнения с датой:

'finish_date' => 'required|date|after:start_date'

after_or_equal: date

Проверяемое поле должно быть значением после или равным указанной дате. Для получения дополнительной информации см. Правило после .

alpha

Проверяемое поле должно состоять исключительно из буквенных символов.

alpha_dash

Проверяемое поле может содержать буквенно-цифровые символы, а также тире и подчеркивания.

alpha_num

Проверяемое поле должно состоять из буквенно-цифровых символов.

array

Проверяемое поле должно быть PHP array.

bail

Прекратите запуск правил проверки после первого сбоя проверки.

before (Date)

Проверяемое поле должно быть значением, предшествующим данной дате. Даты будут переданы в strtotimeфункцию PHP . Кроме того, как afterправило, в качестве значения можно указать имя другого проверяемого поля date.

before Or Equal (Date)

Проверяемое поле должно быть значением, предшествующим или равным указанной дате. Даты будут переданы в strtotimeфункцию PHP . Кроме того, как afterправило, в качестве значения можно указать имя другого проверяемого поля date.

between:min,max

Проверяемое поле должно иметь размер от заданного минимального до максимального значения . Строки, числа, массивы и файлы оцениваются так же, как sizeправило.

boolean

Проверяемое поле должно быть в состоянии быть логическим. Принимаемые входные true, false, 1, 0, "1", и "0".

confirmed

Проверяемое поле должно иметь соответствующее поле foo_confirmation. Например, если проверяемое поле имеет значение password, соответствующее password_confirmationполе должно присутствовать во входных данных.

date

Проверяемое поле должно быть действительной, не относительной датой в соответствии с strtotimeфункцией PHP.

date_equals: date

Проверяемое поле должно быть равно заданной дате. Даты будут переданы в strtotimeфункцию PHP .

date_format: format

Проверяемое поле должно соответствовать заданному формату . Вы должны использовать либоdate или date_formatпри проверке поля, но не оба.

different:field

Проверяемое поле должно иметь значение, отличное от поля .

digits:value

Проверяемое поле должно быть числовым и иметь точную длину значения .

digits_between:min,max

Проверяемое поле должно иметь длину от заданного минимального до максимального значения .

dimensions

Проверяемый файл должен быть изображением, соответствующим ограничениям размеров, указанным в параметрах правила:

'avatar' => 'dimensions:min_width=100,min_height=200'

Доступны следующие ограничения: min_width , max_width , min_height , max_height , ширина , высота , коэффициент .

Отношение ограничение должно быть представлено в виде ширины , деленная на высоту. Это может быть указано либо с помощью оператора like или с плавающей точкой :3/21.5

'avatar' => 'dimensions:ratio=3/2'

Так как это правило требует нескольких аргументов, вы можете использовать метод для свободного создания правила:Rule::dimensions

use IlluminateValidationRule;

Validator::make($data, [
    'avatar' => [
        'required',
        Rule::dimensions()->maxWidth(1000)->maxHeight(500)->ratio(3 / 2),
    ],
]);

distinct

При работе с массивами проверяемое поле не должно иметь повторяющихся значений.

'foo.*.id' => 'distinct'

email

Проверяемое поле должно быть отформатировано как адрес электронной почты.

ends_with:foo,bar,…

Проверяемое поле должно заканчиваться одним из указанных значений.

exists:table,column

Проверяемое поле должно существовать в данной таблице базы данных.

Основное использование правила существования

'state' => 'exists:states'

Если columnопция не указана, будет использовано имя поля.

Указание пользовательского имени столбца

'state' => 'exists:states,abbreviation'

Иногда вам может потребоваться указать конкретное соединение с базой данных, которое будет использоваться для existsзапроса. Это можно сделать, добавив имя соединения к имени таблицы, используя синтаксис «точка»:

'email' => 'exists:connection.staff,email'

Если вы хотите настроить запрос, выполняемый правилом валидации, вы можете использовать Ruleкласс для свободного определения правила. В этом примере мы также указываем правила проверки в виде массива вместо использования |символа для их разделения:

use IlluminateValidationRule;

Validator::make($data, [
    'email' => [
        'required',
        Rule::exists('staff')->where(function ($query) {
            $query->where('account_id', 1);
        }),
    ],
]);

file

Проверяемое поле должно быть успешно загруженным файлом.

filled

Проверяемое поле не должно быть пустым, если оно присутствует.

gt:field

Проверяемое поле должно быть больше указанного поля . Два поля должны быть одного типа. Строки, числа, массивы и файлы оцениваются с использованием тех же соглашений, что и sizeправило.

gte:field

Проверяемое поле должно быть больше или равно данному полю . Два поля должны быть одного типа. Строки, числа, массивы и файлы оцениваются с использованием тех же соглашений, что и sizeправило.

image

Проверяемый файл должен быть изображением (jpeg, png, bmp, gif или svg)

in:foo,bar,…

Проверяемое поле должно быть включено в данный список значений. Поскольку для этого правила часто требуется implodeмассив, метод может быть использован для свободного построения правила:Rule::in

use IlluminateValidationRule;

Validator::make($data, [
    'zones' => [
        'required',
        Rule::in(['first-zone', 'second-zone']),
    ],
]);

in_array:anotherfield.*

Проверяемое поле должно существовать в значениях другого поля .

integer

Проверяемое поле должно быть целым числом.

ip

Проверяемое поле должно быть IP-адресом.

ipv4

Проверяемое поле должно быть адресом IPv4.

ipv6

Проверяемое поле должно быть адресом IPv6.

json

Проверяемое поле должно быть допустимой строкой JSON.

lt:field

Проверяемое поле должно быть меньше указанного поля . Два поля должны быть одного типа. Строки, числа, массивы и файлы оцениваются с использованием тех же соглашений, что и sizeправило.

lte:field

Проверяемое поле должно быть меньше или равно данному полю . Два поля должны быть одного типа. Строки, числа, массивы и файлы оцениваются с использованием тех же соглашений, что и sizeправило.

max:value

Проверяемое поле должно быть меньше или равно максимальному значению . Строки, числа, массивы и файлы оцениваются так же, как sizeправило.

mimetypes:text/plain,…

Проверяемый файл должен соответствовать одному из указанных типов MIME:

'video' => 'mimetypes:video/avi,video/mpeg,video/quicktime'

Чтобы определить тип MIME загруженного файла, его содержимое будет прочитано, и платформа попытается угадать тип MIME, который может отличаться от типа MIME, предоставленного клиентом.

mimes:foo,bar,…

Проверяемый файл должен иметь тип MIME, соответствующий одному из перечисленных расширений.

Основное использование правила MIME

'photo' => 'mimes:jpeg,bmp,png'

Несмотря на то, что вам нужно только указать расширения, это правило фактически проверяет тип файла MIME, читая содержимое файла и угадывая его тип MIME.

Полный список типов MIME и их соответствующих расширений можно найти по следующему адресу : https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types.

min:value

Проверяемое поле должно иметь минимальное значение . Строки, числа, массивы и файлы оцениваются так же, как sizeправило.

not_in:foo,bar,…

Проверяемое поле не должно быть включено в данный список значений. Метод может быть использован для построения свободно правила:Rule::notIn

use IlluminateValidationRule;

Validator::make($data, [
    'toppings' => [
        'required',
        Rule::notIn(['sprinkles', 'cherries']),
    ],
]);

not_regex:pattern

Проверяемое поле не должно соответствовать заданному регулярному выражению.

Внутренне это правило использует preg_matchфункцию PHP . Указанный шаблон должен соответствовать форматированию, требуемому для этого, preg_matchи, следовательно, также включать допустимые разделители. Например: .'email' => 'not_regex:/^.+$/i'

Примечание. При использовании шаблонов regex/ not_regexможет потребоваться указать правила в массиве вместо использования разделителей канала, особенно если регулярное выражение содержит символ канала.

nullable

Проверяемое поле может быть null. Это особенно полезно при проверке примитивов, таких как строки и целые числа, которые могут содержать nullзначения.

numeric

Проверяемое поле должно быть числовым.

present

Проверяемое поле должно присутствовать во входных данных, но может быть пустым.

regex:pattern

Проверяемое поле должно соответствовать заданному регулярному выражению.

Внутренне это правило использует preg_matchфункцию PHP . Указанный шаблон должен соответствовать форматированию, требуемому для этого, preg_matchи, следовательно, также включать допустимые разделители. Например: .'email' => 'regex:/^.+@.+$/i'

Примечание. При использовании шаблонов regex/ not_regexможет потребоваться указать правила в массиве вместо использования разделителей канала, особенно если регулярное выражение содержит символ канала.

required

Проверяемое поле должно присутствовать во входных данных и не быть пустым. Поле считается «пустым», если выполняется одно из следующих условий:

• Значение есть null.
• Значение является пустой строкой.
• Значением является пустой массив или пустой Countableобъект.
• Значением является загруженный файл без пути.

required_if:anotherfield,value,…

Проверяемое поле должно присутствовать и не быть пустым, если поле другого поля равно какому-либо значению .

Если вы хотите построить более сложное условие для required_ifправила, вы можете использовать метод. Этот метод принимает логическое значение или замыкание. Когда передано Закрытие, Закрытие должно возвратиться или указать, требуется ли проверяемое поле:Rule::requiredIftruefalse

use IlluminateValidationRule;

Validator::make($request->all(), [
    'role_id' => Rule::requiredIf($request->user()->is_admin),
]);

Validator::make($request->all(), [
    'role_id' => Rule::requiredIf(function () use ($request) {
        return $request->user()->is_admin;
    }),
]);

required_unless:anotherfield,value,…

Проверяемое поле должно присутствовать и не быть пустым, если поле другого поля не равно какому-либо значению .

required_with:foo,bar,…

Проверяемое поле должно присутствовать и не быть пустым, только если присутствуют какие-либо другие указанные поля.

required_with_all:foo,bar,…

Проверяемое поле должно присутствовать и не быть пустым, только если присутствуют все другие указанные поля.

required_without:foo,bar,…

Проверяемое поле должно присутствовать и не быть пустым, только если нет других указанных полей.

required_without_all:foo,bar,…

Проверяемое поле должно присутствовать и не быть пустым, только если все другие указанные поля отсутствуют.

same:field

Данное поле должно соответствовать проверяемому полю.

size:value

Проверяемое поле должно иметь размер, соответствующий заданному значению . Для строковых данных значение соответствует количеству символов. Для числовых данных значениесоответствует заданному целочисленному значению. Для массива размер соответствует countмассиву. Для файлов размер соответствует размеру файла в килобайтах.

starts_with:foo,bar,…

Проверяемое поле должно начинаться с одного из указанных значений.

string

Проверяемое поле должно быть строкой. Если вы хотите, чтобы поле также было null, вы должны назначить nullableправило для поля.

timezone

Проверяемое поле должно быть действительным идентификатором часового пояса в соответствии с timezone_identifiers_listфункцией PHP.

unique:table,column,except,idColumn

Проверяемое поле не должно существовать в данной таблице базы данных.

Указание пользовательского имени столбца:

columnВариант может быть использован для определения соответствующего столбца базы данных в полях. Если columnопция не указана, будет использовано имя поля.

'email' => 'unique:users,email_address'

Настраиваемое соединение с базой данных

Иногда вам может понадобиться установить пользовательское соединение для запросов к базе данных, выполняемых валидатором. Как показано выше, при настройке в качестве правила проверки будет использоваться соединение с базой данных по умолчанию для запроса к базе данных. Чтобы переопределить это, укажите соединение и имя таблицы, используя синтаксис «точка»:unique:users

'email' => 'unique:connection.users,email_address'

Принудительное уникальное правило игнорирования заданного идентификатора:

Иногда вы можете игнорировать данный идентификатор во время уникальной проверки. Например, рассмотрим экран «Обновить профиль», который включает имя пользователя, адрес электронной почты и местоположение. Возможно, вы захотите убедиться, что адрес электронной почты является уникальным. Однако, если пользователь изменяет только поле имени, а не поле электронной почты, вы не хотите, чтобы выдавалась ошибка проверки, поскольку пользователь уже является владельцем адреса электронной почты.

Чтобы поручить валидатору игнорировать идентификатор пользователя, мы будем использовать Ruleкласс для свободного определения правила. В этом примере мы также указываем правила проверки в виде массива вместо использования |символа для разделения правил:

use IlluminateValidationRule;

Validator::make($data, [
    'email' => [
        'required',
        Rule::unique('users')->ignore($user->id),
    ],
]);

Вы никогда не должны передавать какой-либо пользовательский ввод запроса в ignoreметод. Вместо этого вы должны передавать только сгенерированный системой уникальный идентификатор, такой как идентификатор с автоматическим увеличением или UUID, из экземпляра модели Eloquent. В противном случае ваше приложение будет уязвимо для атаки SQL-инъекцией.

Вместо того, чтобы передавать значение ключа модели в ignoreметод, вы можете передать весь экземпляр модели. Laravel автоматически извлечет ключ из модели:

Rule::unique('users')->ignore($user)

Если ваша таблица использует имя столбца первичного ключа, отличное от id, вы можете указать имя столбца при вызове ignoreметода:

Rule::unique('users')->ignore($user->id, 'user_id')

По умолчанию uniqueправило проверяет уникальность столбца, совпадающего с именем проверяемого атрибута. Однако вы можете передать другое имя столбца в качестве второго аргумента uniqueметода:

Rule::unique('users', 'email_address')->ignore($user->id),

Добавление дополнительных предложений Where:

Вы также можете указать дополнительные ограничения запроса, настроив запрос с помощью whereметода. Например, давайте добавим ограничение , которое проверяет account_idIS 1:

'email' => Rule::unique('users')->where(function ($query) {
    return $query->where('account_id', 1);
})

url​​​​​​​

Проверяемое поле должно быть действительным URL.

uuid​​​​​​​

Проверяемое поле должно быть действительным универсальным уникальным идентификатором (UUID) RFC 4122 (версия 1, 3, 4 или 5).

Условия добавления правил

Проверка при наличии

В некоторых ситуациях вам может потребоваться выполнить проверки правильности для поля, только если это поле присутствует во входном массиве. Чтобы быстро это сделать, добавьте sometimesправило в список правил:

$v = Validator::make($data, [
    'email' => 'sometimes|required|email',
]);

В приведенном выше примере emailполе будет проверено, только если оно присутствует в $dataмассиве.

Если вы пытаетесь проверить поле, которое всегда должно присутствовать, но может быть пустым, ознакомьтесь с этим примечанием к дополнительным полям

Комплексная условная проверка

Иногда вы можете захотеть добавить правила проверки, основанные на более сложной условной логике. Например, вам может потребоваться указать данное поле только в том случае, если другое поле имеет значение больше 100. Или вам может потребоваться, чтобы два поля имели заданное значение только при наличии другого поля. Добавление этих правил проверки не должно быть проблемой. Сначала создайте Validatorэкземпляр со своими статическими правилами,которые никогда не меняются:

$v = Validator::make($data, [
    'email' => 'required|email',
    'games' => 'required|numeric',
]);

Давайте предположим, что наше веб-приложение предназначено для коллекционеров игр. Если коллекционер игр регистрируется в нашем приложении и им принадлежит более 100 игр, мы хотим, чтобы они объяснили, почему у них так много игр. Например, возможно, они управляют магазином перепродажи игр, или, возможно, им просто нравится коллекционировать. Чтобы условно добавить это требование, мы можем использовать sometimesметод в Validatorэкземпляре.

$v->sometimes('reason', 'required|max:500', function ($input) {
    return $input->games >= 100;
});

Первым аргументом, переданным sometimesметоду, является имя поля, которое мы условно проверяем. Второй аргумент — это правила, которые мы хотим добавить. Если Closureпередано в качестве третьего аргумента true, правила будут добавлены. Этот метод позволяет легко создавать сложные условные проверки. Вы можете даже добавить условные проверки для нескольких полей одновременно:

$v->sometimes(['reason', 'cost'], 'required', function ($input) {
    return $input->games >= 100;
});

$inputПараметр , переданный к вашему Closureбудет экземпляром и может использоваться для доступа к вашему вводу и файлам.IlluminateSupportFluent

Проверка массивов

Проверка полей ввода на основе массива не должна быть проблемой. Вы можете использовать «точечную нотацию» для проверки атрибутов в массиве. Например, если входящий HTTP-запрос содержит поле, вы можете проверить его следующим образом:photos[profile]

$validator = Validator::make($request->all(), [
    'photos.profile' => 'required|image',
]);

Вы также можете проверить каждый элемент массива. Например, чтобы проверить, что каждое электронное письмо в данном поле ввода массива уникально, вы можете сделать следующее:

$validator = Validator::make($request->all(), [
    'person.*.email' => 'email|unique:users',
    'person.*.first_name' => 'required_with:person.*.last_name',
]);

Аналогичным образом, вы можете использовать этот *символ при указании ваших сообщений проверки в ваших языковых файлах, что позволяет без труда использовать одно сообщение проверки для полей на основе массива:

'custom' => [
    'person.*.email' => [
        'unique' => 'Each person must have a unique e-mail address',
    ]
],

Пользовательские правила проверки

Использование объектов правил

Laravel предлагает множество полезных правил проверки; тем не менее, вы можете указать свои собственные. Одним из способов регистрации пользовательских правил проверки является использование объектов правил. Чтобы создать новый объект правила, вы можете использовать команду Artisan. Давайте использовать эту команду для генерации правила, которое проверяет строку в верхнем регистре. Laravel поместит новое правило в каталог:make:ruleapp/Rules

php artisan make:rule Uppercase

Как только правило было создано, мы готовы определить его поведение. Объект правила содержит два метода: passesи message. passesМетод получает значение атрибута и имя, и он должен возвращать trueили в falseзависимости от того, является ли или нет значение атрибута. messageМетод должен возвращать сообщение об ошибке проверки , которая должна использоваться при сбое проверки:

<?php

namespace AppRules;

use IlluminateContractsValidationRule;

class Uppercase implements Rule
{
    /**
     * Determine if the validation rule passes.
     *
     * @param  string  $attribute
     * @param  mixed  $value
     * @return bool
     */
    public function passes($attribute, $value)
    {
        return strtoupper($value) === $value;
    }

    /**
     * Get the validation error message.
     *
     * @return string
     */
    public function message()
    {
        return 'The :attribute must be uppercase.';
    }
}

Вы можете вызвать transпомощника из вашего messageметода, если хотите вернуть сообщение об ошибке из ваших файлов перевода:

/**
 * Get the validation error message.
 *
 * @return string
 */
public function message()
{
    return trans('validation.uppercase');
}

Как только правило было определено, вы можете присоединить его к валидатору, передав экземпляр объекта правила с другими вашими правилами валидации:

use AppRulesUppercase;

$request->validate([
    'name' => ['required', 'string', new Uppercase],
]);

Использование замыканий

Если вам требуется функциональность настраиваемого правила только один раз в приложении, вы можете использовать Closure вместо объекта правила. Замыкание получает имя атрибута, значение атрибута и $failобратный вызов, который должен быть вызван в случае сбоя проверки:

$validator = Validator::make($request->all(), [
    'title' => [
        'required',
        'max:255',
        function ($attribute, $value, $fail) {
            if ($value === 'foo') {
                $fail($attribute.' is invalid.');
            }
        },
    ],
]);

Использование расширений

Другой метод регистрации пользовательских правил проверки — использование extendметода на Validator фасаде . Давайте использовать этот метод в сервис-провайдере для регистрации пользовательского правила проверки:

<?php

namespace AppProviders;

use IlluminateSupportServiceProvider;
use IlluminateSupportFacadesValidator;

class AppServiceProvider extends ServiceProvider
{
    /**
     * Register any application services.
     *
     * @return void
     */
    public function register()
    {
        //
    }

    /**
     * Bootstrap any application services.
     *
     * @return void
     */
    public function boot()
    {
        Validator::extend('foo', function ($attribute, $value, $parameters, $validator) {
            return $value == 'foo';
        });
    }
}

Пользовательский валидатор Closure получает четыре аргумента: имя $attributeпроверяемого $valueобъекта, атрибута, массив, $parametersпередаваемый правилу, и Validatorэкземпляр.

Вы также можете передать класс и метод в extendметод вместо Closure:

Validator::extend('foo', 'FooValidator@validate');

Определение сообщения об ошибке

Вам также необходимо определить сообщение об ошибке для вашего пользовательского правила. Это можно сделать либо с помощью встроенного пользовательского массива сообщений, либо добавив запись в файл языка проверки. Это сообщение должно быть помещено в первый уровень массива, а не в customмассив, который предназначен только для сообщений об ошибках, относящихся к атрибуту:

"foo" => "Your input was invalid!",

"accepted" => "The :attribute must be accepted.",

// The rest of the validation error messages...

При создании пользовательского правила проверки иногда может потребоваться определить пользовательские замены заполнителей для сообщений об ошибках. Вы можете сделать это, создав пользовательский Validator, как описано выше, затем вызвав replacerметод на Validatorфасаде. Вы можете сделать это в рамках bootметода поставщика услуг :

/**
 * Bootstrap any application services.
 *
 * @return void
 */
public function boot()
{
    Validator::extend(...);

    Validator::replacer('foo', function ($message, $attribute, $rule, $parameters) {
        return str_replace(...);
    });
}

Неявные расширения

По умолчанию, когда проверяемый атрибут отсутствует или содержит пустую строку, обычные правила проверки, включая пользовательские расширения, не запускаются. Например, unique правило не будет запущено для пустой строки:

$rules = ['name' => 'unique:users,name'];

$input = ['name' => ''];

Validator::make($input, $rules)->passes(); // true

Чтобы правило запускалось, даже если атрибут пуст, правило должно подразумевать, что атрибут является обязательным. Чтобы создать такое «неявное» расширение, используйте метод:Validator::extendImplicit()

Validator::extendImplicit('foo', function ($attribute, $value, $parameters, $validator) {
    return $value == 'foo';
});

«Неявное» расширение подразумевает, что атрибут является обязательным. Независимо от того, действительно ли он аннулирует отсутствующий или пустой атрибут, зависит от вас.

В этой статье мы расскажем, как можно проверить входящие данные через Контроллеры, Запросы формы (FormRequest) и Правила.

Контроллеры

По умолчанию все контроллеры, расширяющие базовый контроллер, наследуют трейт ValidatesRequests. Он даёт возможность использовать метод validate в ваших контроллерах.

Например, предположим, что пользователь (User) создаёт статью (Article). Возможно, он вводит Название (name) и какой-то Текст (body) для этой статьи, и у статьи есть дата публикации (publish_at). Тогда валидация в контроллере может выглядеть так:

public function store(Request $request) {
    $this->validate($request, [
        'name' => 'required|string',
        'body' => 'required|string',
        'publish_at' => 'required|date_format:Y-m-d H:i:s'
    ]);

    // Данные валидны и будет запущен следующий код
    ...
}

public function store(Request $request) {
    // Примечание: также доступен синтаксис массива
    $request->validate([
      'name' => ['required', 'string'],
      'body' => ['required', 'string'],
      'publish_at' => ['required', 'date_format:Y-m-d H:i:s'],
    ]);

    // Данные валидны и будет запущен следующий код
    ...
}

public function store() {
    request()->validate([
      // Правила валидации...
    ]);

    // Данные валидны и будет запущен следующий код
    ...
}

public function store() {
    $this->validate(request(), [
      // Правила валидации...
    ]);

    // Данные валидны и будет запущен следующий код
    ...
}

Следует также отметить, что в ответе метод validate будут проверенные данные:

public function store(Request $request) {
    $validatedData = $request->validate([
      'name' => ['required', 'string'],
      'body' => ['required', 'string'],
      'publish_at' => ['required', 'date_format:Y-m-d H:i:s'],
    ]);

    // Я знаю, что ключами в проверенных данных будет только те, что были проверенны успешно, например: name, body, published_at
    $this->articleService->store($validatedData);
}

Или вы можете сделать так:

public function store(Request $request) {
    $request->validate([
      'name' => ['required', 'string'],
      'body' => ['required', 'string'],
      'publish_at' => ['required', 'date_format:Y-m-d H:i:s'],
    ]);

    // Я знаю, что ключами в проверенных данных будет только те, что были проверенны успешно, например: name, body, published_at
    $this->articleService->store($request->only('name', 'body', 'published_at'));
}

Список доступных правил валидации можно найти здесь.

Запросы форм

Если вы хотите извлечь всю валидационную логику из контроллеров, или же одновременно выполнять и авторизацию и валидацию, то Laravel предоставляет вам класс Запроса формы (Form Request).

Вы можете создать класс Запроса формы, используя один из множества встроенных генераторов:

php artisan make:request StoreArticleRequest

Эта команда создаст следующий класс в app/Http/Requests:

class StoreArticleRequest extends FormRequest
{

    public function authorize()
    {
        return true;
    }

    public function rules()
    {
        return [
            //
        ];
    }
}

Класс идёт с двумя методами: authorize and rules.

Authorize

Этот метод позволяет предотвратить запуск кода, если возвращает false. Laravel выбросит ошибку 401.

Пример использования:

public function authorize()
{
    return $this->user()->can('create articles');
}

Rules

Этот метод возвращает массив с правилами, которые мы использовали ранее в контроллере

public function rules()
{
    return [
      'name' => ['required', 'string'],
      'body' => ['required', 'string'],
      'publish_at' => ['required', 'date_format:Y-m-d H:i:s'],
    ];
}

Примечание: Вы можете тапйхинтить в этот метод любые необходимые вам зависимости.

Итак, как же использовать этот класс? Тайпхинтим его прямо в метод контроллера:

public function store(StoreArticleRequest $request) {
    // Валидация успешно пройдена
}

Если валидация не пройдет, то пользователя редиректнет обратно с ошибками, записанными в сессию. Если это был AJAX-запрос, то выдаст ошибку 422 Unprocessable Entity.

Вы можете получить проверенные данные, также как и раньше:

public function store(StoreArticleRequest $request) {
    $validatedData = $request->validated();

    // Добавление в базу данных
    ...
}

Классы кастомных Правил

Если вам не хватает встроенных правил валидации, то вы можете создать своё собственное. Используем одну из команд make:

php artisan make:rule IsValidStateInUSA

Он создаст следующий класс в app/Rules:

class IsValidStateInUSA implements Rule
{

    public function passes($attribute, $value)
    {
        //
    }

    public function message()
    {
        return 'Сообщение об ошибке валидации.';
    }
}

В методе pass находится логика, позволяющая использовать эту проверку. Метод message содержит сообщение, показываемое в случае неудачной проверки.

В нашей проверке IsValidStateInUSA (Это код существующего штата США?), нам нужно, чтобы передаваемый элемент был одним из 50 имеющихся кодов:

class IsValidStateInUSA implements Rule
{

    public function passes($attribute, $value)
    {
        return in_array(strtoupper($value), [
          'AL',
          'AK',
          'AZ',
          ...
        ]);
    }

    public function message()
    {
        return 'Несуществующий код штата США.';
    }
}

Чтобы использовать это правило в контроллере или запросе формы — просто добавляете его вот так:

public function store(Request $request) {
    $request->validate([
      'state' => ['required', new IsValidStateInUSA],
    ]);

    ...
}

Обработка ошибок валидации

Если проверка не пройдена, Laravel автоматически редиректит пользователя обратно, с переменной $errors в сессии.

Создайте файл messages.blade.php и подключите его в свой основной макета:

@if($errors->any())
    <div class="alert alert-danger" role="alert">
        <button type="button" class="close" data-dismiss="alert" aria-label="Close">
            <span aria-hidden="true">×</span>
        </button>

        @foreach($errors->all() as $error)
            {{ $error }}<br/>
        @endforeach
    </div>
@endif

Он покажет все ошибки из сессии или, если вы предпочитаете обрабатывать их по одной, то можете использовать blade-хелпер @error:

@error('title')
    <div class="alert alert-danger">{{ $message }}</div>
@enderror

Переменная $message будет передана ​внутрь тега @error.

Настройка сообщений об ошибках

Вы можете настроить эти сообщения с помощью третьего параметра метода validate:

public function store(Request $request) {
    $this->validate($request, [
        'name' => 'required|string',
        'body' => 'required|string',
        'publish_at' => 'required|date_format:Y-m-d H:i:s'
    ], [
      'name.required' => 'Поле Название статьи обязательно для заполнения',
      'body.required'  => 'Поле Текст статьи обязательно для заполнения',
      'publish_at.date_format' => 'Поле Дата публикации имеет неверный формат'
    ]);

    // Данные валидны и будет запущен следующий код
    ...
}

При работе с Запросом формы можно настроить сообщения об ошибках в методе messages:

public function messages()
{
    return [
 			'name.required' => 'Поле Название статьи обязательно для заполнения',
      'body.required'  => 'Поле Текст статьи обязательно для заполнения',
      'publish_at.date_format' => 'Поле Дата публикации имеет неверный формат'
    ];
}

Самая свежая и подробная документация по валидации в Laravel находится здесь.

Автор: Anthony Rappa
Перевод: Алексей Широков

Задать вопросы по урокам можно на нашем форуме.

Введение

Laravel предлагает несколько подходов для проверки входящих данных вашего приложения. Например, метод validate , доступен для всех входящих HTTP-запросов. Однако мы обсудим и другие подходы к валидации.

Laravel содержит удобные правила валидации, применяемые к данным, включая валидацию на уникальность значения в конкретной таблице базы данных. Мы подробно рассмотрим каждое из этих правил валидации, чтобы вы были знакомы со всеми особенностями валидации Laravel.

Быстрый старт

Чтобы узнать о мощных функциях валидации Laravel, давайте рассмотрим полный пример валидации формы и отображения сообщений об ошибках конечному пользователю. Прочитав этот общий обзор, вы сможете получить представление о том, как проверять данные входящего запроса с помощью Laravel:

Определение маршрутов

Во-первых, предположим, что в нашем файле routes/web.php определены следующие маршруты:

Маршрут GET отобразит форму для пользователя для создания нового сообщения в блоге, а маршрут POST сохранит новое сообщение в базе данных.

Создание контроллера

Теперь давайте взглянем на простой контроллер, который обрабатывает запросы, входящие на эти маршруты. Пока оставим метод store пустым:

Написание логики валидации

Теперь мы готовы заполнить наш метод store логикой для валидации нового сообщения в блоге. Для этого мы будем использовать метод validate , предоставляемый объектом IlluminateHttpRequest . Если правила валидации будут пройдены, то ваш код продолжит нормально выполняться; однако, если проверка не пройдена, то будет создано исключение IlluminateValidationValidationException и соответствующий ответ об ошибке будет автоматически отправлен обратно пользователю.

Если валидации не пройдена во время традиционного HTTP-запроса, то будет сгенерирован ответ-перенаправление на предыдущий URL-адрес. Если входящий запрос является XHR-запросом, то будет возвращен JSON-ответ, содержащий сообщения об ошибках валидации.

Чтобы лучше понять метод validate , давайте вернемся к методу store :

Как видите, правила валидации передаются в метод validate . Не волнуйтесь – все доступные правила валидации задокументированы. Опять же, если проверка не пройдена, то будет автоматически сгенерирован корректный ответ. Если проверка пройдет успешно, то наш контроллер продолжит нормальную работу.

В качестве альтернативы правила валидации могут быть указаны как массивы правил вместо одной строки с разделителями | :

Кроме того, вы можете использовать метод validateWithBag для валидации запроса и сохранения любых сообщений об ошибках в именованную коллекцию ошибок:

Прекращение валидации при возникновении первой ошибки

По желанию можно прекратить выполнение правил валидации для атрибута после первой ошибки. Для этого присвойте атрибуту правило bail :

В этом примере, если правило unique для атрибута title не будет пройдено, то правило max не будет выполняться. Правила будут проверяться в порядке их назначения.

Примечание о вложенных атрибутах

Если входящий HTTP-запрос содержит данные «вложенных» полей, то вы можете указать эти поля в своих правилах валидации, используя «точечную нотацию»:

С другой стороны, если имя вашего поля буквально содержит точку, то вы можете явно запретить ее интерпретацию как часть «точечной нотации», экранировав точку с помощью обратной косой черты:

Отображение ошибок валидации

Итак, что, если поля входящего запроса не проходят указанные правила валидации? Как упоминалось ранее, Laravel автоматически перенаправит пользователя обратно в его предыдущее местоположение. Кроме того, все ошибки валидации и входящие данные запроса будут автоматически записаны в сессию.

Переменная $errors используется во всех шаблонах вашего приложения благодаря посреднику IlluminateViewMiddlewareShareErrorsFromSession , который включен в группу посредников web . Пока применяется этот посредник, в ваших шаблонах всегда будет доступна переменная $errors , что позволяет вам предполагать, что переменная $errors всегда определена и может безопасно использоваться. Переменная $errors будет экземпляром IlluminateSupportMessageBag . Для получения дополнительной информации о работе с этим объектом ознакомьтесь с его документацией.

Итак, в нашем примере пользователь будет перенаправлен на метод нашего контроллера create , в случае, если валидация завершится неудачно, что позволит нам отобразить сообщения об ошибках в шаблоне:

Корректировка сообщений об ошибках

Каждое встроенное правило валидации Laravel содержит сообщение об ошибке, которое находится в файле resources/lang/en/validation.php вашего приложения. В этом файле вы найдете запись о переводе для каждого правила валидации. Вы можете изменять или модифицировать эти сообщения в зависимости от потребностей вашего приложения.

Кроме того, вы можете скопировать этот файл в каталог перевода другого языка, чтобы перевести сообщения на язык вашего приложения. Чтобы узнать больше о локализации Laravel, ознакомьтесь с полной документацией по локализации.

XHR-запросы и валидация

В этом примере мы использовали традиционную форму для отправки данных в приложение. Однако, многие приложения получают запросы XHR с фронтенда с использованием JavaScript. При использовании метода validate , во время выполнения XHR-запроса, Laravel не будет генерировать ответ-перенаправление. Вместо этого Laravel генерирует JSON-ответ, содержащий все ошибки валидации. Этот ответ JSON будет отправлен с кодом 422 состояния HTTP.

Директива @error

Вы можете использовать директиву @error Blade, чтобы быстро определить, существуют ли сообщения об ошибках валидации для конкретного атрибута, включая сообщения об ошибках в именованной коллекции ошибок. В директиве @error вы можете вывести содержимое переменной $message для отображения сообщения об ошибке:

Если вы используете именованные коллекции ошибок, вы можете передать имя коллекции ошибок в качестве второго аргумента директивы @error :

Повторное заполнение форм

Когда Laravel генерирует ответ-перенаправление из-за ошибки валидации, фреймворк автоматически краткосрочно записывает все входные данные запроса в сессию. Это сделано для того, чтобы вы могли удобно получить доступ к входным данным во время следующего запроса и повторно заполнить форму, которую пользователь попытался отправить.

Чтобы получить входные данные предыдущего запроса, вызовите метод old экземпляра IlluminateHttpRequest . Метод old извлечет ранее записанные входные данные из сессии:

Laravel также содержит глобального помощника old . Если вы показываете входные данные прошлого запроса в шаблоне Blade, то удобнее использовать помощник old для повторного заполнения формы. Если для какого-то поля не были предоставлены данные в прошлом запросе, то будет возвращен null :

Примечание о необязательных полях

По умолчанию Laravel содержит посредников AppHttpMiddlewareTrimStrings и AppHttpMiddlewareConvertEmptyStringsToNull в глобальном стеке посредников вашего приложения. Эти посредники перечислены в классе AppHttpKernel . Первый из упомянутых посредников будет автоматически обрезать все входящие строковые поля запроса, а второй – конвертировать любые пустые строковые поля в null . Из-за этого вам часто нужно будет помечать ваши «необязательные» поля запроса как nullable , если вы не хотите, чтобы валидатор не считал такие поля недействительными. Например:

В этом примере мы указываем, что поле publish_at может быть либо null , либо допустимым представлением даты. Если модификатор nullable не добавлен в определение правила, валидатор сочтет null недопустимой датой.

Валидация запроса формы

Создание запросов формы

Для более сложных сценариев валидации вы можете создать «запрос формы». Запрос формы – это ваш класс запроса, который инкапсулирует свою собственную логику валидации и авторизации. Чтобы сгенерировать новый запрос формы, используйте команду make:request Artisan:

Эта команда поместит новый класс запроса формы в каталог app/Http/Requests вашего приложения. Если этот каталог не существует в вашем приложении, то Laravel предварительно создаст его, когда вы запустите команду make:request . Каждый запрос формы, созданный Laravel, имеет два метода: authorize и rules .

Как вы могли догадаться, метод authorize проверяет, может ли текущий аутентифицированный пользователь выполнить действие, представленное запросом, а метод rules возвращает правила валидации, которые должны применяться к данным запроса:

Вы можете объявить любые зависимости, которые вам нужны, в сигнатуре метода rules . Они будут автоматически извлечены через контейнер служб Laravel.

Итак, как анализируются правила валидации? Все, что вам нужно сделать, это объявить зависимость от запроса в методе вашего контроллера. Входящий запрос формы проверяется до вызова метода контроллера, что означает, что вам не нужно загромождать контроллер какой-либо логикой валидации:

При неуспешной валидации будет сгенерирован ответ-перенаправление, чтобы отправить пользователя обратно в его предыдущее местоположение. Ошибки также будут краткосрочно записаны в сессию, чтобы они были доступны для отображения. Если запрос был XHR-запросом, то пользователю будет возвращен HTTP-ответ с кодом состояния 422, включая JSON-представление ошибок валидации.

Добавление хуков after для запросов форм

Если вы хотите добавить хук валидации after для запроса формы, то вы можете использовать метод withValidator . Этот метод получает полностью инициированный валидатор, что позволяет вам вызвать любой из его методов до того, как правила валидации будут фактически проанализированы:

Прекращение валидации после первой неуспешной проверки

Добавив свойство $stopOnFirstFailure вашему классу запроса, вы можете сообщить валидатору, что он должен прекратить валидацию всех атрибутов после возникновения первой ошибки валидации:

Настройка ответа-перенаправления

Как обсуждалось ранее, будет сгенерирован ответ-перенаправление, чтобы отправить пользователя обратно в его предыдущее местоположение, когда проверка формы запроса не удалась. Однако вы можете настроить это поведение. Для этого определите свойство $redirect в вашем классе запроса:

Или, если вы хотите перенаправить пользователей на именованный маршрут, вы можете вместо этого определить свойство $redirectRoute :

Авторизация запросов

Класс запроса формы также содержит метод authorize . В рамках этого метода вы можете определить, действительно ли аутентифицированный пользователь имеет право изменять текущий ресурс. Например, вы можете определить, действительно ли пользователь владеет комментарием в блоге, который он пытается обновить. Скорее всего, вы будете взаимодействовать с вашими шлюзами и политиками авторизации в этом методе:

Поскольку все запросы формы расширяют базовый класс запросов Laravel, мы можем использовать метод user для доступа к текущему аутентифицированному пользователю. Также обратите внимание на вызов метода route в приведенном выше примере. Этот метод обеспечивает вам доступ к параметрам URI, определенным для вызываемого маршрута, таким как параметр в приведенном ниже примере:

Поэтому, если ваше приложение использует привязку модели к маршруту, ваш код можно сделать еще более кратким, обратившись к разрешенной модели в качестве свойства запроса:

Если метод authorize возвращает false , то будет автоматически возвращен HTTP-ответ с кодом состояния 403, и метод вашего контроллера не будет выполнен.

Если вы планируете обрабатывать логику авторизации для запроса в другой части вашего приложения, то вы можете просто вернуть true из метода authorize :

Вы можете объявить любые зависимости, которые вам нужны, в сигнатуре метода authorize . Они будут автоматически извлечены через контейнер служб Laravel.

Корректировка сообщений об ошибках

Вы можете изменить сообщения об ошибках, используемые в запросе формы, переопределив метод messages . Этот метод должен возвращать массив пар атрибут / правило и соответствующие им сообщения об ошибках:

Корректировка атрибутов валидации

Многие сообщения об ошибках встроенных правил валидации Laravel содержат заполнитель :attribute . Если вы хотите, чтобы заполнитель :attribute вашего сообщения валидации был заменен другим именем атрибута, то вы можете указать собственные имена, переопределив метод attributes . Этот метод должен возвращать массив пар атрибут / имя:

Подготовка входящих данных для валидации

Если вам необходимо подготовить или обработать какие-либо данные из запроса перед применением правил валидации, то вы можете использовать метод prepareForValidation :

Создание валидатора по требованию

Если вы не хотите использовать метод validate запроса, то вы можете создать экземпляр валидатора вручную, используя фасад Validator . Метод make фасада генерирует новый экземпляр валидатора:

Первым аргументом, переданным методу make , являются проверяемые данные. Второй аргумент – это массив правил валидации, которые должны применяться к данным.

После определения того, что запрос не прошел валидацию с помощью метода fails , вы можете использовать метод withErrors для передачи сообщений об ошибках в сессию. При использовании этого метода переменная $errors будет автоматически передана вашим шаблонам после перенаправления, что позволит вам легко отобразить их обратно пользователю. Метод withErrors принимает экземпляр валидатора, экземпляр MessageBag или обычный массив PHP.

Прекращение валидации после первой неуспешной проверки

Метод stopOnFirstFailure проинформирует валидатор о том, что он должен прекратить валидацию всех атрибутов после возникновения первой ошибки валидации:

Автоматическое перенаправление

Если вы хотите создать экземпляр валидатора вручную, но по-прежнему воспользоваться преимуществами автоматического перенаправления, предлагаемого методом validate HTTP-запроса, вы можете вызвать метод validate созданного экземпляра валидатора. Пользователь будет автоматически перенаправлен или, в случае запроса XHR, будет возвращен ответ JSON, если валидация будет не успешной:

Вы можете использовать метод validateWithBag для сохранения сообщений об ошибках в именованной коллекции ошибок, если валидация будет не успешной:

Именованные коллекции ошибок

Если у вас есть несколько форм на одной странице, то вы можете задать имя экземпляру MessageBag , содержащий ошибки валидации, что позволит вам получать сообщения об ошибках для конкретной формы. Чтобы добиться этого, передайте имя в качестве второго аргумента в метод withErrors :

Затем, вы можете получить доступ к именованному экземпляру MessageBag из переменной $errors :

Корректировка сообщений об ошибках

При необходимости вы можете предоставить собственные сообщения об ошибках, которые должен использовать экземпляр валидатора вместо сообщений об ошибках по умолчанию, предоставляемых Laravel. Есть несколько способов указать собственные сообщения. Во-первых, вы можете передать собственные сообщения в качестве третьего аргумента методу Validator::make :

В этом примере заполнитель :attribute будет заменен фактическим именем проверяемого поля. Вы также можете использовать другие заполнители в сообщениях валидатора. Например:

Указание пользовательского сообщения для конкретного атрибута

По желанию можно указать собственное сообщение об ошибке только для определенного атрибута. Вы можете сделать это, используя «точечную нотацию». Сначала укажите имя атрибута, а затем правило:

Указание пользовательских имен для атрибутов

Многие сообщения об ошибках встроенных правил валидации Laravel содержат заполнитель :attribute , который заменяется именем проверяемого поля или атрибута. Чтобы указать собственные значения, используемые для замены этих заполнителей для конкретных полей, вы можете передать массив ваших атрибутов в качестве четвертого аргумента методу Validator::make :

Хук валидатора After

Вы также можете определить замыкания, которые будут запускаться после завершения валидации. Это позволяет легко выполнять дальнейшую валидацию и даже добавлять сообщения об ошибках в коллекцию сообщений. Вызовите метод after на экземпляре валидатора:

Работа с проверенными данными

После проверки данных входящего запроса с помощью запроса формы или вручную созданного экземпляра валидатора вы можете получить данные входящего запроса, которые действительно прошли проверку. Этого можно добиться несколькими способами. Во-первых, вы можете вызвать метод validated в запросе формы или экземпляре валидатора. Этот метод возвращает массив данных, которые были проверены:

В качестве альтернативы вы можете вызвать метод safe в запросе формы или экземпляре валидатора. Этот метод возвращает экземпляр IlluminateSupportValidatedInput . Этот объект предоставляет методы only , except , и all для получения подмножества проверенных данных или всего массива проверенных данных:

Кроме того, экземпляр IlluminateSupportValidatedInput может быть проитерирован и доступен как массив:

Если вы хотите добавить дополнительные поля к проверенным данным, вы можете вызвать метод merge :

Если вы хотите получить проверенные данные в виде экземпляра collection вы можете вызвать метод collect :

Работа с сообщениями об ошибках

После вызова метода errors экземпляр Validator , вы получите экземпляр IlluminateSupportMessageBag , который имеет множество удобных методов для работы с сообщениями об ошибках. Переменная $errors , которая автоматически становится доступной для всех шаблонов, также является экземпляром класса MessageBag .

Получение первого сообщения об ошибке для поля

Чтобы получить первое сообщение об ошибке для указанного поля, используйте метод first :

Получение всех сообщений об ошибках для поля

Если вам нужно получить массив всех сообщений для указанного поля, используйте метод get :

Если вы проверяете массив полей формы, то вы можете получить все сообщения для каждого из элементов массива, используя символ * :

Получение всех сообщений об ошибках для всех полей

Чтобы получить массив всех сообщений для всех полей, используйте метод all :

Определение наличия сообщений для поля

Метод has используется для определения наличия сообщений об ошибках для указанного поля:

Указание пользовательских сообщений в языковых файлах

Каждое встроенное правило валидации Laravel содержит сообщение об ошибке, которое находится в файле resources/lang/en/validation.php вашего приложения. В этом файле вы найдете запись о переводе для каждого правила валидации. Вы можете изменять или модифицировать эти сообщения в зависимости от потребностей вашего приложения.

Кроме того, вы можете скопировать этот файл в каталог перевода другого языка, чтобы перевести сообщения на язык вашего приложения. Чтобы узнать больше о локализации Laravel, ознакомьтесь с полной документацией по локализации.

Указание пользовательского сообщения для конкретного атрибута

Вы можете изменить сообщения об ошибках, используемые для указанных комбинаций атрибутов и правил в языковых файлах валидации вашего приложения. Для этого добавьте собственные сообщения в массив custom языкового файла resources/lang/xx/validation.php вашего приложения:

Указание атрибутов в языковых файлах

Многие сообщения об ошибках встроенных правил валидации Laravel содержат заполнитель :attribute , который заменяется именем проверяемого поля или атрибута. Если вы хотите, чтобы часть :attribute вашего сообщения валидации была заменена собственным значением, то вы можете указать имя настраиваемого атрибута в массиве attributes вашего языкового файла resources/lang/xx/validation.php :

Указание пользовательских имен для атрибутов в языковых файлах

Некоторые сообщения об ошибках встроенных правил валидации Laravel содержат заполнитель :value , который заменяется текущим значением атрибута запроса. Однако, иногда вам может понадобиться заменить часть :value вашего сообщения валидации на собственное значение. Например, рассмотрим следующее правило, которое указывает, что номер кредитной карты требуется обязательно, если для параметра payment_type установлено значение cc :

Если это правило валидации не будет пройдено, то будет выдано следующее сообщение об ошибке:

Вместо того чтобы отображать cc в качестве значения типа платежа, вы можете указать более удобное для пользователя представление значения в вашем языковом файле resources/lang/xx/validation.php , определив массив values :

После определения этого значения правило валидации выдаст следующее сообщение об ошибке:

Доступные правила валидации

Ниже приведен список всех доступных правил валидации и их функций:

accepted

Проверяемое поле должно иметь значение «yes» , «on» , 1 , или true . Применяется для валидации принятия «Условий использования» или аналогичных полей.

accepted_if:anotherfield,value.

Проверяемое поле должно иметь значение «yes» , «on» , 1 , или true , если другое проверяемое поле равно указанному значению. Это полезно для валидации принятия «Условий использования» или аналогичных полей.

active_url

Проверяемое поле должно иметь допустимую запись A или AAAA в соответствии с функцией dns_get_record PHP. Имя хоста указанного URL извлекается с помощью PHP-функции parse_url перед передачей в dns_get_record .

after:date

Проверяемое поле должно иметь значение после указанной даты. Даты будут переданы в функцию strtotime PHP для преобразования в действительный экземпляр DateTime :

Вместо передачи строки даты, которая будет проанализирована с помощью strtotime , вы можете указать другое поле для сравнения с датой:

after_or_equal:date

Проверяемое поле должно иметь значение после указанной даты или равное ей. Для получения дополнительной информации см. правило after.

alpha

Проверяемое поле должно состоять полностью из букв.

alpha_dash

Проверяемое поле может содержать буквенно-цифровые символы, а также дефисы и подчеркивания.

alpha_num

Проверяемое поле должно состоять полностью из буквенно-цифровых символов.

array

Проверяемое поле должно быть массивом PHP.

Когда для правила array предоставляются дополнительные значения, каждый ключ во входном массиве должен присутствовать в списке значений, предоставленных правилу. В следующем примере ключ admin во входном массиве недействителен, поскольку он не содержится в списке значений, предоставленных правилу array :

В общем, вы всегда должны указывать ключи массива, которые могут присутствовать в вашем массиве. В противном случае методы валидатора validate и validated вернут все проверенные данные, включая массив и все его ключи, даже если эти ключи не были проверены другими правилами проверки вложенных массивов.

Если вы хотите, вы можете указать валидатору Laravel никогда не включать непроверенные ключи массива в «проверенные» данные, которые он возвращает, даже если вы используете правило array без указания списка разрешенных ключей. Для этого вы можете вызвать метод валидатора excludeUnvalidatedArrayKeys в методе boot класса AppServiceProvider вашего приложения. После этого валидатор будет включать ключи массива в «проверенные» данные, которые он возвращает, только если эти ключи были специально проверены с помощью правил вложенных массивов:

Остановить дальнейшее применение правил валидации атрибута после первой неуспешной проверки.

В отличие от правила bail , которое прекращает дальнейшую валидацию только конкретного поля, метод stopOnFirstFailure сообщит валидатору, что он должен прекратить дальнейшую валидацию всех атрибутов при возникновении первой ошибке:

before:date

Проверяемое поле должно быть значением, предшествующим указанной дате. Даты будут переданы в функцию PHP strtotime для преобразования в действительный экземпляр DateTime . Кроме того, как и в правиле after , имя другого проверяемого поля может быть указано в качестве значения date .

before_or_equal:date

Проверяемое поле должно иметь значение, предшествующее указанной дате или равное ей. Даты будут переданы в функцию PHP strtotime для преобразования в действительный экземпляр DateTime . Кроме того, как и в правиле after , имя другого проверяемого поля может быть указано в качестве значения date .

between:min,max

Проверяемое поле должно иметь размер между указанными min и max. Строки, числа, массивы и файлы оцениваются так же, как и в правиле size .

boolean

Проверяемое поле должно иметь возможность преобразования в логическое значение. Допустимые значения: true , false , 1 , 0 , «1» , и «0» .

confirmed

Проверяемое поле должно иметь совпадающее поле _confirmation . Например, если проверяемое поле – password , то поле password_confirmation также должно присутствовать во входящих данных.

current_password

Проверяемое поле должно соответствовать паролю аутентифицированного пользователя. Вы можете указать охранника аутентификации используя первый параметр правила:

Проверяемое поле должно быть действительной, не относительной датой в соответствии с функцией strtotime PHP.

date_equals:date

Проверяемое поле должно быть равно указанной дате. Даты будут переданы в функцию strtotime PHP для преобразования в действительный экземпляр DateTime .

date_format:format

Проверяемое поле должно соответствовать переданному format. При валидации поля следует использовать либо date , либо date_format , а не то и другое вместе. Это правило валидации поддерживает все форматы, поддерживаемые классом DateTime PHP.

declined

Проверяемое поле должно иметь значение «no» , «off» , 0 , или false .

declined_if:anotherfield,value.

Проверяемое поле должно иметь значение «no» , «off» , 0 , or false , если другое проверяемое поле равно указанному значению.

different:field

Проверяемое поле должно иметь значение, отличное от field.

digits:value

Проверяемое поле должно быть числовым и иметь точную длину value.

digits_between:min,max

Проверяемое поле должно быть числовым и иметь длину между переданными min и max.

dimensions

Проверяемый файл должен быть изображением, отвечающим ограничениям размеров, указанным в параметрах правила:

Доступные ограничения: min_width, max_width, min_height, max_height, width, height, ratio.

Ограничение ratio должно быть представлено как ширина, разделенная на высоту. Это может быть указано дробью вроде 3/2 или числом с плавающей запятой, например 1.5 :

Поскольку это правило требует нескольких аргументов, вы можете использовать метод Rule::dimensions для гибкости составления правила:

distinct

При валидации массивов проверяемое поле не должно иметь повторяющихся значений:

По умолчанию правило distinct использует гибкое сравнение переменных. Чтобы использовать жесткое сравнение, вы можете добавить параметр strict в определение правила валидации:

Вы можете добавить ignore_case к аргументам правила валидации, чтобы правило игнорировало различия в использовании регистра букв:

email

Проверяемое поле должно быть отформатировано как адрес электронной почты. Это правило валидации использует пакет egulias/email-validator для проверки адреса электронной почты. По умолчанию применяется валидатор RFCValidation , но вы также можете применить другие стили валидации:

В приведенном выше примере будут применяться проверки RFCValidation и DNSCheckValidation . Вот полный список стилей проверки, которые вы можете применить:

• rfc : RFCValidation
• strict : NoRFCWarningsValidation
• dns : DNSCheckValidation
• spoof : SpoofCheckValidation
• filter : FilterEmailValidation

Валидатор filter , который использует функцию filter_var PHP, поставляется с Laravel и применялся по умолчанию до Laravel версии 5.8.

Валидаторы dns и spoof требуют расширения intl PHP.

ends_with:foo,bar.

Проверяемое поле должно заканчиваться одним из указанных значений.

Правило Enum это правило на основе класса, которое проверяет, содержит ли проверяемое поле допустимое значение перечисления. Правило Enum принимает имя перечисления как единственный аргумент конструктора:

Перечисления доступны только в PHP 8.1+.

exclude

Проверяемое поле будет исключено из данных запроса, возвращаемых методами validate и validated .

exclude_if:anotherfield,value

Проверяемое поле будет исключено из данных запроса, возвращаемых методами validate и validated , если поле anotherfield равно value.

exclude_unless:anotherfield,value

Проверяемое поле будет исключено из данных запроса, возвращаемых методами validate и validated , если поле anotherfield не равно value. При value равном null ( exclude_unless: name, null ) проверяемое поле будет исключено, если поле сравнения либо не равно null , либо отсутствует в данных запроса.

exclude_without:anotherfield

Проверяемое поле будет исключено из данных запроса, возвращаемых методами validate и validated если поле anotherfield отсутствует.

exists:table,column

Проверяемое поле должно существовать в указанной таблице базы данных.

Основы использования правила Exists

Если параметр column не указан, будет использоваться имя поля. Таким образом, в этом случае правило будет проверять, что таблица базы данных states содержит запись со значением столбца state , равным значению атрибута запроса state .

Указание пользовательского имени столбца

Вы можете явно указать имя столбца базы данных, которое должно использоваться правилом валидации, поместив его после имени таблицы базы данных:

Иногда требуется указать конкретное соединение с базой данных, которое будет использоваться для запроса exists . Вы можете сделать это, добавив имя подключения к имени таблицы:

Вместо того чтобы указывать имя таблицы напрямую, вы можете указать модель Eloquent, которая должна использоваться для определения имени таблицы:

Если вы хотите использовать свой запрос, выполняемый правилом валидации, то вы можете использовать класс Rule для гибкости определения правила. В этом примере мы также укажем правила валидации в виде массива вместо использования символа | для их разделения:

Проверяемое поле должно быть успешно загруженным на сервер файлом.

filled

Проверяемое поле не должно быть пустым, если оно присутствует.

gt:field

Проверяемое поле должно быть больше указанного field. Два поля должны быть одного типа. Строки, числа, массивы и файлы оцениваются с использованием тех же соглашений, что и в правиле size .

gte:field

Проверяемое поле должно быть больше или равно указанному field. Два поля должны быть одного типа. Строки, числа, массивы и файлы оцениваются с использованием тех же соглашений, что и в правиле size .

image

Проверяемый файл должен быть изображением (jpg, jpeg, png, bmp, gif, svg или webp).

in:foo,bar.

Проверяемое поле должно быть включено в указанный список значений. Поскольку это правило часто требует, чтобы вы «объединяли» массив, то метод Rule::in можно использовать для гибкого построения правила:

Когда правило in комбинируется с правилом array каждое значение во входном массиве должно присутствовать в списке значений, предоставленных правилу in . В следующем примере код аэропорта LAS во входном массиве недействителен, так как он не содержится в списке аэропортов, предоставленном правилу in :

in_array:anotherfield.*

Проверяемое поле должно существовать в значениях anotherfield.

integer

Проверяемое поле должно быть целым числом.

Это правило валидации не проверяет, что значение поля относится к типу переменной integer , а только что значение поля относится к типу, принятому правилом FILTER_VALIDATE_INT PHP. Если вам нужно проверить значение поля в качестве числа, используйте это правило в сочетании с правилом валидации numeric .

Проверяемое поле должно быть IP-адресом.

Проверяемое поле должно быть адресом IPv4.

Проверяемое поле должно быть адресом IPv6.

Проверяемое поле должно быть допустимой строкой JSON.

lt:field

Проверяемое поле должно быть меньше переданного field. Два поля должны быть одного типа. Строки, числа, массивы и файлы оцениваются с использованием тех же соглашений, что и в правиле size .

lte:field

Проверяемое поле должно быть меньше или равно переданному field. Два поля должны быть одного типа. Строки, числа, массивы и файлы оцениваются с использованием тех же соглашений, что и в правиле size .

max:value

Проверяемое поле должно быть меньше или равно максимальному value. Строки, числа, массивы и файлы оцениваются с использованием тех же соглашений, что и в правиле size .

mimetypes:text/plain.

Проверяемый файл должен соответствовать одному из указанных MIME-типов:

Чтобы определить MIME-тип загруженного файла, содержимое файла будет прочитано, и фреймворк попытается угадать MIME-тип, который может отличаться от типа, предоставленного клиентом.

mimes:foo,bar.

Проверяемый файл должен иметь MIME-тип, соответствующий одному из перечисленных расширений.

Основы использования правила MIME

Несмотря на то, что вам нужно только указать расширения, это правило фактически проверяет MIME-тип файла, читая содержимое файла и угадывая его MIME-тип. Полный список типов MIME и соответствующих им расширений можно найти по следующему адресу:

min:value

Проверяемое поле должно иметь минимальное значение value. Строки, числа, массивы и файлы оцениваются с использованием тех же соглашений, что и в правиле size .

multiple_of:value

Проверяемое поле должно быть кратным value.

not_in:foo,bar.

Проверяемое поле не должно быть включено в переданный список значений. Метод Rule::notIn используется для гибкого построения правила:

not_regex:pattern

Проверяемое поле не должно соответствовать переданному регулярному выражению.

Под капотом это правило использует функцию preg_match , поэтому указанный шаблон должен подчиняться требованиям, предъявляемым к ней, а также включать допустимые разделители. Например: ’email’ => ‘not_regex:/^.+$/i’ .

При использовании шаблонов regex / not_regex может потребоваться указать ваши правила валидации с использованием массива вместо использования разделителей | , особенно если регулярное выражение содержит символ | .

nullable

Проверяемое поле может быть null .

numeric

Проверяемое поле должно быть числовым.

password

Проверяемое поле должно соответствовать паролю аутентифицированного пользователя.

Это правило было переименовано в current_password с намерением удалить его в Laravel 9. Пожалуйста, используйте вместо него правило Current Password.

present

Проверяемое поле должно присутствовать во входных данных, но может быть пустым.

prohibited

Проверяемое поле должно быть пустым или отсутствовать.

prohibited_if:anotherfield,value.

Проверяемое поле должно быть пустым или отсутствовать, если поле anotherfield равно любому value.

prohibited_unless:anotherfield,value.

Проверяемое поле должно быть пустым или отсутствовать, если поле anotherfield не равно какому-либо value.

prohibits:anotherfield.

Если проверяемое поле присутствует, никакие поля в anotherfield не могут присутствовать, даже если они пустые.

regex:pattern

Проверяемое поле должно соответствовать переданному регулярному выражению.

Под капотом это правило использует функцию preg_match , поэтому указанный шаблон должен подчиняться требованиям, предъявляемым к ней, а также включать допустимые разделители. Например: ’email’ => ‘regex:/^.+@.+$/i’ .

При использовании шаблонов regex / not_regex может потребоваться указать ваши правила валидации с использованием массива вместо использования разделителей | , особенно если регулярное выражение содержит символ | .

required

Проверяемое поле должно присутствовать во входных данных и не быть пустым. Поле считается «пустым», если выполняется одно из следующих условий:

• Значение поля равно null .
• Значение поля – пустая строка.
• Значение поля представляет собой пустой массив или пустой объект, реализующий интерфейс Countable .
• Значение поля – загружаемый файл, но без пути.

required_if:anotherfield,value.

Проверяемое поле должно присутствовать и не быть пустым, если поле anotherfield равно любому value.

Если вы хотите создать более сложное условие для правила required_if , вы можете использовать метод Rule::requiredIf . Этот метод принимает логическое значение или замыкание. При выполнении замыкания оно должно возвращать true или false , чтобы указать, обязательно ли проверяемое поле:

required_unless:anotherfield,value.

Проверяемое поле должно присутствовать и не быть пустым, если поле anotherfield не равно какому-либо value. Это также означает, что в данных запроса должно присутствовать anotherfield, если value не имеет значения null . Если value равно null ( required_unless: name, null ), проверяемое поле будет обязательным, если поле сравнения не равно null или поле сравнения отсутствует в данных запроса.

required_with:foo,bar.

Проверяемое поле должно присутствовать и не быть пустым, только если любое из других указанных полей присутствует и не является пустым.

required_with_all:foo,bar.

Проверяемое поле должно присутствовать и не быть пустым, только если все другие указанные поля присутствуют и не являются пустыми.

required_without:foo,bar.

Проверяемое поле должно присутствовать и не быть пустым, только когда любое из других указанных полей является пустым или отсутствует.

required_without_all:foo,bar.

Проверяемое поле должно присутствовать и не быть пустым, только когда все другие указанные поля являются пустыми или отсутствуют.

same:field

Переданное field должно соответствовать проверяемому полю.

size:value

Проверяемое поле должно иметь размер, соответствующий переданному value. Для строковых данных value соответствует количеству символов. Для числовых данных value соответствует переданному целочисленному значению (атрибут также должен иметь правило numeric или integer ). Для массива size соответствует count массива. Для файлов size соответствует размеру файла в килобайтах. Давайте посмотрим на несколько примеров:

starts_with:foo,bar.

Проверяемое поле должно начинаться с одного из указанных значений.

string

Проверяемое поле должно быть строкой. Если вы хотите, чтобы поле также могло быть null , вы должны назначить этому полю правило nullable .

timezone

Проверяемое поле должно быть допустимым идентификатором часового пояса в соответствии с функцией timezone_identifiers_list PHP.

unique:table,column

Проверяемое поле не должно существовать в указанной таблице базы данных.

Указание пользовательского имени таблицы / имени столбца:

Вместо того чтобы указывать имя таблицы напрямую, вы можете указать модель Eloquent, которая должна использоваться для определения имени таблицы:

Параметр column используется для указания соответствующего столбца базы данных поля. Если опция column не указана, будет использоваться имя проверяемого поля.

Указание пользовательского соединения базы данных

Иногда требуется указать конкретное соединение для запросов к базе данных, выполняемых валидатором. Для этого вы можете добавить имя подключения к имени таблицы:

Принудительное игнорирование правилом Unique конкретного идентификатора:

Иногда вы можете проигнорировать конкретный идентификатор во время валидации unique . Например, рассмотрим страницу «Обновления профиля», которая включает имя пользователя, адрес электронной почты и местоположение. Вероятно, вы захотите убедиться, что адрес электронной почты уникален. Однако, если пользователь изменяет только поле имени, а не поле электронной почты, то вы не захотите, чтобы выдавалась ошибка валидация, поскольку пользователь уже является владельцем рассматриваемого адреса электронной почты.

Чтобы указать валидатору игнорировать идентификатор пользователя, мы воспользуемся классом Rule для гибкого определения правила. В этом примере мы также укажем правила валидации в виде массива вместо использования символа | для их разделения:

Вы никогда не должны передавать какое-либо введенное пользователем значение из запроса в метод ignore . Вместо этого вы должны передавать только сгенерированный системой уникальный идентификатор, такой как автоинкрементный идентификатор или UUID экземпляра модели Eloquent. В противном случае ваше приложение будет уязвимо для атаки с использованием SQL-инъекции.

Вместо того чтобы передавать значение ключа модели методу ignore , вы также можете передать весь экземпляр модели. Laravel автоматически извлечет ключ из модели:

Если ваша таблица использует имя столбца с первичным ключом, отличное от id , то вы можете указать имя столбца при вызове метода ignore :

По умолчанию правило unique проверяет уникальность столбца, совпадающего с именем проверяемого атрибута. Однако вы можете передать другое имя столбца в качестве второго аргумента метода unique :

Добавление дополнительных выражений Where:

Вы можете указать дополнительные условия запроса, изменив запрос с помощью метода where . Например, давайте добавим условие запроса, ограничивающее область запроса только поиском записями, у которых значение столбца account_id равно 1 :

Проверяемое поле должно быть действительным URL.

Проверяемое поле должно быть действительным универсальным уникальным идентификатором (UUID) RFC 4122 (версии 1, 3, 4 или 5).

Условное добавление правил

Пропуск валидации при определенных значениях полей

По желанию можно не проверять конкретное поле, если другое поле имеет указанное значение. Вы можете сделать это, используя правило валидации exclude_if . В этом примере поля appointment_date и doctor_name не будут проверяться, если поле has_appointment имеет значение false :

В качестве альтернативы вы можете использовать правило exclude_unless , чтобы не проверять конкретное поле, если другое поле не имеет указанного значения:

Валидация при условии наличия

По желанию можно выполнить валидацию поля, только если это поле присутствует в проверяемых данных. Чтобы этого добиться, добавьте правило sometimes в свой список правил:

В приведенном выше примере поле email будет проверено, только если оно присутствует в массиве $request->all() .

Если вы пытаетесь проверить поле, которое всегда должно присутствовать, но может быть пустым, ознакомьтесь с этим примечанием о необязательных полях.

Комплексная условная проверка

Иногда вы можете добавить правила валидации, основанные на более сложной условной логике. Например, вы можете потребовать обязательного присутствия переданного поля только в том случае, если другое поле имеет значение больше 100. Или вам может потребоваться, чтобы два поля имели указанное значение только при наличии другого поля. Добавление этих правил валидации не должно вызывать затруднений. Сначала создайте экземпляр Validator со своими статическими правилами, которые будут неизменными:

Предположим, что наше веб-приложение предназначено для коллекционеров игр. Если коллекционер игр регистрируется в нашем приложении и у него есть более 100 игр, мы хотим, чтобы он объяснил, почему у него так много игр. Например, возможно, они владеют магазином по перепродаже игр или, может быть, им просто нравится коллекционировать игры. Чтобы условно добавить это требование, мы можем использовать метод sometimes экземпляра Validator :

Первый аргумент, переданный методу sometimes – это имя поля, которое мы условно проверяем. Второй аргумент – это список правил, которые мы хотим добавить. Если замыкание, переданное в качестве третьего аргумента, возвращает true , то правила будут добавлены. Этот метод упрощает создание сложных условных проверок. Вы даже можете добавить условные проверки сразу для нескольких полей:

Параметр $input , переданный вашему замыканию, будет экземпляром IlluminateSupportFluent и может использоваться при валидации для доступа к вашим входящим данным и файлам запроса.

Комплексная условная проверка массива

Иногда вам может потребоваться проверить поле на основе другого поля в том же вложенном массиве, индекс которого вам неизвестен. В этих ситуациях вы можете позволить вашему замыканию получить второй аргумент, который будет текущим отдельным элементом в проверяемом массиве:

Подобно переданному в замыкание параметру $input , параметр $item является экземпляром IlluminateSupportFluent , когда значение атрибута является массивом; в противном случае это строка.

Валидация массивов

Правило array , как это уже обсуждалось выше, принимает список разрешенных ключей массива. Если в массиве присутствуют какие-либо дополнительные ключи, проверка не удастся:

В общем, вы всегда должны указывать ключи массива, которые могут присутствовать в вашем массиве. В противном случае методы валидатора validate и validated вернут все проверенные данные, включая массив и все его ключи, даже если эти ключи не были проверены другими правилами проверки вложенных массивов.

Исключение непроверенных ключей массива

Если вы хотите, вы можете указать валидатору Laravel никогда не включать непроверенные ключи массива в «проверенные» данные, которые он возвращает, даже если вы используете правило array без указания списка разрешенных ключей. Для этого вы можете вызвать метод валидатора excludeUnvalidatedArrayKeys в методе boot класса AppServiceProvider вашего приложения. После этого валидатор будет включать ключи массива в «проверенные» данные, которые он возвращает, только если эти ключи были специально проверены с помощью правил вложенных массивов:

Проверка входных данных вложенного массива

Проверка полей ввода формы на основе массива не должна быть проблемой. Вы можете использовать «точечную нотацию» для валидации атрибутов в массиве. Например, если входящий HTTP-запрос содержит поле photos[profile] , вы можете проверить его следующим образом:

Вы также можете проверить каждый элемент массива. Например, чтобы убедиться, что каждое электронное письмо в переданном поле ввода массива уникально, вы можете сделать следующее:

Точно так же вы можете использовать символ * при указании пользовательских сообщений в ваших языковых файлах, что упрощает использование одного сообщения валидации для полей на основе массива:

Валидация паролей

Чтобы гарантировать, что пароли имеют достаточный уровень сложности, вы можете использовать объект правила laravel Password :

Объект правила Password позволяет вам легко настроить требования к сложности пароля для вашего приложения, например указать, что для паролей требуется хотя бы одна буква, цифра, символ или символы со смешанным регистром:

Кроме того, вы можете убедиться, что пароль не был скомпрометирован в результате утечки данных публичного пароля, используя метод uncompromised :

Объект правила Password использует модель k-Anonymity, чтобы определить, не произошла ли утечка пароля через haveibeenpwned.com без ущерба для конфиденциальности или безопасности пользователя.

По умолчанию, если пароль появляется хотя бы один раз при утечке данных, он считается скомпрометированным. Вы можете настроить этот порог, используя первый аргумент метода uncompromised :

Конечно, вы можете связать все методы в приведенных выше примерах:

Определение правил паролей по умолчанию

Возможно, вам будет удобно указать правила проверки паролей по умолчанию в одном месте вашего приложения. Вы можете легко сделать это, используя метод Password::defaults , который принимает замыкание. Замыкание, данное методу defaults , должно вернуть конфигурацию правила пароля по умолчанию. Чаще всего, правило defaults следует вызывать в методе boot одного из поставщиков услуг вашего приложения:

Затем, когда вы хотите применить правила по умолчанию к конкретному паролю, проходящему проверку, вы можете вызвать метод defaults без аргументов:

Пользовательские правила валидации

Использование класса Rule

Laravel предлагает множество полезных правил валидации; однако вы можете указать свои собственные. Один из методов регистрации собственных правил валидации – использование объектов правил. Чтобы сгенерировать новый объект правила, вы можете использовать команду make:rule Artisan. Давайте воспользуемся этой командой, чтобы сгенерировать правило, которое проверяет, что строка состоит из прописных букв. Laravel поместит новый класс правила в каталог app/Rules вашего приложения. Если этот каталог не существует в вашем приложении, то Laravel предварительно создаст его, когда вы выполните команду Artisan для создания своего правила:

Как только правило создано, мы готовы определить его поведение. Объект правила содержит два метода: passes и message . Метод passes получает значение и имя атрибута и должен возвращать true или false в зависимости от того, является ли значение атрибута допустимым или нет. Метод message должен возвращать сообщение об ошибке валидации, которое следует использовать, если проверка оказалась не успешной:

Вы можете вызвать помощник trans в методе message , если хотите вернуть сообщение об ошибке из ваших файлов перевода:

После определения правила вы можете отправить его валидатору, передав экземпляр объекта правила с другими вашими правилами валидации:

Доступ к дополнительным данным

Если вашему пользовательскому классу правил проверки требуется доступ ко всем другим данным, проходящим проверку, ваш класс правил может реализовать интерфейс IlluminateContractsValidationDataAwareRule . Этот интерфейс требует, чтобы ваш класс определил метод setData . Этот метод будет автоматически вызван Laravel (до того, как начнется проверка) со всеми проверяемыми данными:

Или, если ваше правило проверки требует доступа к экземпляру валидатора, выполняющему проверку, вы можете реализовать интерфейс ValidatorAwareRule :

Использование замыканий

Если вам нужна функциональность собственного правила только один раз во всем приложении, то вы можете использовать анонимное правило вместо объекта правила. Анонимное правило получит имя атрибута, значение атрибута и замыкание $fail , которое будет выполнено в случае провала проверки:

Неявные правила

По умолчанию, правила валидации, включая созданные вами, не применяются, если проверяемый атрибут отсутствует или содержит пустую строку. Например, правило unique не будет выполнено для пустой строки:

Чтобы ваше правило было применено, даже если атрибут пуст, то правило должно подразумевать, что атрибут является обязательным. Чтобы создать «неявное» правило, реализуйте интерфейс IlluminateContractsValidationImplicitRule . Это «маркерный интерфейс» для валидатора; следовательно, он не содержит никаких дополнительных методов, которые вам нужно реализовать, помимо методов, требуемых типичным интерфейсом Rule .

Чтобы сгенерировать новый объект неявного правила, вы можете использовать Artisan-команду make:rule с параметром —implicit :

«Неявное» правило только подразумевает, что атрибут является обязательным к валидации. В действительности решать только вам, будет ли пустой или отсутствующий атрибут считаться невалидным.

Источник