La mejor manera para permitir el subdominio cookies de sesión usando Tomcat
https://stackoverflow.com/questions/82645
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Por defecto tomcat creará una cookie de sesión para el dominio actual.
Si usted está en www.example.com, su cookie se creará para www.example.com (sólo funciona en www.example.com).Mientras que para example.com será creado .example.com (comportamiento deseado, funcionará en cualquier subdominio de example.com así como example.com en sí).
Yo he visto un par de Tomcat válvulas que parecen interceptar la creación de cookies de sesión y la creación de una nueva cookie con la correcta .example.com de dominio, sin embargo, ninguno de ellos parece funcionar a la perfección y todos parecen salir de la existente cookie y acaba de crear una nueva.Esto significa que dos JSESSIONID las cookies se envían con cada solicitud.
Me preguntaba si alguien tiene una solución definitiva a este problema.
Solución
Al parecer, esto es apoyado a través de una configuración en 6.0.27 y en adelante:
La configuración se realiza mediante la edición META-INF/context.xml
<Context sessionCookiePath="/something" sessionCookieDomain=".domain.tld" />
Otros consejos
He pasado por todo esto buscando una solución sencilla.Yo empecé a mirarlo desde el tomcat perspectiva de la primera.
Tomcat no dan acceso directo a la configuración del dominio de la cookie de la sesión, y yo definitivamente no quería personalizado parche tomcat para solucionar ese problema, como se muestra en algunos otros posts.
Válvulas en tomcat también parece ser un problema de solución debido a las limitaciones en el acceso encabezados y las cookies integradas en la especificación Servlet.Ellos también fallan completamente si la respuesta http es confirmada antes de que se pasa a la válvula.
Desde que nos proxy nuestras peticiones a través de Apache, luego me mudé en cómo utilizar apache para solucionar el problema en su lugar.
Probé por primera vez el mod_proxy directiva ProxyPassReverseCookieDomain, pero no funciona para JSESSIONID cookies porque tomcat no se establece el atributo de dominio y ProxyPassReverseCookieDomain no puede funcionar sin algún tipo de dominio que se parte de la cookie.
También me he topado con un hack usando ProxyPassReverseCookiePath donde estaban la reescritura de la ruta de acceso para agregar un atributo de dominio de la cookie, pero que se sentía en forma desordenada para un sitio de producción.
Finalmente llegué a trabajar por la reescritura de los encabezados de respuesta utilizando el mod_headers módulo en apache como se ha mencionado por Dave arriba.
He añadido la siguiente línea dentro de la definición del alojamiento 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 debería ser todos de una sola línea en el archivo de configuración config.Reemplazará cualquier JSESSIONID cookies de dominio de un atributo ".example.com".Si una cookie JSESSIONID no contiene un atributo de dominio, a continuación, el patrón va a agregar una con un valor de ".example.com".Como un bono, esta solución no sufren el doble JSESSION cookies problema de las válvulas.
El patrón debe trabajar con varias cookies en el encabezado Set-Cookie sin afectar a los demás "cookies" en el encabezado.También debe ser modificable para trabajar con otras cookies cambiando JSESSIONID en la primera parte del patrón a lo que nunca nombre de la cookie que usted desea.
Yo no soy reg-ex usuario de energía, así que estoy seguro de que hay un par de optimizaciones que podía ser hecha al patrón, pero parece ser que trabajan para nosotros hasta el momento.
Voy a actualizar este post si encuentro algún error con el patrón.Esperemos que esto se detenga unos de tener que ir a través de el último par de días la pena de frustraciones, como yo hice.
Me he topado con este $dias laborales.En mi caso, quería implementar SSL de inicio de sesión a continuación, redirigir a un no SSL página.El problema central en el tomcat es el método (de la memoria) SessionManager.configureSessionCookie que duro códigos de todas las variables que se desea obtener acceso.
Se me ocurrió un par de ideas, incluyendo particularmente atroz hack usando mod_headers en apache para reescribir la cookie basado en regex sustitución.
El definative manera de resolver esto sería enviar un parche para el tomcat desarrolladores que añade parámetros configurables para el SessionManager clase.
Como una sesión (y su Id) es básicamente considera de valor sólo para el issueing aplicación, usted puede buscar para el establecimiento de una cookie adicional.Tener una mirada en la juerga de solteros SingleSignOnValve, proporcionando la extra-Cookie JSESSIONIDSSO (nota de la ...SSO) para la ruta de acceso del servidor "/" en lugar de "/applicationName" (como JSESSIONID cookies son generalmente conjunto).
Con una Válvula que puede implementar cualquier comunicación entre usted necesita para sincronizar cualquier estado entre diferentes servidores, hosts virtuales o webapps en cualquier número de juerga de solteros/servidores/lo que sea.
Otra razón por la que usted no puede utilizar juerga de solteros cookie de sesión para sus propios fines, que múltiples webapps en el mismo host tienen diferentes identificadores de sesión.E. g.hay diferentes cookies para "/webapp1" y "/webapp2".Si usted proporciona "/webapp1"'s cookie "/webapp2", este no iba a encontrar la sesión que se hace referencia, invalidar la sesión+cookie y establecer su propia nueva.Tendría que reescribir todos de juerga de solteros manejo de sesiones para aceptar externo sesión de identificación de valores (mala idea securitywise) o compartir un cierto estado de las solicitudes.
Manejo de sesiones deben ser considerados los contenedores (juerga de solteros) de negocios.Cualquier otra cosa que usted necesita, usted debe agregar sin interferir con lo que el contenedor cree que es necesario hacer.
La válvula de técnicas no parecen ser 100% perfecto.Si usted se atreve a modificar Tomcat sí mismo:
catalina.jar contiene la siguiente clase: org.apache.catalina.el conector.Solicitud
La Solicitud tiene un método:
configureSessionCookie(Cookie cookie)
Para nuestro medio ambiente lo mejor era sólo codificarlo, pero se puede hacer más de fantasía lógica:
cookie.setDomain(".xyz.com");
Parece que funciona perfectamente.Sería bueno si esto se puede configurar en tomcat.
