Что такое серверная валидация
Перейти к содержимому

Что такое серверная валидация

  • автор:

Доброго времени, хаброчеловеки!

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

Проблема

Часто замечаю, что разработчики активно используют исключения (exceptions) для уведомления об ошибках валидации данных. Продемонстрирую примером (поскольку C# мне ближе, буду использовать его):

public void Validate( string userName, string userPassword)
<
if ( /*проверяем имя пользователя*/ )
throw new InvalidUsernameException();
if ( /*проверяем пароль*/ )
throw new InvalidPasswordException();
>

Далее это используется примерно так:

public void RegisterUser ( string username, string password) try ValidateUser(username, password);
>

catch (InvalidUsernameException ex) //добавляем в коллекцию ошибок
>

catch (InvalidPasswordException ex) //добавляем в коллекцию ошибок
>

Что плохого в этом примере?
— используются исключения (exceptions) на этапе бизнес валидации. Важно помнить, что ошибки валидации данных != ошибкам работы приложения;
— использование исключений на этапе бизнес валидации может привести к падению приложения. Такое может произойти, например, если человек забудет написать ещё один блок catch для новых правил валидации;
— код выглядит некрасиво;
— подобное решение сложно тестировать и поддерживать.

Решение

Механизм валидации данных можно реализовать при помощи паттерна Composite (компоновщик).
Нам потребуется непосредственно сам объект валидатор, который непосредственно проверяет данные на соответствие определённым правилам, композитный валидатор, который инкаплусирует в себе коллекцию валидаторов, а также дополнительный класс, используемый в
качестве хранилища результата валидации и коллекции ошибок — ValidationResult. Рассмотрим вначале последний:

public class ValidationResult private bool isSucceedResult = true ;
private readonly List resultCodes = new List ();

public ValidationResult(ResultCode code) isSucceedResult = false ;
resultCodes.Add(code);
>

public static ValidationResult SuccessResult get < return new ValidationResult(); >
>

public void AddError(ResultCode code) isSucceedResult = false ;
resultCodes.Add(code);
>

public void Merge(ValidationResult result) resultCodes.AddRange(result.resultCodes);
isSucceedResult &= result.isSucceedResult;
>
>

Теперь перейдём непосредственно к механизму валидации. Нам необходимо создать базовый класс Validator, от которого будут наследоваться все валидаторы:

public abstract class Validator public abstract ValidationResult Validate();
>

У объектов-валидаторов существует 1 метод, который запускает процедуру проверки и возвращает результат.

CompositeValidator — класс, содержащий в себе коллекцию валидаторов и запускающий механизм проверки у всех дочерних объектов:

public class CompositeValidator : Validator private readonly List validators = new List ();

public void Add(Validator validator) validators.Add(validator);
>

public void Remove(Validator validator) validators.Remove(validator);
>

public override ValidationResult Validate() ValidationResult result = ValidationResult.SuccessResult;
foreach (Validator validator in validators) result.Merge(validator.Validate());
>
return result;
>
>

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

Использование

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

public class UserNameValidator: Validator private readonly string userName;

public UserNameValidator( string userName) this .userName= userName;
>

public override ValidationResult Validate() if ( /*параметр не прошёл проверку на условие, например userName = null*/ ) return new ValidationResult(ResultCode.UserNameIncorrect);
>

Аналогично получаем UserPasswordValidator.

Теперь у нас есть всё, чтобы использовать новый механизм валидации данных:

public ValidationResult ValidateUser( string userName, string userPassword)
CompositeValidator validator = new CompositeValidator();
validator.add( new UserNameValidator(userName));
validator.add( new UserPasswordValidator(userPassword));

public void RegisterUser ( string username, string password) ValidationResult result = ValidateUser(username, password);

if (result.IsSucceed) //успешная валидация
>

else //получаем ошибки валидации result.GetResultCodes() и обрабатываем соответствующим образом
>

Выводы

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

Заключение

В дальнейшем можно применить несколько улучшений к механизму валидации, а именно:
— инкапсулировать все валидаторы в одну сборку и создать фабрику, которая будет возвращать готовый механизм валидации для различных условий (проверка данных для регистрации пользователя, проверка данных при авторизации и т.д.);
— базовый класс Validator можно заменить на интерфейс, кому как нравится;
— правила валидации можно хранить в одном месте, для более удобного управления;
— можно написать обработчик ошибок валидации, который будет сопоставлять коды ошибок и сообщения, выводимые пользователям на UI, в таком случае ещё сильнее упрощается процесс добавления новых валидаторов. Также отпадает проблема локализации сообщений.

Просьба сильно не пинать за возможные ошибки в написании и изложении. Я очень старался)
С удовольствием выслушаю критику и пожелания по поводу реализации и архитектуры.

* All source code was highlighted with Source Code Highlighter .

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

Валидация форм на стороне клиента

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

Начальные требования: Владение компьютером, достаточное понимание HTML, CSS, и JavaScript.
Цель: Понять, что такое валидация на стороне клиента, почему это важно и как применять различные техники для её реализации.

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

Однако, не следует рассматривать валидацию на стороне клиента как достаточную меру безопасности! Любые данные, отправляемые через форму, необходимо дополнительно проверять на безопасность и на стороне сервера, поскольку валидацию на стороне клиента достаточно просто обойти и она может не остановить злоумышленников. Чтобы лучше понимать потенциальные угрозы, рекомендуем ознакомиться с разделом Безопасность вебсайтов; валидация на стороне сервера выходит за рамки этого модуля, но о ней следует помнить.

Что такое валидация формы?

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

  • «Обязательное поле» (Вы не можете оставить поле пустым).
  • «Пожалуйста, введите номер телефона в формате xxx-xxxx» (Чтобы данные считались корректными, их необходимо указать в определённом формате).
  • «Пожалуйста, введите корректный email-адрес» (вы ввели данные в неправильном формате).
  • «Длина пароля должна быть от 8 до 30 символов и включать одну заглавную букву, один символ, и одну цифру.» (Требования к формату данных достаточно конкретные).

Это называется валидацией формы. По мере ввода, браузер и/или сервер проверяют данные, чтобы определить, соответствуют ли они требуемому формату. Валидация, выполняемая в браузере, называется валидацией на стороне клиента, а выполняемая на сервере — валидацией на стороне сервера. В этом разделе мы сосредоточимся на валидации, выполняемой на стороне клиента.

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

Мы хотим максимально упростить заполнение веб-форм. Тогда почему мы настаиваем валидации данных? На это есть три основные причины:

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

Предупреждение: Никогда не доверяйте данным, передаваемым на сервер клиентской программой. Даже если ваша форма правильно валидируется и не допустит введение потенциально вредоносных данных на стороне клиента, злоумышленники по-прежнему могут изменить сетевой запрос.

Типы валидации на стороне клиента

Существует два типа валидации на стороне клиента, с которыми вы столкнётесь в Интернете:

  • Встроенная валидация форм использует функционал валидации HTML5, который мы неоднократно обсуждали в этом модуле. HTML5-валидация обычно не требует большого количества JavaScript-кода и демонстрирует лучшую производительность, но не настолько настраиваема, как валидация с помощью JavaScript.
  • JavaScript-валидация кодируется с помощью JavaScript. Она полностью настраиваема, но требует программирования всей логики (или использования библиотеки).

Использование встроенной валидации форм

Одной из самых важных функций элементов форм HTML5 (en-US) является способность валидировать бóльшую часть пользовательских данных без использования JavaScript. Это выполняется с помощью атрибутов валидации у элементов формы. Многие из них мы уже рассмотрели в этом курсе:

  • required (en-US): Определяет, что для отправки формы данное поле предварительно должно быть заполнено.
  • minlength (en-US) и maxlength (en-US): Задаёт минимальную и максимальную длину текстовых данных (строк)
  • min (en-US) и max (en-US): Задаёт минимальное и максимальное значение для поля, расчитанного на числовой тип данных
  • type : Определяет тип данных, на который рассчитано поле: число, email-адрес или какой-то другой предустановленный тип
  • pattern : С помощью регулярного выражения, определяет шаблон, которому должны соответствовать вводимые данные.

Если данные, введённые в поле формы, соответствуют правилам перечисленных выше атрибутов, они считаются валидными, если нет — не валидными

Когда элемент валиден, справедливы следующие утверждения:

  • Элемент соответствует CSS-псевдоклассу :valid , позволяющему стилизовать только валидные элементы.
  • Если пользователь пытается отправить данные, браузер отправит форму при условии, что ничто другое (например, JavaScript) не помешает ему это сделать

Когда элемент не валиден, справедливы следующие утверждения:

  • Элемент соответствует CSS-псевдоклассу :invalid или, в зависимости от ошибки, другим псевдоклассам (например, :out-of-range ), которые позволяют применять определённые стили к элементам, не являющимся валидными.
  • Если пользователь пытается отправить данные, браузер заблокирует форму и выведет сообщение об ошибке.

Примеры встроенной валидации форм

В этом разделе мы протестируем некоторые из атрибутов, которые обсуждали выше.

Простой начальный файл

Давайте начнём с простого примера: поле, позволяющее указать своё предпочтение — банан или вишня. Этот пример включает обычное текстовое поле , связанный с ним элемент и кнопку отправки формы . Исходный код можно найти на GitHub по адресу fruit-start.html, а ниже приведён рабочий пример.

form> label for="choose">Would you prefer a banana or cherry?label> input id="choose" name="i_like" /> button>Submitbutton> form> 
input:invalid  border: 2px dashed red; > input:valid  border: 2px solid black; > 

Для начала скопируйте файл fruit-start.html в новую папку на вашем жёстком диске.

Атрибут required

Самым простым в HTML5-валидации является атрибут required (en-US) . Добавьте его к элементу, чтобы сделать заполнение обязательным. Элемент с данным атрибутом соответствует CSS-псевдоклассу :required , а если поле ввода пустое, вместо отправки формы отобразится сообщение об ошибке. Пока поле пустое, оно также будет соответствовать CSS-псевдоклассу :invalid .

Добавьте к полю атрибут required , как показано ниже.

form> label for="choose">Would you prefer a banana or cherry? (required)label> input id="choose" name="i_like" required /> button>Submitbutton> form> 

Обратите внимание на CSS, который включён в файл примера:

input:invalid  border: 2px dashed red; > input:invalid:required  background-image: linear-gradient(to right, pink, lightgreen); > input:valid  border: 2px solid black; > 

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

Примечание: Рабочий пример можно найти на GitHub по адресу fruit-validation.html (отдельно можно найти исходный код.)

Попробуйте отправить форму без введения значения. Обратите внимание, что не валидное поле получает фокус, появляется сообщение об ошибке («Заполните это поле») и блокируется отправка формы.

Наличие атрибута required у любого элемента, который его поддерживает, означает, что элемент соответствует CSS-псевдоклассу :required , независимо от того, имеет он значение или нет. Если элемент не содержит значение, он будет соответствовать псевдоклассу :invalid .

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

Валидация с помощью регулярного выражения

Ещё одной полезной функцией валидации является атрибут pattern , который в виде значения принимает Регулярное выражение. Регулярное выражение (regex) — это шаблон, который может быть использован для сопоставления набора символов в текстовой строке, поэтому они идеально подходят для валидации формы и используются для множества других целей в JavaScript.

Регулярные выражения достаточно сложны, и мы не будем подробно рассматривать эту тему в данной статье. Ниже приведены несколько примеров, чтобы дать вам представление о том, как они работают.

  • a — Соответствует одному символу a (не b , не aa , и так далее).
  • abc — Соответствует символу a , за которой следует b , за которой следует c .
  • ab?c — Соответствует символу a , за которым опционально может следовать b , за которым следует c . ( ac или abc )
  • ab*c — Соответствует символу a , за которым опционально может следовать любое количество символов b , за которыми следует c . ( ac , abc , abbbbbc , и так далее).
  • a|b — Соответствует символу a или b .
  • abc|xyz — Соответствует в точности abc или в точности xyz (но не abcxyz или a или y , и так далее).

Есть еще много возможностей, которые мы не упомянули. Полный список со множеством примеров можно найти в документации по Регулярным выражениям

Давайте рассмотрим пример. Добавьте в атрибут pattern следующий шаблон:

form> label for="choose">Would you prefer a banana or a cherry?label> input id="choose" name="i_like" required pattern="[Bb]anana|[Cc]herry" /> button>Submitbutton> form> 
input:invalid  border: 2px dashed red; > input:valid  border: 2px solid black; > 

Это даёт нам следующее обновление — опробуйте его:

Примечание: Рабочий пример можно найти на GitHub по адресу fruit-pattern.html (исходный код.)

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

Примечание: Некоторым типам элементов для валидации с помощью регулярного выражения не требуется атрибут pattern . Например, поле с типом email валидирует значение по шаблону одного email-адреса или, если присутствует атрибут multiple (en-US) , шаблону списка email-адресов, разделённых запятыми.

Примечание: Элемент (en-US) не поддерживает атрибут pattern .

Ограничение длины вводимых значений

Можно ограничить максимально допустимое количество символов для текстовых полей или (en-US) используя атрибуты minlength (en-US) и maxlength (en-US) . Поле будет не валидным, если количество символов его содержимого будет меньше minlength (en-US) или больше maxlength (en-US) .

Зачастую браузеры не позволяют пользователям вводить в текстовое поле значение, длина которого превышает максимально допустимую. Можно существенно повысить удобство использования, если помимо ограничения в атрибуте maxlength добавить доступный индикатор, отображающий текущее и максимально допустимое количество символов, что даст пользователю возможность уместить содержимое в заданные рамки. Хорошим примером является окно написания твита в Twitter. Для реализации такого функционала можно использовать JavaScript, включая решения, использующие maxlength .

Ограничение допустимых значений

В полях, предназначенных для ввода чисел (например, ), диапазон допустимых значений можно определить с помощью атрибутов min (en-US) и max (en-US) . Если поле содержит значение за пределами данного диапазона, оно будет не валидным.

Давайте рассмотрим другой пример. Создайте новую копию файла fruit-start.html.

Содержимое элемента замените на:

form> div> label for="choose">Would you prefer a banana or a cherry?label> input type="text" id="choose" name="i_like" required minlength="6" maxlength="6" /> div> div> label for="number">How many would you like?label> input type="number" id="number" name="amount" value="1" min="1" max="10" /> div> div> button>Submitbutton> div> form> 
  • Здесь мы в поле с типом text атрибутам minlength и maxlength , задали одинаковое значение 6, что соответствует количеству символов в словах banana и cherry.
  • В поле с типом number атрибуту min мы задали значение 1, а атрибуту max значение 10. При вводе чисел за пределами данного диапазона, поле будет становиться не валидным; с помощью стрелок увеличения/уменьшения пользователи не смогут выйти за границы диапазона. Текущее поле не является обязательным для заполнения, поэтому даже после очистки будет оставаться валидным.
input:invalid  border: 2px dashed red; > input:valid  border: 2px solid black; > div  margin-bottom: 10px; > 

Примечание: Рабочий пример можно найти на GitHub по адресу fruit-length.html (исходный код.)

Примечание: (и другие типы, такие как range и date ) могут также принимать атрибут step (en-US) , который задаёт шаг увеличения или уменьшения значения при использовании кнопок вверх и вниз. В примере выше мы явно не указывали атрибут step , поэтому он получает значение по умолчанию, равное 1 . Это значит, что дробные числа, такие как 3.2, будут не валидными.

Полный пример

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

form> p> fieldset> legend>Do you have a driver's license?abbr title="This field is mandatory" aria-label="required">*abbr>legend> input type="radio" required name="driver" id="r1" value="yes">label for="r1">Yeslabel> input type="radio" required name="driver" id="r2" value="no">label for="r2">Nolabel> fieldset> p> p> label for="n1">How old are you?label> input type="number" min="12" max="120" step="1" id="n1" name="age" pattern="\d+"> p> p> label for="t1">What's your favorite fruit?abbr title="This field is mandatory" aria-label="required">*abbr>label> input type="text" id="t1" name="fruit" list="l1" required pattern="[Bb]anana|[Cc]herry|[Aa]pple|[Ss]trawberry|[Ll]emon|[Oo]range"> datalist id="l1"> option>Bananaoption> option>Cherryoption> option>Appleoption> option>Strawberryoption> option>Lemonoption> option>Orangeoption> datalist> p> p> label for="t2">What's your e-mail address?label> input type="email" id="t2" name="email"> p> p> label for="t3">Leave a short messagelabel> textarea id="t3" name="msg" maxlength="140" rows="5">textarea> p> p> button>Submitbutton> p> form> 

И немного CSS для стилизации HTML:

form  font: 1em sans-serif; max-width: 320px; > p > label  display: block; > input[type="text"], input[type="email"], input[type="number"], textarea, fieldset  width: 100%; border: 1px solid #333; box-sizing: border-box; > input:invalid  box-shadow: 0 0 5px 1px red; > input:focus:invalid  box-shadow: none; > 

В статье Атрибуты валидации (en-US) можно найти полный список атрибутов, которые можно использовать для ограничения допустимых значений ввода и типов полей input , которые их поддерживают.

Примечание: Рабочий пример можно найти на GitHub по адресу full-example.html (исходный код.)

Валидация форм с помощью JavaScript

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

Constraint Validation API

Большинство браузеров поддерживают Constraint Validation API, который состоит из набора свойств и методов, доступных на DOM-интерфейсах следующих элементов форм:

  • HTMLButtonElement (представляет элемент )
  • HTMLFieldSetElement (en-US) (представляет элемент )
  • HTMLInputElement (en-US) (представляет элемент )
  • HTMLOutputElement (en-US) (представляет элемент )
  • HTMLSelectElement (en-US) (представляет элемент )
  • HTMLTextAreaElement (en-US) (представляет элемент (en-US))

Для перечисленных выше элементов Constraint Validation API делает доступными следующие свойства.

  • validationMessage : Возвращает локализованное сообщение, описывающее ограничения валидации (если таковые имеются), которым не удовлетворяет определённый элемент. Если элемент не участвует в валидации ( willValidate установлено в false ) или значение элемента удовлетворяет установленным ограничениям (является валидным), будет возвращена пустая строка.
  • validity : Возвращает объект ValidityState , который содержит несколько свойств, описывающих состояние валидности элемента. Подробное описание всех свойств доступности можно найти на странице справочника ValidityState ; ниже приведён список наиболее используемых:
    • patternMismatch : Возвращает true , если значение не соответствует шаблону, указанному в атрибуте pattern , и false если соответствует. Если true, элемент соответствует CSS-псевдоклассу :invalid .
    • tooLong : Возвращает true , если значение длиннее максимальной длины, указанной в атрибуте maxlength , и false если оно короче или равно ей. Если true, элемент соответствует CSS-псевдоклассу :invalid .
    • tooShort : Возвращает true , если значение короче минимальной длины, указанной в атрибуте minlength , и false если оно длинее или равно ей. Если true, элемент соответствует CSS-псевдоклассу :invalid .
    • rangeOverflow : Возвращает true , если значение больше указанного в атрибуте max максимума, и false если меньше или равно ему. Если true, элемент соответствует CSS-псевдоклассам :invalid и :out-of-range
    • rangeUnderflow : Возвращает true , если значение меньше указанного в атрибуте min , и false если больше или равно ему. Если true, элемент соответствует CSS-псевдоклассу :invalid и :out-of-range .
    • typeMismatch : Возвращает true , если значение не соответствует требуемому синтаксису (когда для type задано значение email или url ), и false если синтаксис корректный. Если true , элемент соответствует CSS-псевдоклассу :invalid .
    • valid : Возвращает true , если элемент соответствует всем ограничениям валидации — следовательно, считается валидным, и false если не соответствует какому-то ограничению. Если true, элемент соответствует CSS-псевдоклассу :valid ; иначе :invalid .
    • valueMissing : Возвращает true , если у элемента есть атрибут required , но не введено значенение, иначе возвращает false . Если true, элемент соответствует CSS-псевдоклассу :invalid .

    Также для перечисленных выше элементов Constraint Validation API делает доступными следующие методы.

    • checkValidity() : Возвращает true , если значение элемента проходит валидацию, иначе возвращает false . Если элемент не валиден, данный метод также запускает на нём событие invalid .
    • setCustomValidity(message) : Позволяет добавить в элемент кастомное сообщение об ошибке; при этом элемент будет считаться не валидным и отобразится указанная ошибка. Это позволяет использовать JavaScript-код, чтобы представить ошибку валидации иначе, чем это предусмотрено стандартными средствами валидации HTML5. При сообщении об ошибке данное кастомное сообщение показывается пользователю.
    Реализация кастомного сообщения об ошибке

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

    У этих автоматических сообщений есть два недостатка:

    • Не существует стандартного способа их стилизации с помощью CSS.
    • Они зависят от локали браузера, из-за чего страница может быть на одном языке, а сообщение об ошибке — на другом, как показано на следующем скриншоте браузера Firefox.

    Пример сообщения об ошибке на англоязычной странице в браузере Firefox с настроенным французским языком

    Настройка таких сообщений об ошибках является одной из наиболее распространённых причин использования Constraint Validation API. Давайте рассмотрим простой пример, как это делается.

    Начнём с простого HTML (Не стесняйтесь поместить это в пустой HTML-файл. Вы можете взять за основу свежую копию fruit-start.html, если хотите):

    form> label for="mail" >I would like you to provide me with an e-mail address:label > input type="email" id="mail" name="mail" /> button>Submitbutton> form> 

    Добавьте на страницу следующий JavaScript:

    const email = document.getElementById("mail"); email.addEventListener("input", function (event)  if (email.validity.typeMismatch)  email.setCustomValidity("I am expecting an e-mail address!"); > else  email.setCustomValidity(""); > >); 

    Здесь мы сохраняем ссылку на поле email, а затем добавляем к нему обработчик события, который запускает код обработчика каждый раз, когда в поле меняется значение.

    В коде обработчика мы проверяем, возвращает ли свойство поля email validity.typeMismatch значение true , что значит, что содержащееся значение не соответствует шаблону корректного email-адреса. Если возвращается true , мы вызываем метод setCustomValidity() (en-US) с кастомным сообщением. Это делает поле не валидным, поэтому попытка отправить форму приводит к ошибке и отображается кастомное сообщение об ошибке.

    Если свойство validity.typeMismatch возвращает false , мы вызываем метод setCustomValidity() с пустой строкой. Это делает поле валидным, поэтому форма может быть успешно отправлена.

    Попробовать пример можно ниже:

    Примечание:: Данный пример можно найти на GitHub по адресу custom-error-message.html (отдельно можно найти исходный код.)

    Более подробный пример

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

    Во-первых, HTML. Опять же, не стесняйтесь писать его вместе с нами:

    form novalidate> p> label for="mail"> span>Please enter an email address:span> input type="email" id="mail" name="mail" required minlength="8" /> span class="error" aria-live="polite">span> label> p> button>Submitbutton> form> 

    Эта простая форма использует атрибут novalidate , который отключает автоматическую валидацию браузером; это позволяет нашему скрипту взять управление валидацией на себя. Однако, это не отменяет поддержку Constraint Validation API или псевдоклассов, таких как :valid или ему подобных. Это значит, что хотя браузер автоматически и не проверяет валидность формы перед отправкой данных, вы можете сделать это самостоятельно и соответствующим образом стилизовать форму.

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

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

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

    Перейдём к базовому CSS, чтобы немного улучшить внешний вид формы и обеспечить визуальную обратную связь при введении не валидных данных:

    body  font: 1em sans-serif; width: 200px; padding: 0; margin: 0 auto; > p *  display: block; > input[type="email"]  -webkit-appearance: none; appearance: none; width: 100%; border: 1px solid #333; margin: 0; font-family: inherit; font-size: 90%; box-sizing: border-box; > /* Это стили для не валидных полей */ input:invalid  border-color: #900; background-color: #fdd; > input:focus:invalid  outline: none; > /* Это стили для кастомных сообщений об ошибке */ .error  width: 100%; padding: 0; font-size: 80%; color: white; background-color: #900; border-radius: 0 0 5px 5px; box-sizing: border-box; > .error.active  padding: 0.3em; > 

    Теперь давайте рассмотрим JavaScript, который реализует кастомную валидацию.

    // Существуют разные способы получить DOM-узел; здесь мы определяем саму форму и // поле ввода email и элемент span, в который поместим сообщение об ошибке const form = document.getElementsByTagName("form")[0]; const email = document.getElementById("mail"); const emailError = document.querySelector("#mail + span.error"); email.addEventListener("input", function (event)  // Каждый раз, когда пользователь что-то вводит, // мы проверяем, являются ли поля формы валидными if (email.validity.valid)  // Если на момент валидации какое-то сообщение об ошибке уже отображается, // если поле валидно, удаляем сообщение emailError.textContent = ""; // Сбросить содержимое сообщения emailError.className = "error"; // Сбросить визуальное состояние сообщения > else  // Если поле не валидно, показываем правильную ошибку showError(); > >); form.addEventListener("submit", function (event)  // Если поле email валдно, позволяем форме отправляться if (!email.validity.valid)  // Если поле email не валидно, отображаем соответствующее сообщение об ошибке showError(); // Затем предотвращаем стандартное событие отправки формы event.preventDefault(); > >); function showError()  if (email.validity.valueMissing)  // Если поле пустое, // отображаем следующее сообщение об ошибке emailError.textContent = "You need to enter an e-mail address."; > else if (email.validity.typeMismatch)  // Если поле содержит не email-адрес, // отображаем следующее сообщение об ошибке emailError.textContent = "Entered value needs to be an e-mail address."; > else if (email.validity.tooShort)  // Если содержимое слишком короткое, // отображаем следующее сообщение об ошибке emailError.textContent = `Email should be at least $email.minLength> characters; you entered $email.value.length>.`; > // Задаём соответствующую стилизацию emailError.className = "error active"; > 

    Комментарии объясняют логику хорошо, но кратко:

    • При каждом изменении значения поля, мы производим его валидацию. Если данные валидны, удаляем ранее отображаемые сообщения об ошибках. Если данные не валдны, запускаем showError() , чтобы показать соответствующую ошибку.
    • При каждой попытке отправить форму, мы снова производим валидацию. Если данные валидны, позволяем отправку формы. Если данные не валидны, запускам showError() , чтобы показать соответствующее сообщение об ошибке, а также предотвращаем отправку формы с помощью preventDefault() .
    • Функция showError() использует различные свойства объекта validity поля ввода, чтобы определить тип ошибки и отобразить соответсвущее сообщение.

    Примечание: Рабочий пример можно найти на GitHub по адресу detailed-custom-validation.html (отдельно можно найти исходный код.)

    Constraint Validation API явяется мощным инструментом валидации форм, позволяющим получить контроль над пользовательским интерфейсом, существенно превосходящий возможности HTML и CSS.

    Примечание: Для получения дополнительной информации смотрите руководства Constraint validation guide (en-US) и Constraint Validation API.

    Проверка форм без встроенного API

    В некоторых случаях, например, при необходимости поддержки устаревших браузеров или кастомных элементов формы, вы не сможете или не захотите использовать Constraint Validation API. Вы по-прежнему сможете использовать JavaScript для валидации форм, но для этого всё нужно будет писать самостоятельно.

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

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

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

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

    • SmashingMagazine: Form-Field Validation: The Errors-Only Approach
    • SmashingMagazine: Web Form Validation: Best Practices and Tutorials
    • WebFX: 10 Tips for Optimizing Web Form Submission Usability
    • A List Apart: Inline Validation in Web Forms
    Пример без использования Constraint Validation API

    Чтобы проиллюстрировать это дальше приводится упрощённая версия предыдущего примера, которая работает с устаревшими браузерами.

    HTML почти тот такой же; мы только удалили функционал валидации HTML5.

    form> p> label for="mail"> span>Please enter an email address:span> input type="text" id="mail" name="mail" /> span class="error" aria-live="polite">span> label> p> button type="submit">Submitbutton> form> 

    CSS также не требует особых изменений; мы только заменили CSS-псевдокласс :invalid на реальный класс и не использовали селектор по атрибутам, так как он не работает в Internet Explorer 6.

    body  font: 1em sans-serif; width: 200px; padding: 0; margin: 0 auto; > form  max-width: 200px; > p *  display: block; > input.mail  -webkit-appearance: none; width: 100%; border: 1px solid #333; margin: 0; font-family: inherit; font-size: 90%; box-sizing: border-box; > /* Стилизация не валидных полей */ input.invalid  border-color: #900; background-color: #fdd; > input:focus.invalid  outline: none; > /* Стилизация сообщений об ошибках */ .error  width: 100%; padding: 0; font-size: 80%; color: white; background-color: #900; border-radius: 0 0 5px 5px; box-sizing: border-box; > .error.active  padding: 0.3em; > 

    Существенно изменился только JavaScript-код, который теперь должен выполнять гораздо больше работы.

    // Устаревшие браузеры поддерживают несколько способов получения DOM-узла const form = document.getElementsByTagName("form")[0]; const email = document.getElementById("mail"); // Ниже приведён способ получения узла следующего родственного DOM-элемента // Он опасен, потому что можно создать бесконечный цикл. // В современных браузерах лучше использовать `element.nextElementSibling` let error = email; while ((error = error.nextSibling).nodeType != 1); // Согласно спецификации HTML5 const emailRegExp = /^[a-zA-Z0-9.!#$%&'*+/=?^_`<|>~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$/; // Многие устаревшие браузеры не поддерживают метод `addEventListener` // Есть простой способ заменить его; и далеко не единственный function addEvent(element, event, callback)  let previousEventCallBack = element["on" + event]; element["on" + event] = function (e)  let output = callback(e); // Колбэк, который возвращает `false`, останавливает цепочку колбэков // и прерывает выполнение колбэка события if (output === false) return false; if (typeof previousEventCallBack === "function")  output = previousEventCallBack(e); if (output === false) return false; > >; > // Теперь мы можем изменить наши критерии валидации // Поскольку мы не полагаемся на CSS-псевдокласс, для поля email // нужно явно задать валидный / не валидный класс addEvent(window, "load", function ()  // Проверка, является ли поле пустым (помните, оно не являтеся обязательным) // Если поле не пустое, проверяем содержимое на соответствует шаблону email const test = email.value.length === 0 || emailRegExp.test(email.value); email.className = test ? "valid" : "invalid"; >); // Здесь определяется поведение при вводе пользователем значения поля addEvent(email, "input", function ()  const test = email.value.length === 0 || emailRegExp.test(email.value); if (test)  email.className = "valid"; error.textContent = ""; error.className = "error"; > else  email.className = "invalid"; > >); // Здесь определяется поведение при попытке отправить данные addEvent(form, "submit", function ()  const test = email.value.length === 0 || emailRegExp.test(email.value); if (!test)  email.className = "invalid"; error.textContent = "I expect an e-mail, darling!"; error.className = "error active"; // Некоторые устаревшие браузеры не поддерживают метод event.preventDefault() return false; > else  email.className = "valid"; error.textContent = ""; error.className = "error"; > >); 

    Результат выглядит следующим образом:

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

    Проверьте свои навыки!

    Вы дошли до конца этой статьи, но можете ли вы вспомнить самую важную информацию? Вы можете найти дополнительные тесты, чтобы убедиться, что вы сохранили эту информацию, прежде чем двигаться дальше — Test your skills: Form validation (en-US) .

    Заключение

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

    • Отображать явные сообщения об ошибках.
    • Снисходительно относиться к формату ввода.
    • Указывать, где именно возникла ошибка. Особенно в больших формах.

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

    In this module

    • Ваша первая форма (en-US)
    • Как структурировать веб-формы
    • Основные встроенные элементы формы (en-US)
    • Типы полей ввода в HTML5 (en-US)
    • Другие элементы формы (en-US)
    • Стилизация веб-форм
    • Продвинутая стилизация форм (en-US)
    • UI псевдоклассы (en-US)
    • Валидация форм на стороне клиента
    • Отправка данных формы

    Продвинутые темы

    • Как создавать кастомные элементы формы
    • Отправка форм с помощью JavaScript
    • Таблица совместимости CSS-свойств для элементов формы (en-US)

    Found a content problem with this page?

    • Edit the page on GitHub.
    • Report the content issue.
    • View the source on GitHub.

    This page was last modified on 3 авг. 2023 г. by MDN contributors.

    Your blueprint for a better internet.

    Andipas

    Одна из наиболее частых задач в web-разработке — создание форм и проверка их на корректность вводимых данных. Для того чтобы это все было более юзабильно, есть специальный jQuery Validation Plugin. Этот плагин позволяет на стороне клиента, проверять форму на корректность вводимых данных, соответственно не требуется перезагрузка страницы.

    Чтобы облегчить создание форм в web-приложениях, существуют различные библиотеки. Одна из них HTML_QuickForm2 и ее доработка jQuickForm которая должна была подружить, этот построитель форм с jQuery Validation Plugin. Вышло на мой взгляд не плохо, но слишком наворочено. К тому же автор давно не развивал это дополнение, последний раз когда я скачивал этот пакет, не работала клиентская валидация, а ведь изначально именно для этого и был разработанн этот пакет.

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

    У всех этих «помошников» построителей форм, есть минусы — 1. Необходимо разбиратся с интерфейсами классов, как правило, сделано удобно, разобраться можно быстро 2. Сложности кастомизации, изменения дизайна форм 3. Все эти надстройки жрут ресурсы

    После размышлений над этим, я создал небольшой класс, который занимается только валидацией , правила задаются аналогично jQuery Validation Plugin. Объект этого класса создает необходимый код JS для валидации на стороне клиента (если нужно) и также проверяет формы на стороне сервера по тем же правилам. Привожу пример —

     addRule('login', 'required'); $oValid->addRule('login', 'minlength', 5); $oValid->addRule('pass', 'required'); $oValid->addRule('pass', 'minlength', 5); $oValid->addRule('re_pass', 'equalTo', 'pass'); $oValid->addRule('email', 'required'); $oValid->addRule('email', 'email'); if (isset($_POST['login'])) < if ($oValid->check()) < // Здесь можно проверить дополнительно, на повторный логин и мыло например echo 'Валидация успешна'; // Сохраняем данные, редиректим если надо >> ?>   Valid - mini validator        

    getReq('login');?>" /> getErr('login');?>

    getErr('pass');?>

    getErr('re_pass');?>

    getErr('email');?>

    " submit"/>

    getJS('reg_form'); ?>

    Пример реализации можно посмотреть в моем mini MVC framework, там уже реализована регистрация, авторизация - mFram

    Как проверить валидность введенных данных в форме

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

    Клиентская валидация

    Клиентская валидация осуществляется на стороне пользователя (в браузере) с использованием JavaScript. Она позволяет быстро проверить данные и предотвратить отправку некорректной информации на сервер.

    Встроенная валидация HTML5

    HTML5 предоставляет встроенные атрибуты для валидации форм, такие как required , pattern , min , max и др.

    Пример использования атрибута required :

      

    Валидация с использованием JavaScript

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

      
    document.getElementById('myForm').addEventListener('submit', function(e) < e.preventDefault(); var username = document.getElementById('username').value; if (username.length < 3) < alert('Имя пользователя должно содержать минимум 3 символа'); >else < this.submit(); >>);

    Веб-разработчик: новая работа через 9 месяцев
    Получится, даже если у вас нет опыта в IT

    Серверная валидация

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

    В зависимости от языка программирования и фреймворка, используемых на сервере, процесс валидации может отличаться. Ниже приведен пример серверной валидации с использованием Node.js и Express:

    const express = require('express'); const app = express(); app.use(express.urlencoded(< extended: true >)); app.post('/submit-form', (req, res) => < const < username >= req.body; if (username.length < 3) < res.status(400).send('Имя пользователя должно содержать минимум 3 символа'); >else < res.send('Данные приняты'); >>); app.listen(3000, () => < console.log('Сервер работает на порту 3000'); >);

    �� Важно помнить, что валидация данных является критическим компонентом веб-разработки. Использование клиентской и серверной валидации вместе обеспечит безопасность и корректность данных, отправленных на сервер.

Добавить комментарий

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