Перевірка введення користувача

Елементи управління для перевірки введення користувача (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).

Трасування в ASP.NET 2.0, включення трасування для сторінки і застосування, об'єкт Trace, переглядач trace.axd

Звичайно ж, в застосуваннях ASP.NET, як в будь-яких застосуваннях, можуть зустрічатися як помилки компіляції, так і помилки часу виконання. Помилки компіляції "ловляться" компілятором ASP.NET, а для помилок часу виконання використовуються об'єкт Trace, об'єкт Debug і деякі засоби VS.NET.

Трасування визначається як отримання інформативних повідомлень про виконання Web-приложения. Ці повідомлення дозволяють виявити проблеми або проаналізувати продуктивність. Для цілей отримання інформації під час виконання використовуються два об'єкти: Debug і Trace. Вони і будуть розглянуті в цьому модулі.

Що ми можемо робити під час роботи застосування:

· набувати значень змінних;

· визначати істинність/помилковість певних умов;

· покроково виконувати наше застосування в цілях відладки.

Для цих цілей використовуються об'єкти Trace і Debug.

У звичайному ASP для виведення інформації про роботу застосування (на саму сторінку або в інше місце) використовувалися команди Response.Write. Застосування об'єкту Trace має та перевага, що відключити все, що відноситься до його роботи, можна просто трохи змінивши параметри у файлі Web.config. В результаті різкого спрощується перехід від оточення розробки до production.

Крім того, при трасуванні можна також використовувати об'єкт Debug. Всі виклики до цього об'єкту взагалі працюють тільки в налагоджувальній конфігурації. У конфігурації Release вони ігноруються.

При використанні цього об'єкту всі повідомлення виводяться у вікні Output відладчика. Для використання цього об'єкту потрібно імпортувати простір імен System.Diagnostics.

Трасування можна включати на різних рівнях.

Перший рівень - рівень сторінки. Для включення потрібно встановити атрибут Trace в директиві Page в True:

< %@ Page Language="vb" Trace="true" %>

Після цього на сторінці можна використовувати команди Trace.Write. Після того, як атрибут Trace буде прибраний, ці команди можна не прибирати - вони просто ігноруватимуться.

Другий рівень - рівень застосування. Крім того, що можливості об'єкту Trace включаються для всіх сторінок, на відміну від попереднього рівня, ми дістаємо можливість записувати повідомлення трасування не тільки на сторінки, але і на пам'ять. Проглянути повідомлення трасування в пам'яті можна за допомогою trace viewer рівня застосування - trace.axd.

Управління трасуванням рівня застосування - через файл Web.config. У нім потрібне значення trace enabled переставити в true (за умовчанням воно в - false).

< configuration>

<system.web>

<trace enabled="true"/>

< /system.web>

< /configuration>

Щоб додати можливість виводити інформацію трасування на сторінки, потрібно додати код:

< trace enabled="true" pageOutput="true" />

(якщо pageOutput - в false, то інформація виводитиметься тільки в пам'ять).

Щоб повідомлення трасування були видні тільки на локальному комп'ютері, можна додати наступний код:

< trace enabled="true" pageOutput="true" localOnly="true"/>

Для запису повідомлень на сторінку (або в пам'ять) використовуються методи Trace.Write і Trace.Warn (відмінності між ними тільки в тому, що Trace.Warn виводить повідомлення червоним кольором). Ці методи приймають два параметри:

Trace.Write (категорія, повідомлення)

Категорія - це можливість розсортувати повідомлення. Приклад:

Trace.Write("Custom Trace", "Beginning User Code...")

Trace.Warn("Custom Trace", "Array count is null!")

Можливість перевірити, чи включено трасування для сторінки або включить/выключить її під час виконання - властивість Trace.IsEnabled:

If Trace.IsEnabled Then

strMsg = "Tracing is enabled!"

Trace.Write("myTrace", strMsg)

End If

або

Trace.IsEnabled = False

Якщо включити трасування на рівні Web-формы, то при цьому виводитимуться не тільки повідомлення трасування, які ви визначили явно за допомогою Trace.Warn і Trace.Write, але і безліч повідомлень трасування, що автогенеруються. Вони розділені на декілька розділів:

· Request Details - ідентифікатор сесії, час запиту, тип запиту, код стану, кодування;

· Trace Information - інформація про час почала і кінця кожного етапу обробки/генерації сторінки;

· Control Tree - перелік всіх елементів сторінки разом з інформацією про розмір кожного елементу;

· Cookies collection - інформація про використані cookies;

· Headers Collection - інформація заголовків протоколу HTTP

· Forms Collection (доступна не завжди) - інформація про елементи управління і їх значення, які були передані на сервер;

· Server Variables - інформація про всі серверні змінні і їх значення.

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

http://имя_сервера/имя_проекта/trace.axd

Теги на рівні сторінки продовжують діяти і вони мають пріоритет перед настройками рівня застосування. Якщо на рівні застосування трасування буде включено, а на рівні сторінки - відключена, перемагають настройки на рівні сторінки.

Можна залишити тільки проглядання повідомлень переглядача, а виведення повідомлень на сторінки - відмінити. Виглядати такі настройки в web.config будуть так:

< configuration>

<system.web>

< trace enabled="true" pageOutput="false"/>

</system.web>

< /configuration>

Для цілей безпеки можливість роботи з trace.axd іноді відключають. зробити це можна так: знайти файл system folder\Microsoft.NET\Framework\version number\Config\machine.config і в нім знайти секцію httpHandlers. За умовчанням вона виглядає так:

< httpHandlers>

<add verb="*" path="trace.axd"

type="System.Web.Handlers.TraceHandler"/>

< /httpHandlers>

Для відключення переглядача потрібно, щоб атрибут path виглядав так: path = ""

Якщо ви використовували атрибут LocalOnly, то не тільки повідомлення трасування будуть видні тільки з локального комп'ютера, але і до файлу trace.axd також можна буде звертатися тільки з локального комп'ютера.

Якщо у вашому застосуванні Web-форма викликає компонент, ви цілком можете додати в цей компонент повідомлення трасування. Для цього потрібно:

· імпортувати в компонент простір імен System.Web:

Imports System.Web

· включити трасування в компоненті:

HttpContext.Current.Trace.IsEnabled = True

у цьому коді HttpContext.Current - це програмний еквівалент сторінки, яка викликає компонент;

· використовувати звичайні Trace.Write і Trace.Warn для виведення повідомлень:

HttpContext.Current.Trace.Write ("component", "this is my trace statement")

При включенні таким чином трасування на рівні компоненту виведення повідомлень трасування проводитиметься навіть в тому випадку, якщо трасування на рівні сторінки відключене.

Тепер - про можливості видаленої відладки. Відладжувати застосування.NET можна локально - звичайними способами і видалено. У цьому модулі буде розглянута видалена відладка засобами ASP.NET.

Видалена відладка дуже зручна. Вона дозволяє організовувати роботу над одним сайтом цілих команд розробників, дозволяти розробникам створювати застосування.NET тоді, коли на їх комп'ютері не встановлений Web-сервер і тому подібне

Для можливості видаленої відладки існують наступні вимоги:

· на сервері повинна бути встановлена VS.NET (або тільки remote components, що входять в її постачання);

· VS.NET обов'язково повинна бути встановлена і на клієнтському комп'ютері, з якого проводиться відладка;

· програміст, що проводить відладку, повинен володіти адміністративними правами на сервер, де знаходиться відладжуване Web-приложение (не тільки Web-сервер, а на сервер цілком);

· користувача обов'язково потрібно додати в групу Debugger Users на комп'ютері, де знаходиться відладжуване застосування (навіть тоді, коли він вже володіє адміністративними правами);

Для виконання видалену відладку досить на клієнтському комп'ютері відкрити VS.NET і в меню File вибрати Open -> Project from Web, потім ввести URL сервера, а потім вибрати потрібний проект і натиснути Open.