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

Question

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

Поскольку это не очень понятно, вот пример.

Допустим, посетитель может что-то прокомментировать.

• Комментарий сохраняется в базе данных в столбце nvarchar(500).
• Длина поля <input /> ограничена 500.

Но, конечно, ничто не запрещает более опытному пользователю отключить ограничение длины и ввести 501 символ.

(Другие примеры: отправка опции, которой даже нет в<select />. Но там - это изящная ошибка, когда пользователя просят ввести число, и вместо этого она вводит не число, поскольку события нажатия клавиш контролируются с помощью JavaScript, иJavaScript может быть отключен)

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

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

---

Примечание. Я понимаю, что отстойно отображать подробную ошибку .NET Frameworkи трассировка стека, когда что-то подобное происходит.Если я это сделаю, это серьезная проблема безопасности.Но в моем случае это просто ответ AJAX с чем-то очень общим или перенаправление на общую страницу с извинениями за ошибку.

Answer 1

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

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

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

Короче говоря, то, что вы делаете, прекрасно.

Answer 2

Сначала самое главное

Вы должны проверить все, что пользователь поставляет на сервер! Это означает, что 501 букв не пропускается через

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

Лучший способ - отобразить общую ошибку, например: «Извините, мы сразу же решаем проблему» и отправим разработчикам по электронной почте информацию об исключении, чтобы они могли ее исправить. *

Answer 3

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

Я бы предложил вам спросить себя, почему вы не справляетесь с этими очень простыми в управлении ситуациями. Это лень или вам просто не хватает опыта как пользователя?

Answer 4

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

Answer 5

Зачем мне создавать чёткие и явные сообщения об ошибках в тех случаях, когда посетитель, правильно использующий сайт, никогда не получит?

Если бы все пользовались Интернетом правильно, нам бы никогда не потребовалось валидации.

Как однажды сказал Рональд Рейган: «Доверяй, но проверяй».

Включить проверку на стороне сервера для длины полей. Поставьте валидацию, чтобы убедиться в отсутствии атак XSS или SQL-инъекций. Вам нужно беспокоиться не о людях, которые правильно используют ваш сайт, а о тех, кто использует его злонамеренно.

Answer 6

Проверка на стороне сервера для двух основных целей:

• как постепенное ухудшение, если проверка клиента по какой-то причине не работает

  • в этом случае вам нужно приятное удобное сообщение

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

  • в этом случае вам не нужны никакие внутренние данные

Если вы хотите пойти по пути истинной постепенной деградации, было бы НИЧЕГО, если бы сервер все еще возвращал пользователю дружественное сообщение для каждой проверки.

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

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