Que NO hacer al mostrar errores en un sitio de ASP.NET público

jueves 7 de junio de 2007

Ayer que me disponía a ir al cine a pesar de ser miércoles 2x1 (o "miércoles de pelusa" como dice un amigo), pues lancé mi navegador para intentar revisar la cartelera en el sitio de una de las cadenas de salas de cine nacionales (no les digo cual pa' no quemarlos). Me recibió el siguiente mensaje. Como dicen los gringos: what's wrong with this picture? Pues para comenzar se me ocurre:

  1. No están manejando las excepciones adecuadamente. Aunque un error levantado por el HttpRuntime es un poco más difícil de atrapar, hay maneras de regresar páginas de error personalizadas que estén más bonitas y no asusten a los usuarios con las letrotas grandes y rojas.
  2. Están mostrando la información de debug con todo y el stack trace (!). Esto podría darles las herramientas o al menos información a alguien que quisiera hackearlos. Por ejemplo, con ese mensaje ya sé al menos qué versión del .NET Framework están utilizando, lo cual podría servirme para ver qué vulnerabilidades específicas pudiera explotar. Pero algunos otros mensajes de error son mucho más chismosos.
  3. "Server Too Busy" en mi mente se traduce a "somos bien codos y no compramos un web farm" o "no le invertimos en planear la capacidad necesaria" o "nuestra aplicación no escala como debería"... lo cual no deberías comunicar a tus clientes nunca.
¿Se te ocurre alguna otra razón para no permitir este tipo de situaciones?

categorías:

2 comentarios:

  1. Anónimo dijo:

    sip, usan windows.

    :-P

  2. k dijo:

    jeje ni tan anonimo... era cinepolis