Aquí está el contexto:ambiente de producción - página de error http 500 - no stacktrace por favor
Yo trabajo para una empresa muy grande. Aquí, tenemos muchos clústeres de WebSphere Application Server, cada uno ejecutando muchas aplicaciones web Java EE. La mayoría (pero no todas) de estas aplicaciones contienen directivas especiales en su web.xml para mostrar la página de error personalizada cuando ocurre una excepción inesperada. He aquí un ejemplo:
<error-page>
<error-code>500</error-code>
<location>/500.jsp</location>
</error-page>
Al hacer esto, por supuesto, nuestro objetivo es mostrar una página de error de usar para nuestros clientes, sino que, además, nuestro objetivo es principalmente para ocultar los stacktraces que por lo general se incluyen en las páginas de error estándar HTTP 500 .
Como debe saber, estas stacktraces incluyen una gran cantidad de datos confidenciales, como nombres de paquetes, nombres de clases e incluso nombres de métodos. Lo peor, a veces, estas stacktraces contienen excepciones SQL, que a menudo revelan qué bases de datos se usa el software del servidor. Incluso peor, en algún momento, estas stacktraces contienen rutas de archivos y carpetas, que, a su vez, pueden revelar en qué familia de sistemas operativos se ejecuta nuestro WebSphere Application Server.
¿Debo mencionar todos los datos aún más confidenciales que pueden revelarse en estas stacktraces? (Nombres de usuario, números de puerto, direcciones IP, nombres de equipos/servidores, nombres de objetos JNDI ...)
Por lo tanto, no hay gran sorpresa aquí, cada gran empresa necesita ocultar estas stacktraces a sus clientes.
Pero, aquí es nuestro problema:
En algún momento, incluso con una página de error personalizada bien configurado en el archivo web.xml, WebSphere envía la página de error básico en el navegador web del cliente. Entiendo muy bien por qué WebSphere hace eso. Como ejemplo, sé que cuando los encabezados de la respuesta http ya están comprometidos, WebSphere no puede restablecer su búfer para enviar la página de error personalizada, y entonces no puede hacer nada mejor que enviar una página de error básica.
Aquí es mi pregunta:
(1) ¿Es posible configurar WebSphere para que nunca jamás incluye cualquier StackTrace en su página de error básico? De esta forma, incluso cuando, por algún motivo técnico, WebSphere no pueda enviar nuestra página de error personalizada, al menos la página de error básico no incluirá ningún dato confidencial.
¿Cómo podemos hacer esto?
Gracias,
No se puede responder a su pregunta específica acerca de cómo deshabilitar el seguimiento de pila, pero no tiene un servidor web o proxy en al frente de WebSphere, donde puede establecer una página de error allí? – dbreaux
Cuando obtiene la página de error predeterminada, utiliza un servidor web delante de WAS y va a través del complemento http? – ams
Utilizamos Microsoft Internet Information Server frente a nuestros servidores WebSphere y utilizamos el plugin de WebSphere (un filtro ISAPI) para reenviar las solicitudes HTTP a nuestros servidores WebSphere. Además, utilizamos la consola de administración de WebSphere para generar nuestros archivos "plugin-cfg.xml". No podemos editar estos archivos (porque si los editamos para ajustarlos, los reeditaríamos constantemente para mantener nuestros ajustes). Por lo tanto, si se requieren algunas modificaciones en estos archivos, la consola de administración de WebSphere deberá incluir estas modificaciones al generar los archivos "plugin-cfg.xml". – closingBrace