Версія фреймворка: 8.x

Перевірка

Вступ

Laravel пропонує декілька різних підходів для перевірки вхідних даних вашої програми. За замовчуванням базовий клас контролера Laravel використовує aValidatesRequestsознака, яка забезпечує зручний метод перевірки вхідних запитів HTTP за допомогою різноманітних потужних правил перевірки.

Швидкий старт перевірки

Щоб дізнатись про потужні функції перевірки Laravel, давайте розглянемо повний приклад перевірки форми та відображення повідомлень про помилки назад для користувача.

Визначення маршрутів

По-перше, припустимо, що в нашому визначені такі маршрутиroutes/web.phpфайл:

use App\Http\Controllers\PostController;

Route::get('post/create', [PostController::class, 'create']);

Route::post('post', [PostController::class, 'store']);

GETroute буде відображати форму для користувача, щоб створити нову публікацію в блозі, тоді якPOSTroute збереже новий запис у блозі в базі даних.

Створення контролера

Далі, давайте поглянемо на простий контролер, який обробляє ці маршрути. Ми залишимоstoreна даний момент метод порожній:

<?php

namespace App\Http\Controllers;

use App\Http\Controllers\Controller;
use Illuminate\Http\Request;

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метод, передбаченийIlluminate\Http\Requestоб'єкт. Якщо правила перевірки пройдуть, ваш код буде продовжувати працювати нормально; однак, якщо перевірка не вдається, буде видано виняток і відповідна відповідь на помилку буде автоматично надіслана користувачеві. У випадку традиційного HTTP-запиту буде сформовано відповідь на переадресацію, тоді як відповідь JSON буде надіслана на запити AJAX.

Для кращого розуміння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метод. Знову ж таки, якщо перевірка не вдається, відповідна відповідь буде автоматично сформовано. Якщо перевірка пройде, наш контролер продовжить нормальне виконання.

Як варіант, правила перевірки можуть бути вказані як масиви правил замість одного|розділений рядок:

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

Ви можете використовуватиvalidateWithBagметод для перевірки запиту та збереження повідомлень про помилки віменований пакет помилок:

$validatedData = $request->validateWithBag('post', [
    'title' => ['required', 'unique:posts', 'max:255'],
    'body' => ['required'],
]);

Зупинка на першій помилці перевірки

Іноді, можливо, вам доведеться припинити запуск правил перевірки атрибута після першої помилки перевірки. Для цього призначте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',
]);

З іншого боку, якщо ваше ім'я поля містить буквальний крапка, ви можете явно заборонити інтерпретувати це як синтаксис "крапки", уникаючи крапки з зворотною рискою:

$request->validate([
    'title' => 'required|unique:posts|max:255',
    'v1\.0' => 'required',
]);

Відображення помилок перевірки

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

Знову зауважте, що нам не потрібно було явно прив’язувати повідомлення про помилки до подання в нашомуGETмаршрут. Це пов’язано з тим, що Laravel перевірить наявність помилок у даних сеансу та автоматично прив’яже їх до подання, якщо вони доступні.$errorsзмінна буде екземпляромIlluminate\Support\MessageBag. Для отримання додаткової інформації про роботу з цим об’єктом,ознайомтесь з його документацією.

The$errorsзмінна пов'язана з поданнямIlluminate\View\Middleware\ShareErrorsFromSessionMiddlware, яке надаєwebгрупа проміжного програмного забезпечення.Коли застосовується це Middlware$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Директива

Ви також можете використовувати@errorBladeдиректива, щоб швидко перевірити, чи існують повідомлення про помилки перевірки для даного атрибута. В межах@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іConvertEmptyStringsToNullMiddlware у глобальному стеку проміжного програмного забезпечення вашої програми. Це Middlware перелічено в стекуApp\Http\Kernelклас. Через це вам часто доведеться позначати свої "необов'язкові" поля запиту якnullableякщо ви не хочете, щоб валідатор розглядавnullзначення як недійсні. Наприклад:

$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.

Перевірка запиту форми

Створення запитів на форми

Для більш складних сценаріїв перевірки ви можете створити "запит форми". Запити форми - це власні класи запитів, які містять логіку перевірки. Щоб створити клас запиту форми, використовуйтеmake:requestКоманда Artisan CLI:

php artisan make:request StoreBlogPost

Створений клас буде розміщений уapp/Http/Requestsкаталог. Якщо цей каталог не існує, він буде створений під час запускуmake:requestкоманди. Давайте додамо кілька правил перевірки доrulesметод:

/**
 * 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  \Illuminate\Validation\Validator  $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',
    ];
}

Підготуйте дані для перевірки

Якщо вам потрібно продезінфікувати будь-які дані із запиту, перш ніж застосовувати свої правила перевірки, ви можете скористатисяprepareForValidationметод:

use Illuminate\Support\Str;

/**
 * Prepare the data for validation.
 *
 * @return void
 */
protected function prepareForValidation()
{
    $this->merge([
        'slug' => Str::slug($this->slug),
    ]);
}

Створення валідаторів вручну

Якщо ви не хочете використовуватиvalidateметоду на запит, ви можете створити екземпляр валідатора вручну, використовуючиValidatorфасад.makeна фасаді генерує новий екземпляр валідатора:

<?php

namespace App\Http\Controllers;

use App\Http\Controllers\Controller;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Validator;

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метод приймає валідатор, aMessageBag, or a PHP array.

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

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

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

Ви можете використовуватиvalidateWithBagметод зберігання повідомлень про помилки віменований пакет помилокякщо перевірка не вдається:

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

Іменовані пакети помилок

Якщо у вас є кілька форм на одній сторінці, ви можете назвати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метод на aValidatorнаприклад, ви отримаєтеIlluminate\Support\MessageBagекземпляр, який має безліч зручних методів роботи з повідомленнями про помилки.$errorsЗмінна, яка автоматично стає доступною для всіх подань, також є екземпляромMessageBagклас.

Отримання першого повідомлення про помилку для поля

Щоб отримати перше повідомлення про помилку для даного поля, використовуйте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',
],

Ви також можете передати користувацькі атрибути як четвертий аргумент дляValidator::makeметод:

$customAttributes = [
    'email' => 'email address',
];

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

Вказівка ​​користувацьких значень у мовних файлах

Іноді вам може знадобитися: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мовний файл, визначивши avaluesмасив:

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

Тепер, якщо правило перевірки не вдається, воно видасть таке повідомлення:

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

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

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

прийнято

Поле, що перевіряється, має бути_так_,на,1, або_правда_. Це корисно для перевірки прийняття "Умов використання".

active_url

Поле, що перевіряється, повинно мати дійсний запис A або AAAA відповідно доdns_get_recordФункція PHP. Ім'я хосту наданої URL-адреси витягується за допомогоюparse_urlФункція PHP перед передачеюdns_get_record.

після:дата

Поле, що перевіряється, має мати значення після заданої дати. Дати будуть передані вstrtotimeФункція PHP:

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

Замість того, щоб передавати рядок дати, яку слід оцінитиstrtotime, Ви можете вказати інше поле для порівняння з датою:

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

після_або_дорівнює:дата

Поле, що перевіряється, має мати значення після або дорівнювати даній даті. Для отримання додаткової інформації дивпісляправило.

альфа

Поле, що перевіряється, повинно мати повністю алфавітні символи.

alpha_dash

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

Alpha_num

Поле, що перевіряється, повинно мати повністю алфавітно-цифрові символи.

масив

Поле, що перевіряється, має бути PHParray.

застава

Зупиніть запуск правил перевірки після першої помилки перевірки.

до:дата

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

раніше_або_дорівнює:дата

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

між:хв,макс

Поле, що перевіряється, має мати розмір між заданим_хв_і_макс_. Рядки, числа, масиви та файли оцінюються так само, як іsizeправило.

логічний

Поле, що перевіряється, повинно мати можливість бути доданим як логічне значення. Приймаються введенняtrue,false,1,0,"1", і"0".

підтверджено

Поле, що перевіряється, повинно мати відповідне полеfoo_confirmation. Наприклад, якщо поле для перевірки єpassword, відповідністьpassword_confirmationполе повинно бути присутнім у введенні.

дата

Поле, що перевіряється, має бути дійсною, не відносною датою відповідно доstrtotimeФункція PHP.

дата_дорівнює: _date_

Поле, що перевіряється, має дорівнювати вказаній даті. Дати будуть передані в PHPstrtotimeфункція.

дата_формат: _format_

Поле, що перевіряється, має відповідати заданому_формат_. Ви повинні використовуватиабоdateабоdate_formatпід час перевірки поля, а не обох. Це правило перевірки підтримує всі формати, що підтримуються PHPДата, часклас.

інший:поле

Поле, що перевіряється, має мати інше значення, ніж_поле_.

цифри:значення

Поле, що перевіряється, має бути_числовий_і повинна мати точну довжину_значення_.

цифри_між: _min_,макс

Поле, що перевіряється, має бути_числовий_і повинна мати довжину між заданими_хв_і_макс_.

розміри

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

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

Доступні обмеження:хв_ширина,макс_ширина,хв_висота,макс_висота,ширина,висота,співвідношення.

A_співвідношення_обмеження має бути представлене як ширина, поділена на висоту. Це може бути вказано або твердженням типу3/2або поплавок типу1.5:

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

Оскільки це правило вимагає кількох аргументів, ви можете використовуватиRule::dimensionsметод вільно побудувати правило:

use Illuminate\Validation\Rule;

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

виразний

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

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

електронною поштою

Поле, що перевіряється, має бути відформатоване як електронна адреса. Під капотом це правило перевірки використовуєegulias/email-validatorпакет для перевірки адреси електронної пошти. За замовчуваннямRFCValidationзастосовується валідатор, але ви можете застосувати й інші стилі перевірки:

'email' => 'email:rfc,dns'

У наведеному вище прикладі буде застосованоRFCValidationіDNSCheckValidationперевірки. Ось повний перелік стилів перевірки, які ви можете застосувати:

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

filterвалідатор, який використовує PHPfilter_varфункція під капотом, поставляється з Laravel і є поведінкою Laravel до 5,8.dnsіspoofвалідатори вимагають PHPintlрозширення.

закінчується_з: _foo_,бар,...

Поле, що перевіряється, має закінчуватися одним із заданих значень.

виключити_if: _anotherfield_,значення

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

виключити_хіба що: _ані інше поле_,значення

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

існує:таблиця,стовпець

Поле, що перевіряється, повинно існувати в даній таблиці бази даних.

Основне використання правила існуючих правил

'state' => 'exists:states'

Якщоcolumnпараметр не вказаний, буде використано назву поля.

Вказівка ​​власного імені стовпця

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

Іноді вам може знадобитися вказати конкретне підключення до бази даних, яке буде використовуватися дляexistsзапит. Ви можете досягти цього, додавши ім'я з'єднання до імені таблиці, використовуючи синтаксис "крапка":

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

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

'user_id' => 'exists:App\Models\User,id'

Якщо ви хочете налаштувати запит, який виконується правилом перевірки, ви можете використовуватиRuleклас, щоб вільно визначити правило. У цьому прикладі ми також визначимо правила перевірки як масив замість того, щоб використовувати|символ для їх розмежування:

use Illuminate\Validation\Rule;

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

файл

Поле, що перевіряється, має бути успішно завантаженим файлом.

заповнені

Поле, що перевіряється, не повинно бути порожнім, коли воно є.

gt:поле

Поле, що перевіряється, має бути більше заданого_поле_. Два поля мають бути одного типу. Рядки, числа, масиви та файли обчислюються за тими ж умовами, що іsizeправило.

gte:поле

Поле, що перевіряється, має бути більше або дорівнює заданому_поле_. Два поля мають бути одного типу. Рядки, числа, масиви та файли обчислюються за тими ж умовами, що іsizeправило.

зображення

Файл, що перевіряється, повинен бути зображенням (jpeg, png, bmp, gif, svg або webp)

у:foo,бар,...

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

use Illuminate\Validation\Rule;

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

в_масив: _anotherfield_.*

Поле, що перевіряється, повинно існувати у_інше поле_значення.

ціле число

Поле, що перевіряється, має бути цілим числом.

Це правило перевірки не підтверджує, що вхідні дані мають тип змінної "ціле число", а лише те, що введенням є рядок або числове значення, яке містить ціле число.

ip

Поле, що перевіряється, має бути IP-адресою.

ipv4

Поле, що перевіряється, має бути адресою IPv4.

ipv6

Поле, що перевіряється, має бути адресою IPv6.

json

Поле, що перевіряється, має бути дійсним рядком JSON.

lt:поле

Поле, що перевіряється, має бути менше заданого_поле_. Два поля мають бути одного типу. Рядки, числа, масиви та файли обчислюються за тими ж умовами, що іsizeправило.

lte:поле

Поле, що перевіряється, має бути меншим або рівним заданому_поле_. Два поля мають бути одного типу. Рядки, числа, масиви та файли обчислюються за тими ж умовами, що іsizeправило.

макс:значення

Поле, що перевіряється, має бути менше або дорівнювати максимуму_значення_. Рядки, числа, масиви та файли оцінюються так само, як іsizeправило.

міметипи:текст / звичайний,...

Файл, що перевіряється, повинен відповідати одному з поданих типів MIME:

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

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

міми:foo,бар,...

Файл, що перевіряється, повинен мати тип MIME, що відповідає одному з перелічених розширень.

Основне використання правила MIME

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

Незважаючи на те, що вам потрібно лише вказати розширення, це правило фактично перевіряє тип MIME файлу, читаючи вміст файлу та вгадуючи його тип MIME.

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

хв:значення

Поле, що перевіряється, має містити мінімум_значення_. Рядки, числа, масиви та файли оцінюються так само, як іsizeправило.

множинні_з: _value_

Поле, що перевіряється, має бути кратним_значення_.

ні_у: _foo_,бар,...

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

use Illuminate\Validation\Rule;

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

ні_регулярний вираз: візерунок_

Поле, що перевіряється, не повинно відповідати заданому регулярному виразу.

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

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

нульовий

Поле, що перевіряється, може бутиnull. Це особливо корисно під час перевірки примітивів, таких як рядки та цілі числа, які можуть міститиnullзначення.

числовий

Поле, що перевіряється, має бути числовим.

пароль

Поле, що перевіряється, повинно відповідати паролю користувача, що пройшов аутентифікацію. Ви можете вказати захист автентифікації, використовуючи перший параметр правила:

'password' => 'password:api'

сьогодення

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

регулярний вираз:візерунок

Поле, що перевіряється, має відповідати заданому регулярному виразу.

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

**Note:**При використанніregex/not_regexшаблонів, може знадобитися вказати правила в масиві замість використання роздільників контурів, особливо якщо регулярний вираз містить символ конвеєра.

вимагається

Поле, що перевіряється, має бути присутнім у вхідних даних, а не порожнім. Поле вважається "порожнім", якщо виконується одна з наступних умов:

  • Значенняnull.
  • Значення - це порожній рядок.
  • Значення є порожнім масивом або порожнімCountableоб'єкт.
  • Значення - це завантажений файл без шляху.

вимагається_if: _anotherfield_,значення,...

Поле, що перевіряється, має бути присутнім і не порожнім, якщо_інше поле_поле дорівнює будь-якому_значення_.

Якщо ви хочете побудувати більш складну умову дляrequired_ifправило, ви можете використовуватиRule::requiredIfметод. Цей метод приймає логічне значення або Закриття. Коли пройде закриття, закриття має повернутисяtrueабоfalseщоб вказати, чи потрібно поле для перевірки:

use Illuminate\Validation\Rule;

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;
    }),
]);

вимагається_хіба що: _ані інше поле_,значення,...

Поле, що перевіряється, має бути присутнім і не бути порожнім, якщо не вказано_інше поле_поле дорівнює будь-якому_значення_.

вимагається_з: _foo_,бар,...

Поле, що перевіряється, має бути присутнім і не порожнім_тільки якщо_будь-яке інше вказане поле присутнє.

вимагається_with_all: _foo_,бар,...

Поле, що перевіряється, має бути присутнім і не порожнім_тільки якщо_усі інші вказані поля присутні.

вимагається_без: _foo_,бар,...

Поле, що перевіряється, має бути присутнім і не порожнім_лише коли_жодне з інших зазначених полів відсутнє.

вимагається_без_всі: _foo_,бар,...

Поле, що перевіряється, має бути присутнім і не порожнім_лише коли_всі інші вказані поля відсутні.

те саме:поле

Дане_поле_має відповідати полю, що перевіряється.

розмір:значення

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

// Validate that a string is exactly 12 characters long...
'title' => 'size:12';

// Validate that a provided integer equals 10...
'seats' => 'integer|size:10';

// Validate that an array has exactly 5 elements...
'tags' => 'array|size:5';

// Validate that an uploaded file is exactly 512 kilobytes...
'image' => 'file|size:512';

починається_з: _foo_,бар,...

Поле, що перевіряється, повинно починатися з одного із заданих значень.

рядок

Поле, що перевіряється, має бути рядком. Якщо ви хочете, щоб поле також булоnull, вам слід призначитиnullableправило до поля.

часовий пояс

Поле, що перевіряється, має бути дійсним ідентифікатором часового поясу відповідно доtimezone_identifiers_listФункція PHP.

унікальний:таблиця,стовпець,крім,idColumn

Поле, що перевіряється, не повинно існувати в даній таблиці бази даних.

Вказівка ​​власної назви таблиці / стовпця:

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

'email' => 'unique:App\Models\User,email_address'

columnОпція може бути використана для вказівки відповідного стовпця бази даних поля. Якщоcolumnпараметр не вказаний, буде використано назву поля.

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

Спеціальне підключення до бази даних

Іноді вам може знадобитися встановити користувальницьке підключення для запитів до бази даних, зроблених засобом перевірки. Як видно вище, налаштуванняunique:usersяк правило перевірки використовуватиме підключення до бази даних за замовчуванням для запиту до бази даних. Щоб замінити це, вкажіть підключення та назву таблиці, використовуючи синтаксис "крапка":

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

Примушування унікального правила ігнорувати даний ідентифікатор:

Іноді, можливо, ви захочете проігнорувати заданий ідентифікатор під час унікальної перевірки. Наприклад, розглянемо екран "оновлення профілю", який включає ім'я користувача, адресу електронної пошти та місцезнаходження. Можливо, ви захочете перевірити, що адреса електронної пошти унікальна. Однак, якщо користувач змінює лише поле імені, а не поле електронної пошти, ви не хочете, щоб виникала помилка перевірки, оскільки користувач уже є власником адреси електронної пошти.

Щоб доручити валідатору ігнорувати ідентифікатор користувача, ми використаємоRuleклас, щоб вільно визначити правило. У цьому прикладі ми також визначимо правила перевірки як масив замість того, щоб використовувати|символ для розмежування правил:

use Illuminate\Validation\Rule;

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_idє1:

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

url

Поле, що перевіряється, має бути дійсною URL-адресою.

uuid

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

Умовно додавання правил

Пропуск перевірки, коли поля мають певні значення

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

$v = Validator::make($data, [
    'has_appointment' => 'required|bool',
    'appointment_date' => 'exclude_if:has_appointment,false|required|date',
    'doctor_name' => 'exclude_if:has_appointment,false|required|string',
]);

Крім того, ви можете використовуватиexclude_unlessправило не перевіряти дане поле, якщо інше поле не має заданого значення:

$v = Validator::make($data, [
    'has_appointment' => 'required|bool',
    'appointment_date' => 'exclude_unless:has_appointment,true|required|date',
    'doctor_name' => 'exclude_unless:has_appointment,true|required|string',
]);

Перевірка при наявності

У деяких ситуаціях, можливо, ви захочете запустити перевірки перевірки щодо полялишеякщо це поле присутнє у вхідному масиві. Щоб швидко досягти цього, додайте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;
});
The$inputпараметр переданий у вашClosureбуде екземпляромIlluminate\Support\Fluentі може використовуватися для доступу до ваших даних та файлів.

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

Перевірка полів введення форми на основі масиву не повинна бути болем. Ви можете використовувати "крапкове позначення" для перевірки атрибутів у масиві. Наприклад, якщо вхідний запит 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 пропонує безліч корисних правил перевірки; однак, можливо, ви захочете вказати деякі власні. Одним із методів реєстрації власних правил перевірки є використання об'єктів правил. Щоб створити новий об'єкт правила, ви можете використовуватиmake:ruleArtisan командування. Давайте використаємо цю команду, щоб сформувати правило, яке перевіряє рядок у верхньому регістрі. Laravel помістить нове правило вapp/Rulesкаталог:

php artisan make:rule Uppercase

Після створення правила ми готові визначити його поведінку. Об'єкт правила містить два методи:passesіmessage.passesметод отримує значення і ім'я атрибута і повинен повернутисьtrueабоfalseзалежно від того, чи є значення атрибута дійсним чи ні.messageметод повинен повертати повідомлення про помилку перевірки, яке слід використовувати, коли перевірка не вдається:

<?php

namespace App\Rules;

use Illuminate\Contracts\Validation\Rule;

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 App\Rules\Uppercase;

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

Використання замикань

Якщо вам потрібна функціональність спеціального правила лише один раз у всій програмі, ви можете використовувати Закриття замість об’єкта правила. Закриття отримує ім’я атрибута, значення атрибута та a$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 App\Providers;

use Illuminate\Support\ServiceProvider;
use Illuminate\Support\Facades\Validator;

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';
        });
    }
}

Спеціальний валідатор Закриття отримує чотири аргументи: ім'я$attributeперевіряється,$valueатрибута, масив$parametersперейшло до правила, аValidatorінстанції.

Ви також можете передати клас і метод доextendметод замість Закриття:

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

Визначення повідомлення про помилку

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

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

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

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

Створюючи власне правило перевірки, іноді може знадобитися визначити власні заміни заповнювачів для повідомлень про помилки. Ви можете зробити це, створивши власний Валідатор, як описано вище, а потім зателефонувавши доreplacerметод наValidatorфасад. Ви можете зробити це в межахbootметод aпостачальник послуг:

/**
 * 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';
});
Тільки "неявне" розширення_передбачає_що атрибут є обов’язковим. Чи справді він анулює відсутність чи порожній атрибут, вирішувати вам.

Неявні об'єкти правила

Якщо ви хочете, щоб об'єкт правила запускався, коли атрибут порожній, вам слід реалізувати файлIlluminate\Contracts\Validation\ImplicitRuleінтерфейс. Цей інтерфейс служить "інтерфейсом маркера" для валідатора; отже, він не містить жодних методів, які вам потрібно реалізувати.