Ошибка валидации запроса самп

Обновлено: 29.01.2023

Почти все разработчики так или иначе постоянно работают с api по http, клиентские разработчики работают с api backend своего сайта или приложения, а бэкендеры «дергают» бэкенды других сервисов, как внутренних, так и внешних. И мне кажется, одна из самых главных вещей в хорошем API это формат передачи ошибок. Ведь если это сделано плохо/неудобно, то разработчик, использующий это API, скорее всего не обработает ошибки, а клиенты будут пользоваться молчаливо ломающимся продуктом.

За 7 лет я как поддерживал множество legacy API, так и разрабатывал c нуля. И я поработал, наверное, с большинством стратегий по возвращению ошибок, но каждая из них создавала дискомфорт в той или иной мере. В последнее время я нащупал оптимальный вариант, о котором и хочу рассказать, но с начала расскажу о двух наиболее популярных вариантах.

Если у вас примитивная бизнес-логика или API из 5 url, то в принципе это нормальный подход. Однако как-только бизнес-логика станет сложнее, то начнется ряд проблем.

REST скорее концепция, чем формат общения из чего следует неоднозначность использования статусов. Разработчики используют статусы как им заблагорассудится. Например, некоторые API при отсутствии сущности возвращают 404 и текст ошибки, а некоторые 200 и пустое тело.

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

Когда бизнес-логика приложения усложняется, начинают делать как-то так:

Принудительный вызов валидации

Для принудительного вызова проверки, без использования Spring Boot, создайте валидатор вручную.

Тем не менее, Spring Boot предоставляет предварительно сконфигурированный экземпляр валидатора. Внедрив этот экземпляр в сервис не придется создавать его вручную.

Когда этот сервис внедряется Spring, в конструктор автоматически вставляется экземпляр валидатора.

Группы валидаций

Некоторые объекты участвуют в разных вариантах использования.

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

  • только перед созданием
  • только перед обновлением
  • или в обоих случаях

Функция Bean Validation, которая позволяет нам внедрять такие правила проверки, называется «Validation Groups».

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

Для нашего примера CRUD определим два маркерных интерфейса OnCreate и OnUpdate :

Затем используем эти интерфейсы с любой аннотацией ограничения:

Это позволит убедиться, что id пуст при создании и заполнен при обновлении.

Spring поддерживает группы проверки только с аннотацией @Validated

Обратите внимание, что аннотация @Validated применяется ко всему классу. Чтобы определить, какая группа проверки активна, она также применяется на уровне метода.

Использование групп проверки может легко стать анти-паттерном. При использовании групп валидации сущность должна знать правила валидации для всех случаев использования (групп), в которых она используется.

Сначала нужно определить эту структуру данных. Назовем ее ValidationErrorResponse и она содержит список объектов Violation :

Затем создадим глобальный ControllerAdvice , который обрабатывает все ConstraintViolationExventions , которые пробрасываются до уровня контроллера. Чтобы отлавливать ошибки валидации и для тел запросов, мы также будем работать с MethodArgumentNotValidExceptions :

Здесь информацию о нарушениях из исключений переводится в нашу структуру данных ValidationErrorResponse .

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

Валидация сущностей JPA

Persistence Layer это последняя линия проверки данных. По умолчанию Spring Data использует Hibernate, который поддерживает Bean Validation из коробки.

Обычно мы не хотим делать проверку так поздно, поскольку это означает, что бизнес-код работал с потенциально невалидными объектами, что может привести к непредвиденным ошибкам.

Допустим, необходимо хранить объекты нашего класса Input в базе данных. Сначала добавляем нужную JPA аннотацию @Entity , а так же поле id :

Когда репозиторий пытается сохранить невалидный Input , чьи аннотации ограничений нарушаются, выбрасывается ConstraintViolationException .

Bean Validation запускается Hibernate только после того как EntityManager вызовет flush.

Чтобы отключить Bean Validation в репозиториях Spring, достаточно установить свойство Spring Boot spring.jpa.properties.javax.persistence.validation.mode равным null .

№2: На все 200

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

На самом деле формат зависит от вас или от выбранной библиотеки для реализации коммуникации, например JSON-API.

В некоторых случаях, если есть библиотека десериализации данных, она может взять часть работы на себя. Писать SDK вокруг такого подхода проще нежели вокруг той или иной имплементации REST, ведь реализация зависит от того, как это видел автор. Кроме того, теперь никто не вызовет случайное срабатывание alert в мониторинге из-за того, что выбрал неудачный код ошибки.

Но неудобства тоже есть:

Избыточность полей при передаче данных, т.е. нужно всегда передавать 2 поля: для данных и для ошибки. Это усложняет чтение логов и написание документации.

При использовании средств отладки (Chrome DevTools) или других подобных инструментов вы не сможете быстро найти ошибочные запросы бизнес логики, придется обязательно заглянуть в тело ответа (ведь всегда 200)

нельзя делать повторы для неудавшихся GET запросов (на backend) на реверс-прокси (например, nginx) по указанной выше причине

имеются проблемы с документированием – swagger и ApiDoc не подходят, а удобных аналогов я не нашел

Итог: Для сложной бизнес-логики с большим количеством типов ошибок такой подход лучше, чем расплывчатый REST, не зря в проектах c “разухабистой” бизнес-логикой часто именно такой подход и используют.

№3: Смешанный

400 – ошибка бизнес логики

остальное ошибки в транспорте

Мы можем расширять объект ошибки для детализации проблемы, если хотим. С мониторингом все как во втором варианте, дописывать парсинг придется, но и риска “стрельбы” некорректными alert нету. Для документирования можем спокойно использовать Swagger и ApiDoc. При этом сохраняется удобство использования инструментов разработчика, таких как Chrome DevTools, Postman, Talend API.

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

Самое главное какой бы формат ошибок вы бы не выбрали лучше обговорить его заранее и следовать ему. Если эту вещь пустить на “самотек”, то очень скоро обработка ошибок в проекте станет невыносимо сложной для всех.

P.S. Иногда ошибки любят передавать массивом

Но это актуально в основном в двух случаях:

Когда наш API выступает в роли сервиса без фронтенда (нет сайта/приложения). Например, сервис платежей.

Когда в API есть url для загрузки какого-нибудь длинного отчета в котором может быть ошибка в каждой строке/колонке. И тогда для пользователя удобнее, чтобы ошибки в приложении сразу показывались все, а не по одной.

Антонина Пшеничникова

SMMplanner

Антонина Пшеничникова

Антонина Пшеничникова

Когда захожу на вашу почту support. вобще происходит что-то непонятное, есть скрин

SMMplanner

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

Максим Захаров

SMM planner, здравствуйте. Сильно упали охваты после атвопостинга. Речь идёт о инстаграме. Возможно из-за сммпланера?

Добавьте возможность отмечать на видео для ленты в инстаграме. А то несерьезно как-то. В самой инсте уже около года это возможно.

SMMplanner

SMMplanner

Рома Егорихин

Произошла ошибка валидации.

Ни один сайт с автопостингом и тд не могу подключить.
Что я сделал до этого?
Создал бота по правилам , токен отправил на сайт вместе с ссылкой на канал (был новый канал для проверки и нужный мой канал) ни один не смог подключиться.
Пересоздал бота и добавил его в ManyBot (не знаю зачем) , все равно ошибка.

maksim92

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

maksim92

Andrew Stark, ну а если связать эти две вещи и вынести? Вы же программист симфони)

Правда это slim. Но на симфони можно сделать так, чтобы вообще этот метод убрать из контроллера.

Нередко пользователи пытаются передать в приложение некорректные данные. Это происходит либо из злого умысла, либо по ошибке. Поэтому стоит проверять данные на соответствие бизнес-требованиям.

Эту задачу решает Bean Validation. Он интегрирован со Spring и Spring Boot. Hibernate Validator считается эталонной реализацией Bean Validation.

Добавление пользовательского валидатора

Если имеющихся аннотаций ограничений недостаточно, то создайте новые.

В классе Input использовалось регулярное выражение для проверки того, что строка является IP адресом. Регулярное выражение не является полным: оно позволяет сокеты со значениями больше 255, таким образом «111.111.111.333» будет считаться действительным.

Давайте напишем валидатор, который реализует эту проверку на Java. Потому что как говорится, до решения проблемы регулярным выражением у вас была одна проблема, а теперь стало двe :smile:

Сначала создаем пользовательскую аннотацию @IpAddress :

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

Теперь можно использовать аннотацию @IpAddress , как и любую другую аннотацию ограничения.

Валидация в Spring MVC Controller

  • тело запроса
  • переменные пути (например, id в /foos/)
  • параметры запроса

Рассмотрим каждый из них подробнее.

Валидация тела запроса

Тело запроса POST и PUT обычно содержит данные в формате JSON. Spring автоматически сопоставляет входящий JSON с объектом Java.

Проверяем соответствует ли входящий Java объект нашим требованиям.

  • Поле numberBetweenOneAndTen должно быть от 1 до 10, включительно.
  • Поле ipAddress должно содержать строку в формате IP-адреса.

Контроллер REST принимает объект Input и выполняет проверку:

Достаточно добавить в параметр input аннотацию @Valid , чтобы сообщить спрингу передать объект Валидатору, прежде чем делать с ним что-либо еще.

Если класс содержит поле с другим классом, который тоже необходимо проверить — это поле необходимо пометить аннотацией Valid.

Проверка переменных пути и параметров запроса

Проверка переменных пути и параметров запроса работает по-другому.

Не проверяются сложные Java-объекты, так как path-переменные и параметры запроса являются примитивными типами, такими как int , или их аналогами: Integer или String .

Вместо аннотации поля класса, как описано выше, добавляют аннотацию ограничения (в данном случае @Min ) непосредственно к параметру метода в контроллере Spring:

Обратите внимание, что необходимо добавить @Validated Spring в контроллер на уровне класса, чтобы сказать Spring проверять ограничения на параметрах метода.

В этом случае аннотация @Validated устанавливается на уровне класса, даже если она присутствует на методах.

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

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

Можно проверять данные на любых компонентах Spring. Для этого используется комбинация аннотаций @Validated и @Valid .

Аннотация @Validated устанавливается только на уровне класса, так что не ставьте ее на метод в данном случае.

Основы валидации Bean

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

При передаче размеченного таким образом объекта класса в валидатор, происходит проверка на ограничения.

Настройка

Добавьте следующие зависимости в проект:

Стандартные ограничения

Каждая аннотация имеет следующие поля:

Рассмотрим популярные ограничения.

@NotNull и @Null

@NotNull — аннотированный элемент не должен быть null. Принимает любой тип.
@Null — аннотированный элемент должен быть null. Принимает любой тип.

@NotBlank и @NotEmpty

@NotBlank — аннотированный элемент не должен быть null и должен содержать хотя бы один непробельный символ. Принимает CharSequence .
@NotEmpty — аннотированный элемент не должен быть null или пустым. Поддерживаемые типы:

  • CharSequence
  • Collection . Оценивается размер коллекции
  • Map . Оценивается размер мапы
  • Array . Оценивается длина массива

@NotBlank применяется только к строкам и проверяет, что строка не пуста и не состоит только из пробелов.

@NotNull применяется к CharSequence , Collection , Map или Array и проверяет, что объект не равен null . Но при этом он может быть пуст.

@NotEmpty применяется к CharSequence , Collection , Map или Array и проверяет, что он не null имеет размер больше 0.

Аннотация @Size(min=6) пропустит строку состоящую из 6 пробелов и/или символов переноса строки, а @NotBlank не пропустит.

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

  • CharSequence . Оценивается длина последовательности символов
  • Collection . Оценивается размер коллекции
  • Map . Оценивается размер мапы
  • Array . Оценивается длина массива

Валидация конфигурации приложения

Spring Boot аннотация @ConfigurationProperties используется для связывания свойств из application.properties с Java объектом.

Данные из application необходимы для стабильной работы приложения. Bean Validation поможет обнаружить ошибку в этих данных при старте приложения.

Допустим имеется следующий конфигурационный класс:

При попытке запуска с недействительным адресом электронной почты получаем ошибку:

Читайте также:

  • Fortnite ошибка 0xc000007b normaliz dll
  • Medal of honor above and beyond системные требования
  • Как установить game guardian на nox
  • Как установить dlc dark souls 3
  • Highfleet вылетает в редакторе

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

Комплексный аудит сайта, что входит, как сделать

Ошибка валидации, что это такое?

Для написания страниц используется HTML – стандартизированный язык разметки, применяемый в веб-разработке. HTML, как любой другой язык, имеет специфические особенности синтаксиса, грамматики и т. д. Если во время написания кода правила не учитываются, то после запуска сайта будут появляться различные виды проблем. Если HTML-код ресурса не соответствует стандарту W3C, то он является невалидным, о чем мы писали выше.

Почему ошибки валидации сайта оказывают влияние на ранжирование, восприятие?

Наличие погрешностей в коде – проблема, с которой необходимо бороться сразу после обнаружения. Поисковые системы «читают» HTML-код, если он некорректный, то процесс индексации и ранжирования может быть затруднен. Поисковые роботы должны понимать, каким является ресурс, что он предлагает, какие запросы использует. Особо критичны такие ситуации для ресурсов, имеющих большое количество веб-страниц.

Как проверить ошибки валидации?

Как проверить ошибки валидации
Для этой работы используется либо технический аудит сайта, либо валидаторы, которые ищут проблемы автоматически. Одним из самых популярных является сервис The W3C Markup Validation Service, выполняющий сканирование с оглядкой на World Wide Web Consortium (W3C). Рассматриваемый валидатор предлагает три способа, с помощью которых можно осуществить проверку сайта:

  • ввод URL-адреса страниц, которые необходимо просканировать;
  • загрузка файла страницы;
  • ввод части HTML-кода, нуждающегося в проверке.

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

Существуют другие сервисы, позволяющие выполнить проверку валидности кода:

  • Dr. Watson. Проверяет скорость загрузки страниц, орфографию, ссылки, а также исходный код;
  • InternetSupervision.com. Отслеживает производительность сайта, проверяет доступность HTML.

Плагины для браузеров, которые помогут найти ошибки в коде

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

  • HTML Validator для браузера Firefox;
  • HTML Validator for Chrome;
  • Validate HTML для Firefox.

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

Как исправить ошибку валидации?

Как исправить ошибку валидации
В первую очередь нужно сосредоточить внимание на слабых местах, связанных с контентом – это то, что важно для поисковых систем. Если во время сканирования было выявлено более 25 проблем, то их нельзя игнорировать из-за ряда причин:

  • частичная индексация;
  • медленная загрузка;
  • баги, возникающие во время непосредственной коммуникации пользователя с ресурсом.

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

Технический и SEO-аудит

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

В заключение

На всех сайтах наблюдаются ошибки валидации – их невозможно искоренить полностью, но и оставлять без внимания не стоит. Например, если провести проверку сайтов Google или «Яндекс», то можно увидеть ошибки, однако это не означает, что стоит вздохнуть спокойно и закрыть глаза на происходящее. Владелец сайта должен ставить во главу угла комплексное развитие, при таком подходе ресурс будет наполняться, обновляться и «лечиться» своевременно. Если проблем мало, то можно попробовать устранить их своими силами или с помощью привлечения стороннего частного специалиста. В остальных случаях лучше заказать услугу у проверенного подрядчика.

Что такое ошибки валидации и как их исправить

Просмотров 1.2к. Опубликовано 19.12.2022
Обновлено 19.12.2022

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

В этой статье рассмотрим, что такое валидность, какие могут быть ошибки в HTML-разметке и как их устранить.

Содержание

  1. Что такое HTML-ошибка валидации и зачем она нужна
  2. Чем опасны ошибки в разметке
  3. Как проверить ошибки валидации
  4. Предупреждения
  5. Ошибки
  6. Пример прохождения валидации для страницы сайта
  7. Как исправить ошибку валидации
  8. Плагины для браузеров, которые помогут найти ошибки в коде
  9. Коротко о главном

Что такое HTML-ошибка валидации и зачем она нужна

Под понятием  “валидация” подразумевается процесс онлайн-проверки HTML-кода страницы на соответствие стандартам w3c. Эти стандарты были разработаны Организацией всемирной паутины и стандартов качества разметки. Сама организация продвигает идею унификации сайтов по HTML-коду — чтобы каждому пользователю, вне зависимости от браузера или устройства, было удобно использовать ресурс.

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

Чем опасны ошибки в разметке

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

К наиболее распространённым последствиям ошибок в коде HTML-разметки также относят сбои в нормальной работе сайта и помехи в продвижении ресурса в поисковых системах.

Рассмотрим несколько примеров, как ошибки могут проявляться при работе:

  • Медленно подгружается страница 

Согласно исследованию Unbounce, более четверти пользователей покидают страницу, если её загрузка занимает более 3 секунд, ещё треть  уходит после 6 секунд;

  • Не видна часть текстовых, фото и видео-блоков 

Эта проблема делает контент для пользователей неинформативным, поэтому они в большинстве случаев уходят со страницы, не досмотрев её до конца;

  • Страница может остаться не проиндексированной

Если поисковый робот распознает недочёт в разметке, он может пропустить страницу и прервать её размещение в поисковых системах;

  • Разное отображение страниц на разных устройствах

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

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

Как проверить ошибки валидации

Владельцы ресурсов используют 2 способа онлайн-проверки сайтов на наличие ошибок — технический аудит или использование валидаторов. 

Первый случай подходит для серьёзных проблем и масштабных сайтов. Валидаторами же пользуются ежедневно. Наиболее популярный — сервис The W3C Markup Validation Service. Он сканирует сайт и сравнивает код на соответствие стандартам W3C. Валидатор выдаёт 2 типа несоответствий разметки стандартам W3C: предупреждения и ошибки. 

Давайте рассмотрим каждый из типов чуть подробнее.

Предупреждения

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

Тем не менее, предупреждения всё равно нужно устранять, так как из-за них сайт может работать медленнее — например, по сравнению с конкурентами с такими же сайтами.

Примером предупреждения может быть указание на отсутствие тега alt у изображения. 

Ошибки

Ошибки  —  это те проблемы, которые требуют обязательного устранения. 

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

Распространённым примером ошибки может быть отсутствие тега <!DOCTYPE html> в начале страницы, который помогает информации преобразоваться в разметку. 

Пример прохождения валидации для страницы сайта

Рассмотрим процесс валидации на примере сайта avavax.ru, который создали на WordPress.

пример ошибки валидации

В результате проверки валидатор выдал 17 замечаний. После анализа отчета их можно свести к 3 основным:

  1. атрибут ‘text/javascript’ не требуется при подключении скрипта;
  2. атрибут ‘text/css’ не требуется при подключении стиля;
  3. у одного из элементов section нет внутри заголовка h1-h6.

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

Решить проблемы с предупреждениями для стилей и скриптов можно через добавление кода в файл темы function.php.

Добавление кода в файл

Для этого на хук wp_loaded нужно повесить функцию output_buffer_start(), которая загрузит весь генерируемый код html в буфер. При выводе в буфер вызывается функция output_callback($tag), которая просматривает все теги, находит нежелательные атрибуты с помощью регулярных выражений и заменяет их пробелами. Затем на хук ‘shutdown вешается функция output_buffer_end(), которая возвращает обработанное содержимое буфера.

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

  1. Добавить заголовок в код:  <h3>Обо мне</h3>

Отключить отображение заголовка:

1 #about h3 {
2 display: none;
3 }

После этой части заголовок будет в коде, но валидатор его увидит, а посетитель — нет. 

За 3 действия удалось убрать все предупреждения, чтобы качество кода устроило валидатор. Это подтверждается зелёной строкой с надписью: “Document checking completed. No errors or warnings to show”.

Как исправить ошибку валидации

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

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

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

Плагины для браузеров, которые помогут найти ошибки в коде

Для поиска ошибок валидации можно использовать и встроенные в браузеры плагины. Они помогут быстро находить неточности еще на этапе создания кода. 

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

  • HTML Validator для браузера Firefox;
  • HTML Validator for Chrome;
  • HTML5 Editor для Opera.

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

Коротко о главном

Валидация — процесс выявления проблем с HTML-разметкой сайта и ее соответствия стандартам W3C. Это унифицированные правила, с помощью которых сайт может нормально работать и отображаться и для поисковых роботов, и для пользователей. 

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

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

Даже у крупных сайтов с миллионной аудиторией, например, Яндекс.Дзен или ВКонтакте, есть проблемы с кодом. Но комплексный подход к решению проблем помогает устранять серьёзные моменты своевременно. Нужно развивать сайт всесторонне, чтобы получить результат от его существования и поддержки. Если самостоятельно разобраться с проблемами не получается, не стоит “доламывать” — лучше обратиться за помощью к профессионалам, например, агентствам по веб-аудиту. 

  • Пожаловаться на файл
  • Как установить?
  • Добавил: Alina
  • 7-07-2020, 14:42

 ЧАСТОТА   АДРЕС  ПРИЧИНА  РЕШЕНИЕ

редкий

 0x00000000 SA-MP не инициализируется. Переустановите игру, убедитесь, что одиночная игра работает. Если у вас установлены какие-либо моды, удалите их.

редкий

 0x006E3D17 Смена скина игрока при его коннектевыходе, либо если он находится в авто. Менять скин игроку только тогда, когда он не в автомобиле. Либо поставить проверку.

редкий

 0x0058370A Краш происходит когда игрок только садится в авто, а его тут-же телепортируют вместе с авто в другую точку карты или интерьер. (Камера остается на том же месте где он садился) Подождать пока игрок сядет полностью в авто, либо использовать функцию SetCameraBehindPlayer при телепортации игрока с автомобилем.

редкий

 0x0040F64C Проблема в Windows 7 / Vista, связанная с разрешением экрана. Проблема в версии установщика, которую использует клиент SA-MP Обновление до SA-MP 0.3d. Если это все еще происходит, переименуйте Ваш каталог игры.

редкий

 0x0059F8B4 Происходит, когда клиенту не удается загрузить объекты SA-MP. Обычно проблема с одним большим файлом, samp.img отсутствует. Переустановите клиент. Попробуйте запустить программу установки с правами администратора, если используете Windows 7 / 8 / 8.1 / 10.

редкий

 0x00746929 ИЛИ 0x0081214A Плохо настроенный параметр на стороне клиента.

частый

 0x007F0BF7 Связанные с модернизацией транспортных средств. Часто вызывается, когда сервер пытается поставить недопустимый тюнинг на транспортное средство (например, NOS или спойлеры на мотоцикле). Другими причинами могут быть плохие клиентские моды автомобиля. На этих форумах были выпущены различные скрипты, в которых предусмотрена проверка ошибок.

частый

 0x00544BC8 Связано с объектами. Обычно происходит, когда для клиента отображается слишком много объектов, т.е. Больше, чем он может обработать. Одним из практических решений может быть использование обработчика / стримера объекта. Многие стримеры на этих форумах имеют настройки конфигурации, чтобы уменьшить максимальное количество видимых объектов, отображаемых для игрока в любой момент времени.

частый

 0x00415D47 Объект, связанный. Обычно происходит, когда слишком много текстур объекта загружено для клиента. Проблема низкого уровня, которую сложно отследить и исправить. Я думаю, это как-то связано со столкновениями. Это происходит случайным образом в зависимости от объекта. Попробуйте удалить группы объектов и использовать процесс исключения, чтобы установить, какие объекты вызывают его, и удалить их из своего режима.

частый

 0x00536DF4 Объект, связанный. Обычно происходит, когда слишком много текстур объекта загружено для клиента. Смотри выше.

частый

Коды предупреждений чата

 СООБЩЕНИЕ    ПРИЧИНА  РЕШЕНИЕ
Исключение 0xC0000005 в 0x5E5815 Сложно отследить. Метод, на который указывает этот адрес, выполняет множество задач. Он обрабатывает смешивание анимации на основе поверхности, на которой стоит пед, а затем имеет дело со звуком, и вызывается сразу после функции, которая * дает вам оружие … Возможно, здесь произошло то, что какое-то вызванное сценарием событие произошло прямо в момент, когда вы садитесь в транспортное средство (например, получаете оружие, телепортируетесь или что-то подобное). —
Исключение 0x0000005 в 0x534134 Проблема с уровнями доступа Windows 7 / 10 Запуск SA-MP в качестве администратора, кажется, чтобы исправить это.
Исключение 0xC0000005 в 0x544BC8 Смотрите 0x00544BC8 Смотрите 0x00544BC8
Исключение 0xC0000005 в 0x536DF4 Смотрите 0x00544BC8 Смотрите 0x00544BC8
Исключение 0xC0000005 в 0x7F120E Применен неверный тюнинг автомобиля

« Назад

  • Категория:
    Информационная база / Техническая информация
  • Просмотров: 11 470
  • Заменяет: Ничего
  • Стиллер не обнаружен

Ошибки валидации – это ошибки в коде страниц сайта, при этом ошибки на главной странице и на внутренних страницах сайта могут отличаться друг от друга. Сайт считается валидным, если у него отсутствуют ошибки в коде страниц сайта. Ошибки могут появляться в ходе разработки сайта, например, когда неверно закрыты html-теги или не закрыты вовсе, когда используются устаревшие теги, не задан тип документа (<!DOCTYPE html>), некорректно организована вложенность элементов и другие. Часть ошибок могут быть видимыми, и пользователь сможет заметить их при посещении страниц сайта, часть ошибок может быть скрытой от глаз.

Наиболее популярный и зарекомендовавший себя валидатор, на наш взгляд, – validator.w3.org, он сканирует сайт на наличие ошибок в соответствии с принятыми Консорциумом Всемирной паутины стандартами. Данный валидатор имеет 3 способа проверки на ошибки: ввести URL конкретной страницы вашего сайта, загрузить файл страницы сайта и ввести часть кода сайта, которую необходимо проверить.

После выполнения проверки вам будет предоставлен список ошибок на странице с указанием описания ошибки, номер строки с ошибкой и в какой части строки содержится ошибка.

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

Также существуют плагины для браузеров для поиска ошибок на страницах сайта.

http://users.skynet.be/mgueury/mozilla/ – плагин для Mozilla

https://chrome.google.com/webstore/detail/html-tidy-browser-extensi/gljdonhfjnfdklljmfaabfpjlonflfnm – плагин для Chrome

https://addons.opera.com/en/extensions/details/validator/ – плагин для Opera

После того как сайт проверили на ошибки, встает вполне резонный вопрос: нужно ли их немедленно удалять и чем это чревато при SEO-продвижении?

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

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

Давайте проанализируем, сколько ошибок присутствует в коде страниц у крупных ресурсов.

Яндекс:

Google:

ОАО «РЖД»:

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

Кстати, проверка сайта на ошибки, которые действительно влияют на продвижение, проходит в рамках SEO-аудита. Если сомневаетесь, что можете адекватно оценить свой сайт на наличие ошибок, обращайтесь. 

Зарегистрируйтесь для доступа к 15+ бесплатным курсам по программированию с тренажером

Валидация HTTP запросов
—
Веб-разработка на Go

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

В этом уроке мы разберем, как проверять HTTP-запросы в Go. Это важно, потому что проверки позволяют избежать ошибок и обеспечить безопасность нашего приложения.

Ручная проверка запросов в Go

Процесс проверки запросов на корректность перед последующей обработкой называется валидацией:

set

У разработчиков есть несколько вариантов реализации валидации в Go. В некоторых проектах придерживаются идеологии простоты чтения кода и реализуют валидацию вручную.

Например, валидация запроса на сохранение поста может выглядеть следующим образом:

package main

import (
    "errors"
    "fmt"
    "github.com/gofiber/fiber/v2"
    "github.com/sirupsen/logrus"
)

type CreatePostRequest struct {
    UserID int64  `json:"user_id"`
    Text   string `json:"text"`
}

func (req *CreatePostRequest) Validate() error {
    if req.UserID < 0 {
        return errors.New("user ID cannot be less than 0")
    }
    if req.Text == "" {
        return errors.New("text is empty")
    }
    if len(req.Text) > 140 {
        return errors.New("text is too long")
    }

    return nil
}

func main() {
    webApp := fiber.New()

    webApp.Post("/posts", func(ctx *fiber.Ctx) error {
        // Парсинг JSON-строки из тела запроса в объект.
        var req CreatePostRequest
        if err := ctx.BodyParser(&req); err != nil {
            return fmt.Errorf("body parser: %w", err)
        }

        // Проверка запроса на корректность.
        err := req.Validate()
        if err != nil {
            return ctx.Status(fiber.StatusUnprocessableEntity).SendString(err.Error())
        }

        // @TODO Сохранение поста в хранилище.

        return ctx.SendStatus(fiber.StatusOK)
    })

    logrus.Fatal(webApp.Listen(":80"))
}

Запускаем веб-приложение и отправляем запрос на создание поста с некорректными данными:

curl --location --request POST 'http://localhost/posts' 
--header 'Content-Type: application/json' 
--data-raw '{"user_id": -1, "text": ""}'

В данном запросе мы указали некорректный идентификатор пользователя и пустой текст поста. В ответ получаем сообщение об ошибке:

 HTTP/1.1 422 Unprocessable Entity

user ID cannot be less than 0%

Попробуем отправить корректные значения:

curl --location --request POST 'http://localhost/posts' 
--header 'Content-Type: application/json' 
--data-raw '{"user_id": 100, "text": "Hello, World!"}'

В ответ приходит статус 200 OK, что означает успешное прохождение проверок.

Таким образом, мы настроили проверку запросов, которые приходят в наше веб-приложение. Если запрос на создание поста содержит некорректные данные, то мы возвращаем ошибку. В случае успешной валидации запроса мы возвращаем ответ со статусом 200 OK.

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

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

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

Чтобы решить эти недочеты, следует использовать готовую библиотеку для валидации запросов. Мы рассмотрим самую часто используемую библиотеку в Go — go-playground/validator. Далее будем ее называть Validator.

Валидация запросов с помощью Validator

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

package main

import (
    "fmt"
    "github.com/go-playground/validator/v10"
    "github.com/gofiber/fiber/v2"
    "github.com/sirupsen/logrus"
)

type CreatePostRequest struct {
    // Описываем правила валидации в аннотациях полей структуры.
    UserID int64  `json:"user_id" validate:"required,min=0"`
    Text   string `json:"text" validate:"required,max=140"`
}

func main() {
    webApp := fiber.New()

    validate := validator.New()

    webApp.Post("/posts", func(ctx *fiber.Ctx) error {
        // Парсинг JSON-строки из тела запроса в объект.
        var req CreatePostRequest
        if err := ctx.BodyParser(&req); err != nil {
            return fmt.Errorf("body parser: %w", err)
        }

        // Проверка запроса на корректность.
        err := validate.Struct(req)
        if err != nil {
            return ctx.Status(fiber.StatusUnprocessableEntity).SendString(err.Error())
        }

        // @TODO Сохранение поста в хранилище.

        return ctx.SendStatus(fiber.StatusOK)
    })

    logrus.Fatal(webApp.Listen(":80"))
}

Запускаем веб-приложение и отправляем запрос на создание поста с некорректными данными:

curl --location --request POST 'http://localhost/posts' 
--header 'Content-Type: application/json' 
--data-raw '{"user_id": -1, "text": ""}'

В данном запросе мы указали некорректный идентификатор пользователя и пустой текст поста. В ответ получаем сообщение об ошибке:

 HTTP/1.1 422 Unprocessable Entity

Key: 'CreatePostRequest.UserID' Error:Field validation for 'UserID' failed on the 'min' tag
Key: 'CreatePostRequest.Text' Error:Field validation for 'Text' failed on the 'required' tag

Попробуем отправить корректные значения:

curl --location --request POST 'http://localhost/posts' 
--header 'Content-Type: application/json' 
--data-raw '{"user_id": 100, "text": "Hello, World!"}'

В ответ приходит статус 200 OK, что означает успешное прохождение проверок.

Так мы реализовали валидацию запросов с помощью библиотеки Validator. Когда мы передаем некорректные данные, то в ответ получаем сообщение об ошибке. Оно позволяет понять, какие данные необходимо исправить. Если все данные заполнены правильно, то мы получаем статус 200 OK.

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

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

package main

import (
    "fmt"
    "github.com/go-playground/validator/v10"
)

type User struct {
    Email string `validate:"required,email"`
}

func main() {
    v := validator.New()

    // Вывод: Key: 'User.Email' Error:Field validation for 'Email' failed on the 'required' tag
    fmt.Println(v.Struct(&User{}))
    // Вывод: Key: 'User.Email' Error:Field validation for 'Email' failed on the 'email' tag
    fmt.Println(v.Struct(&User{Email: "test"}))
    // Пустой вывод, так как ошибки нет.
    fmt.Println(v.Struct(&User{Email: "test@gmail.com"}))
}

Полный список правил проверок можно смотреть в документации.

Пользовательские валидаторы

Готовые правила обычно покрывают большинство нужд в валидации запросов. Но иногда нужно добавить свои правила с пользовательской логикой. Для этого можно использовать функцию validate.RegisterValidation().

Например, мы хотим проверить, что в публикуемом посте отсутствуют слова-фильтры. Для этого мы напишем следующий код:

package main

import (
    "fmt"
    "github.com/go-playground/validator/v10"
    "github.com/gofiber/fiber/v2"
    "github.com/sirupsen/logrus"
    "log"
    "strings"
)

type CreatePostRequest struct {
    // Описываем правила валидации в аннотациях полей структуры.
    UserID int64  `json:"user_id" validate:"required,min=0"`
    Text   string `json:"text" validate:"required,max=140,allowable_text"`
}

var forbiddenWords = []string{
    "umbrella",
    "shinra",
}

func main() {
    webApp := fiber.New()

    validate := validator.New()
    vErr := validate.RegisterValidation("allowable_text", func(fl validator.FieldLevel) bool {
        // Проверяем, что текст не содержит запрещенных слов.
        text := fl.Field().String()
        for _, word := range forbiddenWords {
            if strings.Contains(strings.ToLower(text), word) {
                return false
            }
        }

        return true
    })
    if vErr != nil {
        log.Fatal("register validation ", vErr)
    }

    webApp.Post("/posts", func(ctx *fiber.Ctx) error {
        // Парсинг JSON-строки из тела запроса в объект.
        var req CreatePostRequest
        if err := ctx.BodyParser(&req); err != nil {
            return fmt.Errorf("body parser: %w", err)
        }

        // Проверка запроса на корректность.
        err := validate.Struct(req)
        if err != nil {
            return ctx.Status(fiber.StatusUnprocessableEntity).SendString(err.Error())
        }

        // @TODO Сохранение поста в хранилище.

        return ctx.SendStatus(fiber.StatusOK)
    })

    logrus.Fatal(webApp.Listen(":80"))
}

Запускаем веб-приложение и отправляем запрос на создание поста с текстом, который содержит слово-фильтр:

curl --location --request POST 'http://localhost/posts' 
--header 'Content-Type: application/json' 
--data-raw '{"user_id": 100, "text": "Hello Umbrella corp!"}'

В ответ получаем валидационную ошибку:

HTTP/1.1 422 Unprocessable Entity

Key: 'CreatePostRequest.Text' Error:Field validation for 'Text' failed on the 'allowable_text' tag

Если же отправить запрос с текстом без запрещенных слов, то получим успешный ответ:

curl --location --request POST 'http://localhost/posts' 
--header 'Content-Type: application/json' 
--data-raw '{"user_id": 100, "text": "Hello Good corp!"}'

HTTP/1.1 200 OK

В итоге мы описали пользовательское правило валидации по тегу allowable_text. Оно проверяет, что текстовое поле не содержит запрещенных слов.

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

Выводы

  • В веб-приложениях следует проверять все запросы на корректность, чтобы избежать ошибок и уязвимостей

Каждый раз, когда я начинаю реализацию нового REST API с помощью Spring, мне сложно решить, как выполнять валидацию запросов и обрабатывать бизнес-исключения. В отличие от других типичных проблем API, Spring и его сообщество, похоже, не согласны с лучшими методами решения этих проблем, и трудно найти полезные статьи по этому поводу.

В этой статье я обобщаю свой опыт и даю несколько советов по валидации интерфейсов.

Архитектура и терминология

Я создаю свои приложения, которые предоставляют веб-API, следуя шаблону луковой архитектуры (Onion Architecture). Эта статья не об архитектуре Onion, но я хотел бы упомянуть некоторые из ее ключевых моментов, которые важны для понимания моих мыслей:

  • Контроллеры REST и любые веб-компоненты и конфигурации являются частью внешнего «инфраструктурного» уровня .

  • Средний «сервисный» уровень содержит сервисы, которые объединяют бизнес-функции и решают общие проблемы, такие как безопасность или транзакции.

  • Внутренний уровень «домена» содержит бизнес-логику без каких-либо задач, связанных с инфраструктурой, таких как доступ к базе данных, конечные точки web и т.д.

Набросок слоев луковой архитектуры и места размещения типичных классов Spring.

Набросок слоев луковой архитектуры и места размещения типичных классов Spring.

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

  • Запрос отправляется контроллеру на уровне «инфраструктуры».

  • Контроллер десериализует запрос и — в случае успеха — запрашивает результат у соответствующего сервиса на уровне сервисы.

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

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

  • Сервис также может вызывать несколько репозиториев, преобразовывать и агрегировать результаты.

  • Репозиторий на уровне домена возвращает бизнес-объекты. Этот уровень отвечает за поддержание всех объектов в допустимом состоянии.

  • В зависимости от ответа сервиса, который является допустимым результатом или исключением, уровень инфраструктуры сериализует ответ.

Проверка на уровне запроса, уровня обслуживания и домена.

Проверка на уровне запроса, уровня обслуживания и домена.

В этой архитектуре у нас есть три интерфейса, для каждого из которых требуется разная валидация:

  • Контроллер определяет первый интерфейс. Чтобы десериализовать запрос, нужно выполнить его валидацию по нашей схеме API . Это делается неявно с помощью фреймворка маппирования, такого как Jackson, и явно с помощью ограничений, таких как @NotNull. Мы называем это валидацией запроса .

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

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

Валидация запроса

Обычно мы десериализуем входящий запрос, для которого уже выполнена неявная валидация параметров запроса и тела запроса. Spring Boot автоматически настраивает Jackson десериализацию и общую обработку исключений. Например, взгляните на пример контроллера моей демонстрации BGG: 

@GetMapping("/newest")
Flux<ThreadsPerBoardGame> getThreads(@RequestParam String user, @RequestParam(defaultValue = "PT1H") Duration since) {
    return threadService.findNewestThreads(user, since);
}

Оба вызова с отсутствующим параметром и неправильным типом возвращают сообщения об ошибках с правильным кодом состояния :

curl -i localhost:8080/threads/newest
HTTP/1.1 400 Bad Request
Content-Type: application/json
Content-Length: 189

{"timestamp":"2020-04-15T03:40:00.460+0000","path":"/threads/newest","status":400,"error":"Bad Request","message":"Required String parameter 'user' is not present","requestId":"98427b15-7"}

curl -i "localhost:8080/threads/newest?user=chrigu&since=a"
HTTP/1.1 400 Bad Request
Content-Type: application/json
Content-Length: 156

{"timestamp":"2020-04-15T03:40:06.952+0000","path":"/threads/newest","status":400,"error":"Bad Request","message":"Type mismatch.","requestId":"7600c788-8"}

С конфигурацией по умолчанию Spring Boot мы также получим трассировки стека . Я выключил их, установив

server:
  error:
    include-stacktrace: never

в application.yml . Эта обработка ошибок по умолчанию обеспечивается BasicErrorController в классическом Web MVC и по DefaultErrorWebExceptionHandler в WebFlux, и извлечение тела ответа от ErrorAttributes.

Связывание данных

В приведенных выше примерах демонстрируются атрибуты @RequestParam или любой простой атрибут метода контроллера без аннотации. Проверка запроса становится иной при проверке @ModelAttribute , @RequestBody или непростых параметров, как в

@GetMapping("/newest/obj")
Flux<ThreadsPerBoardGame> getThreads(@Valid ThreadRequest params) {
    return threadService.findNewestThreads(params.user, params.since);
}

static class ThreadRequest {
    @NotNull
    private final String user;
    @NotNull
    private final Duration since;

    public ThreadRequest(String user, Duration since) {
        this.user = user;
        this.since = since == null ? Duration.ofHours(1) : since;
    }
}

Если аннотации @RequestParam могут использоваться, чтобы сделать параметр обязательным или со значением по умолчанию , в командных объектах это делается с помощью ограничений проверки bean-компонентов, таких как @NotNull и простой Java / Kotlin. Чтобы активировать проверку bean-компонента, аргумент метода должен быть аннотирован @Valid.

Когда проверка bean-компонента завершается неудачно, в реактивном стеке выдается исключение BindException или WebExchangeBindException . Оба исключения реализуют BindingResult, который предоставляет вложенные ошибки для каждого недопустимого значения поля. Вышеуказанный метод контроллера приведет к сообщениям об ошибках, например

curl "localhost:8080/java/threads/newest/obj" -i
HTTP/1.1 400 Bad Request
Content-Type: application/json
Content-Length: 1138

{"timestamp":"2020-04-17T13:52:39.500+0000","path":"/java/threads/newest/obj","status":400,"error":"Bad Request","message":"Validation failed for argument at index 0 in method: reactor.core.publisher.Flux<ch.chrigu.bgg.service.ThreadsPerBoardGame> ch.chrigu.bgg.infrastructure.web.JavaThreadController.getThreads(ch.chrigu.bgg.infrastructure.web.JavaThreadController$ThreadRequest), with 1 error(s): [Field error in object 'threadRequest' on field 'user': rejected value [null]; codes [NotNull.threadRequest.user,NotNull.user,NotNull.java.lang.String,NotNull]; arguments [org.springframework.context.support.DefaultMessageSourceResolvable: codes [threadRequest.user,user]; arguments []; default message [user]]; default message [darf nicht null sein]] ","requestId":"c87c7cbb-17","errors":[{"codes":["NotNull.threadRequest.user","NotNull.user","NotNull.java.lang.String","NotNull"],"arguments":[{"codes":["threadRequest.user","user"],"arguments":null,"defaultMessage":"user","code":"user"}],"defaultMessage":"darf nicht null sein","objectName":"threadRequest","field":"user","rejectedValue":null,"bindingFailure":false,"code":"NotNull"}]}

Настройка обработки исключений

Приведенное выше ответное сообщение не является удобным для клиента, поскольку оно содержит имена классов и другие внутренние подсказки, которые не могут быть понятны клиентом API. Еще худший пример обработки исключений по умолчанию Spring Boot:

curl "localhost:8080/java/threads/newest/obj?user=chrigu&since=a" -i
HTTP/1.1 500 Internal Server Error
Content-Type: application/json
Content-Length: 513

{"timestamp":"2020-04-17T13:56:42.922+0000","path":"/java/threads/newest/obj","status":500,"error":"Internal Server Error","message":"Failed to convert value of type 'java.lang.String' to required type 'java.time.Duration'; nested exception is org.springframework.core.convert.ConversionFailedException: Failed to convert from type [java.lang.String] to type [java.time.Duration] for value 'a'; nested exception is java.lang.IllegalArgumentException: Parse attempt failed for value [a]","requestId":"4c0dc6bd-21"}

Он также возвращает неправильный код ошибки, подразумевающий ошибку сервера, даже если клиент указал неправильный тип для параметра since. Оба примера были сгенерированы с помощью реактивного стека, MVC имеет лучшие значения по умолчанию. Для обоих случаев нам нужно настроить обработку исключений. Это можно сделать, предоставив собственный bean-компонент ErrorAttributes , который записывает желаемое тело ответа. Код состояния ответа предоставляется значением status.

Или мы можем пойти на меньшее вмешательство и использовать реализацию DefaultErrorAttributes, либо добавив в исключения аннотацию @ResponseStatus, либо позволив всем исключениям расширять ResponseStatusException . Оба способа позволяют настроить статус ответа и значение сообщения. К сожалению, большинство исключений, создаваемых на уровне инфраструктуры, предоставляются фреймворком и не могут быть настроены, поэтому нам нужно другое решение. Одна из возможностей для аннотированных контроллеров — использовать @ExceptionHandler для отдельных исключений. Тогда мы могли бы создать ответ с нуля, но это пропустило бы обработку исключений по умолчанию, и мы хотели бы иметь одинаковую обработку для каждого исключения. Таким образом, чтобы улучшить ответ выше, просто повторно вызовите исключения (rethrow):

@ControllerAdvice
class GlobalExceptionHandler {

    @ExceptionHandler(TypeMismatchException::class)
    fun handleTypeMismatchException(e: TypeMismatchException): HttpStatus {
        throw ResponseStatusException(HttpStatus.BAD_REQUEST, "Invalid value '${e.value}'", e)
    }

    @ExceptionHandler(WebExchangeBindException::class)
    fun handleWebExchangeBindException(e: WebExchangeBindException): HttpStatus {
        throw object : WebExchangeBindException(e.methodParameter!!, e.bindingResult) {
            override val message = "${fieldError?.field} has invalid value '${fieldError?.rejectedValue}'"
        }
    }
}

Резюме

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

  • Непосредственно в контроллере с помощью try/catch (MVC) или onErrorResume() (Webflux). Я не рекомендую это в большинстве случаев, потому что сквозная проблема, такая как обработка исключений, должна быть определена глобально, чтобы гарантировать согласованное поведение.

  • Перехватить исключения в функциях @ExceptionHandler . Создайте свои собственные ответы с помощью @ExceptionHandler (Throwable.class) для случая по умолчанию.

  • Или повторно генерируйте исключения , аннотируйте их с помощью @ResponseStatus или расширяйте ResponseStatusException, чтобы настроить ответ для определенных случаев.

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

В этом блоге я лишь поверхностно коснулся всего того, чему я научился за эти годы. Существует гораздо больше тем, касающихся валидации и обработки исключений, таких как внутренняя обработка сообщений об ошибках, пользовательские аннотации ограничений, различия между Java и Kotlin, автоматическое документирование ограничений и, конечно же, проверка данных на внутренних уровнях. Я продолжу эту тему в будущих статьях начиная с внутренних слоев и свяжу их.

Источник

Обновлено: 24.06.2023

Почти все разработчики так или иначе постоянно работают с api по http, клиентские разработчики работают с api backend своего сайта или приложения, а бэкендеры «дергают» бэкенды других сервисов, как внутренних, так и внешних. И мне кажется, одна из самых главных вещей в хорошем API это формат передачи ошибок. Ведь если это сделано плохо/неудобно, то разработчик, использующий это API, скорее всего не обработает ошибки, а клиенты будут пользоваться молчаливо ломающимся продуктом.

За 7 лет я как поддерживал множество legacy API, так и разрабатывал c нуля. И я поработал, наверное, с большинством стратегий по возвращению ошибок, но каждая из них создавала дискомфорт в той или иной мере. В последнее время я нащупал оптимальный вариант, о котором и хочу рассказать, но с начала расскажу о двух наиболее популярных вариантах.

Если у вас примитивная бизнес-логика или API из 5 url, то в принципе это нормальный подход. Однако как-только бизнес-логика станет сложнее, то начнется ряд проблем.

REST скорее концепция, чем формат общения из чего следует неоднозначность использования статусов. Разработчики используют статусы как им заблагорассудится. Например, некоторые API при отсутствии сущности возвращают 404 и текст ошибки, а некоторые 200 и пустое тело.

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

Когда бизнес-логика приложения усложняется, начинают делать как-то так:

Принудительный вызов валидации

Для принудительного вызова проверки, без использования Spring Boot, создайте валидатор вручную.

Тем не менее, Spring Boot предоставляет предварительно сконфигурированный экземпляр валидатора. Внедрив этот экземпляр в сервис не придется создавать его вручную.

Когда этот сервис внедряется Spring, в конструктор автоматически вставляется экземпляр валидатора.

Группы валидаций

Некоторые объекты участвуют в разных вариантах использования.

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

  • только перед созданием
  • только перед обновлением
  • или в обоих случаях

Функция Bean Validation, которая позволяет нам внедрять такие правила проверки, называется «Validation Groups».

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

Для нашего примера CRUD определим два маркерных интерфейса OnCreate и OnUpdate :

Затем используем эти интерфейсы с любой аннотацией ограничения:

Это позволит убедиться, что id пуст при создании и заполнен при обновлении.

Spring поддерживает группы проверки только с аннотацией @Validated

Обратите внимание, что аннотация @Validated применяется ко всему классу. Чтобы определить, какая группа проверки активна, она также применяется на уровне метода.

Использование групп проверки может легко стать анти-паттерном. При использовании групп валидации сущность должна знать правила валидации для всех случаев использования (групп), в которых она используется.

Сначала нужно определить эту структуру данных. Назовем ее ValidationErrorResponse и она содержит список объектов Violation :

Затем создадим глобальный ControllerAdvice , который обрабатывает все ConstraintViolationExventions , которые пробрасываются до уровня контроллера. Чтобы отлавливать ошибки валидации и для тел запросов, мы также будем работать с MethodArgumentNotValidExceptions :

Здесь информацию о нарушениях из исключений переводится в нашу структуру данных ValidationErrorResponse .

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

Валидация сущностей JPA

Persistence Layer это последняя линия проверки данных. По умолчанию Spring Data использует Hibernate, который поддерживает Bean Validation из коробки.

Обычно мы не хотим делать проверку так поздно, поскольку это означает, что бизнес-код работал с потенциально невалидными объектами, что может привести к непредвиденным ошибкам.

Допустим, необходимо хранить объекты нашего класса Input в базе данных. Сначала добавляем нужную JPA аннотацию @Entity , а так же поле id :

Когда репозиторий пытается сохранить невалидный Input , чьи аннотации ограничений нарушаются, выбрасывается ConstraintViolationException .

Bean Validation запускается Hibernate только после того как EntityManager вызовет flush.

Чтобы отключить Bean Validation в репозиториях Spring, достаточно установить свойство Spring Boot spring.jpa.properties.javax.persistence.validation.mode равным null .

№2: На все 200

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

На самом деле формат зависит от вас или от выбранной библиотеки для реализации коммуникации, например JSON-API.

В некоторых случаях, если есть библиотека десериализации данных, она может взять часть работы на себя. Писать SDK вокруг такого подхода проще нежели вокруг той или иной имплементации REST, ведь реализация зависит от того, как это видел автор. Кроме того, теперь никто не вызовет случайное срабатывание alert в мониторинге из-за того, что выбрал неудачный код ошибки.

Но неудобства тоже есть:

Избыточность полей при передаче данных, т.е. нужно всегда передавать 2 поля: для данных и для ошибки. Это усложняет чтение логов и написание документации.

При использовании средств отладки (Chrome DevTools) или других подобных инструментов вы не сможете быстро найти ошибочные запросы бизнес логики, придется обязательно заглянуть в тело ответа (ведь всегда 200)

нельзя делать повторы для неудавшихся GET запросов (на backend) на реверс-прокси (например, nginx) по указанной выше причине

имеются проблемы с документированием – swagger и ApiDoc не подходят, а удобных аналогов я не нашел

Итог: Для сложной бизнес-логики с большим количеством типов ошибок такой подход лучше, чем расплывчатый REST, не зря в проектах c “разухабистой” бизнес-логикой часто именно такой подход и используют.

№3: Смешанный

400 – ошибка бизнес логики

остальное ошибки в транспорте

Мы можем расширять объект ошибки для детализации проблемы, если хотим. С мониторингом все как во втором варианте, дописывать парсинг придется, но и риска “стрельбы” некорректными alert нету. Для документирования можем спокойно использовать Swagger и ApiDoc. При этом сохраняется удобство использования инструментов разработчика, таких как Chrome DevTools, Postman, Talend API.

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

Самое главное какой бы формат ошибок вы бы не выбрали лучше обговорить его заранее и следовать ему. Если эту вещь пустить на “самотек”, то очень скоро обработка ошибок в проекте станет невыносимо сложной для всех.

P.S. Иногда ошибки любят передавать массивом

Но это актуально в основном в двух случаях:

Когда наш API выступает в роли сервиса без фронтенда (нет сайта/приложения). Например, сервис платежей.

Когда в API есть url для загрузки какого-нибудь длинного отчета в котором может быть ошибка в каждой строке/колонке. И тогда для пользователя удобнее, чтобы ошибки в приложении сразу показывались все, а не по одной.

Антонина Пшеничникова

SMMplanner

Антонина Пшеничникова

Антонина Пшеничникова

Когда захожу на вашу почту support. вобще происходит что-то непонятное, есть скрин

SMMplanner

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

Максим Захаров

SMM planner, здравствуйте. Сильно упали охваты после атвопостинга. Речь идёт о инстаграме. Возможно из-за сммпланера?

Добавьте возможность отмечать на видео для ленты в инстаграме. А то несерьезно как-то. В самой инсте уже около года это возможно.

SMMplanner

SMMplanner

Рома Егорихин

Произошла ошибка валидации.

Ни один сайт с автопостингом и тд не могу подключить.
Что я сделал до этого?
Создал бота по правилам , токен отправил на сайт вместе с ссылкой на канал (был новый канал для проверки и нужный мой канал) ни один не смог подключиться.
Пересоздал бота и добавил его в ManyBot (не знаю зачем) , все равно ошибка.

maksim92

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

maksim92

Andrew Stark, ну а если связать эти две вещи и вынести? Вы же программист симфони)

Правда это slim. Но на симфони можно сделать так, чтобы вообще этот метод убрать из контроллера.

Нередко пользователи пытаются передать в приложение некорректные данные. Это происходит либо из злого умысла, либо по ошибке. Поэтому стоит проверять данные на соответствие бизнес-требованиям.

Эту задачу решает Bean Validation. Он интегрирован со Spring и Spring Boot. Hibernate Validator считается эталонной реализацией Bean Validation.

Добавление пользовательского валидатора

Если имеющихся аннотаций ограничений недостаточно, то создайте новые.

В классе Input использовалось регулярное выражение для проверки того, что строка является IP адресом. Регулярное выражение не является полным: оно позволяет сокеты со значениями больше 255, таким образом «111.111.111.333» будет считаться действительным.

Давайте напишем валидатор, который реализует эту проверку на Java. Потому что как говорится, до решения проблемы регулярным выражением у вас была одна проблема, а теперь стало двe :smile:

Сначала создаем пользовательскую аннотацию @IpAddress :

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

Теперь можно использовать аннотацию @IpAddress , как и любую другую аннотацию ограничения.

Валидация в Spring MVC Controller

  • тело запроса
  • переменные пути (например, id в /foos/)
  • параметры запроса

Рассмотрим каждый из них подробнее.

Валидация тела запроса

Тело запроса POST и PUT обычно содержит данные в формате JSON. Spring автоматически сопоставляет входящий JSON с объектом Java.

Проверяем соответствует ли входящий Java объект нашим требованиям.

  • Поле numberBetweenOneAndTen должно быть от 1 до 10, включительно.
  • Поле ipAddress должно содержать строку в формате IP-адреса.

Контроллер REST принимает объект Input и выполняет проверку:

Достаточно добавить в параметр input аннотацию @Valid , чтобы сообщить спрингу передать объект Валидатору, прежде чем делать с ним что-либо еще.

Если класс содержит поле с другим классом, который тоже необходимо проверить — это поле необходимо пометить аннотацией Valid.

Проверка переменных пути и параметров запроса

Проверка переменных пути и параметров запроса работает по-другому.

Не проверяются сложные Java-объекты, так как path-переменные и параметры запроса являются примитивными типами, такими как int , или их аналогами: Integer или String .

Вместо аннотации поля класса, как описано выше, добавляют аннотацию ограничения (в данном случае @Min ) непосредственно к параметру метода в контроллере Spring:

Обратите внимание, что необходимо добавить @Validated Spring в контроллер на уровне класса, чтобы сказать Spring проверять ограничения на параметрах метода.

В этом случае аннотация @Validated устанавливается на уровне класса, даже если она присутствует на методах.

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

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

Можно проверять данные на любых компонентах Spring. Для этого используется комбинация аннотаций @Validated и @Valid .

Аннотация @Validated устанавливается только на уровне класса, так что не ставьте ее на метод в данном случае.

Основы валидации Bean

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

При передаче размеченного таким образом объекта класса в валидатор, происходит проверка на ограничения.

Настройка

Добавьте следующие зависимости в проект:

Стандартные ограничения

Каждая аннотация имеет следующие поля:

Рассмотрим популярные ограничения.

@NotNull и @Null

@NotNull — аннотированный элемент не должен быть null. Принимает любой тип.
@Null — аннотированный элемент должен быть null. Принимает любой тип.

@NotBlank и @NotEmpty

@NotBlank — аннотированный элемент не должен быть null и должен содержать хотя бы один непробельный символ. Принимает CharSequence .
@NotEmpty — аннотированный элемент не должен быть null или пустым. Поддерживаемые типы:

  • CharSequence
  • Collection . Оценивается размер коллекции
  • Map . Оценивается размер мапы
  • Array . Оценивается длина массива

@NotBlank применяется только к строкам и проверяет, что строка не пуста и не состоит только из пробелов.

@NotNull применяется к CharSequence , Collection , Map или Array и проверяет, что объект не равен null . Но при этом он может быть пуст.

@NotEmpty применяется к CharSequence , Collection , Map или Array и проверяет, что он не null имеет размер больше 0.

Аннотация @Size(min=6) пропустит строку состоящую из 6 пробелов и/или символов переноса строки, а @NotBlank не пропустит.

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

  • CharSequence . Оценивается длина последовательности символов
  • Collection . Оценивается размер коллекции
  • Map . Оценивается размер мапы
  • Array . Оценивается длина массива

Валидация конфигурации приложения

Spring Boot аннотация @ConfigurationProperties используется для связывания свойств из application.properties с Java объектом.

Данные из application необходимы для стабильной работы приложения. Bean Validation поможет обнаружить ошибку в этих данных при старте приложения.

Допустим имеется следующий конфигурационный класс:

При попытке запуска с недействительным адресом электронной почты получаем ошибку:

Читайте также:

      

  • Fortnite ошибка 0xc000007b normaliz dll

    •   

  • Medal of honor above and beyond системные требования

    •   

  • Как установить game guardian на nox

    •   

  • Как установить dlc dark souls 3

    •   

  • Highfleet вылетает в редакторе
Источник

Автор PanKamenets, 03 фев 2023, 20:11

0 Пользователей и 1 гость просматривают эту тему.

Добрый день. Передаю в json данные на сервис. Но постоянно получаю статус 400 и {«code»:»RequestModelValidationError»,»description»:»Ошибка валидации параметров запроса»,»traceId»:»00-91cf045709dbeb51ae156e1d437d8a6f-3ffbaccc9f94b74c-00″,»messages»:[«$: The JSON value could not be converted to Shate.WebApi.Models.ArticlePrice.ArticlePriceFilterKey[]. Path: $ | LineNumber: 0 | BytePositionInLine: 1.»]}. Адрес, куда стучусь написан верно, передаваемые параметры в структуре тоже написаны верно.

PanKamenets, а все в структуре в JSON залетает правильно. В JSON есть ограничение по типам, которые он кушает. МОжет где-то уникальный идентификатор пытаетесь передать или что-то наподобие?

передаю 2 параметра, строку и число

PanKamenets, а там JSON в структуру или соответствие заворачивается? может здесь собака порылась?

  • 1 пользователь сказал спасибо!

В документации api ничего не сказано, в каком виде передавать данные. Я везде передавал json структурой и все работало корректно.

проверьте какие заголовки передаете

Content-Type: text/json?

Максим75, Вы навели на меня на мысль, что я делаю не так. Решил проблему. Огромное спасибо!

Необходимо было просто положить структуру в массив, невнимательно прочитал документацию api

Теги:

  • Форум База
  • ►
    Форум 1С — ПРЕДПРИЯТИЕ 8.0 8.1 8.2 8.3 8.4
  • ►
    Конфигурирование, программирование в 1С Предприятие 8
  • ►
    Ошибка валидации параметров запроса Http запрос

Похожие темы (5)

Рейтинг@Mail.ru

Rambler's Top100

Поиск

Источник

Просмотров 10к. Опубликовано 19.12.2022
Обновлено 19.12.2022

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

В этой статье рассмотрим, что такое валидность, какие могут быть ошибки в HTML-разметке и как их устранить.

Содержание

  1. Что такое HTML-ошибка валидации и зачем она нужна
  2. Чем опасны ошибки в разметке
  3. Как проверить ошибки валидации
  4. Предупреждения
  5. Ошибки
  6. Пример прохождения валидации для страницы сайта
  7. Как исправить ошибку валидации
  8. Плагины для браузеров, которые помогут найти ошибки в коде
  9. Коротко о главном

Что такое HTML-ошибка валидации и зачем она нужна

Под понятием  “валидация” подразумевается процесс онлайн-проверки HTML-кода страницы на соответствие стандартам w3c. Эти стандарты были разработаны Организацией всемирной паутины и стандартов качества разметки. Сама организация продвигает идею унификации сайтов по HTML-коду — чтобы каждому пользователю, вне зависимости от браузера или устройства, было удобно использовать ресурс.

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

Чем опасны ошибки в разметке

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

К наиболее распространённым последствиям ошибок в коде HTML-разметки также относят сбои в нормальной работе сайта и помехи в продвижении ресурса в поисковых системах.

Рассмотрим несколько примеров, как ошибки могут проявляться при работе:

  • Медленно подгружается страница 

Согласно исследованию Unbounce, более четверти пользователей покидают страницу, если её загрузка занимает более 3 секунд, ещё треть  уходит после 6 секунд;

  • Не видна часть текстовых, фото и видео-блоков 

Эта проблема делает контент для пользователей неинформативным, поэтому они в большинстве случаев уходят со страницы, не досмотрев её до конца;

  • Страница может остаться не проиндексированной

Если поисковый робот распознает недочёт в разметке, он может пропустить страницу и прервать её размещение в поисковых системах;

  • Разное отображение страниц на разных устройствах

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

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

Как проверить ошибки валидации

Владельцы ресурсов используют 2 способа онлайн-проверки сайтов на наличие ошибок — технический аудит или использование валидаторов. 

Первый случай подходит для серьёзных проблем и масштабных сайтов. Валидаторами же пользуются ежедневно. Наиболее популярный — сервис The W3C Markup Validation Service. Он сканирует сайт и сравнивает код на соответствие стандартам W3C. Валидатор выдаёт 2 типа несоответствий разметки стандартам W3C: предупреждения и ошибки. 

Давайте рассмотрим каждый из типов чуть подробнее.

Предупреждения

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

Тем не менее, предупреждения всё равно нужно устранять, так как из-за них сайт может работать медленнее — например, по сравнению с конкурентами с такими же сайтами.

Примером предупреждения может быть указание на отсутствие тега alt у изображения. 

Ошибки

Ошибки  —  это те проблемы, которые требуют обязательного устранения. 

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

Распространённым примером ошибки может быть отсутствие тега <!DOCTYPE html> в начале страницы, который помогает информации преобразоваться в разметку. 

Пример прохождения валидации для страницы сайта

Рассмотрим процесс валидации на примере сайта avavax.ru, который создали на WordPress.

пример ошибки валидации

В результате проверки валидатор выдал 17 замечаний. После анализа отчета их можно свести к 3 основным:

  1. атрибут ‘text/javascript’ не требуется при подключении скрипта;
  2. атрибут ‘text/css’ не требуется при подключении стиля;
  3. у одного из элементов section нет внутри заголовка h1-h6.

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

Решить проблемы с предупреждениями для стилей и скриптов можно через добавление кода в файл темы function.php.

Добавление кода в файл

Для этого на хук wp_loaded нужно повесить функцию output_buffer_start(), которая загрузит весь генерируемый код html в буфер. При выводе в буфер вызывается функция output_callback($tag), которая просматривает все теги, находит нежелательные атрибуты с помощью регулярных выражений и заменяет их пробелами. Затем на хук ‘shutdown вешается функция output_buffer_end(), которая возвращает обработанное содержимое буфера.

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

  1. Добавить заголовок в код:  <h3>Обо мне</h3>

Отключить отображение заголовка:

1 #about h3 {
2 display: none;
3 }

После этой части заголовок будет в коде, но валидатор его увидит, а посетитель — нет. 

За 3 действия удалось убрать все предупреждения, чтобы качество кода устроило валидатор. Это подтверждается зелёной строкой с надписью: “Document checking completed. No errors or warnings to show”.

Как исправить ошибку валидации

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

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

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

Плагины для браузеров, которые помогут найти ошибки в коде

Для поиска ошибок валидации можно использовать и встроенные в браузеры плагины. Они помогут быстро находить неточности еще на этапе создания кода. 

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

  • HTML Validator для браузера Firefox;
  • HTML Validator for Chrome;
  • HTML5 Editor для Opera.

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

Коротко о главном

Валидация — процесс выявления проблем с HTML-разметкой сайта и ее соответствия стандартам W3C. Это унифицированные правила, с помощью которых сайт может нормально работать и отображаться и для поисковых роботов, и для пользователей. 

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

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

Даже у крупных сайтов с миллионной аудиторией, например, Яндекс.Дзен или ВКонтакте, есть проблемы с кодом. Но комплексный подход к решению проблем помогает устранять серьёзные моменты своевременно. Нужно развивать сайт всесторонне, чтобы получить результат от его существования и поддержки. Если самостоятельно разобраться с проблемами не получается, не стоит “доламывать” — лучше обратиться за помощью к профессионалам, например, агентствам по веб-аудиту. 

Источник

Содержание

  1. Ошибки при обработке документов Честным знаком
  2. Как узнать статус документа в Честном Знаке?
  3. Что такое ошибки валидации и как их исправить: инструкция
  4. Ошибка валидации, что это такое?
  5. Почему ошибки валидации сайта оказывают влияние на ранжирование, восприятие?
  6. Как проверить ошибки валидации?
  7. Плагины для браузеров, которые помогут найти ошибки в коде
  8. Как исправить ошибку валидации?
  9. Технический и SEO-аудит
  10. В заключение
  11. Валидация
  12. Принципы
  13. Виды валидации
  14. Валидация по потере фокуса
  15. Когда использовать
  16. Как работает
  17. Валидация при отправке формы
  18. Когда использовать
  19. Как работает
  20. Блокирование кнопки отправки
  21. Сообщения об ошибках
  22. Тултипы
  23. Как работают
  24. Единообразие поведения и внешнего вида
  25. Красные тексты на странице
  26. Как работают
  27. Валидация зависимых полей
  28. Пример

Ошибки при обработке документов Честным знаком

Когда стороны сделки подписывают УПД, оператор ЭДО, передаёт в ГИС МТ «Честный ЗНАК» информацию, содержащуюся в этом документе. Затем в системе маркировки начинается дополнительная проверка документа и после завершения проверки, пользователь в личном кабинете системы маркировки может увидеть следующий результат:

  1. Когда у документа появляется статус «Обработан успешно» — означает, что произошел переход прав собственности на маркированные товары. Товары из документа можно реализовывать дальше.
  2. Когда у документа появляется статус «Обработан с ошибками» — означает, что переход права собственности на маркированные товары не произошел.

Как узнать статус документа в Честном Знаке?

Для просмотра статуса документа необходимо выполнить следующие действия:

1. Перейдите в личный кабинет по ссылке

2. Выберите необходимую товарную группу:

3. Перейдите в раздел «Документы»:

4. В разделе «Документы» выберите вкладку «Документы»:

5. Статус документа можно отфильтровать:

6. Если есть документ со статус «Обработан с ошибкой», то ошибку можно посмотреть, зайдя в документ:

7. Для того чтобы посмотреть ошибку, нажмите на кнопку «Сформировать список ошибок»

8. Дождитесь формирования списка ошибок:

9. Затем скачайте список ошибок, нажав на кнопку «Скачать список ошибок»

10. Скачанный документ рекомендуется извлечь из архива и открыть через блокнот:

11. Затем в документе можно посмотреть текст ошибки:

В образце указан номер ошибки «24», «Статус кода маркировки <КМ>не соответствует выполняемой операции»

Источник

Что такое ошибки валидации и как их исправить: инструкция

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

Ошибка валидации, что это такое?

Для написания страниц используется HTML – стандартизированный язык разметки, применяемый в веб-разработке. HTML, как любой другой язык, имеет специфические особенности синтаксиса, грамматики и т. д. Если во время написания кода правила не учитываются, то после запуска сайта будут появляться различные виды проблем. Если HTML-код ресурса не соответствует стандарту W3C, то он является невалидным, о чем мы писали выше.

Почему ошибки валидации сайта оказывают влияние на ранжирование, восприятие?

Наличие погрешностей в коде – проблема, с которой необходимо бороться сразу после обнаружения. Поисковые системы «читают» HTML-код, если он некорректный, то процесс индексации и ранжирования может быть затруднен. Поисковые роботы должны понимать, каким является ресурс, что он предлагает, какие запросы использует. Особо критичны такие ситуации для ресурсов, имеющих большое количество веб-страниц.

Как проверить ошибки валидации?

Для этой работы используется либо технический аудит сайта, либо валидаторы, которые ищут проблемы автоматически. Одним из самых популярных является сервис The W3C Markup Validation Service, выполняющий сканирование с оглядкой на World Wide Web Consortium (W3C). Рассматриваемый валидатор предлагает три способа, с помощью которых можно осуществить проверку сайта:

  • ввод URL-адреса страниц, которые необходимо просканировать;
  • загрузка файла страницы;
  • ввод части HTML-кода, нуждающегося в проверке.

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

Существуют другие сервисы, позволяющие выполнить проверку валидности кода:

  • Dr. Watson. Проверяет скорость загрузки страниц, орфографию, ссылки, а также исходный код;
  • InternetSupervision.com. Отслеживает производительность сайта, проверяет доступность HTML.

Плагины для браузеров, которые помогут найти ошибки в коде

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

  • HTML Validator для браузера Firefox;
  • HTML Validator for Chrome;
  • Validate HTML для Firefox.

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

Как исправить ошибку валидации?

В первую очередь нужно сосредоточить внимание на слабых местах, связанных с контентом – это то, что важно для поисковых систем. Если во время сканирования было выявлено более 25 проблем, то их нельзя игнорировать из-за ряда причин:

  • частичная индексация;
  • медленная загрузка;
  • баги, возникающие во время непосредственной коммуникации пользователя с ресурсом.

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

Технический и SEO-аудит

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

В заключение

На всех сайтах наблюдаются ошибки валидации – их невозможно искоренить полностью, но и оставлять без внимания не стоит. Например, если провести проверку сайтов Google или «Яндекс», то можно увидеть ошибки, однако это не означает, что стоит вздохнуть спокойно и закрыть глаза на происходящее. Владелец сайта должен ставить во главу угла комплексное развитие, при таком подходе ресурс будет наполняться, обновляться и «лечиться» своевременно. Если проблем мало, то можно попробовать устранить их своими силами или с помощью привлечения стороннего частного специалиста. В остальных случаях лучше заказать услугу у проверенного подрядчика.

Источник

Валидация

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

Описанное здесь поведение валидаций и отображение ошибок реализовано в библиотеке «React UI Validations», по возможности используйте эту библиотеку в продукте.

Принципы

Задача дизайнера — сделать так, чтобы пользователь не совершил ошибку и валидация не понадобилась, для этого:

  1. Ограничьте выбор заведомо неверных значений в списке: блокируйте эти значения или не показывайте в списке.
  2. Ограничьте ввод неподходящих символов. Если в поле нужно вводить только цифры, и это очевидно пользователю, игнорируйте ввод букв вместо того, чтобы показать ошибку. Используйте маски в полях, где у значений известен формат.
  3. Пишите подсказки для заполнения формы. Например, плейсхолдер в полях ввода.

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

Виды валидации

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

Чем раньше интерфейс сообщает об ошибке, тем лучше — пользователю проще вернуться и исправить ошибку.

Самый быстрый способ сообщить об ошибке — мгновенная валидация. Но она возможна только в тех случаях, когда в процессе ввода понятно, что значение некорректное. Обычно такие ошибки связаны с неправильной раскладкой клавиатуры (кириллица вместо латиницы) или вводом букв в цифровое поле (ИНН, КПП и др.) Для этих случаев мы используем поля с масками: ввод неподходящих символов в них заблокирован. Поэтому в наших интерфейсах есть только два вида валидации:

  • по потере фокуса — основной вид валидации
  • по отправке формы — для тех случаев, когда валидация по потере фокуса невозможна.

Валидация по потере фокуса

Когда использовать

Этот вид валидации подходит для большинства случаев.

Как работает

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

Валидация срабатывает сразу после потери фокуса, если значение в поле заполнено. Если найдена ошибка, поле подсвечивается красным. Фокус в это поле автоматически не возвращается:

Текст ошибки появляется в тултипе, когда поле получает наведение или фокус:

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

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

Валидация при отправке формы

Когда использовать

Используйте этот вид валидации, когда нельзя проверить поля по потере фокуса. Например, для проверки заполнения обязательных полей.

Как работает

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

При прокрутке к первому полю от верхней границы окна до ошибочного поля остается отступ 48px — шесть модулей.

Блокирование кнопки отправки

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

Как только заполнены все обязательные поля — кнопка становится активной. Если после этого пользователь стер значение в одном из полей — кнопка снова должна стать не активной.

Сообщения об ошибках

Об ошибках можно сообщать двумя способами:

  1. Красным текстом около поля, обычно под полем или справа от него:
  2. Текстом в тултипе:

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

Тултипы

Как работают

Тултип с подсказкой появляется в двух случаях:

  1. При наведении на поле с ошибкой.
  2. Когда поле с ошибкой получает фокус.

Если значение в поле с ошибкой было изменено, потеряло фокус, а потом заново оказалось в фокусе — тултип с текстом старой ошибки уже не возникает. Это правило одинаково работает для всех типов валидаций: и по потере фокуса, и при отправке формы.

Тултип исчезает, когда:

  1. Курсор вышел из области поля с ошибкой.
  2. Поле с ошибкой потеряло фокус.

Тултип по наведению перекрывает тултип по фокусу.

Тултип может появляться сверху или справа от контрола с ошибкой, так чтобы он не перекрывал полезную информацию:

Единообразие поведения и внешнего вида

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

Красные тексты на странице

Как работают

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

Как только пользователь начал исправлять значение, красная подсветка поля исчезает, и цвет текста ошибки меняется на черный —  #333.

Текст ошибки пропадает по потере фокуса и больше не появляется, если поле заново получает фокус. Это правило одинаково работает для всех типов валидаций: и по потере фокуса, и при отправке формы.

Выводите текст ошибки справа, если на форме есть место, а само сообщение короткое. Так форму не придется раздвигать, чтобы показать ошибку.

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

На более сложных формах выводите сообщение об ошибке в тултипе.

Валидация зависимых полей

Зависимые поля — это поля, значение которых зависит друг от друга.

Ошибки, которые связаны с нарушением зависимости полей, мы показываем после сабмита формы. Например, ИНН и КПП. Если пользователь указал ИНН из 10 цифр, а поле с КПП оставил пустым, после отправки формы пустое поле с КПП будет подсвечено.

ИНН может быть двух видов:

  • 10-значный у юридических лиц
  • 12-значный у ИП.

Если пользователь указал ИНН из 12 цифр, значит организация — индивидуальный предприниматель, и у нее нет КПП, значит поле КПП заполнять не нужно. И наоборот, если заполнено КПП, а ИНН указан 12-значный, возможно неверно указан ИНН.

Подсветка зависимых полей пропадает, как только пользователь начал исправлять значение в одном из этих полей.

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

Пример

Есть форма из 5 полей:

  • Название организации — простое текстовое, обязательное
  • ИНН — 10 или 12 цифр, проверка контрольной суммы по потере фокуса, обязательное
  • КПП — 9 цифр с проверкой контрольной суммы по потере фокуса, обязательное, если ИНН состоит из 10 цифр
  • Электронная почта — адрес почты, проверка по потере фокуса по маске a@a.aa, необязательное
  • Телефон — международный формат, проверка по потере фокуса по маске +00000000000, обязательное

Пользователь пропустил поле с названием организации, заполнил ИНН значением из 10 цифр, перешел в поле почты, указал некорректный адрес, перешел в поле с телефоном и указал некорректный номер, но из поля пока не ушел:

Пользователь навел курсор на поле с почтой, появился тултип. Но исправлять значение пользователь не стал:

Пользователь нажал кнопку «Отправить» — фокус перешел в поле «Название организации», так как оно обязательное и незаполненное:

Поле с телефоном также подсветилось красным, так как заполнено некорректно. ИНН и КПП подсветились, так как ИНН состоит из 10 цифр, значит должен быть заполнен и КПП — валидация зависимых полей произошла только после отправки формы.

Пользователь начинает вводить название организации, подсветка поля гаснет, а текст подсказки остается:

Заполнил название организации, перешел в поле ИНН:

Понял, что ИНН правильный, и нужно заполнить КПП:

Начал заполнять поле КПП. Красная рамка у ИНН и КПП исчезла — пользователь изменил значение в одном из зависимых полей:

Заполнил КПП, перешел в следующее поле:

Исправил почту, перешел в следующее поле:

Исправил телефон, кликнул за пределами поля:

Теперь по нажатию кнопки «Отправить» все будет хорошо.

Реализованный пример этой формы можно посмотреть в библиотеке валидаций.

Источник

Источник

  • Ошибка валидации токена recaptcha
  • Ошибка валидации запроса аризона рп
  • Ошибка валидации домена ботхелп
  • Ошибка валидации документов что это такое
  • Ошибка валидации документов личный кабинет лукойл