При создании веб-приложений важно серьезно относиться к безопасности, особенно, когда приходится иметь дело с получением данных от пользователей.
Общее правило безопасности - не доверять никому, так что нельзя надеяться на то, что пользователи всегда будут вводить в формы правильные значения. Например, вместо ввода в поле правильного email-адреса, пользователь может ввести неверный адрес, или вообще какие-нибудь вредоносные данные.
Когда дело доходит до валидации пользовательских данных, ее можно проводить как на стороне клиента (в веб-браузере), так и на серверной стороне.
Ранее валидацию на стороне клиента можно было провести только с помощью JavaScript. Но все изменилось (или почти изменилось), так как с помощью HTML5 валидацию можно проводить средствами браузера, без необходимости писать сложные скрипты для валидации на JavaScript.
Валидация форм с помощью HTML5HTML5 предоставляет довольно надежный механизм, основанный на следующих атрибутах тега : type , pattern и require . Благодаря этим новым атрибутам вы можете переложить некоторые функции проверки данных на плечи браузера.
Давайте рассмотрим эти атрибуты, чтобы понять, как они могут помочь в валидации форм.
Атрибут typeЭтот атрибут говорит, какое поле ввода отобразить для обработки данных, например, уже знакомое поле типа
Некоторые поля ввода уже предоставляют стандартные способы валидации, без необходимости писать дополнительный код. Например, проверяет поле на то, что введенное значение соответствует шаблону правильного email адреса. Если в поле введен неверный символ, форму нельзя будет отправить, пока значение не будет исправлено.
Попробуйте поиграться со значениями поля email в нижеприведенной демонстрации .
Также существуют другие стандартные типы полей, вроде , и для валидации чисел, URL’ов и телефонных номеров соотвествено.
Замечание: формат телефонного номера различается для разных стран из-за несоответствия количества цифр в телефонных номерах и разности форматов. Как результат, спецификация не определяет алгоритм проверки телефонных номеров, так что на время написания статьи данная возможность слабо поддерживается браузерами.
К счастью для нас, валидацию телефонных номеров можно провести с использованием атрибута pattern , который принимает как аргумент регулярное выражение, который мы рассмотрим далее.
Атрибут patternАтрибут pattern , скорее всего, заставит многих фронтенд-разработчиков прыгать от радости. Этот атрибут принимает регулярное выражение (аналогичное формату регулярных выражений JavaScript), по которому будет проверяться корректность введенных в поле данных.
Регулярные выражения это язык, использующийся для разбора и манипуляции текстом. Они часто используются для сложных операций поиска и замены, а также для проверки корректности введенных данных.
На сегодняшний день регулярные выражения включены в большинство популярных языков программирования, а также во многие скриптовые языки, редакторы, приложения, базы данных, и утилиты командной строки.
Регулярные выражения (RegEX) являются мощным, кратким и гибким инструментом для сопоставления строки текста, вроде отдельных символов, слов или шаблонов символов.
Передав регулярное выражение в качестве значения атрибута pattern можно указать, какие значения приемлемы для данного поля ввода, а также проинформировав пользователя об ошибках.
Давайте посмотрим на пару примеров использования регулярных выражений для валидации значения полей ввода.
Телефонные номераКак упоминалось ранее, тип поля tel не полностью поддерживается браузерами из-за несоответствия форматов номеров телефонов в разных странах.
Например, в некоторых странах формат телефонных номеров представляется в виде xxxx-xxx-xxxx , и сам телефонный номер будет что-то вроде этого: 0803-555-8205 .
Регулярное выражение, которому соответствует данный шаблон, такое: ^\d{4}-\d{3}-\d{4}$ . В коде это можно записатьтак :
Phone Number:
Буквенно-цифровые значения Атрибут requiredЭто атрибут булевого типа, использующийся для указания того, что значение данного поле обязательно заполнить для того, чтобы отправить форму. При добавлении этого атрибута полю браузер потребует от пользователя заполнить данное поле перед отправкой формы.
Это избавляет нас от реализации проверки полей с помощью JavaScript, что может сохранить немного времени разработчикам.
Например: или (для совместимости с XHTML)
Во всех демках, которые вы видели выше, используют атрибут required , так что вы можете попробовать его в действии, попытавшись отослать форму без заполнения полей.
ЗаключениеПоддержка валидации форм браузерами довольно хороша , а для старых браузеров вы можете использовать полифиллы.
Стоит отметить, что надеяться на валидацию только на стороне браузера опасно, так как эти проверки могут быть легко обойдены злоумышленниками или ботами.
Не все браузеры поддерживают HTML5, и не все данные, посланные вашему скрипту, придут с вашей формы. Это значит, что перед тем, как окончательно принять данные от пользователя, необходимо проверить их корректность на стороне сервера.
It is very essential to have the input to your form validated before taking the form submission data for further processing. When there are many fields in the form, the PHP validation script becomes too complex. Moreover, since you are doing the same or similar validation for most of the forms that you make, just too much of duplicate effort is spent on form validations.
This generic PHP form validator script makes it very easy to add validations to your form.
We create and associate a set of “validation descriptors” with each element in the form. The “validation descriptor” is a string specifying the type of validation to be performed. For example, “req” means required, “alpha” means allow only alphabetic characters and so on.
Each field in the form can have zero, one or more validations. For example, the input should not be empty, should be less than 25 chars, should be alpha-numeric, etc
You can associate a set of validation descriptors for each input field in the form.
Download the PHP form validation scriptYou can download the PHP form validation script below:
The zip file contains the form validation script formvalidator.php, documentation and usage samples.
The first argument is the name of the input field in the form. The second argument is the validation descriptor that tells the type of the validation required. The third argument is the error message to be displayed if the validation fails.
$inpname: $inp_err
\n"; } } ExampleThe example below will make the idea clearer
Name: Email:
Adding Custom ValidationIf you want to add a custom validation, which is not provided by the validation descriptors, you can do so. Here are the steps:
class MyValidator extends CustomValidator { function DoValidate(&$formars,&$error_hash) { if(stristr($formars["Comments"],"http://")) { $error_hash["Comments"]="No URLs allowed in comments"; return false; } return true; } }
$validator = new FormValidator(); $validator->addValidation("Name","req","Please fill in Name"); $validator->addValidation("Email","email", "The input for Email should be a valid email value"); $validator->addValidation("Email","req","Please fill in Email"); $custom_validator = new MyValidator(); $validator->AddCustomValidator($custom_validator);
The custom validation function will be called automatically after other validations.
Table of Validation DescriptorsHere is the list of all validation descriptors:
| Validation Descriptor | Usage |
| req | The field should not be empty |
| maxlen=??? | checks the length entered data to the maximum. For example, if the maximum size permitted is 25, give the validation descriptor as “maxlen=25” |
| minlen=??? | checks the length of the entered string to the required minimum. example “minlen=5” |
| alnum | Check the data if it contains any other characters other than alphabetic or numeric characters |
| alnum_s | Allows only alphabetic, numeric and space characters |
| num | Check numeric data |
| alpha | Check alphabetic data. |
| alpha_s | Check alphabetic data and allow spaces. |
| The field is an email field and verify the validity of the data. | |
| lt=??? lessthan=??? | Verify the data to be less than the value passed. Valid only for numeric fields. example: if the value should be less than 1000 give validation description as “lt=1000” |
| gt=??? greaterthan=??? | Verify the data to be greater than the value passed. Valid only for numeric fields. example: if the value should be greater than 10 give validation description as “gt=10” |
| regexp=??? | Check with a regular expression the value should match the regular expression. example: “regexp=^{1,20}$” allow up to 20 alphabetic characters. |
| dontselect=?? | This validation descriptor is for select input items (lists) Normally, the select list boxes will have one item saying ‘Select One’. The user should select an option other than this option. If the value of this option is ‘Select One’, the validation description should be “dontselect=Select One” |
| dontselectchk | This validation descriptor is for check boxes. The user should not select the given check box. Provide the value
of the check box instead of ?? For example, dontselectchk=on |
| shouldselchk | This validation descriptor is for check boxes. The user should select the given check box. Provide the value of the check box instead of ?? For example, shouldselchk=on |
| dontselectradio | This validation descriptor is for radio buttons. The user should not select the given radio button. Provide the value of the radio button instead of ?? For example, dontselectradio=NO |
| selectradio | This validation descriptor is for radio buttons. The user should select the given radio button. Provide the value of the radio button instead of ?? For example, selectradio=yes |
| selmin=?? | Select atleast n number of check boxes from a check box group. For example: selmin=3 |
| selone | Makes a radio group mandatory. The user should select atleast one item from the radio group. |
| eqelmnt=??? | compare two elements in the form and make sure the values are the same For example, ‘password’ and ‘confirm password’. Replace the ??? with the name of the other input element. For example: eqelmnt=confirm_pwd |
Laravel поставляется с простой, удобной системой валидации (проверки входных данных на соответствие правилам) и получения сообщений об ошибках - классом Validation .
Простейший пример валидации $validator = Validator::make(array("name" => "Дейл"), array("name" => "required|min:5"));Первый параметр, передаваемый методу make - данные для проверки. Второй параметр - правила, которые к ним должны быть применены.
Использование массивов для указания правилНесколько правил могут быть разделены либо прямой чертой (|), либо быть отдельными элементами массива.
$validator = Validator::make(array("name" => "Дейл"), array("name" => array("required", "min:5")));
Проверка нескольких полей $validator = Validator::make(array("name" => "Дейл", "password" => "плохойпароль", "email" => "[email protected]"), array("name" => "required", "password" => "required|min:8", "email" => "required|email|unique"));Как только был создан экземпляр Validator , метод fails (или passes) может быть использован для проведения проверки.
If ($validator->fails()) { // Переданные данные не прошли проверку }
Если Validator нашёл ошибки, вы можете получить его сообщения таким образом:
$messages = $validator->messages();
Вы также можете получить массив правил, данные которые не прошли проверку, без самих сообщений:
$failed = $validator->failed();
Проверка файловКласс Validator содержит несколько изначальных правил для проверки файлов, такие как size , mimes и другие. Для выполнения проверки над файлами просто передайте эти файлы вместе с другими данными.
Хук после валидацииLaravel после завершения валидации может запустить вашу функцию-замыкание, в которой вы можете, например, проверить что-то особенное или добавить какое-то своё сообщение об ошибке. Для этого служит метод after() :
$validator = Validator::make(...); $validator->after(function($validator) { if ($this->somethingElseIsInvalid()) { $validator->errors()->add("field", "Something is wrong with this field!"); } }); if ($validator->fails()) { // }
Вы можете добавить несколько after , если это нужно.
Валидация в контроллерахПисать полный код валидации каждый раз, когда нужно провалидировать данные - это неудобно. Поэтому Laravel предоставляет несколько решений для упрощения этой процедуры.
Базовый контроллер App\Http\Controllers\Controller включает в себя трейт ValidatesRequests , который уже содержит методы для валидации:
/** * Сохранить пост в блоге. * * @param Request $request * @return Response */ public function store(Request $request) { $this->validate($request, [ "title" => "required|unique|max:255", "body" => "required", ]); // }
Если валидация проходит, код продолжает выполняться. Если нет - бросается исключение Illuminate\Contracts\Validation\ValidationException . Если вы не поймаете это исключение, его поймает фреймворк, заполнит flash-переменные сообщениями об ошибках валидации и средиректит пользователя на предыдущую страницу с формой - сам!
В случае AJAX-запроса редиректа не происходит, фреймворк отдает ответ с HTTP-кодом 422 и JSON с ошибками валидации.
Код, приведенный выше, аналогичен вот этому::
/** * Сохранить пост в блоге. * * @param Request $request * @return Response */ public function store(Request $request) { $v = Validator::make($request->all(), [ "title" => "required|unique|max:255", "body" => "required", ]); if ($v->fails()) { return redirect()->back()->withErrors($v->errors()); } // }
Изменения формата ошибокЕсли вы хотите кастомизировать сообщения об ошибках валидации, которые сохраняются во флэш-переменных сессии при редиректе, перекройте метод formatValidationErrors в вашем контроллере:
/** * {@inheritdoc} */ protected function formatValidationErrors(\Illuminate\Validation\Validator $validator) { return $validator->errors()->all(); } Валидация запросовДля реализации более сложных сценариев валидации вам могут быть удобны так называемые Form Requests. Это специальные классы HTTP-запроса, содержащие в себе логику валидации. Они обрабатывают запрос до того, как он поступит в контроллер.
Чтобы создать класс запроса, используйте artisan-команду make:request:
Php artisan make:request StoreBlogPostRequest
Класс будет создан в папке app/Http/Requests . Добавьте необходимые правила валидации в его метод rules:
/** * Get the validation rules that apply to the request. * * @return array */ public function rules() { return [ "title" => "required|unique|max:255", "body" => "required", ]; }
Для того, чтобы фреймворк перехватил запрос перед контроллером, добавьте этот класс в аргументы необходимого метода контроллера:
При грамотном использовании валидации запросов вы можете быть уверены, что в ваших контроллерах всегда находятся только отвалидированные входные данные!
В случае неудачной валидации фреймворк заполняет флэш-переменные ошибками валидации и возврашает редирект на предыдущую страницу. В случае AJAX-запроса отдается ответ с кодом 422 и JSON с ошибками валидации.
Контроль доступаКлассы Form Request также содержат метод authorize . В этом методе вы можете проверять, разрешено ли пользователю совершать это действие, обновлять данный ресурс. Например, если пользователь пытается отредактировать комментарий к посту, является ли он его автором?
/** * Determine if the user is authorized to make this request. * * @return bool */ public function authorize() { $commentId = $this->route("comment"); return Comment::where("id", $commentId) ->where("user_id", Auth::id())->exists(); }
Обратите внимание на вызов метода route() выше. Этод метод дает вам доступ к параметрам в урле (в данном случае это {comment}), определенным в роуте:
Route::post("comment/{comment}");
Если метод authorize возвращает false, фреймворк формирует ответ с HTTP-кодом 403 и сразу же отсылает его. Метод контроллера не выполняется.
/** * Determine if the user is authorized to make this request. * * @return bool */ public function authorize() { return true; }
Изменения формата ошибок во флэш-переменныхЕсли вы хотите кастомизировать сообщения об ошибках валидации, которые сохраняются во флэш-переменных сессии при редиректе, переопределите метод formatValidationErrors в базовом классе запросов (App\Http\Requests\Request):
/** * {@inheritdoc} */ protected function formatValidationErrors(\Illuminate\Validation\Validator $validator) { return $validator->errors()->all(); } Работа с сообщениями об ошибкахПосле вызова метода messages объекта Validator вы получите объект MessageBag , который имеет набор полезных методов для доступа к сообщениям об ошибках.
Получение первого сообщения для поля echo $messages->first("email"); Получение всех сообщений для одного поля foreach ($messages->get("email") as $message) { // } Получение всех сообщений для всех полей foreach ($messages->all() as $message) { // } Проверка на наличие сообщения для поля if ($messages->has("email")) { // } Получение ошибки в заданном формате echo $messages->first("email", "");Примечание: по умолчанию сообщения форматируются в вид, который подходит для Twitter Bootstrap.
Получение всех сообщений в заданном формате foreach ($messages->all("Как только вы провели проверку, вам понадобится простой способ, чтобы передать ошибки в шаблон. Laravel позволяет удобно сделать это. Например, у нас есть такие роуты:
Route::get("register", function() { return View::make("user.register"); }); Route::post("register", function() { $rules = array(...); $validator = Validator::make(Input::all(), $rules); if ($validator->fails()) { return redirect("register")->withErrors($validator); } });
Заметьте, что когда проверки не пройдены, мы передаём объект Validator объекту переадресации Redirect с помощью метода withErrors . Этот метод сохранит сообщения об ошибках в одноразовых flash-переменных сессии, таким образом делая их доступными для следующего запроса.
Однако, заметьте, мы не передаем в View::make("user.register"); переменные $errors в шаблон. Laravel сам проверяет данные сессии на наличие переменных и автоматически передает их шаблону, если они доступны. Таким образом, важно помнить, что переменная $errors будет доступна для всех ваших шаблонов всегда, при любом запросе. . Это позволяет вам считать, что переменная $errors всегда определена и может безопасно использоваться. Переменная $errors - экземпляр класса MessageBag .
Таким образом, после переадресации вы можете прибегнуть к автоматически установленной в шаблоне переменной $errors:
Именованные MessageBag
Если у вас есть несколько форм на странице, то вы можете выбрать имя объекта MessageBag, в котором будут возвращаться тексты ошибок, чтобы вы могли их корректно отобразить для нужной формы.
Return redirect("register")->withErrors($validator, "login");
Получить текст ошибки из MessageBag с именем login:
Правила проверки
Ниже список всех доступных правил и их функции:
acceptedПоле должно быть в значении yes , on или 1 . Это полезно для проверки принятия правил и лицензий.
active_urlПоле должно быть корректным URL, доступным через функцию checkdnsrr .
after:dateПоле должно быть датой, более поздней, чем date
alphaПоле должно содержать только алфавитные символы.
alpha_dashПоле должно содержать только алфавитные символы, цифры, знаки подчёркивания (_) и дефисы (-).
alpha_numПоле должно содержать только алфавитные символы и цифры.
arrayПоле должно быть массивом.
before:dateПоле должно быть датой, более ранней, чем date . Строки приводятся к датам функцией strtotime .
between:min ,maxПоле должно иметь размер в диапазоне от min до max . Строки, числа и файлы трактуются аналогично правилу size .
booleanПоле должно быть логическим (булевым). Разрешенные значения: true , false , 1 , 0 , "1" и "0" .
confirmedЗначение поля должно соответствовать значению поля с этим именем, плюс foo_confirmation . Например, если проверяется поле password , то на вход должно быть передано совпадающее по значению поле password_confirmation .
dateПоле должно быть правильной датой в соответствии с функцией strtotime .
date_format:formatПоле должно подходить под формат даты format в соответствии с функцией date_parse_from_format .
different:fieldЗначение проверяемого поля должно отличаться от значения поля field .
emailПоле должно быть корректным адресом e-mail.
exists:table ,columnПоле должно существовать в заданной таблице базе данных.
Простое использование:
"state" => "exists:states"
Указание имени поля в таблице:
"state" => "exists:states,abbreviation"
Вы также можете указать больше условий, которые будут добавлены к запросу "WHERE":
"email" => "exists:staff,email,account_id,1"
imageЗагруженный файл должен быть изображением в формате jpeg, png, bmp, gif или svg.
in:foo ,bar ,...Значение поля должно быть одним из перечисленных (foo , bar и т.д.).
integerПоле должно иметь корректное целочисленное значение.
ipПоле должно быть корректным IP-адресом.
max:valueЗначение поля должно быть меньше или равно value
mimes:foo ,bar ,...MIME-тип загруженного файла должен быть одним из перечисленных.
Простое использование:
"photo" => "mimes:jpeg,bmp,png"
min:valueЗначение поля должно быть более value . Строки, числа и файлы трактуются аналогично правилу .
not_in:foo ,bar ,...Значение поля не должно быть одним из перечисленных (foo , bar и т.д.).
numericПоле должно иметь корректное числовое или дробное значение.
regex:patternПоле должно соответствовать заданному регулярному выражению.
Внимание: при использовании этого правила может быть нужно перечислять другие правила в виде элементов массива, особенно если выражение содержит символ вертикальной черты (|).
requiredПроверяемое поле должно присутствовать и иметь непустое значение.
required_if:field ,value ,...Проверяемое поле должно присутствовать и иметь непустое значение, если другое поле field присутствует и имеет любое из значений value .
required_with:foo ,bar ,...Присутствует и имеет непустое значение хотя бы одно из перечисленных полей (foo , bar и т.д.).
required_with_all:foo ,bar ,...Проверяемое поле должно присутствовать и иметь непустое значение, но только если присутствуют и имеют непустое значение все перечисленные поля (foo , bar и т.д.).
required_without:foo ,bar ,...Проверяемое поле должно присутствовать и иметь непустое значение, но только если не присутствует или имеет пустое значение хотя бы одно из перечисленных полей (foo , bar и т.д.).
required_without_all:foo ,bar ,...Проверяемое поле должно присутствовать и иметь непустое значение, но только если не присутствуют или имеют пустые значения все перечисленные поля (foo , bar и т.д.).
same:fieldПоле должно иметь то же значение, что и поле field .
size:valueПоле должно иметь совпадающий с value размер. Для строк это обозначает длину, для чисел - число, для файлов - размер в килобайтах.
timezoneПоле должно содержать идентификатор часового пояса (таймзоны), один из перечисленных в php-функции timezone_identifiers_list
unique:table ,column ,except ,idColumnЗначение поля должно быть уникальным в заданной таблице базы данных. Если column не указано, то будет использовано имя поля.
Простое использование "email" => "unique:users" Указание имени поля в таблице "email" => "unique:users,email_address" Игнорирование определённого ID "email" => "unique:users,email_address,10" Добавление дополнительных условийВы также можете указать больше условий, которые будут добавлены к запросу "WHERE"":
"email" => "unique:users,email_address,NULL,id,account_id,1"
В правиле выше только строки с account_id равном 1 будут включены в проверку.
urlПоле должно быть корректным URL.
Примечание: используется PHP-функция filter_var
Условные правилаИногда вам нужно валидировать некое поле только тогда, когда оно присутствует во входных данных. Для этого добавьте правило sometimes:
$v = Validator::make($data, array("email" => "sometimes|required|email",));
В примере выше для поля email будет запущена валидация только когда $data["email"] существует.
Сложные условные правилаИногда вам нужно, чтобы поле имело какое-либо значение только если другое поле имеет значеие, скажем, больше 100. Или вы можете требовать наличия двух полей, только когда также указано третье. Это легко достигается условными правилами. Сперва создайте объект Validator с набором статичных правил, которые никогда не изменяются:
$v = Validator::make($data, array("email" => "required|email", "games" => "required|numeric",));
Теперь предположим, что ваше приложение написано для коллекционеров игр. Если регистрируется коллекционер с более, чем 100 играми, то мы хотим их спросить, зачем им такое количество. Например, у них может быть магазин или может им просто нравится их собирать. Итак, для добавления такого условного правила мы используем метод Validator .
$v->sometimes("reason", "required|max:500", function($input) { return $input->games >= 100; });
Первый параметр этого метода - имя поля, которое мы проверяем. Второй параметр - правило, которое мы хотим добавить, если переданная функция-замыкание (третий параметр) вернёт true . Этот метод позволяет легко создавать сложные правила проверки ввода. Вы можете даже добавлять одни и те же условные правила для нескольких полей одновременно:
$v->sometimes(array("reason", "cost"), "required", function($input) { return $input->games >= 100; });
Примечание: Параметр $input , передаваемый замыканию - объект Illuminate\Support\Fluent и может использоваться для чтения проверяемого ввода и файлов.
Собственные сообщения об ошибкахВы можете передать собственные сообщения об ошибках вместо используемых по умолчанию. Есть несколько способов это сделать.
Передача своих сообщений в Validator $messages = array("required" => "Поле:attribute должно быть заполнено.",); $validator = Validator::make($input, $rules, $messages);Примечание: строка:attribute будет заменена на имя проверяемого поля. Вы также можете использовать и другие строки-переменные.
Использование других переменных-строк $messages = array("same" => "Значения:attribute и:other должны совпадать.", "size" => "Поле:attribute должно быть равно exactly:size.", "between" => "Значение:attribute должно быть от:min и до:max.", "in" => "Поле:attribute должно иметь одно из следующих значений: :values",); Указание собственного сообщения для отдельного поляИногда вам может потребоваться указать своё сообщение для отдельного поля.
$messages = array("email.required" => "Нам нужно знать ваш e-mail адрес!",);
Указание собственных сообщений в файле локализацииТакже можно определять сообщения валидации в файле локализации вместо того, чтобы передавать их в Validator напрямую. Для этого добавьте сообщения в массив custom файла локализации app/lang/xx/validation.php .
"custom" => array("email" => array("required" => "Нам нужно знать ваш e-mail адрес!",),),
Собственные правила проверки Регистрация собственного правила валидацииLaravel изначально содержит множество полезных правил, однако вам может понадобиться создать собственные. Одним из способов зарегистрировать произвольное правило - через метод Validator::extend .
Validator::extend("foo", function($attribute, $value, $parameters) { return $value == "foo"; });
Примечание: имя правила должно быть в формате_с_подчёркиваниями.
Переданная функция-замыкание получает три параметра: имя проверяемого поля $attribute , значение поля $value и массив параметров $parameters , переданных правилу.
Вместо функции в метод extend можно передать ссылку на метод класса:
Validator::extend("foo", "FooValidator@validate");
Обратите внимание, что вам также понадобится определить сообщение об ошибке для нового правила. Вы можете сделать это либо передавая его в виде массива строк в Validator , либо вписав в файл локализации.
Расширение класса ValidatorВместо использования функций-замыканий для расширения набора доступных правил вы можете расширить сам класс Validator . Для этого создайте класс, который наследует Illuminate\Validation\Validator . Вы можете добавить новые методы проверок, начав их имя с validate .
