Problemas de Sessão HTTP
Use informações de resolução de problemas para problemas ao criar ou usar sessões do Protocolo de Transporte de Hipertexto (HTTP).
Para visualizar e atualizar as configurações do gerenciador de sessão discutidas aqui, utilize o console administrativo. Selecione o servidor de aplicativos que hospeda o aplicativo do programa, então sob Propriedades adicionais, selecione Contênier de web, em seguida Gerenciador de sessões.
- As sessões HTTP não estão sendo criadas ou estão perdidas entre os pedidos
- Sessões HTTP não são persistentes
- A sessão é compartilhada por vários navegadores na mesma máquina
- A sessão não está sendo invalidada imediatamente depois do intervalo de tempo limite da sessão especificado
- Sessões Indesejadas Estão Sendo Criadas pelas Páginas JSP (JavaServer Pages)
Dados de Sessão Direcionados a um Cliente São Vistos por Outro Cliente
- Usuários Não Efetuam Logout Depois do Cronômetro da Sessão HTTP Expirar
- Poderão ocorrer exceções durante o tempo de execução quando forem atualizados aplicativos que tenham a persistência de sessão ativada
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
- Examine Dicas de Resolução de Problemas do Gerenciador de Sessão do HTTP para conhecer as etapas gerais de depuração dos problemas relacionados ao gerenciador da sessão.
Reveja Visão Geral da Tarefa: Gerenciando Sessões HTTP para obter informações sobre como configurar o gerenciador de sessão e as boas práticas para utilizá-lo.
- Verifique se o problema foi identificado e documentado, consultando o suporte on-line disponível (dicas e sugestões, notas técnicas e correções).
- Se você não localizar seu problema listado aí, entre em contato com o IBM Support.
As sessões HTTP não estão sendo criadas ou estão perdidas entre os pedidos
- Certifique-se de que a caixa de seleção Ativar cookies está selecionada sob a propriedade Mecanismo de Rastreio de Sessão.
- Certifique-se de que os cookies estejam ativados no navegador a partir do qual você está testando ou a partir do qual os usuários estão acessando o aplicativo.
- Verifique o domínio Cookie especificado no Gerenciador de Sessões (para visualizar ou atualizar as configurações de cookie, no Modificar).
- Por exemplo, se o domínio de cookies estiver configurado com ".myCom.com", os recursos devem ser acessados usando o nome de domínio. Exemplo: http://www.myCom.com/myapp/servlet/sessionservlet.
- Se a propriedade do domínio for definida, certifique de que seja iniciada por um ponto (.). Determinadas versões do Netscape não aceitam cookies se o nome do domínio não começar com um ponto. O Internet Explorer aceita o domínio com ou sem um ponto. Por exemplo,
se o nome do domínio for definido para mycom.com, altere-o para .mycom.com para que o Netscape e o Internet Explorer aceitem o cookie. Nota: Quando os servidores estão em hosts diferentes, assegure-se de que os cookies de sessão fluam para todos os servidores configurando um roteador de front-end como um servidor da Web com o plug-in ou configurando o domínio Cookie.
, clique em - Verifique o caminho Cookie especificado no Gerenciador de Sessões. Verifique se a URL do problema está hierarquicamente abaixo do caminho do Cookie especificado. Se não estiver, corrija o caminho do Cookie.
- Se a propriedade de Idade máxima de cookie estiver configurada, certifique-se de que a data e hora da máquina do cliente (navegador) são as mesmas que as do servidor, incluindo o fuso horário. Se a diferença do horário do cliente e do servidor for maior que a "Idade máxima do cookie", então todo acesso seria uma nova sessão, uma vez que o cookie expira depois do acesso.
- Se você tiver múltiplos módulos da Web dentro de um aplicativo corporativo que controle sessões:
- Se você quiser ter diferentes configurações de sessão entre módulos da Web em um aplicativo corporativo, assegure-se de que cada módulo da Web especifique um nome de cookie ou caminho diferente, ou
- Se os módulos da web em um aplicativo corporativo usar nome e caminho do cookie comuns, certifique-se de que as configurações da sessão HTTP, como "Idade máxima do cookie", são as mespas para todos os módulos da web. Caso contrário, o comportamento do cookie será imprevisível e dependerá de qual aplicativo cria a sessão. Observe que isso não afeta dados da sessão, que são mantidos separadamente pelo módulo da Web.
- Verifique o fluxo do cookie entre o navegador e o servidor:
- No navegador, ative "prompt de cookies". Consulte o servlet e certifique-se de que o cookie esteja sendo solicitado.
No servidor, ative o rastreio do SessionManager. Ative o rastreio para o componente do gerenciador de sessões HTTP usando a especificação de rastreio "com.ibm.ws.session.*=all=enabled". Depois que o rastreio for ativado, teste sua sessão utilizando servlet ou JSP e siga as instruções para fazer dump e procurar a saída do rastreio.
- Acesse o servlet da sessão a partir do navegador.
- O navegador solicita o cookie; anote o jsessionid.
- Carregue o servlet, anote o cookie se um novo cookie for enviado.
- Verifique o rastreio da sessão e procure o ID da sessão e rastreie o pedido através do encadeamento. Verifique se a sessão está estável entre as solicitações da Web:
- Procure por getIHttpsession(...) que é o início do pedido da sessão.
- Procure por releaseSession(..) que é o fim do pedido do servlet.
- Se você estiver utilizando a regravação da URL em vez de cookies:
- Certifique-se de que não haja nenhuma página HTML estática no caminho de navegação do aplicativo.
Verifique se os seus servlets e arquivos JSP estejam implementando a regravação da URL corretamente. Para obter mais detalhes e um exemplo, consulte Opções de Acompanhamento de Sessão.
- Se você estiver utilizando SSL como o mecanismo de rastreio da sessão:
Recurso Reprovado: O rastreamento de sessão que utiliza o ID de SSL foi reprovado no WebSphere Application Server versão 7.0. Você pode configurar o rastreio de sessão para utilizar cookies ou modificar o aplicativo para utilizar regravação de URL.depfeat
- Assegure-se de que o SSL esteja ativado no IBM HTTP Server ou no iPlanet HTTP Server.
Reveja a seção Opções de Acompanhamento de Sessão.
- Se você estiver em um ambiente em cluster (vários nós), certifique-se de que persistência de sessão esteja ativado.
Sessões HTTP não são persistentes
- Verifique a origem de dados.
- Verifique as propriedades das configurações de persistência do
gerenciador da sessão:
- Caso pretenda tirar proveito da persistência da sessão, verifique se a Persistência está configurada como Banco de Dados.
A persistência também pode ser configurada como Replicação Memória a Memória.
- Se estiver usando Persistência baseada em banco de dados:
- Verifique se o nome da JNDI da origem de dados foi especificado corretamente no SessionManager.
- Especifique ID de usuário e senha corretos para acessar o banco de dados.
Observe se tais configurações foram verificadas em relação às propriedades de uma origem de dados existente no console administrativo. O gerenciador de sessão não cria automaticamente um banco de dados de sessão.
- A origem de dados deve ser não-JTA, por exemplo, não ativado para XA.
Verifique Registros de JVM para obter as mensagens de erro do banco de dados apropriadas.
Procure mensagens de erro de banco de dados apropriadas nos registros.
- Com o DB2, para tamanhos de linha diferentes de 4 k, certifique-se de que o tamanho de linha especificado corresponda ao tamanho da página do DB2. Certifique-se de que o nome do espaço de tabelas seja especificado corretamente.
- Se estiver utilizando persistência baseada em
memória (disponível apenas num ambiente de implementação de rede):
- Reveja a seção Replicação de memória a memória.
- Revise as propriedades dos Domínios de Replicação Internos de seu gerenciador de sessões.
A sessão é compartilhada por vários navegadores na mesma máquina
Esse comportamento depende do navegador. Ele varia entre os fornecedores de navegadores e também pode mudar de acordo com a ativação do navegador como um novo processo ou como um subprocesso de uma sessão de navegador existente (por exemplo, pressionando Ctl-N no Windows).
A propriedade Validade Máxima do Cookie do gerenciador de sessão também afeta esse comportamento, caso os cookies sejam utilizados como mecanismo de rastreio de sessão. Se a duração máxima for definida para algum valor positivo, todas as instâncias do navegador compartilham os cookies, que passam por persistência para arquivo no cliente pelo tempo de duração máxima especificado.
A sessão não está sendo invalidada imediatamente depois do intervalo de tempo limite da sessão especificado
O encadeamento do processo de invalidação SessionManager é executado a cada x segundos para invalidar quaisquer sessões não válidas, sendo que x é determinado com base no intervalo de tempo limite da sessão especificado nas propriedades do gerenciador de sessão. Para o valor padrão de 30 minutos, x está por volta de 300 segundos. Nesse caso, pode levar até 5 minutos (300 segundos) além do limite do tempo limite de 30 minutos para que uma determinada sessão seja invalidada.
Sessões Indesejadas Estão Sendo Criadas pelas Páginas JSP (JavaServer Pages)
<% @page session="false" %>
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Dados de Sessão Direcionados a um Cliente São Vistos por Outro Cliente
Em situações raras, geralmente devido a erros de aplicativos, os dados de sessão direcionados a um cliente podem ser vistos por outro cliente. Essa situação é chamada de cruzamento de dados de sessão. Quando a propriedade customizada DebugSessionCrossover estiver configurada para true, o código é ativado para detectar e registrar instâncias de cruzamento de dados da sessão. As verificações são executadas para assegurar que somente a sessão associada ao pedido seja acessada ou referida. As mensagens serão registradas se forem detectadas discrepâncias. Essas mensagens fornecem um ponto de partida para depurar esse problema. Essa verificação adicional é executada somente ao executar no encadeamento de dispatch gerenciado pelo WebSphere, não em qualquer encadeamento criado pelo usuário.
Para obter informações adicionais sobre como definir essa propriedade, consulte o artigo Propriedades Customizadas do Contêiner de Web.
Usuários Não Efetuam Logout Depois do Cronômetro da Sessão HTTP Expirar
Se usuários do WebSphere Application Server efetuarem logon em um aplicativo e ficarem inativos durante um tempo superior ao valor de tempo limite de sessão HTTP especificado, as informações do usuário não serão invalidadas e as credenciais do usuário permanecerão ativas até que ocorra o tempo limite do token LTPA.
- No console administrativo, clique em Segurança > Segurança Global.
- Em Propriedades Customizadas, clique em Novo.
- No campo Nome, insira com.ibm.ws.security.web.logoutOnHTTPSessionExpire.
- No campo Valor, digite true.
- Clique em Aplicar e Salvar para salvar as alterações na configuração.
- Ressincronize e reinicie o servidor.
Exceções Podem Ocorrer Durante o Tempo de Execução ao Atualizar Aplicativos Nos Quais a Persistência de Sessão Está Ativada
Os usuários que possuem persistência de sessão ativada e executam atualizações de aplicativos durante o tempo de execução podem presenciar exceções inesperadas depois que o aplicativo for reiniciado.
Se tiverem sido feitas atualizações que alteram os atributos salvos, todas as sessões criadas pelo aplicativo associado talvez precisem ser invalidadas antes da atualização do aplicativo se o aplicativo não puder lidar com essas mudanças. Nesta situação, todos os objetos de sessão também devem ser removidos do backend. Consulte as informações de invalidação da sessão HTTP para saber mais sobre como remover estas sessões adequadamente.