Laravel
Проверка

параметры

Основной пример

Вы можете проверить данные запроса, используя метод validate (доступный в базовом контроллере, предоставляемый признаком ValidatesRequests ).

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

• для типичных запросов формы HTML пользователь будет перенаправлен на предыдущую страницу, при этом форма сохраняет представленные значения
• для запросов, ожидающих ответа JSON, будет генерироваться HTTP-ответ с кодом 422

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

/**
 * @param  Request  $request
 * @return Response
 */
public function store(Request $request) {
    $this->validate($request, [
        'name' => 'required',
        'email' => 'email|unique:users|max:255'
    ],
    // second array of validation messages can be passed here
    [
        'name.required' => 'Please provide a valid name!',
        'email.required' => 'Please provide a valid email!',
    ]);

    // The validation passed
}

В приведенном выше примере мы проверяем, что поле name существует с непустым значением. Во-вторых, мы проверяем, что поле email имеет допустимый формат электронной почты, уникально в таблице базы данных «пользователи» и имеет максимальную длину 255 символов.

| (pipe) объединяет различные правила валидации для одного поля.

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

$this->validate($request, [
    'name' => 'bail|required',
    'email' => 'email|unique:users|max:255'
]);

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

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

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

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

$validator = \Validator::make($request->all(), [
    'name.*'       => 'required', 
    'email.*'      => 'email|unique:users',
    'fatherName.*' => 'required'
]);

if ($validator->fails()) {
    return back()->withInput()->withErrors($validator->errors());
}

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

[
    'name.*' => [
        'required' => 'Name field is required',
    ],
    'email.*' => [
        'unique'   => 'Unique Email is required',
    ],
    'fatherName.*' => [
        'required' => 'Father Name required',
    ]
]

Ваш последний код будет выглядеть так:

$validator = \Validator::make($request->all(), [
    'name.*'       => 'required', 
    'email.*'      => 'email|unique:users',
    'fatherName.*' => 'required',
], [
    'name.*'       => 'Name Required',
    'email.*'      => 'Unique Email is required',
    'fatherName.*' => 'Father Name required',
]);

if ($validator->fails()) {
    return back()->withInput()->withErrors($validator->errors());
}

Другие подходы к валидации

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

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

Команда make:request Команда Artisan CLI генерирует класс и помещает его в каталог app/Http/Requests :

php artisan make:request StoreBlogPostRequest

Метод authorize может быть переопределен логикой авторизации для этого запроса:

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

Метод rules может быть переопределен конкретными правилами для этого запроса:

public function rules()
{
    return [
        'title' => 'required|unique:posts|max:255',
        'body' => 'required',
    ];
}

Метод messages может быть переопределен конкретными сообщениями для этого запроса:

public function messages()
{
    return [
        'title.required' => 'A title is required',
        'title.unique' => 'There is another post with the same title',
        'title.max' => 'The title may not exceed :max characters',
        'body.required' => 'A message is required',
    ];
}

Чтобы проверить запрос, просто введите hint конкретный класс запроса в соответствующий метод контроллера. Если проверка не удалась, ответ об ошибке будет отправлен обратно.

public function store(StoreBlogPostRequest $request)
{
    // validation passed
}

2) Ручное создание валидаторов

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

<?php    
namespace App\Http\Controllers;

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

class PostController extends Controller
{
    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...
    }
}

2) Свободное создание правил

Иногда вам может потребоваться создание уникальных правил «на лету», работа с методом boot() в Провайдере может быть сверху, а с Laravel 5.4 вы можете свободно создавать новые правила, используя класс Rule .

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

<?php
namespace App\Http\Requests;
use Illuminate\Foundation\Http\FormRequest;
use Illuminate\Http\Request;
use Illuminate\Validation\Rule;

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

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules(Request $request)
    {
        $id = $request->route()->getParameter('user');

        return [
            'name'           =>  'required',
            
            // Notice the value is an array and not a string like usual
            'email'         =>  [
                'required',
                Rule::unique('users')->ignore($id)
            ]
        ];
    }
}

Один класс запроса формы для POST, PUT, PATCH

Следуя примеру «Проверка формы запроса» , для POST , PUT , PATCH можно использовать один и тот же класс запросов, поэтому вам не нужно создавать другой класс, используя те же / аналогичные проверки. Это пригодится, если у вас есть уникальные атрибуты в вашей таблице.

/**
 * Get the validation rules that apply to the request.
 *
 * @return array
 */
public function rules() {
    switch($this->method()) {
        case 'GET':
        case 'DELETE':
            return [];
        case 'POST':
            return [
                'name'     => 'required|max:75|unique',
                'category' => 'required',
                'price'    => 'required|between:0,1000',
            ];
        case 'PUT':
        case 'PATCH':
            return [
                'name'     => 'required|max:75|unique:product,name,' . $this->product,
                'category' => 'required',
                'price'    => 'required|between:0,1000',
            ];
        default:break;
    }
}

Начиная с вершины, наш оператор switch будет искать тип метода запроса ( GET , DELETE , POST , PUT , PATCH ).

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

'field_name' => 'unique:table_name,column_name,' . $idToIgnore`

Если у вас есть первичный ключ с надписью, отличным от id , вы укажете столбец первичного ключа в качестве четвертого параметра.

'field_name' => 'unique:table_name,column_name,' . $idToIgnore . ',primary_key_column'

В этом примере мы используем PUT и переходим к маршруту ( admin/products/{product} ) значение идентификатора продукта. Таким образом, $this->product будет равен id для игнорирования.

Теперь ваши правила проверки PUT|PATCH и POST не обязательно должны быть одинаковыми. Определите свою логику, которая соответствует вашим требованиям. Этот метод позволяет повторно использовать пользовательские сообщения, которые вы, возможно, определили в пользовательском классе запроса формы.

Сообщения об ошибках

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

Файлы /resources/lang/[lang]/validation.php содержат сообщения об ошибках, которые будут использоваться валидатором. Вы можете редактировать их по мере необходимости.

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

Например, в 'required' => 'The :attribute field is required.' , То :attribute заполнитель будет заменен на имя поля ( в качестве альтернативы, вы можете также настроить значение отображения каждого поля в attributes массива в том же файле).

пример

Конфигурация сообщения:

'required' => 'Please inform your :attribute.',
//...
'attributes => [
    'email' => 'E-Mail address'
]

правила:

`email' => `required`

сообщение об ошибке:

«Пожалуйста, сообщите свой адрес электронной почты».

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

Класс Request имеет доступ к методу messages() который должен возвращать массив, это может использоваться для переопределения сообщений без необходимости входить в файлы lang. Например, если у нас есть пользовательская проверка file_exists вы можете file_exists сообщения, как file_exists ниже.

class SampleRequest extends Request {

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules()
    {
        return [
            'image' =>  'required|file_exists'
        ];
    }

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

    public function messages()
    {
        return [
            'image.file_exists' =>  'That file no longer exists or is invalid'
        ];
    }

}

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

Ошибки проверки сверкают в сеанс и также доступны в переменной $errors , которая автоматически делится на все виды.

Пример отображения ошибок в представлении Blade:

@if (count($errors) > 0)
    <div class="alert alert-danger">
        <ul>
            @foreach ($errors->all() as $error)
                <li>{{ $error }}</li>
            @endforeach
        </ul>
    </div>
@endif

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

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

<?php
namespace App\Providers;

use Illuminate\Support\ServiceProvider;
use Validator;

class AppServiceProvider extends ServiceProvider
{
    public function boot()
    {
        Validator::extend('starts_with', function($attribute, $value, $parameters, $validator) {
            return \Illuminate\Support\Str::startsWith($value, $parameters[0]);
        });

        Validator::replacer('starts_with', function($message, $attribute, $rule, $parameters) {
            return str_replace(':needle', $parameters[0], $message);
        });
    }
}

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

Сообщение об ошибке для этого настраиваемого правила может быть установлено как обычно в файле /resources/lang/[lang]/validation.php и может содержать заполнители, например, для значений параметров:

'starts_with' => 'The :attribute must start with :needle.'

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

Используйте это правило как любое другое:

$this->validate($request, [
    'phone_number' => 'required|starts_with:+'
]);