Безрассудный validation php. Валидация и очистка данных средствами PHP. Некорректная информация

Validation of data is a fundamentally important aspect of a CRUD application. You need to be sure that the data that the client is sending you is what you expect. This is not just for security reasons, protecting your data from misuse and intentional corruption, but also simply from unintentional mistakes in submitting data. Strings limited to a certain length, dates in a particular format and required fields are all common uses of data validation.

The Editor PHP libraries provide two different validation methods:

• Field based, where each individual value submitted is independently validated: Field->validator() .
• Global validation, where the data submitted by the client-side can be validated as a whole: Editor->validator() .

Legacy information (v1.6-)

Please note that PHP validation in Editor 1.6 and older was a little different. The older form of validation will still work with the 1.7+ libraries and its documentation remains available , but for new projects use the validation style discussed here.

Field validation is the one you will most commonly work with - for example checking that an e-mail address field actually contains an e-mail address, and Editor provides a number of ready to use validators for the most common data types as well as the ability to specify your own. Global validation can be useful when checking dependencies between fields and conflicts in the existing data set.

Field validation

The Editor PHP libraries provide a validator() method for the Field class and a number of pre-built validation methods in the Validate class. Each of these validation methods returns a function which is executed when required to validate submitted data.

Consider the following example - the Validate::minNum() function is configured with a number and returns a function that can be used for the field validator.

Field::inst("age") ->validator(Validate::minNum(16));

Please see below for more detailed examples.

Validation options

Each validation method provided by the Validation class can optionally accept parameters to tell it how to validate data (for example the minLen method will accept an integer to indicate the minimum length of an acceptable string), but all optionally accept a ValidateOptions class instance. This class defines a number of options that are shared between all validation methods.

The ValidateOptions class is constructed with ValidateOptions::inst() (or new ValidateOptions() in PHP 5.4+) similar to the other Editor classes. It has three methods that can be used to alter the validation behaviour:

• ->allowEmpty(boolean) : How to handle empty data (i.e. a zero length string):
  • true (default) - Allow the input for the field to be zero length
  • false - Disallow zero length inputs
• ->message(string) : the error message to show if the validation fails. This is simply "Input not valid" by default, so you will likely want to customise this to suit your needs.
• ->optional(boolean) : Require the field to be submitted or not. This option can be particularly useful in Editor as Editor will not set a value for fields which have not been submitted - giving the ability to submit just a partial list of options.
  • true (default) - The field does not need to be be in the list of parameters sent by the client.
  • false - The field must be included in the data submitted by the client.

Example - setting a custom error message Field::inst("stock_name") ->validator(Validate::minNum(10, new ValidateOptions::inst() ->message("Stock name must be at least 10 characters long"))); Multiple validators

It can often be useful to use multiple validators together, for example to confirm that an input string is less than a certain number of characters and also that it is unique in the database. Multiple validators can be added to a field simply by calling the Field->validator() method multiple times. Rather than overwriting the previous validator it will in fact add them together. They are run in the sequence they were added, and all validators must pass for the data to be accepted as valid.

As an example consider the following code which will check the min and max length of the data, and also that it is unique:

Field::inst("stock_name") ->validator(Validate::minLen(10)) ->validator(Validate::maxLen(12)) ->validator(Validate::unique());

Ready to use field validators

The Validate class in the Editor PHP libraries has a number of methods which can be used to perform validation very quickly and easily. These are:

Basic

• none(ValidateOptions $cfg=null) - No validation is performed
• basic(ValidateOptions $cfg=null) - Basic validation - only the validation provided by ValidateOptions is performed
• required(ValidateOptions $cfg=null) - The field must be submitted and the data must not be zero length. Note that Editor has the option of not submitting all fields (for example when inline editing), so the notEmpty() validator is recommended over this one.
• notEmpty(ValidateOptions $cfg=null) - The field need not be submitted, but if it is, it cannot contain zero length data
• boolean(ValidateOptions $cfg=null) - Check that boolean data was submitted (including 1, true on, yes, 0, false, off and no)

Numbers

• numeric(string $decimalChar=".", ValidateOptions $cfg=null) - Check that any input is numeric.
• minNum(integer $min, string $decimalChar=".", ValidateOptions $cfg=null) - Numeric input is greater than or equal to the given number
• maxNum(integer $max, string $decimalChar=".", ValidateOptions $cfg=null) - Numeric input is less than or equal to the given number
• minMaxNum(integer $min, integer $max, string $decimalChar=".", ValidateOptions $cfg=null) - Numeric input is within the given range (inclusive)

Strings

• email(ValidateOptions $cfg=null) - Validate an input as an e-mail address.
• ip(ValidateOptions $cfg=null) - Validate as an IP address.
• minLen(integer $min, ValidateOptions $cfg=null) - Validate a string has a minimum length.
• maxLen(integer $max, ValidateOptions $cfg=null) - Validate a string does not exceed a maximum length.
• minMaxLen(integer $min, integer $max, ValidateOptions $cfg=null) - Validate a string has a given length in a range
• noTags(ValidateOptions $cfg=null) - Don"t allow HTML tags
• url(ValidateOptions $cfg=null) - Validate as an URL address.
• values(array $values, ValidateOptions $cfg=null) - Allow only values which have been specified in an array of options (the first parameter). This could be useful if you wish to have free-form input or event a select list, and want to confirm that the value submitted is within a given data set (see also the dbValues() method if valid values are stored in a database). Note that the values given in the values array are checked against the submitted data as case-sensitive data (i.e. `"A" != "a").
• xss(ValidateOptions $cfg=null) - Check to see if the input could contain an XSS attack . This used the Field "s XSS formatting function to determine if the input string needs to be formatted or not.

Date / time

• dateFormat(string $format, ValidateOptions $cfg=null) - Check that a valid date input is given. The format is defined by PHP"s date() method which is used for the parsing of date and time string.

Database

• dbValues(ValidateOptions $cfg=null, string $column=null, string $table=null, Database $db=null, array $valid=null) - Allow only a value that is present in a database column. This is specifically designed for use with joined tables (i.e. ensure that the reference row is present before using it), but it could potentially also be used in other situations where referential integrity is required.
• unique(ValidateOptions $cfg=null, string $column=null, string $table=null, array $db=null) - Ensure that the data submitted is unique in the table"s column.

One-to-many (Mjoin)

Note that these methods are for use with the Mjoin->validator() method (Editor 1.9 and newer). Please see the Mjoin documentation for more details.

• mjoinMinCount($minimum, ValidateOptions $cfg=null) - Require that at least the given number of options / values are submitted for the one-to-many join.
• mjoinMaxCount($maximum, ValidateOptions $cfg=null) - Require that this many or less options / values are submitted for the one-to-many join.

Custom field validators

If the provided methods above don"t suit the kind of validation you are looking for, it is absolutely possible to provide custom validation methods. The validator() Field method will accept a function that returns either true or a string and accepts the following input parameters:

value - The value to be validated

data - The collection of data for the row in question

field -The host Field instance

host - Information about the host Editor instance

The return value should be true to indicate that the validate passed, or a string that contains an error message if the validation failed.

The following simple example shows how a maxLen string check could be implemented with a custom validation method:

Field::inst("last_name") ->validator(function ($val, $data, $field, $host) { return strlen($val) > 50 ? "Name length must be 50 characters or less" : true; });

Field validation examples

Use the Validation.minNum() method to validate an input as numeric and greater or equal to a given number (no validation options specified, so the defaults are used):

// Simple non-empty field Field::inst("age") ->validator(Validate::minNum(16))

As above, but with ValidateOptions used to set the error message:

// Number range check with custom error message Field::inst("range") ->validator(Validate::minNum(16, ValidateOptions::inst() ->message("Minimum age is 16")));

This time validating an e-mail address which cannot be empty and must be submitted:

Field::inst("email") ->validator(Validate::email(ValidateOptions::inst() ->allowEmpty(false) ->optional(false)));

A join with dbValues which will accept an empty value, which is stored as null on the database:

Field::inst("users.site") ->options(Options::inst() ->table("sites") ->value("id") ->label("name")) ->validator(Validate::dbValues()),

Allow only certain values to be submitted:

Field::inst("group") ->validator(Validate::values(array("CSM", "FTA", "KFVC")))

The following shows a complete Editor example with validation methods applied:

Ditor::inst($db, "staff") ->fields(Field::inst("first_name") ->validator(Validate::notEmpty(ValidateOptions::inst() ->message("A first name is required"))), Field::inst("last_name") ->validator(Validate::notEmpty(ValidateOptions::inst() ->message("A last name is required"))), Field::inst("position"), Field::inst("email") ->validator(Validate::email(ValidateOptions::inst() ->message("Please enter an e-mail address"))), Field::inst("office"), Field::inst("extn"), Field::inst("age") ->validator(Validate::numeric()) ->setFormatter(Format::ifEmpty(null)), Field::inst("salary") ->validator(Validate::numeric()) ->setFormatter(Format::ifEmpty(null)), Field::inst("start_date") ->validator(Validate::dateFormat("Y-m-d")) ->getFormatter(Format::dateSqlToFormat("Y-m-d")) ->setFormatter(Format::dateFormatToSql("Y-m-d"))) ->process($_POST) ->json();

Global validators

You may also find it useful to be able to define a global validator that will execute whenever a request is made to the server and the Editor->process() method is executed. This method can be used to provide security access restrictions, validate input data as a whole or even to check that a user is logged in before processing the request.

Function

The function that is given to the Editor->validator() method has the following signature:

$editor - The Editor instance that the function is being executed for.

$action - The action being performed - this will be one of:

• Editor::ACTION_READ - Read / get data
• Editor::ACTION_CREATE - Create a new record
• Editor::ACTION_EDIT - Edit existing data
• Editor::ACTION_DELETE - Delete existing row(s)
• Editor::ACTION_UPLOAD - Upload a file.

$data - The data submitted by the client.

The return value from the function should be a string if the validation fails, where the string returned is the error message to show the end user. If the validation passes, return an empty string, null or simply have no return statement.

Note that this function is executed only once when the Editor->process() method is called, rather than once per submitted row. Also, as of Editor 1.9, it is possible to add multiple validation functions by calling Editor->validator() multiple times, just as with the field validators. The given validators will run sequentially.

Examples // Allow read only access based on a session variable Editor::inst($db, "table") ->fields(...) ->validator(function ($editor, $action, $data) { if ($action !== Editor::ACTION_READ && $_SESSION["read_only"]) { return "Cannot modify data"; } }) ->process($_POST) ->json(); // Create and edit with dependent validation Editor::inst($db, "table") ->fields(...) ->validator(function ($editor, $action, $data) { if ($action === Editor::ACTION_CREATE || $action === Editor::ACTION_EDIT) { foreach ($data["data"] as $pkey => $values) { if ($values["country"] === "US" && $values["location"] === "London UK") { return "London UK is not in the US"; } } } }) ->process($_POST) ->json(); PHP API documentation

The PHP API developer documentation for the Editor PHP classes is available for detailed and technical discussion about the methods and classes discussed above.

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

Получение массива данных для валидации: $input = Input::all(); Определение правил валидации данных: $rules = array("name" => "required|max:50", "email" => "required|email|unique:users",); Создание экземпляра Validator и валидация данных: $validation = Validator::make($input, $rules); if ($validation->fails()) { return $validation->errors; }

При наличии свойства errors вы получаете доступ к сборщику сообщений, позволяющему легко создавать свои сообщения об ошибках. Конечно же, все правила валидации имеют соощения об ошибках по умолчанию. Стандартные сообщения об ошибках находятся в language/en/validation.php .

Теперь вы знакомы с основными правилами использования класса Validator. Вы готовы к исследованию и изучению правил используемых для проверки ваших данных!

Правила валидации Обязательные данные Проверка на обязательное не пустое значение параметра: "name" => "required" Alpha, Alpha Numeric, & Alpha Dash Проверка на наличие только букв: "name" => "alpha" Проверка на наличие только букв и цифр: "username" => "alpha_num" Проверка на наличие только букв, цифр, тире и символа подчеркивания: "username" => "alpha_dash" Размер Проверка на размер строки строчного атрибута, или диапазон значений числового атрибута: "name" => "size:10" Проверка на диапазон значений: "payment" => "between:10,50"

Примечание: Минимум и максимум включены в диапазон.

Проверка минимального размера атрибута: "payment" => "min:10" Проверка максимального размера атрибута: "payment" => "max:50" Числовые типы Проверка принадлежности атрибута к числовому типу: "payment" => "numeric" Проверка принадлежности атрибута к целочисленному типу: "payment" => "integer" Вхождения и исключения Проверка атрибута на вхождение в массив значений: "size" => "in:small,medium,large" Проверка атрибута на исключение из массива значений: "language" => "not_in:cobol,assembler" Подтверждение

Правило confirmed проверяет, что для данного атрибута есть соответствующее подтверждение * attribute_confirmation *.

Проверка атрибута на подтверждение: "password" => "confirmed"

В этом примере Validator проверяет, что параметр password удовлетворяет условиям password_confirmation из массива валидации.

Акцептирование

Правило accepted проверяет параметр на значение yes или 1 . Это правило проверяет установку обязательных чекбоксов, таких, как, например, флажок согласия с "Условиями предоставления услуг".

Проверка акцептирования: "terms" => "accepted" Соответствия и различия Проверка, что атрибут такой же как, и сравниваемый другой артибут: "token1" => "same:token2" Проверка на то, что атрибут имеет разное значение: "password" => "different:old_password", Регулярные выражения

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

Поверка на удовлетворение регулярному выражению: "username" => "match:/+/"; Уникальность и существование Проверка параметра на уникальность в базе данных: "email" => "unique:users"

В этом примере параметр email проверяется на уникальность в таблице users . Необходимо проверить уникальность атрибута другого столбца, кроме этого? Нет проблем:

Указание другого столбца для проверки: "email" => "unique:users,email_address"

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

Игнорирование указанного ID: "email" => "unique:users,email_address,10" Проверка на наличие атрибута в указанной базе данных: "state" => "exists:states" Указание имени столбца для правила exists: "state" => "exists:states,abbreviation" Даты Проверка того, что параметр даты имеет значение до...: "birthdate" => "before:1986-28-05"; Проверка того, что параметр даты имеет значение после...: "birthdate" => "after:1986-28-05";

Примечание: Проверка before и after использует функцию PHP strtotime .

E-Mail адреса Проверка того, что параметр является E-Mail адресом: "address" => "email"

Примечание: Это правило использует встроенный в PHP метод filter_var .

URLs Проверка того, что параметр есть URL: "link" => "url" Проверка того, что параметр есть активный URL: "link" => "active_url"

Примечание: Правило active_url используетs checkdnsr для проверки активности URL.

Загрузки

Правила mimes проверяют, что загружаемый файл соответствует MIME типу. Это правило использует расширение PHP Fileinfo проверяющее содержимое файла и определяющее его тип. Любые расширения файлов, применимые к этому правилу, определяются в config/mimes.php .

Проверка принадлежности файла определенному типу: "picture" => "mimes:jpg,gif"

Примечание: При проверке не забудьте использовать Input::file() или Input::all().

Проверка того, что файл изображение: "picture" => "image" Проверка на размер файла: "picture" => "image|max:100" Запрос сообщения об ошибке

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

Определение, что атрибут имеет сообщение об ошибке: if ($validation->errors->has("email")) { // The e-mail attribute has errors... } Запрос первого сообщения об ошибке для атрибута: echo $validation->errors->first("email");

Вам может понадобиться обернуть ваше сообщение об ошибке в HTML тэги. Нет проблем. Вызывая:message place-holder, определите формат вторым параметром метода.

Форматирование сообщения об ошибке: echo $validation->errors->first("email", ""); Получение всех сообщений об ошибках для атрибута: $messages = $validation->errors->get("email"); Форматирование всех сообщений об ошибках для аттрибута: $messages = $validation->errors->get("email", ""); Получение всех сообщений об ошибках для всех атрибутов: $messages = $validation->errors->all(); Форматирование всех сообщений об ошибках для всех атрибутов: $messages = $validation->errors->all(""); Прохождение валидации

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

Route::get("register", function() { return View::make("user.register"); }); Route::post("register", function() { $rules = array(...); $validation = Validator::make(Input::all(), $rules); if ($validation->fails()) { return Redirect::to("register")->with_errors($validation); } });

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

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

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

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

Создание массива собственных сообщений об ошибках для Validator: $messages = array("required" => "The:attribute field is required.",); $validation = Validator::make(Input::get(), $rules, $messages);

Отлично! Теперь наши пользовательских сообщения будет использоваться всегда при проверке. Но, что за выражение :attribute в нашем сообщении. Для облегчения вашей жизни, класс Validator заменяет :attribute на атрибут, ввод которго вызвал ошибку. Он даже удалит символ подчеркивания из имени атрибута. Вы также можете использовать :other , :size , :min , :max , и :values заполнители для конструирования ваших сообщений об ошибках.

Примеры пользовательских сообщений об ошибках: $messages = array("same" => "The:attribute and:other must match.", "size" => "The:attribute must be exactly:size.", "between" => "The:attribute must be between:min - :max.", "in" => "The:attribute must be one of the following types: :values",);

Что, если вам нужно определить необходимое сообщение, но только для атрибута электронной почты? Без проблем. Просто укажите сообщение, используя attribute_rule именование:

Определение сообщения для конктретного атрибута: $messages = array("email_required" => "We need to know your e-mail address!",);

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

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

Добавление собственного массива в языковый файл: "custom" => array("email_required" => "We need to know your e-mail address!",) Собственные правила валидации

Laravel предоставляет ряд мощных правил проверки. Тем не менее, вы можете создать свои собственные. Есть два простых способа создания правил проверки. И тот и другой надежны в использовании. Вам остается только выбрать более подходящий для вашего проекта.

Регистрация собственного валидационного правила: Validator::register("awesome", function($attribute, $value, $parameters) { return $value == "awesome"; });

В этом примере мы зарегистрировали новые правила проверки для класса Validator. Это правило получает три параметра. Во-первых, это имя проверяемого атрибута, второй - значение проверяемого атрибута, а третий представляет собой массив из параметров, которые были заданы для правила.

Так выглядит вызов вашего правила:

$rules = array("username" => "required|awesome",);

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

$messages = array("awesome" => "The attribute value must be awesome!",); $validator = Validator::make(Input::get(), $rules, $messages);

или, добавив запись для правила в language/en/validation.php :

"awesome" => "The attribute value must be awesome!",

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

// При построении правила... $rules = array("username" => "required|awesome:yes",); // В правиле... Validator::register("awesome", function($attribute, $value, $parameters) { return $value == $parameters; }

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

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

Сначала, создаете класс Validator который наследует класс Laravel\Validator и размещаете его в application/libraries :

Определение собственного класса: