¿Es malo no proporcionar errores graciosos a un usuario que no usa el sitio web correctamente?

Question

Recientemente recibí un comentario de un colega sobre mi código fuente de un sitio web. Él dice que es una mala práctica no manejar con gracia lo que la interfaz visual no permite.

Como no está muy claro, he aquí un ejemplo.

Digamos que un visitante puede comentar algo.

• Un comentario se guarda en una base de datos, en la columna nvarchar(500).
• La longitud <input /> campo está limitado a 500.

Pero, por supuesto, nada impide a un usuario más avanzado a desactivar el límite de longitud y para escribir 501 caracteres.

(Otros ejemplos:. Presentar una opción que ni siquiera existe en un <select />Pero no es un error de elegante cuando se le pide al usuario que introduzca un número, y ella entra en un no-número en lugar, ya los eventos de pulsación de tecla se controlan a través de JavaScript, y es posible que JavaScript esté deshabilitado)

Si el visitante lo hace, se produce un error en el nivel de contratos de código. La solicitud AJAX fallaría con un error inesperado (o, en el envío de la página, habrá un error inesperado). En todos los casos, el visitante verá que algo malo sucedió, pero no tendrá un mensaje elegante que indique que la duración del comentario enviado es demasiado larga.

¿Por qué es una mala práctica? ¿Por qué me molestaría en diseñar mensajes de error claros y explícitos para los casos en que el visitante que usa correctamente el sitio web nunca tendrá?

---

Nota: entiendo que aspira a mostrar un error detallada de .NET Framework y un seguimiento de pila cuando sucede algo como esto. Si lo hago, es un grave problema de seguridad. Pero en mi caso, solo hay una respuesta AJAX con algo muy genérico o una redirección a una página genérica con la que se disculpa por un error.

Answer 1

Como todo el mundo parece que falta la pregunta real, voy a poner en mi 2c (aunque sin duda a estar downvoted en venganza)

Mientras sus entradas se validan lado del servidor (el cliente- la duración máxima del lado está probablemente bien, aunque algunos navegadores poco conocidos pueden no ser compatibles), puede devolver un mensaje de error genérico siempre que no contenga ninguna información de excepción (que usted ha indicado que no).

Si, sin embargo, es posible fallar la validación por falta de javascript o entrada incorrecta, se debe proporcionar un mensaje de error personalizado en aras de la cordura del usuario.

En resumen, lo que está haciendo está bien.

validación del lado del servidor

Answer 2

Primero lo más importante un

debe validar todo lo que los equipos de usuario en el servidor! Esto significa no dejar que 501 cartas a través

Aparte de eso, si se produce una excepción no controlada se debe mostrar al usuario un mensaje la que no da nada de distancia. Si devolvió información de excepción, esto es polvo de oro a un atacante.

El mejor método es mostrar un error general como "Lo sentimos, estamos trabajando en el problema de inmediato" y enviar por correo electrónico la información de la excepción a los desarrolladores para que la solucionen.

Answer 3

¿Por qué me molestaría en diseñar mensajes de error claros y explícitos para los casos en que el visitante que utiliza correctamente el sitio web nunca tendrá?

Si todos usaran la web correctamente, nunca necesitaríamos tener validación.

Como dijo una vez Ronald Reagan, "Confíe, pero verifique".

Ponga en la validación del lado del servidor la longitud de los campos. Ponga en validación para asegurarse de que no haya ningún ataque de inyección XSS o SQL. No son las personas que usan su sitio correctamente de las que tiene que preocuparse, sino las que lo usan maliciosamente.

Answer 4

Creo que la mayor parte del problema es que está asumiendo que la validación solo debería estar ocurriendo en la interfaz de usuario. Lo mejor es validar en la interfaz de usuario y el back-end. No es necesario devolver un rastreo de pila o información de excepción detallada. En Page_Load(), siempre debe estar validando nuevamente todas las entradas del usuario y mostrando la información estáticamente, como si el usuario hubiera deshabilitado JavaScript.

Answer 5

Lo que estás describiendo no es solo una mala práctica, es un mal diseño. Si puede anticipar un error o excepción, entonces debe anticipar los métodos para manejarlo, mitigarlo o aliviarlo. Esto se aplica a cualquier diseño de interfaz, ya sea para un sitio web o un refrigerador. Si un visitante obtiene un error genérico y no se le da una idea de cómo solucionarlo, ¿por qué debería esa persona molestarse en usar su sitio web? Si se ven obligados (por razones de trabajo tal vez), entonces todo lo que has hecho es alejar a tu cliente y darte una mala reputación.

Le sugiero que se pregunte por qué no maneja estas situaciones tan fáciles de controlar. ¿Es pereza o simplemente carece de experiencia como usuario?

Answer 6

es para dos propósitos principales:

• como una degradación gradual si la validación del cliente no funciona por alguna razón

  • en este caso, desea que un usuario agradable Mensaje fácil de usar

• como una medida de seguridad para garantizar que los clientes malintencionados no puedan dañar su sistema.

  • en este caso, es preferible no hay detalles internos muestran

Si usted quiere tomar la ruta de la verdadera degradación elegante, sería bueno si el servidor todavía devolvió al usuario una mensaje amistoso para cada validación

En el caso de maxLength, esto no es muy probable que sea necesario. Pero muchos tipos de validación usan Javascript, y todavía existen personas o plataformas que no admiten Javascript. Las plataformas móviles más antiguas serían los principales sospechosos aquí.

Sin embargo, en la actualidad, la mayoría de nosotros suponemos que se puede confiar en Javascript, por lo que un mensaje de error genérico si falla la validación del servidor está bien.