Майже кожен сайт містить веб-форми, нехай це проста форма зворотного зв'язку або ж процес реєстрації нового користувача. Для того, щоб бути впевненим, що дані, відправлені користувачем, будуть коректно прийняті та оброблені, необхідно забезпечити перевірку заповнення веб-форми. Це здійснюється за допомогою валідації. Коректні дані можуть бути відправлені на сервер і збережені в базі даних. У разі, якщо користувач допустив помилку при заповненні форми (навмисне чи ні), такі дані не повинні бути занесені до бази даних.
М’які та жорсткі валідаційні політики
Згідно з міжнародним стандартом ISO 9000, валідація (англ. «Validation») – це підтвердження на основі об'єктивних доказів того, що вимоги, призначені для конкретного використання або застосування, виконані. Валідація повинна відповідати на питання «Чи робимо ми правильний продукт?».
З технічної точки зору виділяють два види валідації форми:
- перевірка на боці клієнта;
- перевірка на боці серверу.
Різниця між перевіркою на стороні клієнта та на стороні серверу
Перевірка на боці клієнта – це «миттєва» перевірка даних безпосередньо у браузері, тобто ще до відправки даних на сервер. Це значно зручніше перевірки на боці сервера, так як, контроль вводу на стороні клієнта дає швидку відповідь.
Тут можна виділити два основних методи реалізації:
- за допомогою JavaScript – дуже гнучкий і повністю налаштовуваний ;
- за допомогою HTML5 – має кращу продуктивність, але обмежений у своєму налаштуванні у порівнянні з JavaScript.
Перевірка на стороні сервера здійснюється на сервері, тобто вже після відправки даних. Це не так зручно, як перевірка безпосередньо в браузері, оскільки користувач не отримає зворотного зв'язку до тих пір, поки не буде відправлена повністю вся форма. Винятком є перевірка з використанням Ajax – Ajax-дзвінки на сервер можуть перевірятися в міру їх введення і забезпечувати негайний зворотний зв'язок (наприклад, перевірка нового імені користувача на доступність при реєстрації). Перевірка на стороні сервера – це остання лінія захисту від неправильних або навіть шкідливих даних. Цей метод безпечний, тому що він буде працювати, навіть якщо JavaScript відключений в браузері і зловмисники не можуть його легко обійти. На сьогодні функції перевірки даних мають всі популярні серверні фреймворки.
Основним недоліком перевірки на стороні клієнта є те, що вона спирається на JavaScript. Якщо користувачі відключають JavaScript, вони можуть легко обійти перевірку. Ось чому перевірка повинна завжди здійснюватися як на клієнті, так і на сервері. Комбінуючи методи на стороні сервера і на стороні клієнта, ми можемо отримати найкраще з двох: швидку відповідь, більш надійну перевірку і кращий користувальницький досвід (UX).
Якщо говорити в загальному, то розрізняють жорстку і м'яку валідацію.
За замовчуванням, правила валідації є жорсткими, тобто користувач зобов'язаний виправити помилки до відправки даних на сервер. Суворі перевірки забезпечують високу якість даних клієнтів з мінімальними помилками. Проблемою жорсткої валідації форм є ефективне блокування роботи користувача. Це, звичайно, є її метою, але якщо правила валідації не можуть бути бездоганно реалізовані на 100%, користувачі в кінцевому підсумку можуть зіткнутися з перешкодами. Наприклад: користувачі з нетиповими (але реальними і повністю дійсними) адресами електронної пошти блокуються засобами перевірки електронної пошти, внаслідок чого користувач не може завершити оформлення замовлення. У таких випадках навіть може створюватися новий обліковий запис електронної пошти просто для покупки на цьому сайті.
Виключивши суворі перевірки, можна реалізувати м'які правила валідації, які можуть бути проігноровані користувачем. Це означає, що якщо введені дані не відповідають певним вимогам, то користувач побачить якесь попередження про це. При цьому він зможе продовжити роботу і навіть зможе зберегти свої дані, відправивши їх на сервер.
Валідація повинна попередити користувача про необхідність повторного перегляду введених даних, не заважаючи йому продовжувати роботу. Користувач може бути попереджений про потенційні наслідки помилкового введення, а також запропоновано «діяти на свій страх та ризик».
