валидация на сервере что это
Что такое валидация
Основные определения
Это процесс проверки данных, введенных пользователем, на соответствие заданным критериям (например, на отсутствие ошибок в данных).
Это введенная пользователем информация, которая будет провалидирована (ФИО, адрес, город, номер телефона, ИНН и др.).
Требования, которым должны соответствовать введенные данные (номер мобильного телефона должен состоять из 11 цифр, имя должно быть написано латинскими буквами и т.д.)
Задача валидации
Основной задачей валидации является предоставление полнофункционального инструмента валидации форм в целом и отдельных контролов ввода. Валидация осуществляет проверку данных на их корректность.
Предмет валидации — данные, а не визуальные контролы. Логика в том, чтобы валидировать не контрол, а значение, которое будет записано в этот контрол. Валидация позволяет проверить данные до того, как они будут отправлены на сервер.
Виды валидации
В Wasaby существует три вида запуска валидации:
Чем раньше интерфейс сообщает об ошибке, тем лучше — пользователю проще вернуться и исправить ошибку.
Соответственно, самый быстрый способ сообщить об ошибке — мгновенная валидация. Она возможна только в тех случаях, когда в процессе ввода понятно, что значение некорректное. Чаще всего, такие ошибки связаны с неправильной раскладкой клавиатуры или вводом букв в цифровое поле (ИНН, номер телефона и другие). Для этих случаев обычно используют поля с масками: ввод неподходящих символов в них заблокирован.
Валидация при потере фокуса — основной вид запуска валидации. Валидация срабатывает сразу после потери фокуса, если значение в поле заполнено.
Валидация при отправке формы — для тех случаев, когда запуск валидации по потере фокуса невозможен. Используйте этот вид запуска валидации, когда нельзя проверить поля по потере фокуса. Например, для проверки заполнения обязательных полей. Проверка происходит после того, как пользователь нажал кнопку отправки данных.
Валидация на клиенте и на сервере
Общий алгоритм валидации данных, введенных пользователем, можно представить следующим образом:
Даже если данные будут проверены на клиенте, на сервере они должны будут пройти повторную проверку.
| Преимущества | Недостатки | |
|---|---|---|
| Клиент | Валидация данных на клиенте позволяет произвести предварительную проверку данных без отправки их на сервер. Процесс проверки будет быстрым, пользователь моментально увидит результат. Такая валидация позволяет избежать «забивания» канала передачи данных. | У злоумышленников есть доступ к процессу валидации, соответственно, проверка данных на клиенте является небезопасной. |
| Сервер | Процесс валидации безопасен, поскольку доступа к валидации на сервере у злоумышленников нет. | Если валидировать данные только на сервере, канал передачи данных может быть перегружен лишними запросами, поскольку данные каждый раз будут перемещаться между клиентом и сервером. |
Итак, проверка на стороне клиента хороша для ускорения обратной связи с клиентами. Однако она недостаточна, поскольку ее объем действия очень ограничен. Проверка выполняется только в пользовательском интерфейсе браузера. Проверка на стороне сервера является обязательной, поскольку проверка на стороне клиента не гарантирует, что на сервер будут поступать неподтвержденные данные.
Контролы с внутренней валидацией
Часть контролов поддерживают внутреннюю валидацию. Например, Controls/date:BaseInput и Controls/dateRange:Input проверяют корректность введенных данных и показывают сообщение, если данные введены неправильно.
Такие контролы имеют внутри себя встроенный контейнер валидации и их можно не оборачивать внешним.
Валидаторы для Controls/date:BaseInput передаются во внутренний контейнер валидации с помощью опции valueValidators, которая содежит массив валидаторов. Валидаторы проверяют значение опции value.
У Controls/dateRange:Input есть две опции startValueValidators и endValueValidators, которые содержат массивы валидаторов. Валидаторы проверяют значение опций startValue и endValue соотвественно.
Валидация — что это простыми словами? Чем отличается валидация от верификации? + ПРАКТИЧЕСКИЙ СОВЕТ
Здравствуйте, дорогие читатели! Добро пожаловать на блог!
Валидация — что это простыми словами? Чем отличается валидация от верификации? Ответы на эти вопросы — в статье.
Многие слова «валидация» и «верификация» считают синонимами. Но это не так. Разница есть, но она очень тонкая. Давайте разбираться.
Валидация и верификация — что это простыми словами?
Справедливости ради надо сказать, что в разных областях деятельности (в банках, в платежных системах, в интернете), в разных отраслях производства эти термины используются по-разному. Я решила привести здесь определение валидации и верификации из стандарта ISO 9000.
Мы видим, что определения совпадают в значительной части, но не полностью. Однако, несмотря на такое большое совпадение валидация и верификация — это разные действия.
Чтобы проще было понять, что такое валидация, давайте сначала разберемся, чем валидация отличается от верификации.
Чем отличается валидация от верификации?
Итак, что такое верификация? Более детально можете узнать из этой статьи, но здесь скажем коротко, что слово «верификация» происходит от английского слова «verification» — проверка. А слово «валидация» происходит от английского «validation» — придание законной силы.
Примеры валидации и верификации в разных сферах.
Без примеров трудно понять отличия валидации и верификации. Приведем несколько примеров из разных областей.
Пример из области медицины
Скажем, разработали новое лекарство. Провели многочисленные тесты для ПРОВЕРКИ, что лекарство лечит такую-то болезнь. Здесь речь идет о ВЕРИФИКАЦИИ (о проверке соответствия лекарства его предназначению). Но Вы знаете, что на самом деле лекарство подходит не всем. Чтобы начать лечение Вам нужна ВАЛИДАЦИЯ врача. Только врач может ПОДТВЕРДИТЬ, что это лекарство подойдет КОНКРЕТНО Вам.
ВЕРИФИКАЦИЯ — это тестирование лекарства с целью ПРОВЕРКИ на соответствие его предназначению. А ВАЛИДАЦИЯ — это ПОДТВЕРЖДЕНИЕ врача, что лекарство подойдет КОНКРЕТНОМУ больному.
Пример из области производства
Предположим завод по производству велосипедов принял заказ на партию велосипедов. Так вот, ВЕРИФИКАЦИЮ (ПРОВЕРКУ) на соответствие требованиям заказчика выполняет сам завод-производитель. А вот ВАЛИДАЦИЮ (ТЕСТИРОВАНИЕ, ПРОВЕРКУ) на соответствие своим требованиям будут выполнять представители самого заказчика.
Пример из области IT
Аналогичный пример можно привести из области IT. Компания — разработчик программного обеспечения получила заказ на разработку какого-то софта. Программа, которая была создана, прошла тестирование. Результатом тестирования является ВЕРИФИКАЦИЯ на стороне компании, выполняющей заказ, что программа полностью соответствует тех заданию заказчика. А вот ВАЛИДАЦИЮ будет выполнять сам заказчик, когда установит программное обеспечение и протестирует его.
Пример из сферы интернета
Социальная сеть Твиттер проводит ВЕРИФИКАЦИЮ аккаунтов знаменитостей, чтобы участники сети точно знали, что посты публикуются действительно этой знаменитостью. В результате верификации в аккаунте знаменитости появляется синий значок с галочкой.
Еще пример. Для того, чтобы стать продавцом на Амазоне, Вам необходимо пройти ВЕРИФИКАЦИЮ личности. Также необходимо пройти верификацию при регистрации аккаунтов во всех платежных системах (Вебмани, Яндекс.Деньги, Киви и т.д.)
Пример из законодательной области
Инициативный депутат решил улучшить жизнь и придумал прогрессивный Закон. Законотворческие органы выполнят ПРОВЕРКУ нового Закона на соответствие другим Законам и международному праву и ВЕРИФИЦИРУЮТ его. Но Закон вступит в силу не сразу, а только через месяц — после его ВАЛИДАЦИИ (придания законной силы) высшим органом законодательной власти. За этот месяц можно отозвать Закон, выявив вред для каких-то КОНКРЕТНЫХ слоев населения.
Например, соц сеть Твиттер верифицирует аккаунты знаменитостей для того, чтобы пользователи были уверены, что сообщения действительно публикует эта знаменитость или её официальный представитель. В аккаунте пользователя Твиттере, который прошел такую верификацию, ставится синий значок с галочкой.
Теперь можно сделать общий вывод, что верификация (проверка) встречается чаще, чем валидация. Валидация (подтверждение для конкретного случая) нужна не всегда.
Практический совет
Вы спросите, для чего нужно разбираться в этих терминах? Скажу, что есть и практическая польза. Главная цель верификации и валидации — безопасность, чтобы Ваши банковские карты и аккаунты были защищены. Однако, пользуясь тем, что многие не разбираются в этих терминах, злоумышленники для похищения личных данных часто применяют такой способ, как сообщение с просьбой верифицировать или валидировать вашу банковскую карту, аккаунт и т.д..
Практический совет: При появлении окна с просьбой верификации или валидации Ваших данных проверьте в адресной строке данные сайта, нет ли пропущенных или лишних символов. Либо попробуйте зайти в эту программу с другого устройства и если такого сообщения не появляется, значит Ваш компьютер надо лечить от опасных вирусов.
Резюме
Надеюсь, статья, оказалась полезной для Вас и Вы теперь знаете ответы на вопросы: Валидация — что это простыми словами? Чем отличается валидация от верификации?
Вот по традиции порция полезного видео. В котором Жак Фреско учит мыслить нестандартно, не так, как все. ЭТИ НЕСКОЛЬКО МИНУТ БУДУТ ТОЧНО ПОТРАЧЕНЫ НЕ ЗРЯ!
Желаю всем новых идей и много сил для их реализации!
Админка магазина на vue.js. Урок 11. Обрабатываем ошибки на клиенте и сервере
Когда мы создаем любые приложения, не стоит рассчитывать, что пользователи будут работать с ним так, как мы задумали. Нет, они постоянно будут делать тупые с нашей точки зрения вещи:
Работать с нашим приложением будут не программисты. Представьте менеджера, которому нужно забить в базу 3 сотни товаров, и это до завтра. Он не будет изучать нашу инструкцию, он сядет и сразу будет набивать по списку. Так сделает любой нормальный человек.
Наша задача, как программистов, сделать так, чтобы система обрабатывала любые данные. Приложение должно или распарсить эти данные и понять, что хотел ввести пользователь, или приостановить работу и сказать, в чем ошибка. И сказать человеческим языком, а не ошибкой в консоли. Сегодня мы займемся этой проблемой и посмотрим, как адекватно обрабатывать разные ошибки.
Валидация на клиенте и сервере. В чем разница?
— юзер пытается добавить товар с пустым названием
— юзер забыл указать цену товара
— юзер вбивает длинное описание, хотя допускается максимум 200 символов.
Все это можно проверить в клиентской части приложения с помощью javascript.
— юзер пытается добавить уже существующий товар
— юзер пытается удалить категорию, хотя в ней есть какие-то товары
— юзер пытается удалить бренд, но у него нет прав доступа на это
Все эти вещи проверяются на бекенде, клиент о них не знает.
— стоит по максимуму валидировать данные на клиенте
— дублировать эти же проверки на сервере.
Валидация на клиенте выполняется быстро и не требует лишнего запроса на сервер. Это ускоряет работу приложения. Действительно, зачем юзеру ждать, пока запрос сбегает на сервер, если нужно всего лишь проверить, не пустое ли поле названия товара?
Дублировать эти же проверки на сервере нужно для других случаев. Во-первых, нашим приложением могут пользоваться по API, то есть не через интерфейс, а дергать rest-запросы напрямую. И тут валидация на клиенте не поможет. А во-вторых, могут найтись какие-нибудь хакеры или бродящие по интернету боты, которые захотят поломать наш сервис, закинув в него неподходящие данные.
Валидация в нашей админке интернет-магазина
До какой степени валидировать данные в приложении, каждый решает сам. Процесс этот бесконечный, можно проверять все, что угодно. Главное, вовремя остановиться и не забыть проверить самые важные вещи.
В нашей админке мы не будем стелить соломку по всему коду, смысл уроков не в этом. Мы подробно рассмотрим валидацию только в одном компоненте, но покроем и клиентские, и серверные проверки. И научимся показывать юзерам ошибки в человеческом виде.
Мы проработаем форму добавления брендов, которую сделали в прошлом уроке. Сейчас мы можем добавить любой бренд, потому что никаких проверок нет. Исправим это и будем проверять такие вещи:
— не пустой ли бренд
— не превышает ли бренд 20 символов (практического смысла мало, но для примера нормально)
— существует ли этот бренд в базе
— нет ли ошибки в запросе (неверный роутер, проходили в третьем уроке)
— общие ошибки, например, сервис недоступен, бекенд лежит
Дублировать клиентские проверки на сервере мы не будем. Они очень простые и легко реализуются на php, не будем перегружать код. Другие серверные ошибки, номер 3 и 4, уже реализованы в третьем уроке, когда мы готовили api для админки.
Общая схема обработки ошибок
Сделаем так. В окошке добавления бренда заведем поле, куда будем выводить сообщение об ошибке. Пользователям все равно, клиентская это ошибка или серверная, для него это будет выглядеть одинаково, вот так
Валидация на клиенте
Добавим еще вычисляемое логическое поле isError, которое покажет, если ли в данный момент ошибка
Дальше нам нужно вывести сообщение об ошибки в окне добавления бренда. Добавим такой код между инпутом-брендом и кнопкой Добавить
Это выделенный красным текст, пример взяли из библиотеки minicss. Напоминаю, наше приложение на этом css-фреймворке. Чуток поправим стили, добавим в style
Итак, errorCode у нас есть, нужны методы для работы с ним. Один метод будет устанавливать код, другой очищать. Добавим в раздел methods
Можно было обойтись и одним только setError, но позже увидим, что clearError удобная штука и нам еще пригодится.
Базовая подготовка сделана, пора заняться самой валидацией. Напомню, мы будем проверять, что новый бренд не пустой и что не длиннее 20 символов. Метод валидации будет выполнять эти проверки и в случае ошибкок устанавливать соответствующий код codeError. Вот так выглядит метод validate
Два простых if-а, которые проставляют нужные коды brand_empty или brand_long_title. А в случае успеха дергаем метод clearError, чтобы сбросить ошибку, если она была до этого. Например, юзер ввел правильно инфу со второго раза.
Важный момент. Помимо установки codeError мы возвращаем true или false в зависимости от итога валидации. Нам это нужно, чтобы понять, отправлять ли запрос на сервер с добавлением бренда или же ждать, пока юзер введет бренд правильно.
Посмотрим, какой метод добавления бренда мы написали раньше
Все просто, вызываем действие через dispatch, очищаем инпут с названием и закрываем модалку. Этот код нужно чуть переделать, вызывать действие только если валидация прошла успешно. Добавим условие if
На этом с клиентской валидацией все, можно проверять. Пробуем добавить пустой или чересчур длинный бренд, увидим сообщение с нужным кодом ошибки, а запрос на сервер не отправится. Красота. Идем дальше.
Валидация на сервере
С серверными проверками есть свои особенности.
Во-первых, на клиенте мы генерили коды ошибок сами, а для серверных нужно дождаться ответа и получить их из респонса. Да, мы эти коды (brand_exists и invalid_router) сами сделали в уроке по API. Но вообще мы можем даже и не знать, что за коды нам возвращает бекенд.
Во-вторых, есть интерфейсный момент. Сейчас в методе addBrand сразу после dispatch мы очищаем поле бренда и закрываем модалку. Это годится, если бренд успешно добавлен и никуда не годится, если сервер вернул ошибку. Значит, мы должны не просто дернуть dispatch, а дождаться ответа от сервера и только потом решать, что делать. Если ответ 200 и бренд добавлен, то закрывать модалку, а если ошибка, то выводить ее и оставлять модалку.
Если бы мы писали приложение на jquery, то сделали бы примерно так
Начнем с действия addBrand. Открываем файл store/modules/brands.js и смотрим, как реализовано сейчас
Отправляем запрос на сервер через axios и в случае успеха вызываем мутацию ADD_BRAND. Нам нужно сделать то же самое, только при этом еще и возвращать промис. Вот так
Кода прибавилось, но немного. В метод resolve попадает
Параметр response нам не нужен, просто для наглядности. Получается, если запрос прошел успешно, бренд добавлен, то очищаем поле в модалке и саму модалку закрываем. При ошибке выполняется другое
Поэтому именно здесь мы подстилаем соломку и проверяем всю цепочку error.response.data.code. Только если data.code действительно существует, то мы понимаем, что эту ошибку вернул наш бекенд и в errorCode мы записываем валидное значение. А в противном случае мы понимаем, что случилась какая-то хрень и поэтому ставим unknown_error. Типа «случилась непонятная хрень». Так и напишем пользователю.
Задача программиста как можно меньше пугать юзеров непонятными ошибками и стараться по максимуму обрабатывать их руками. Другое дело, что пользователям вообще по фигу, лежит ли у вас бекенд, упала ли база и кто-то накосячил в коде. Ему важно, что приложение не работает и все. Поэтому есть смысл не перегружать юзера техническими деталями, а выдать общую ошибку и попросить попробовать позже. Естественно, предполагается, что мы уже устраняем косяки и поднимаем бекенд.
Это все, что касается валидации на сервере. Можно проверять, попытаться добавить существующий бренд или изменить урл /admin/api/v1/brands на какой-нибудь левый. Если все сделали правильно, то при добавлении бренда будет уходить запрос на сервер, возвращаться ошибка и модалка не закроется, а выведет код.
Когда мы будем тестировать работу, то заметим одну визуальную неприятность. Допустим, попытались мы добавить пустой бренд, нам выскочила ошибка brand_empty. Изменяем бренд в инпуте, а ошибка так и торчит. Бесит. Давайте добавим одну строчку, чтобы при установке фокуса в инпуте ошибка пропадала. Теперь инпут будет выглядеть так
Вывод нормального сообщения об ошибке вместо кода
Идем обратно в компонент BrandsNew. В теге script импортируем lodash и конфиг брендов
Создаем новое вычисляемое поле в computed
Это и есть сообщение об ошибке, которое берется из конфига по нужному коду. Осталось воткнуть его в разметку вместо errorCode. Вот так
Эссе о валидации данных
Зачем нужна валидация данных?
Казалось бы, «невалидные» данные, не удовлетворяющие определённым ограничениям, могут вызвать сбой в работе программы. Но что это означает? Предположим, в каком-то месте программы возникает исключение при попытке преобразовать строку в число, если строка имеет некорректный формат. Разумеется, если исключение не будет нигде перехвачено, это может привести к аварийному завершению программы. Но это маловероятный сценарий развития событий. Скорее всего в каком-то месте сработает перехватчик, который либо выдаст пользователю какое-то сообщение об ошибке в программе, либо сделает запись в журнал ошибок, после чего программа постарается восстановиться от сбоя и продолжить работу. То есть даже если валидацию не выполнять, вполне вероятно, что ничего страшного не случится.
Где и когда выполнять валидацию данных?
Как уже было сказано выше, с точки зрения уменьшения нагрузки лучше всего вообще не выполнять валидацию данных.
Но если всё-таки проверка нужна, логика подсказывает, что удобно проверять данные в том месте, где они попадают в программу из внешнего мира. После такой проверки можно быть уверенным, что в программу попадают правильные данные и в дальнейшем они могут использоваться без дополнительных проверок.Это может быть пользовательский интерфейс, через который человек вводит данные. Это может быть файл, содержащий настройки программы или данные, которые программа должна обработать. Это может быть база данных, в которую информация может попадать из других программ. Это может быть сетевой протокол обмена данными с другими программами. Наконец, это может быть программный интерфейс, который использует другая программа, вызывая некоторые функции/процедуры и передавая в них параметры.
Как выполнять валидацию данных?
Какой способ валидации следует применять на практике в том или ином случае? Чаще всего одним способом ограничиться не удаётся, да и не нужно. Валидацию данных можно и нужно выполнять в несколько этапов, усложняя проверки.
Сначала, по мере ввода, следим за тем, чтобы данные не содержали недопустимых символов. Например, для числового поля пользователю может быть запрещён ввод нецифровых символов.
После того, как ввод завершён, можно проверить всё значение целиком. Для введённого числа могут быть какие-то ограничения, например, оно не должно превышать определённого максимального допустимого значения. Если наше числовое поле представляет собой возраст, оно должно находиться в пределах от 0 до, скажем, 120.
Когда заполнены все поля, можно проверить, согласованы ли введённые значения друг с другом. Например, если в форме кроме поля для указания возраста есть поле для ввода номера паспорта, приложение может проверить, что при заполнении номера паспорта возраст должен быть не менее 14 лет.
Наконец, если всё введено корректно, можно попытаться начать обработку, выполняя проверки по ходу дела, а также в самом конце, и если что-то пошло не так, выполнить откат к исходному состоянию.
Ну и, конечно же, проверки на следующем уровне могут подстраховывать проверки предыдущих уровней. Скажем, для веб-приложений обязательной является проверка данных, пришедших на сервер в HTTP-запросе, независимо от того, выполнялась ли перед этим предварительная валидация в браузере или нет. Причина этого в том, что проверку на клиентской стороне можно обойти. Для других видов приложений обойти проверки не так просто, но иногда тоже вполне возможно, как показано в примере чуть ниже.
Тестирование валидаторов
Завершим статью демонстрацией различных видов валидаторов, а также некоторыми рекомендациями относительно того, как при тестировании проверять правильность их работы.
Начнём с посимвольной проверки. Графический редактор Paint, диалог изменения размеров рисунка, ширина рисунка. В это поле допускается вводить только цифры, при попытке ввести другие символы выдаётся сообщение об ошибке:
Однако, проявив смекалку, можно обойти эту валидацию вводимых символов: через буфер обмена удаётся вставить в это поле отрицательное число, несмотря на то, что минус является недопустимым символом:
Впрочем, это не приводит к негативным последствиям, потому что на следующем уровне стоит ещё одна проверка, которая срабатывает при нажатии кнопки OK:
Есть и другие ограничения для этого поля, которые тоже проверяются после нажатия кнопки OK:
А вот находящееся совсем рядом в том же диалоге поле для ввода наклона рисунка не содержит валидации символов, несмотря на то, что это тоже числовое поле. Более того, при вводе недопустимых символов после нажатия OK можно увидеть вот такое странное сообщение, практически не поддающееся расшифровке:
Все вышеописанные примеры связаны с проверкой отдельно взятого поля. Пример валидации комбинации полей можно найти в том же приложении, но в другом месте — в диалоге настройки параметров страницы для печати. Если указать размеры полей страницы так, чтобы в сумме они превосходили ширину страницы, получим вот такое сообщение:
Ну и, наконец, в заметке «Почему не хватает памяти, чтобы уменьшить размеры рисунка?» описана ошибка, связанная с тем, что в этом графическом редакторе отсутствует корректная обработка сбоев и откат транзакции при слишком сильном увеличении размера рисунка.
Тестировщику необходимо все эти ситуации отрабатывать. Во-первых, нужно проверять валидацию на всех уровнях. Во-вторых, нужно проверять согласованность валидаторов на разных уровнях. В-третьих, надо искать пути обхода валидаторов, пытаясь добраться до следующего уровня без предварительных проверок.
Заключение
Большая часть этой статьи посвящена не способам тестирования валидаторов, а описанию их устройства. Почему? Потому что врага надо знать в лицо. Чтобы найти дефект валидации данных, надо понимать, где искать и на что обращать внимание.