La mejor manera de permitir las cookies de sesión de subdominio con Tomcat

Question

Por defecto, tomcat creará una cookie de sesión para el dominio actual.

Si está en www.example.com, su cookie se creará para www.example.com (solo funcionará en www.example.com). Mientras que para example.com se creará para .example.com (el comportamiento deseado, funcionará en cualquier subdominio de example.com así como de example.com).

He visto algunas válvulas Tomcat que parecen interceptar la creación de cookies de sesión y crear una cookie de reemplazo con el dominio .example.com correcto, sin embargo, ninguna de ellas parece funcionar sin problemas y todas parecen salir de la cookie existente y simplemente crea una nueva. Esto significa que se envían dos cookies de JSESSIONID con cada solicitud.

Me preguntaba si alguien tiene una solución definitiva a este problema.

Answer 1

Esto aparentemente es compatible a través de una configuración en 6.0.27 en adelante:

La configuración se realiza mediante la edición de META-INF/context.xml

< Contexto sessionCookiePath = "/ algo" sessionCookieDomain =/>

"domain.tld."

https://issues.apache.org/bugzilla/show_bug.cgi?id=48379

Answer 2

Me he encontrado con esto en $ DAYJOB. En mi caso, quería implementar el inicio de sesión SSL y luego redirigir a una página que no es SSL. El problema principal en tomcat es el método (de memoria) SessionManager.configureSessionCookie que codifica todas las variables a las que le gustaría tener acceso.

Se me ocurrieron algunas ideas, incluyendo un truco particularmente atroz usando mod_headers en apache para reescribir la cookie basada en la sustitución de expresiones regulares.

La forma definitiva de resolver esto sería enviar un parche a los desarrolladores de tomcat que agregue parámetros configurables a la clase SessionManager.

Answer 3

Como una sesión (y su Id) se considera básicamente de valor solo para la aplicación de emisión, puede buscar establecer una cookie adicional. Eche un vistazo a Tomcats SingleSignOnValve, proporcionando el extra Cookie JSESSIONIDSSO (tenga en cuenta el ... SSO) para la ruta del servidor "/" en lugar de "/ applicationName" (ya que las cookies JSESSIONID suelen estar configuradas).

Con tal válvula puede implementar cualquier comunicación entre procesos que necesite para sincronizar cualquier estado entre diferentes servidores, hosts virtuales o aplicaciones web en cualquier cantidad de tomcats/servidores web/lo que sea.

Otra razón por la que no puede usar la cookie de sesión de tomcat para sus propios fines es que varias aplicaciones web en el mismo host tienen identificadores de sesión diferentes. P.ej. hay diferentes cookies para "/ webapp1" y "/ webapp2". Si proporciona la cookie "/ webapp1" a "/ webapp2", no encontrará la sesión a la que hizo referencia, invalidará su sesión + cookie y establecerá una nueva. Tendría que volver a escribir todo el manejo de la sesión de Tomcat para aceptar valores de identificación de sesión externos (mala idea de seguridad) o para compartir un cierto estado entre las aplicaciones.

El manejo de sesiones debe considerarse el negocio de contenedores (tomcat). Cualquier otra cosa que necesite, debe agregar sin interferir con lo que el contenedor cree que es necesario hacer.

Answer 4

Las técnicas de la válvula no parecen ser 100% perfectas. Si se atreve a modificar Tomcat sí:

catalina.jar contiene la clase siguiente: org.apache.catalina.connector.Solicitud

La solicitud tiene un método:

configureSessionCookie(Cookie cookie) 

Para nuestro medio ambiente que lo mejor era simplemente codificar, pero que podría hacer la lógica más elegante:

cookie.setDomain(".xyz.com"); 

parece funcionar perfectamente. Sería bueno si esto fuera configurable en Tomcat.

Answer 5

Acabo de pasar por todo esto en busca de una solución simple. Empecé a mirarlo desde la perspectiva de Tomcat primero.

Tomcat no da acceso directo a la configuración de la cookie de dominio para la sesión, y definitivamente no quería personalizar el parche de tomcat para solucionar ese problema como se muestra en otras publicaciones.

Las válvulas en tomcat también parecen ser una solución problema debido a las limitaciones para acceder a las cookies de encabezados & integradas en la especificación de Servlet. También fallan por completo si se confirma la respuesta http antes de que pase a su válvula.

Como aprobamos nuestras solicitudes a través de Apache, pasé a utilizar apache para solucionar el problema.

Probé por primera vez la directiva mod_proxy ProxyPassReverseCookieDomain, pero no funciona para las cookies de JSESSIONID porque tomcat no establece el atributo de dominio y ProxyPassReverseCookieDomain no puede funcionar sin algún tipo de dominio que forme parte de la cookie.

También encontré un truco usando ProxyPassReverseCookiePath, donde estaban reescribiendo la ruta para agregar un atributo de dominio a la cookie, pero eso parecía demasiado complicado para un sitio de producción.

Finalmente lo tengo que trabajar reescribiendo los encabezados de respuesta usando el módulo mod_headers en apache mencionado por Dave arriba.

he añadido la siguiente línea dentro de la definición de host virtual:

Header edit Set-Cookie "(JSESSIONID\s?=[^;,]+?)((?:;\s?(?:(?i)Comment|Max-Age|Path|Version|Secure)[^;,]*?)*)(;\s?(?:(?i)Domain\s?=)[^;,]+?)?((?:;\s?(?:(?i)Comment|Max-Age|Path|Version|Secure)[^;,]*?)*)(,|$)" "$1$2; Domain=.example.com$4$5" 

lo anterior debe ser todos una sola línea en la config. Reemplazará cualquier atributo de dominio de cookies JSESSIONID con ".example.com". Si una cookie JSESSIONID no contiene un atributo de dominio, entonces el patrón agregará uno con un valor de ".example.com". Como beneficio adicional, esta solución no sufre el doble problema de cookies JSESSION de las válvulas.

El patrón debería funcionar con varias cookies en el encabezado Set-Cookie sin afectar las otras cookies en el encabezado. También debe ser modificable trabajar con otras cookies cambiando JSESSIONID en la primera parte del patrón por el nombre de cookie que desee.

No soy usuario avanzado de reg-ex, por lo que estoy seguro de que hay un par de optimizaciones que se podrían hacer para el patrón, pero parece estar funcionando para nosotros hasta ahora.

Actualizaré esta publicación si encuentro algún error con el patrón. Con suerte, esto evitará que algunos de ustedes pasen los últimos dos días frustrados como yo.