Валидация и очистка данных средствами PHP. Класс Validator для валидации POST данных Запрос сообщения об ошибке

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

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

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

Немного отступления от темы:
Работа над проектами, разработка и программирование сайтов, скриптов, прочих систем занимает практически всё мое свободное время (по мимо рабочего), иными словами я занимаюсь этим делом максимально возможное количество часов в сутки. Время от времени возникает потребность в тестировании чего либо, ради забавы или просто любопытства. В итоге подобными тестируемыми лабораторными крысами становятся сайты сделанные на скорую руку, на самописных движках или на CMS древних версий. разумеется всё перечисленное страдает от криво написанного кода, нехватки котроля за данными и просто кишит различными багами. Собственно, в большинстве случаем за час моих экспериментов над такими сайтами мне удается найти несколько серьезных уязвимостей и большинство из них кроется в недостаточной валидации пришедших данных. В последнее время часто это встречается в скриптах обрабатывающих POST данные пришедших от JavaScript + Ajax.

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

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

Думаю важность валидации всем понятна. На протяжении длительно времени я писал каждый раз один и тот же кусок кода, затем использовал собственные функции проверки данных, многие из которых были весьма примитивны и как правило разбросаны в разных частях (прииклюденных) файлов. В скором я начал знакомится с PHP фреймворками Zend, CI, Kohana, в каждом из был реализован свой класс для валидации данных, которые я заимствовал для своих проектов. В конце концов я решил заточить один из классов CI под свои нужды, но оказалось, что об этом уже позаботился автор одного из блогов по программированию. Далее делюсь его трудами, а именно модифицированной библиотекой CodeIgniter.

Разберем следующий код :

Просмотр кода PHP

require_once "validator.class.php" ; $validator = new Validator() ; $validator -> set_rules ("name" , "Ваше имя" , array ("required" => , "alpha" => ) ) ; $validator -> set_rules ("email" , "Ваш email" , array ("required" => "Поле %s обязательно для заполнения" , "valid_email" => ) ) ; if ($validator -> run () ) { echo "Валидация прошла успешно" ; } else { echo $validator -> get_string_errors () ; }

Как видно из примера, первой строкой мы подключаем файл класса validator.calss.php к нашем скрипту. Далее создаем экземпляр класса и сохраняем объект в переменную $validator .
Затем используя метод $validator->set_rules($field, $label, $rules) задаем поля для валидации.

Данный метод принимает 3 параметра:

$field - имя поля валидации (значение атрибута name в теге )

$label - название поля валидации, будет подставляться в сообщения об ошибках

$rules - массив правил валидации, у которого в качестве ключа используется правило валидации, а в качестве значения - сообщение об ошибке для этого правила

После того, как все поля для валидации установлены, запускаем валидатор используя метод $validator->run() . Если валидация прошла успешно, то данный метод вернет значение TRUE , иначе, если есть хоть какие-то ошибки, вернет FALSE .

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

get_string_errors() — возвращает все сообщения об ошибках в виде строки

get_array_errors() — возвращает все сообщения в виде массива, где в качестве ключа используется имя поля, а в качестве значения - описание ошибки для этого поля.

form_error($field) - возвращает сообщение об ошибке для поля, переданного в качестве параметра $field

По умолчанию сообщения об ошибках оборачиваются в тег . Для того чтобы задать свое оформление используйте метод set_error_delimiters($prefix, $suffix) . Например так:

Теперь сообщения об ошибках будут оборачиваться в div с классом «error»

Как видите все очень просто.

Просмотр кода PHP

$validator -> set_error_delimiters (" " , " " ) ;

Для установки правил валидации Вы можете методу set_rules($fields) передать многомерный ассоциативный массив. Давайте посмотрим на пример:

Просмотр кода PHP

$rules = array ( array ( "field" => "name" , "label" => "Ваше имя" , "rules" => array ( "required" => "Поле %s обязательно для заполнения" , "alpha" => "Поле %s должно содержать только буквы" ) ) , array ( "field" => "email" , "label" => "Ваш email" , "rules" => array ( "required" => "Поле %s обязательно для заполнения" , "valid_email" => "Поле %s должно содержать правильный email-адрес" ) ) ) ; $validator -> set_rules ($rules ) ;

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

Итак, какие же правила валидации поддерживает данный класс?

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

required	Возвращает FALSE если поле не заполнено
integer	Возвращает FALSE если значение не является целым числом
float	Возвращает FALSE если значение не числового вида
valid_url	Возвращает FALSE если значения не является корректным URL адресом
valid_email	Возвращает FALSE если значения не является корректным e-mail адресом
valid_ip	Возвращает FALSE если IP-адрес не является действительным
matches	Возвращает FALSE если элемент не соответствует значению другого элемента field
alpha	Возвращает FALSE если элемент содержит не только буквы
valid_captcha	Возвращает FALSE если значение в сессии field не равно значению поля формы
valid_date	Возвращает FALSE если элемент содержит не корректную дату

Большинство этих правил используют фильтры , которые стали доступны в PHP 5.

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

Для того чтобы получить обработанное значение POST данных используется метод:

Просмотр кода PHP

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

В предыдущей статье я обещал написать сравнение своей собственной библиотеки с другими имеющимися решениями, так что сегодня мы рассмотрим валидацию с помощью Aura.Filter , Respect Validation , Sirius Validation и Valitron .

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

name. Должно содержать ровно два слова, где первое - имя пользователя, а второе - фамилия.

login. Если значение передано, то оно должно только латинские буквы, дефисы и нижнее подчеркивание.

email. Должно содержать валидный адрес электронной почты.

password. Должен быть установлен и иметь длину не более 64 символов.

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

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

$data = [ "name" => "Альберт", // Должно быть два слова "login" => "@lbert", // "Запрещенный" символ @ "email" => "что-то не то", // Здесь должен быть e-mail "password" => Aura.Filter

Валидация с использованием Aura.Filter начинается с фабрики фильтров. Нам необходимо создать так называемый «фильтр субъекта», так как мы будет валидировать массив, а не индивидуальное значение.

Определяем правила use Aura\Filter\FilterFactory; $filter = (new FilterFactory)->newSubjectFilter(); $filter->validate("name") ->isNotBlank() ->is("two_words") ->setMessage("Имя должно состоять из двух слов."); $filter->validate("login") ->isBlankOr("alnum") ->setMessage("Если вы указываете логин, он должен содержать только латинские символы."); $filter->validate("email") ->isNotBlank() ->is("email") ->setMessage("Пожалуйста, напишите корректный адрес эл. почты."); $filter->validate("password") ->isNotBlank() ->is("strlenMax", 64) ->setMessage("Пожалуйста, напишите пароль."); $filter->validate("agreed") ->is("callback", function($subject, $field) { return $subject->{$field} === true; })->setMessage("Вам необходимо согласиться с условиями сервиса.");

Как видите, описание правил достаточно простое. Aura.Filter предоставляет целый набор полезных правил «из коробки» и некоторые из них были использованы в примере выше:

метод isNotBlank. Указывает, что поле не может иметь пустое значение.

alnum. Это правило допускает только латинские буквы.

email. И так понятно:)

strlenMax. Указывает, что поле не может превышать длину, указанную вторым аргументом метода is .

callback. Этот тип правила похож на замыкания из Kontrolio. Он позволяет определить правило в виде замыкания. В это замыкание Aura.Filter передает «субъект», наш массив данных из формы, и поле, в данном случае agreed .

Наверняка вы заметили, что я не указал правило two_words . Естественно, в Aura.Filter такого правила нет, поэтому нам необходимо его создать. Как гласит документация, это делается с помощью отдельного класса для правила:

/** * Правило, которое валидирует имя пользователя. * Имя пользователя состоит из двух слов: имени и фамилии, разделенных одним пробелом. */ class UserNameRule { /** * Валидирует имя пользователя. * * @param object|array $subject * @param string $field * @param int $max * * @return bool */ public function __invoke($subject, $field, $max = null) { $value = $subject->{$field}; if (! is_scalar($value)) { return false; } return (bool) preg_match("/^+\s+$/u", $value); } }

The second step is to let the filter factory know about our new rule. It’s done by passing the first argument as an array of rules to the filter factory:

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

use Aura\Filter\FilterFactory; $rules = [ "two_words" => function() { return new UserNameRule; } ]; $filter = (new FilterFactory($rules))->newSubjectFilter();

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

Обратная связь

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

Валидируем с Aura.Filter мы следующим образом:

$valid = $filter->apply($data); if (! $valid) { $failures = $filter->getFailures(); $messages = $failures->getMessages(); }

В $messages записывается массив, поэтому для вывода сообщений нам потребуется два вложенных foreach:

Respect Validation

Вторая библиотека, использованная мной в сравнении, - относительно популярное решение под названием Respect Validation . Раз люди ей доверяют, думаю, там есть что посмотреть.

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

use Respect\Validation\Validator as v; $data = [ "name" => "Альберт", // Должно быть два слова "login" => "@lbert", // "Запрещенный" символ @ "email" => "что-то не то", // Здесь должен быть e-mail "password" => "" // Пароль вообще не указан // "agreed" нет в массиве, потому что пользователь не установил флажок ]; Определяем правила

Как и в случае с Aura.Filter, нам необходимо собственное правило валидации для имени пользователя, поэтому давайте с него и начнем:

namespace MyNamespace; use Respect\Validation\Rules\AbstractRule; class UserNameRule extends AbstractRule { public function validate($input) { return (bool) preg_match("/^+\s+$/u", $input); } }

Внешнее API правил практически идентично Aura.Filter, только используется метод validate() вместо магии __invoke(). Мне оно, это API, показалось более простым и понятным. Ну, и к Kontrolio оно ближе:)

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

use Respect\Validation\Exceptions\NestedValidationException; class UserNameRuleException extends NestedValidationException { // }

Ну и наконец-то мы можем провалидировать наши данные. Для начала мы передаем валидатору наше новое правило, чтобы он узнал о нем, и мы смогли его использовать в дальнейшем. В Respect Validation это делается вызовом метода with() с передачей пространства имен, в котором находятся нестандартные правила.

v::with("MyNamespace\\");

Теперь все нестандартные правила, находящиеся в пространстве имен MyNamespace , будут «опознаны» валидатором. Следующий шаг - описать необходимые правила и выполнить валидацию.

v::attribute("name", v::userNameRule()) ->attribute("login", v::alnum("-_")) ->attribute("email", v::email()) ->attribute("password", v::notEmpty()->stringType()->length(null, 64)) ->attribute("agreed", v::trueVal()) ->assert((object) $data);

Обратите внимание на то, как мы применяем наше правило к атрибуту name . Здесь название класса правило трансформировалось в название метода валидатора. Остальные правила, в общем-то, интуитивно понятны.

Отдельно стоит сказать о том, зачем мы приводим массив $data к объекту. Дело в том, что Respect Validation принимает на вход объекты, а не массивы. Это следует учесть при разработке с использованием данной библиотеки.

Обратная связь

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

try { v::with("RespectValidationExample\\"); v::attribute("name", v::userNameRule()) ->attribute("login", v::alnum("-_")) ->attribute("email", v::email()) ->attribute("password", v::notEmpty()->stringType()->length(null, 64)) ->attribute("agreed", v::trueVal()) ->assert((object) $data); } catch (NestedValidationException $ex) { $messages = $ex->getMessages(); }

Используя getMessages() , мы получим плоский массив всех сообщений, который валидатор собрал в процессе валидации. Задампив массив, мы получим примерно такой результат:

array(5) { => string(29) “Data validation failed for %s” => string(60) “login must contain only letters (a-z), digits (0–9) and “-_”” => string(25) “email must be valid email” => string(26) “password must not be empty” => string(32) “Attribute agreed must be present” }

Можно поменять сообщения на свои собственные. Возможно, я как-то не так понял эту библиотеку, но мне этот процесс не показался таким уж очевидным: необходимо использовать метод findMessages() на обработанном исключении, в котором вы определяете сообщения не для атрибутов, а для правил.

$ex->findMessages([ "userNameRule" => "Имя пользователя должно состоять из двух слов.", "alnum" => "Ваш логин нам не нравится.", "email" => "Вы явно не хотите давать нам свой e-mail.", "notEmpty" => "Ну и где же ваш пароль?", "agreed" => "Жаль, что вы не согласны." ]);

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

array(5) { => string(40) “Имя пользователя должно состоять из двух слов.” => string(31) “Ваш логин нам не нравится.” => string(25) “email must be valid email” => string(5) “Ну и где же ваш пароль?” => string(9) “Жаль, что вы не согласны.” }

Как видите, сообщение для поля электронной почты не применилось, осталось стандартное. А вот сообщение за индексом 4 наоборот! И это при том, что я использовал не название правила, а название поля. В то время как если бы я использовал название правила (trueVal), моё сообщение бы куда-то затерялось. Комментарии опытных пользователей данной библиотеки очень приветствуются.

Sirius Validation

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

Определяем правила

И снова нам необходимо определить правило для имени пользователя. Мы его напишем как-то так:

class UserNameRule extends AbstractRule { // Сообщения об ошибках const MESSAGE = "Имя пользователя должно состоять из двух слов."; const LABELED_MESSAGE = "{label} должно состоять из двух слов."; public function validate($value, $valueIdentifier = null) { return (bool) preg_match("/^+\s+$/u", $value); } }

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

Теперь давайте опишем логику валидации:

$validator = new Validator; $validator ->add("name", "required | MyApp\Validation\Rule\UserNameRule") ->add("login", "required | alphanumhyphen", null, "Логин может содержать только латинские буквы, черточки и подчеркивания.") ->add("email", "required | email", null, "Пожалуйста, укажите корректный e-mail.") ->add("password", "required | maxlength(64)", null, "Ваш пароль, сударь.") ->add("agree", "required | equal(true)", null, "Почему же вы не согласились?");

Как видите, набор правил весьма прост и читабелен. Для описания мы используем названия, разделенные горизонтальными черточками. Этот подход похож на тот, что используется в Laravel и Kontrolio.

Четвертый аргумент метода add() описывает сообщение об ошибке валидации, которое Sirius использует, если валидация будет провалена. А почему же мы не добавили сообщение для нашего нового правила UserNameRule ?

$validator->add("name", "required | MyApp\Validation\Rule\UserNameRule")

Так это потому, что сообщения уже описаны в константах класса:

class UserNameRule extends AbstractRule { // Сообщения об ошибках const MESSAGE = "Имя пользователя должно состоять из двух слов."; ...

Другой вариант - использовать метод addMessage() самого валидатора:

$validator->addMessage("email", "Пожалуйста, укажите корректный e-mail.");

Обратите внимание, что кастомные правила идентифицируются по полному названию их класса, в то время как в Kontrolio можно задать псевдоним/алиас.

Обратная связь

Чтобы выполнить валидацию, мы вызываем метод валидатора validate() , передавая в него данные:

$data = [ "name" => "Альберт", // Должно быть два слова "login" => "@lbert", // "Запрещенный" символ @ "email" => "что-то не то", // Здесь должен быть e-mail "password" => "" // Пароль вообще не указан // "agreed" нет в массиве, потому что пользователь не установил флажок ]; $validator->validate($data);

В отличие от Respect, Sirius не выкинет исключение, а просто вернет false . Сообщения об ошибках валидации можно получить через метод валидатора getMessages() . Он возвращает ошибки, сгруппированные по атрибутам, так что для прохода по ошибкам нам понадобится два цикла foreach:

foreach ($validator->getMessages() as $attribute => $messages) { foreach ($messages as $message) { echo $message->getTemplate() . "\n"; } }

Здесь $message - объект класса Sirius\Validation\ErrorMessage , у которого есть метод getTemplate() , возвращающий то самое необходимое нам сообщение.

ValitronОпределяем правила

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

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

use Valitron\Validator; Validator::addRule("two_words", function($field, $value) { return (bool) preg_match("/^+\s+$/u", $value); }, "Имя пользователя должно состоять ровно из двух слов.");

Второе отличие - то, как правила применяются к атрибутам. Во всех предыдущих случаях мы видели, что атрибут - вещь как бы первичная.

В Valitron пошли другим путем и на первое место поставили именно правила валидации. Описывая правила, вы как бы применяете атрибуты к этим правилам, а не наоборот.

$validator = new Validator($data); $validator ->rule("two_words", "name")->label("") ->rule("required", [ "name", "login", "email", "password", "agreed" ]) ->rule("slug", "login") ->rule("email", "email") ->rule("accepted", "agreed");

Как видно из примера, в методе rule() мы сначала пишем название правила, а уже затем указываем атрибуты, которые должны соответствовать этому правилу. Более явный пример - правило required , где показано, как атрибуты «принадлежат» этому правилу.

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

Valitron подставляет имена атрибутов в текст сообщения даже в том случае, когда используются нестандартные сообщения об ошибках. Поэтому мы и воспользовались методом label() с пустой строкой, чтобы убрать имя атрибута.

$validator->rule("two_words", "name")->label("") Обратная связь

Конкретно что касается валидации, API библиотеки Valitron практически ничем не отличается от того, что мы уже видели в статье. Чтобы выполнить валидацию мы вызываем метод валидатора validate() :

$validator->validate();

Сообщения об ошибках валидации можно получить с помощью метода getErrors() :

$validator->errors();

Сообщения здесь группирутся по атрибутам точно так же, как и в Sirius Validation, за исключеним того, что для сообщения нет отдельного класса, и мы получаем обычный многомерный массив.

foreach ($validator->errors() as $attribute => $messages) { foreach ($messages as $message) { echo $message . "\n"; } } Kontrolio

Ну и наконец, последняя библиотека на сегодня - моя собственная разработка под названием Kontrolio .

Определяем правила

Снова, в пятый раз мы создадим правило валидации для имени пользователя. Всё относительно просто и стандартно:

namespace MyProject\Validation\Rules; use Kontrolio\Rules\AbstractRule; class TwoWords extends Kontrolio\Rules\AbstractRule { public function isValid($input = null) { return (bool) preg_match("/^+\s+$/u", $input); } }

Теперь мы создаем фабрику и регистриуем правило в ней, используя метод extend() :

namespace MyProject; use Kontrolio\Factory; use MyProject\Validation\Rules\TwoWords; $factory = Kontrolio\Factory::getInstance()->extend();

После регистрации правила мы можем воспользоваться им в том числе по имени - two_words . Давайте создадим валидатор:

$data = [ "name" => "Альберт", // Должно быть два слова "login" => "@lbert", // "Запрещенный" символ @ "email" => "что-то не то", // Здесь должен быть e-mail "password" => "" // Пароль вообще не указан // "agreed" нет в массиве, потому что пользователь не установил флажок ]; $rules = [ "name" => "two_words", "login" => "sometimes|alphadash", "email" => "email", "password" => "length:1,64", "agreed" => "accepted" ]; $messages = [ "name" => "Имя пользователя должно состоять из двух слов.", "login" => "Ваш логин нам не нравится.", "email" => "Вы явно не хотите давать нам свой e-mail.", "password" => "Ну и где же ваш пароль?", "agreed" => "Жаль, что вы не согласны." ]; $validator = $factory->make($data, $rules, $messages);

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

$rules = [ "name" => new TwoWords, "login" => , "email" => new Email, "password" => new Length(1, 64), "agreed" => new Accepted ]; Обратная связь

Валидация запускается всё тем же методом validate() :

$validator->validate();

Теперь мы можем получить сообщения об ошибках, используя один из методов getErrors() или getErrorsList() . Первый метод позволяет сделать более сложный вывод ошибок, тогда как второй возвращает плоский массив. Используя getErrors() мы можем вывести сообщения как-то так:

А с getErrorsList() можно сделать более простой список сообщений:

Итог

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

Aura.Filter

Respect Validation

Sirius Validation

Valitron

Kontrolio

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

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

Благодарю за прочтение. Сделайте правильный выбор.

Теги:

• валидация данных
• php
• велосипедостроение

Добавить метки

В предыдущей статье я обещал написать сравнение своей собственной библиотеки с другими имеющимися решениями, так что сегодня мы рассмотрим валидацию с помощью Aura.Filter , Respect Validation , Sirius Validation и Valitron .

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

name. Должно содержать ровно два слова, где первое - имя пользователя, а второе - фамилия.

login. Если значение передано, то оно должно только латинские буквы, дефисы и нижнее подчеркивание.

email. Должно содержать валидный адрес электронной почты.

password. Должен быть установлен и иметь длину не более 64 символов.

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

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

$data = [ "name" => "Альберт", // Должно быть два слова "login" => "@lbert", // "Запрещенный" символ @ "email" => "что-то не то", // Здесь должен быть e-mail "password" => Aura.Filter

Валидация с использованием Aura.Filter начинается с фабрики фильтров. Нам необходимо создать так называемый «фильтр субъекта», так как мы будет валидировать массив, а не индивидуальное значение.

Определяем правила use Aura\Filter\FilterFactory; $filter = (new FilterFactory)->newSubjectFilter(); $filter->validate("name") ->isNotBlank() ->is("two_words") ->setMessage("Имя должно состоять из двух слов."); $filter->validate("login") ->isBlankOr("alnum") ->setMessage("Если вы указываете логин, он должен содержать только латинские символы."); $filter->validate("email") ->isNotBlank() ->is("email") ->setMessage("Пожалуйста, напишите корректный адрес эл. почты."); $filter->validate("password") ->isNotBlank() ->is("strlenMax", 64) ->setMessage("Пожалуйста, напишите пароль."); $filter->validate("agreed") ->is("callback", function($subject, $field) { return $subject->{$field} === true; })->setMessage("Вам необходимо согласиться с условиями сервиса.");

Как видите, описание правил достаточно простое. Aura.Filter предоставляет целый набор полезных правил «из коробки» и некоторые из них были использованы в примере выше:

метод isNotBlank. Указывает, что поле не может иметь пустое значение.

alnum. Это правило допускает только латинские буквы.

email. И так понятно:)

strlenMax. Указывает, что поле не может превышать длину, указанную вторым аргументом метода is .

callback. Этот тип правила похож на замыкания из Kontrolio. Он позволяет определить правило в виде замыкания. В это замыкание Aura.Filter передает «субъект», наш массив данных из формы, и поле, в данном случае agreed .

Наверняка вы заметили, что я не указал правило two_words . Естественно, в Aura.Filter такого правила нет, поэтому нам необходимо его создать. Как гласит документация, это делается с помощью отдельного класса для правила:

/** * Правило, которое валидирует имя пользователя. * Имя пользователя состоит из двух слов: имени и фамилии, разделенных одним пробелом. */ class UserNameRule { /** * Валидирует имя пользователя. * * @param object|array $subject * @param string $field * @param int $max * * @return bool */ public function __invoke($subject, $field, $max = null) { $value = $subject->{$field}; if (! is_scalar($value)) { return false; } return (bool) preg_match("/^+\s+$/u", $value); } }

The second step is to let the filter factory know about our new rule. It’s done by passing the first argument as an array of rules to the filter factory:

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

use Aura\Filter\FilterFactory; $rules = [ "two_words" => function() { return new UserNameRule; } ]; $filter = (new FilterFactory($rules))->newSubjectFilter();

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

Обратная связь

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

Валидируем с Aura.Filter мы следующим образом:

$valid = $filter->apply($data); if (! $valid) { $failures = $filter->getFailures(); $messages = $failures->getMessages(); }

В $messages записывается массив, поэтому для вывода сообщений нам потребуется два вложенных foreach:

Respect Validation

Вторая библиотека, использованная мной в сравнении, - относительно популярное решение под названием Respect Validation . Раз люди ей доверяют, думаю, там есть что посмотреть.

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

use Respect\Validation\Validator as v; $data = [ "name" => "Альберт", // Должно быть два слова "login" => "@lbert", // "Запрещенный" символ @ "email" => "что-то не то", // Здесь должен быть e-mail "password" => "" // Пароль вообще не указан // "agreed" нет в массиве, потому что пользователь не установил флажок ]; Определяем правила

Как и в случае с Aura.Filter, нам необходимо собственное правило валидации для имени пользователя, поэтому давайте с него и начнем:

namespace MyNamespace; use Respect\Validation\Rules\AbstractRule; class UserNameRule extends AbstractRule { public function validate($input) { return (bool) preg_match("/^+\s+$/u", $input); } }

Внешнее API правил практически идентично Aura.Filter, только используется метод validate() вместо магии __invoke(). Мне оно, это API, показалось более простым и понятным. Ну, и к Kontrolio оно ближе:)

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

use Respect\Validation\Exceptions\NestedValidationException; class UserNameRuleException extends NestedValidationException { // }

Ну и наконец-то мы можем провалидировать наши данные. Для начала мы передаем валидатору наше новое правило, чтобы он узнал о нем, и мы смогли его использовать в дальнейшем. В Respect Validation это делается вызовом метода with() с передачей пространства имен, в котором находятся нестандартные правила.

v::with("MyNamespace\\");

Теперь все нестандартные правила, находящиеся в пространстве имен MyNamespace , будут «опознаны» валидатором. Следующий шаг - описать необходимые правила и выполнить валидацию.

v::attribute("name", v::userNameRule()) ->attribute("login", v::alnum("-_")) ->attribute("email", v::email()) ->attribute("password", v::notEmpty()->stringType()->length(null, 64)) ->attribute("agreed", v::trueVal()) ->assert((object) $data);

Обратите внимание на то, как мы применяем наше правило к атрибуту name . Здесь название класса правило трансформировалось в название метода валидатора. Остальные правила, в общем-то, интуитивно понятны.

Отдельно стоит сказать о том, зачем мы приводим массив $data к объекту. Дело в том, что Respect Validation принимает на вход объекты, а не массивы. Это следует учесть при разработке с использованием данной библиотеки.

Обратная связь

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

try { v::with("RespectValidationExample\\"); v::attribute("name", v::userNameRule()) ->attribute("login", v::alnum("-_")) ->attribute("email", v::email()) ->attribute("password", v::notEmpty()->stringType()->length(null, 64)) ->attribute("agreed", v::trueVal()) ->assert((object) $data); } catch (NestedValidationException $ex) { $messages = $ex->getMessages(); }

Используя getMessages() , мы получим плоский массив всех сообщений, который валидатор собрал в процессе валидации. Задампив массив, мы получим примерно такой результат:

array(5) { => string(29) “Data validation failed for %s” => string(60) “login must contain only letters (a-z), digits (0–9) and “-_”” => string(25) “email must be valid email” => string(26) “password must not be empty” => string(32) “Attribute agreed must be present” }

Можно поменять сообщения на свои собственные. Возможно, я как-то не так понял эту библиотеку, но мне этот процесс не показался таким уж очевидным: необходимо использовать метод findMessages() на обработанном исключении, в котором вы определяете сообщения не для атрибутов, а для правил.

$ex->findMessages([ "userNameRule" => "Имя пользователя должно состоять из двух слов.", "alnum" => "Ваш логин нам не нравится.", "email" => "Вы явно не хотите давать нам свой e-mail.", "notEmpty" => "Ну и где же ваш пароль?", "agreed" => "Жаль, что вы не согласны." ]);

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

array(5) { => string(40) “Имя пользователя должно состоять из двух слов.” => string(31) “Ваш логин нам не нравится.” => string(25) “email must be valid email” => string(5) “Ну и где же ваш пароль?” => string(9) “Жаль, что вы не согласны.” }

Как видите, сообщение для поля электронной почты не применилось, осталось стандартное. А вот сообщение за индексом 4 наоборот! И это при том, что я использовал не название правила, а название поля. В то время как если бы я использовал название правила (trueVal), моё сообщение бы куда-то затерялось. Комментарии опытных пользователей данной библиотеки очень приветствуются.

Sirius Validation

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

Определяем правила

И снова нам необходимо определить правило для имени пользователя. Мы его напишем как-то так:

class UserNameRule extends AbstractRule { // Сообщения об ошибках const MESSAGE = "Имя пользователя должно состоять из двух слов."; const LABELED_MESSAGE = "{label} должно состоять из двух слов."; public function validate($value, $valueIdentifier = null) { return (bool) preg_match("/^+\s+$/u", $value); } }

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

Теперь давайте опишем логику валидации:

$validator = new Validator; $validator ->add("name", "required | MyApp\Validation\Rule\UserNameRule") ->add("login", "required | alphanumhyphen", null, "Логин может содержать только латинские буквы, черточки и подчеркивания.") ->add("email", "required | email", null, "Пожалуйста, укажите корректный e-mail.") ->add("password", "required | maxlength(64)", null, "Ваш пароль, сударь.") ->add("agree", "required | equal(true)", null, "Почему же вы не согласились?");

Как видите, набор правил весьма прост и читабелен. Для описания мы используем названия, разделенные горизонтальными черточками. Этот подход похож на тот, что используется в Laravel и Kontrolio.

Четвертый аргумент метода add() описывает сообщение об ошибке валидации, которое Sirius использует, если валидация будет провалена. А почему же мы не добавили сообщение для нашего нового правила UserNameRule ?

$validator->add("name", "required | MyApp\Validation\Rule\UserNameRule")

Так это потому, что сообщения уже описаны в константах класса:

class UserNameRule extends AbstractRule { // Сообщения об ошибках const MESSAGE = "Имя пользователя должно состоять из двух слов."; ...

Другой вариант - использовать метод addMessage() самого валидатора:

$validator->addMessage("email", "Пожалуйста, укажите корректный e-mail.");

Обратите внимание, что кастомные правила идентифицируются по полному названию их класса, в то время как в Kontrolio можно задать псевдоним/алиас.

Обратная связь

Чтобы выполнить валидацию, мы вызываем метод валидатора validate() , передавая в него данные:

$data = [ "name" => "Альберт", // Должно быть два слова "login" => "@lbert", // "Запрещенный" символ @ "email" => "что-то не то", // Здесь должен быть e-mail "password" => "" // Пароль вообще не указан // "agreed" нет в массиве, потому что пользователь не установил флажок ]; $validator->validate($data);

В отличие от Respect, Sirius не выкинет исключение, а просто вернет false . Сообщения об ошибках валидации можно получить через метод валидатора getMessages() . Он возвращает ошибки, сгруппированные по атрибутам, так что для прохода по ошибкам нам понадобится два цикла foreach:

foreach ($validator->getMessages() as $attribute => $messages) { foreach ($messages as $message) { echo $message->getTemplate() . "\n"; } }

Здесь $message - объект класса Sirius\Validation\ErrorMessage , у которого есть метод getTemplate() , возвращающий то самое необходимое нам сообщение.

ValitronОпределяем правила

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

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

use Valitron\Validator; Validator::addRule("two_words", function($field, $value) { return (bool) preg_match("/^+\s+$/u", $value); }, "Имя пользователя должно состоять ровно из двух слов.");

Второе отличие - то, как правила применяются к атрибутам. Во всех предыдущих случаях мы видели, что атрибут - вещь как бы первичная.

В Valitron пошли другим путем и на первое место поставили именно правила валидации. Описывая правила, вы как бы применяете атрибуты к этим правилам, а не наоборот.

$validator = new Validator($data); $validator ->rule("two_words", "name")->label("") ->rule("required", [ "name", "login", "email", "password", "agreed" ]) ->rule("slug", "login") ->rule("email", "email") ->rule("accepted", "agreed");

Как видно из примера, в методе rule() мы сначала пишем название правила, а уже затем указываем атрибуты, которые должны соответствовать этому правилу. Более явный пример - правило required , где показано, как атрибуты «принадлежат» этому правилу.

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

Valitron подставляет имена атрибутов в текст сообщения даже в том случае, когда используются нестандартные сообщения об ошибках. Поэтому мы и воспользовались методом label() с пустой строкой, чтобы убрать имя атрибута.

$validator->rule("two_words", "name")->label("") Обратная связь

Конкретно что касается валидации, API библиотеки Valitron практически ничем не отличается от того, что мы уже видели в статье. Чтобы выполнить валидацию мы вызываем метод валидатора validate() :

$validator->validate();

Сообщения об ошибках валидации можно получить с помощью метода getErrors() :

$validator->errors();

Сообщения здесь группирутся по атрибутам точно так же, как и в Sirius Validation, за исключеним того, что для сообщения нет отдельного класса, и мы получаем обычный многомерный массив.

foreach ($validator->errors() as $attribute => $messages) { foreach ($messages as $message) { echo $message . "\n"; } } Kontrolio

Ну и наконец, последняя библиотека на сегодня - моя собственная разработка под названием Kontrolio .

Определяем правила

Снова, в пятый раз мы создадим правило валидации для имени пользователя. Всё относительно просто и стандартно:

namespace MyProject\Validation\Rules; use Kontrolio\Rules\AbstractRule; class TwoWords extends Kontrolio\Rules\AbstractRule { public function isValid($input = null) { return (bool) preg_match("/^+\s+$/u", $input); } }

Теперь мы создаем фабрику и регистриуем правило в ней, используя метод extend() :

namespace MyProject; use Kontrolio\Factory; use MyProject\Validation\Rules\TwoWords; $factory = Kontrolio\Factory::getInstance()->extend();

После регистрации правила мы можем воспользоваться им в том числе по имени - two_words . Давайте создадим валидатор:

$data = [ "name" => "Альберт", // Должно быть два слова "login" => "@lbert", // "Запрещенный" символ @ "email" => "что-то не то", // Здесь должен быть e-mail "password" => "" // Пароль вообще не указан // "agreed" нет в массиве, потому что пользователь не установил флажок ]; $rules = [ "name" => "two_words", "login" => "sometimes|alphadash", "email" => "email", "password" => "length:1,64", "agreed" => "accepted" ]; $messages = [ "name" => "Имя пользователя должно состоять из двух слов.", "login" => "Ваш логин нам не нравится.", "email" => "Вы явно не хотите давать нам свой e-mail.", "password" => "Ну и где же ваш пароль?", "agreed" => "Жаль, что вы не согласны." ]; $validator = $factory->make($data, $rules, $messages);

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

$rules = [ "name" => new TwoWords, "login" => , "email" => new Email, "password" => new Length(1, 64), "agreed" => new Accepted ]; Обратная связь

Валидация запускается всё тем же методом validate() :

$validator->validate();

Теперь мы можем получить сообщения об ошибках, используя один из методов getErrors() или getErrorsList() . Первый метод позволяет сделать более сложный вывод ошибок, тогда как второй возвращает плоский массив. Используя getErrors() мы можем вывести сообщения как-то так:

А с getErrorsList() можно сделать более простой список сообщений:

Итог

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

Aura.Filter

Respect Validation

Sirius Validation

Valitron

Kontrolio

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

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

Благодарю за прочтение. Сделайте правильный выбор.

Теги: Добавить метки

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.

About this generic PHP form validation script

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 script

You can download the PHP form validation script below:
The zip file contains the form validation script formvalidator.php, documentation and usage samples.

Using the PHP form validation script

Include formvalidator.php in your form processing script

require_once "formvalidator.php"

Create a FormValidator object and add the form validation descriptors.

$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");

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.

Validate the form by calling ValidateForm() function

if(!$validator->ValidateForm()) { echo "Validation Errors:"; $error_hash = $validator->GetErrors(); foreach($error_hash as $inpname => $inp_err) { echo "

$inpname: $inp_err

\n"; } } Example

The example below will make the idea clearer

Name: Email:

Adding Custom Validation

If you want to add a custom validation, which is not provided by the validation descriptors, you can do so. Here are the steps:

Create a class for the custom validation and override the DoValidate() function

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

Add the custom validation object

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

Here 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.
email	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

Доброго всем вечера (скорее ночи – прим.ред.). Сегодня мы будем немного совершенствовать ту . Для начала научимся делать проверку формы на php и сделаем некоторые манипуляции по защите .

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

Изменено название полей формы . Вы спросите – на кой хрен нам это надо? А всё просто, отвечу я вам. Насколько мне известно, то некоторые спам боты рыскают по сайтам в поисках форм, и заполняют их, ориентируясь на названия этих полей. По идее если они не находят совпадений, то уходят восвояси, чего нам и надо. Конечно степень этой защиты не думаю, что особо велик, но от нас не убудет, а если писем спама уменьшится на 1 письмо, это уже будет хорошо=).

Проверка на правильность ввода адреса почты . В 17 строке используется оператор elseif, который будет проверяться, если if вернул нам положительный ответ, то есть сказал, что адрес почты вообще отсутствует, то есть не был введён. Здесь мы используем функцию preg_match, которая позволяет сравнить введённый адрес с регулярным выражением . Про регулярные выражения возможно я напишу кратко потом, а пока стоит знать, что регулярное выражение создаёт некий шаблон, с которым сверяется наша строка. И если, в нашем случае, введённый адрес не совпадает с выражением, то опять же будет выведена ошибка. Для примера вот ещё парочку регулярных выражений:
|^[-а-яе\s\.,;:\?!]+$|i – это регулярное выражение позволяет использовать только русский алфавит и некоторые символы типа пробела, точки, запятой и пр.
#http://[-a-z0-9_.]+[-a-z0-9_:@&?=+,.!/~*’%$]*\.(html?|php)#i – а это выражение позволяет проверить правильность написание адреса в интернете.

Далее используется оператор else, куда уже перенесён весь наш код по отправке письма. Правила проверки можно создать самому в любом количестве, просто дописывайте новые elseif, как например для проверки адреса почты, и будет вам счастье.

Контактное лицо:

Почта для связи:

Сообщение:

Вот так можно проверять ваши формы на PHP, не прибегая ни к чему постороннему. В следующий раз в посте на тему форм, думается мне, будет рассмотрена валидация форм на jQuery. А пока жду ваших комментариев и пожеланий. Всем спокойной ночи и весёлого утра=).

Facebook

Twitter

Вконтакте

Одноклассники

Google+