7. Проверка ввода пользователя

Элементы управления для проверки ввода пользователя (validation controls) в ASP.NET 2.0, CompareValidator, CustomValidator, RangeValidator, RegularExpressionValidator, RequiredFieldValidator, ValidationSummary

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

В ASP.NET проверка всегда производится на сервере плюс в добавление к серверной проверке можно реализовать проверку и на клиенте. Только на клиенте реализовать проверку нельзя: по соображениям безопасности она всегда дублируется на сервере.

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

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

Проверки - это еще и защита Web-приложения от хакеров. Стандартно используются две атаки:

·        spoofing - хакер генерирует специальный код и посылает его серверу, сообщая, что он "прошел" проверку на клиенте. ASP.NET за счет обязательного дублирования проверок такой класс атак отметает радикально.

·        если пользователь может вводить текст неограниченной длины в поля Web-формы, то можно нарваться на переполнение буфера, атаку DDOS или прочие вещи. Проверки и ограничения позволяют решить эту проблему.

Клиентские проверки в ASP.NET реализуются средствами DHTML и JScript. Серверные проверки могут быть реализованы на любом .NET-совместимом языке. Работу с проверками очень упрощает то, что для проверок заранее заготовлены специальные элементы управления - validation controls.

Клиентские проверки (в IE4.0 и более поздних версиях) срабатывают, когда пользователь нажимает на кнопку Submit и работают до отправки данных на Web-сервер. Если проверка не пройдена, данные и не будут посланы на Web-сервер.

В IE5.0 и более поздних, в которых поддерживается DHTML, проверки также могут срабатывать для конкретного элемента управления, когда он теряет фокус.

Учитывая различия в версиях и возможностях броузеров, обычно реализация проверок, которые нормально бы работали на броузерах разных версий - достаточно тяжелая и трудоемкая задача. Использование элементов управления .NET, которые автоматом определяют версию броузера и генерируют нужный код, позволяет эту работу во многом упростить.

Серверные проверки выполняются на сервере. Они могут быть реализованы на любом .NET-совместимом языке и по своему характеру более функциональны, чем клиентские (например, можно сравнивать ввод пользователя с данными, хранящимися на сервере). Для любой клиентской проверки в ASP.NET автоматически создается дублирующий ее серверный код проверки.

Какие элементы управления ASP.NET позволяют реализовать проверки клиентского ввода:

·        CompareValidator - ввод пользователя сравнивается со значением в другом элементе управления, фиксированным значением, со значением из файла или проверяется на соответствие типу данных. Используется очень часто (например, для проверки правильности ввода пароля в двух полях);

·        CustomValidator - можно реализовать свой собственный код проверки (например, проверяем, правильно ли указан номер телефона и т.п.)

·        RangeValidator - проверка, попадает ли введенное пользователем значение в указанный диапазон (например, проверка возраста)

·        RegularExpressionValidator - проверка по шаблону (на соответствие подстановочным символам). Проверяем адреса e-mail, почтовые индексы, ИНН, телефонные номера и т.п. Наиболее часто используемые шаблоны уже реализованы в .NET

·        RequiredFieldValidator - просто проверяется, введено пользователем значение в это поле или нет;

·        ValidationSummary - предназначено для вывода информации о всех ошибках проверки (чтобы пользователь знал, что ему исправлять). Обычно помещается недалеко от кнопки Submit.

Теперь - непосредственно о работе с этими элементами управления.

Принцип работы с validation controls достаточно простой:

1) при помощи Toolbox помещаем на форму нужный validation control;

2) настраиваем его свойство ControlToValidate, определяя тем самым, значение какого элемента управления будет проверяться. Одному обычному элементу управления можно назначить много validation controls. Пока все они не вернут True, будет генерироваться ошибка проверки.

3) настраиваем прочие свойства validation control - выражение для проверки, текст сообщения об ошибке и т.п.

Свойства у разных элементов управления validation разные, но у каждого из них (кроме validation summary) есть два общих свойства:

·        Type - проверяемый тип данных

·        EnableClientScript - нужно ли реализовывать данную проверку на клиенте (по умолчанию нужно). Клиентские проверки всегда будут созданы на JScript.

Validation controls нужно размещать не в любом месте формы, а в правильном, поскольку при возникновении ошибки на месте vc выводится сообщение. Желательно, конечно, располагать его рядом с проверяемым ЭУ.

По умолчанию то сообщение, которое будет выводиться на месте VC и передаваться ValidationSummary, определяется свойством ErrorMessage. Однако текст сообщения, которое будет выводиться на месте VC, можно переопределить при помощи свойства Text. ValidationSumary всегда передается значение ErrorMessage. Если вы используете в форме ValidationSummary, то ЭУ, значение в котором вызвало ошибку, будет помечен красной звездочкой.

То, как будет выглядеть сообщение об ошибке на месте VC, определяется его свойством Display. Это свойство может принимать три значения:

·        Static (по умолчанию) - место под этот элемент управления всегда будет зарезервировано на странице;

·        Dynamic - этот элемент управления будет рендериться, как все остальные, и если сообщения нет, его место будет занято другими компонентами формы

·        None - вывод сообщения на месте VC будет вообще подавлен.

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

·        RequiredFieldValidator - чтобы пользователь не забыл его заполнить;

·        RegularExpressionField - на соответствие маске;

·        CustomValidator - есть ли уже такой номер в нашей базе.

Некоторые особенности работы с проверяющими элементами управления.

Для самого простого элемента управления RequiredFieldValidator предусмотрено свойство InitialValue. Это - то значение, с которым не должно совпасть проверяемое поле. По умолчанию оно пусто, и, значит, пользователь не может оставить значение в проверяемом поле пустым. Если у вас для проверяемого поля используется значение по умолчанию, то значение RequiredFieldValidator желательно поменять на такое же значение.

Проверять на пустое значение можно только при помощи RequiredFieldValidator. Если вам нужно проверять на пустое значение и на что-то еще, используется RequiredFieldValidator и дополнительный проверяющий элемент управления.

Для CompareValidator используются следующие свойства:

·        ValueToCompare - проверка на соответствие константным значениям. Можно указывать несколько константных значений (их нужно будет разделять вертикальной чертой - |).

·        ControlToCompare - проверка на соответствие значению из другого элемента управления. Обычно для сравнения двух значений паролей.

·        Type - проверка на соответствие типу данных.

·        Operators - здесь придется указывать имя операторов сравнения: Equal, NotEqual, GreaterThen, GreaterThanEqual и т.п.

Для RangeValidator используются понятные свойства MinimumValue, MaximumValue и Type.

Особенности работы с RegularExpressionValidator: главное свойство - ValidationExpression. При нажатии на него появляется большое список готовых шаблонов. Можно использовать и свой шаблон (Custom). Список подстановочных символов, которые можно использовать, очень большой.

CustomValidator - самый мощный и самый сложный проверяющий элемент управления. Можно проверять на соответствие формуле, значению из источника данных, значению, возвращаемому COM-компонентом или Web-службой. Используется в сложных ситуациях, например, для проверки паролей, база которых хранится на сервере.

В отличие от других элементов управления, CustomValidator не генерирует серверные и клиентские скрипты за вас - это придется сделать вам. Два главных свойства CustomValidator:

·        ClientValidationFunction - клиентский проверяющий скрипт;

·        OnServerValidate - серверный скрипт.

Конечно, логическое соответствие клиентского и серверного скрипта вам придется обеспечивать и проверять самостоятельно.

Серверная функция для CustomValidator создается на странице Codebehind автоматически, и чтобы до нее добраться, нужно просто щелкнуть два раза мышью в окне дизайнера по объекту CustomValidator. Добраться до значения в проверяемом поле можно при помощи свойства args.Value. Установить отрицательный или положительный результат проверки можно при помощи свойства args.IsValid = False (не прошло) или = True (прошло).

Клиентскую процедуру надо писать на JScript вручную на странице HTML (не Codebehind), сразу после тега Head, например так:

function MyClientValidation(source, arguments)

{

alert("I am running on the client! ");

var intValue = arguments.Value;

if (intValue % 2 == 0)

{

arguments.IsValid = true;

} else {

arguments.IsValid = false;

}

}

Затем в свойствах CustomValidator для свойства ClientValidationFunction указать имя этой функции, а для свойства EnableClientScript установить значение True. Желательно также определиться с версией броузера, в которой будет выполняться этот скрипт. Для этого нужно открыть свойства страницы (из контекстного меню в дизайнере, щелкнув правой кнопкой по пустому месту в странице) и для свойства Target Schema выбрать нужный броузер, например, Internet Explorer 5.0.

Теперь - о ValidationSummary и Page.IsValid.

Обычно, прежде чем продолжать обработку страницы, необходимо убедиться, что все проверяющие элементы управления дали на это "добро". Для проверки всех серверных элементов управления используется свойство Page.IsValid, а для вывода сводной информации об ошибках на клиенте - элемент управления ValidationSummary.

Свойство IsValid для страницы объединяет через логическое И все проверяющие ЭУ на странице. Если хотя бы один такой элемент вернул false, то IsValid возвращает false.

Информация проверки недоступна во время инициализации и загрузки страницы - только после.

Пример кода для кнопки, в котором проверяется свойство isValid:

Sub cmdSubmit_Click (s As Object, e As EventArgs)

If Page.IsValid Then

Message.Text = "Page is valid!"

’ Perform database updates or other logic here

End If

End Sub

Else на isValid = False писать незачем, поскольку страница автоматически вернется пользователю по сработавшими серверными проверяющими элементами управления.

Если на странице был создан элемент управления ValidationSummary, то он отработает на сервере автоматически, если IsValid = False. Этот элемент управления отобразит значения свойств ErrorMessage (списком) для всех сработавших проверяющих элементов управления и пометит соответствующие проверяемые элементы управления красной звездочкой. Главные свойства ValidationSummary:

·        HeaderText - заголовок списка;

·        DisplayMode - отражать сообщения маркированным списком или просто абзацем

·        ShowSummary - выводить ли список на странице (по умолчанию true).

·        ShowMessageBox - выводить ли список в окне сообщения (по умолчанию false).

Получить учебные материалы по этому курсу