A melhor maneira para permitir cookies de sessão subdomínio usando Tomcat

Question

Por tomcat padrão criará um cookie de sessão para o domínio atual.

Se você estiver em www.example.com, o cookie será criado para www.example.com (só irá funcionar em www.example.com). Enquanto que para example.com será criado para .example.com (comportamento desejado, irá funcionar em qualquer subdomínio de example.com, bem como example.com si).

Eu vi algumas válvulas do Tomcat que parecem interceptar a criação de cookies de sessão e criar um cookie de substituição com o domínio .example.com correta, no entanto nenhum deles parece funcionar perfeitamente e todos eles parecem deixar o existente cookie e apenas criar um novo. Isto significa que dois biscoitos JSESSIONID estão sendo enviados com cada solicitação.

Eu queria saber se alguém tem uma solução definitiva para este problema.

Answer 1

Esta é, aparentemente apoiado através de uma configuração no 6.0.27 em diante:

A configuração é feita pela edição META-INF / context.xml

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

Answer 2

Eu já passamos por tudo isso procurando uma solução simples. Comecei a olhar para ele a partir da perspectiva tomcat em primeiro lugar.

Tomcat não dá acesso directo à configuração do cookie de domínio para a sessão, e eu definitivamente não queria tomcat patch personalizado para corrigir esse problema, como mostrado em alguns outros lugares.

Válvulas em tomcat também parece ser uma solução do problema devido às limitações sobre como acessar os cabeçalhos e os cookies construídos na especificação Servlet. Eles também falhar completamente se a resposta http está comprometida antes que ele obtém passado para sua válvula.

Uma vez que nós procuração nossos pedidos através Apache, Eu, então, mudou-se para como usar o Apache para corrigir o problema em seu lugar.

Eu tentei primeiro a directiva mod_proxy ProxyPassReverseCookieDomain, mas ele não funciona para os cookies JSESSIONID porque tomcat não definir o atributo de domínio e ProxyPassReverseCookieDomain não pode trabalhar sem algum tipo de domínio fazer parte do cookie.

Eu também veio através de um hack usando ProxyPassReverseCookiePath onde foram reescrever o caminho para adicionar um atributo de domínio para o cookie, mas dessa forma feltro para confuso para um local de produção.

Eu finalmente tenho que trabalhar por reescrever os cabeçalhos de resposta utilizando o mod_headers módulo no apache como mencionado por Dave acima.

Eu adicionei a seguinte linha dentro da definição 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"

O acima devem ser todos uma única linha na configuração. Ele irá substituir qualquer atributo de domínio biscoitos JSESSIONID com ".example.com". Se um cookie JSESSIONID não contém um atributo de domínio, em seguida, o padrão irá adicionar uma com um valor de ".example.com". Como um bônus, esta solução não sofrem com o duplo biscoitos JSESSION problema das válvulas.

O padrão deve funcionar com vários cookies no cabeçalho Set-Cookie sem afetar os outros cookies no cabeçalho. Também deve ser modificável para trabalhar com outros cookies alterando JSESSIONID na primeira parte do padrão ao que nunca bolinho nome que você deseja.

Eu não sou usuário reg-ex poder, por isso tenho certeza que estou há um par de otimizações que poderiam ser feitas para o padrão, mas parece estar a trabalhar para nós até agora.

Vou atualizar este post se eu encontrar quaisquer erros com o padrão. Esperemos que isto irá parar um pouco de você de ter que passar pelo último par de dias de frustrações como eu fiz.

Answer 3

Eu executar para esse em US $ dayjob. No meu caso eu queria implementar SSL signon, em seguida, redirecionar para uma página não SSL. O problema central no tomcat é o método (de memória) SessionManager.configureSessionCookie que codifica todas as variáveis ??duro você gostaria de ter acesso.

Eu vim com algumas ideias, incluindo um corte particularmente notório usando mod_headers em apache reescrever o cookie baseado na substituição de regex.

A forma definative para resolver este seria submeter um patch para os desenvolvedores do tomcat que adiciona parâmetros configuráveis ??para a classe SessionManager.

Answer 4

Como uma sessão (e sua Id) é basicamente considerada de valor apenas para a aplicação issueing, você pode sim olhar para definir um cookie adicional. Ter um olhar para Tomcats SingleSignOnValve, proporcionando extra-Cookie JSESSIONIDSSO (note a ... SSO) para o caminho do servidor "/" em vez de "/ applicationName" (como biscoitos JSESSIONID são geralmente fixados).

Com essa válvula você pode implementar qualquer comunicação entre você precisa, a fim de sincronizar qualquer estado entre diferentes servidores, hosts virtuais ou webapps em qualquer número de tomcats / webservers / whatever.

Outra razão pela qual você não pode usar tomcats cookie de sessão para seus próprios fins é que vários webapps no mesmo host têm diferentes ids de sessão. Por exemplo. existem diferentes cookies para "/ WebApp1" e "/ webapp2". Se você fornecer "/ WebApp1" 's cookie para '/ webapp2', isso não iria encontrar a sessão que referenciada, invalidar a sessão + cookie e definir o seu próprio novo. Você teria que reescrever tudo de sessão tomcats manipulação para aceitar valores de ID de sessão externo (má idéia securitywise) ou para compartilhar um determinado estado entre as aplicações.

A manipulação de sessões deve ser considerada a recipientes (tomcats) negócio. Qualquer outra coisa que você precisa, você deve adicionar sem interferir com o que o recipiente acredita é necessário fazer.

Answer 5

As técnicas de válvulas parecem não ser 100% perfeito. Se você se atreve a modificar Tomcat-se:

catalina.jar contém a seguinte classe: org.apache.catalina.connector.Request

A solicitação tem um método:

configureSessionCookie(Cookie cookie)

Para nosso ambiente era melhor apenas codificá-lo, mas você poderia fazer mais lógica fantasia:

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

Parece funcionar perfeitamente. Seria bom se isso foi configurável no tomcat.