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

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

Так как это не очень понятно, вот пример.

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

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

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

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

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

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

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


user-interface asp.net usability
person Arseni Mourzenko    schedule 14.01.2011    source источник
comment
Ты ведь шутишь, правда? Похоже, ты просто не хочешь работать. Пользователь не должен видеть кучу ошибок кода. У вас должна быть надлежащая проверка ошибок, которая не должна позволять пользователям делать то, чего они явно не должны. Вы должны проверить это во внешнем интерфейсе (JavaScript) и в серверной части. Если пользователь каким-то образом обходит проверки javascript, ваша система должна уловить его, прежде чем пытаться отправить его в БД.   -  person xil3    schedule 14.01.2011
comment
@ xil3 - Ты хоть вопрос читал? В нем говорится, что он защищен на FrontEnd с помощью maxlength и на backend с помощью контрактов кода. Он спрашивает, должен ли он отображать отформатированное (и потенциально переведенное) сообщение об ошибке для сценария, который может быть вызван только злоумышленником.   -  person Richard Szalay    schedule 14.01.2011
comment
@MainMa - я думаю, вам нужно перефразировать свой вопрос, поскольку каждый ответ здесь упускает из виду.   -  person Richard Szalay    schedule 14.01.2011
comment
@Richard: Да, я прочитал это и написал это, основываясь на том, что я понял. Это был не очень четкий вопрос, поэтому я добавил его в качестве комментария ...   -  person xil3    schedule 14.01.2011
comment
@ xil3 - Вы не ошиблись.   -  person Richard Szalay    schedule 14.01.2011
comment
Я просто перечитал его еще раз, и, судя по тому, что он написал, нет никаких указаний на то, что он выполняет какую-либо внутреннюю проверку. If the visitor does so, there would be a failure on code contracts level. The AJAX request would fail with an unexpected error (or, on page submit, there will be an unexpected error). - не должно быть «неожиданной» ошибкой, если она проверена на сервере. Если он был отправлен через AJAX с 501, серверная часть должна обработать его правильно, а не просто дать сбой.   -  person xil3    schedule 14.01.2011
comment
@ xil3 - контракты кода вызовут исключение, если проверка завершится неудачно. Возвращенная ошибка не содержит информации об исключении (он упоминает это в примечании внизу). Он спрашивает, требуется ли для ошибки специальное сообщение об ошибке.   -  person Richard Szalay    schedule 14.01.2011
comment
Это отстой? что это, Digg?   -  person adolf garlic    schedule 14.01.2011
comment
В стороне: по моему опыту как пользователь, я предпочитаю, когда текстовое поле не ограничивает то, что я набираю, а вместо этого проверяет поля, когда я нажимаю кнопку отправки (прерывание и выделение плохих полей, если что-то не так).   -  person Dunes    schedule 14.01.2011

Ответы (6)


arrow_upward
8
arrow_downward

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

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

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

Короче то, что ты делаешь, нормально.

person Richard Szalay    schedule 14.01.2011

arrow_upward
4
arrow_downward

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

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

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

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

person m.edmondson    schedule 14.01.2011
comment
В вопросе указано, что длинная запись будет поймана. Он спрашивает, следует ли отображать удобное для пользователя сообщение в ситуации, когда пользователь явно вмешивается в систему. - person Richard Szalay; 14.01.2011
comment
Если пользователь знает, как возиться с вашим приложением, вы, конечно, не должны ему помогать, поэтому вы должны отображать только общее сообщение - person m.edmondson; 14.01.2011
comment
Что вы имеете в виду под утверждением? Если я использую кодовые контракты для ограничения длины до 500 символов, это означает, что пользователь вряд ли сможет пойти дальше бизнес-уровня при отправке 501 письма. Даже если она это сделает, столбец базы данных ограничен 500 символами (даже если мне не нравится идея отправить в базу данных запрос, который обязательно завершится ошибкой). - person Arseni Mourzenko; 14.01.2011
comment
В вашей ситуации контракты кода защищают вас, но вы также должны стремиться использовать элементы управления, такие как элементы управления проверкой ASP.NET. Это гарантирует, что недействительные данные будут остановлены при первой возможности. - person m.edmondson; 14.01.2011
comment
@MainMa у вас должна быть проверка переднего и заднего плана, а не только передняя часть. - person xil3; 14.01.2011
comment
-1 Хотя ничего из того, что вы сказали, неверно, вы упустили всю суть вопроса. В вопросе указано, что он не возвращает информацию об исключении и что проверка защищена на стороне сервера. - person Richard Szalay; 14.01.2011

arrow_upward
2
arrow_downward

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

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

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

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

person George Stocker    schedule 14.01.2011
comment
-1 ОП заявил, что использует кодовые контракты. Он спрашивает, следует ли возвращать конкретный код ошибки или общий сбой (без информации об исключениях) подходит. - person Richard Szalay; 14.01.2011

arrow_upward
2
arrow_downward

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

person Joseph Ferris    schedule 14.01.2011
comment
Я знаю, что вопрос не ясен на 100%, но он явно не делает такого предположения. - person Richard Szalay; 14.01.2011
comment
Мы все понимаем, что упустили суть вопроса, но мне кажется немного грубым, что вам пришлось выделить время, чтобы указать на это во всех ответах, кроме вашего собственного, и даже сказать, что вы голосовали против других. Пусть ваш ответ сам по себе стоит. Независимо от того, получили ли вы его только вы, в этих сообщениях все еще есть много ценной информации. - person Joseph Ferris; 14.01.2011
comment
Непонимание вопроса - единственная причина, по которой я добавил ответ, и, честно говоря, мне показалось грубым, что почти все ответы неверно истолковывают вопрос и затем намекнули, что OP был каким-то ленивым или иным образом некомпетентным . Я добавил -1 комментарий, потому что мне не нравится, когда анонимно голосуют против. Кстати, если вы поставите перед комментарием префикс @Richard (имеют значение только первые 3 символа), я буду автоматически уведомлен. - person Richard Szalay; 15.01.2011

arrow_upward
2
arrow_downward

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

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

person Joel Etherton    schedule 14.01.2011
comment
То, что вы описываете, не то, что он описывает. - person Richard Szalay; 14.01.2011

arrow_upward
0
arrow_downward

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

  • как постепенная деградация, если проверка клиента не работает по какой-то причине

    • in this case, you want a nice user-friendly message

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

    • in this case, you want no internal details displayed

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

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

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

person O'Rooney    schedule 31.10.2011