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.

[AIX Solaris HP-UX Linux Windows][IBM i]Se seu problema não estiver descrito aqui, ou se nenhuma destas etapas corrigir o problema:

As sessões HTTP não estão sendo criadas ou estão perdidas entre os pedidos

Por padrão, o gerenciador de sessão utiliza cookies para armazenar o ID da sessão no cliente entre os pedidos. A não ser que você pretenda impedir o monitoramento de sessões baseadas em cookie, assegure-se de que os cookies estejam fluindo entre o WebSphere Application Server e o navegador:
  • 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 Mecanismo de rastreio de sessões > ativar propriedade de cookies, clique em 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.
  • 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:
    1. No navegador, ative "prompt de cookies". Consulte o servlet e certifique-se de que o cookie esteja sendo solicitado.
    2. [AIX Solaris HP-UX Linux Windows][IBM i]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.
    3. Acesse o servlet da sessão a partir do navegador.
    4. O navegador solicita o cookie; anote o jsessionid.
    5. Carregue o servlet, anote o cookie se um novo cookie for enviado.
    6. 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.
    • [AIX Solaris HP-UX Linux Windows][IBM i]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.
  • Recurso Reprovado 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
    Se você estiver utilizando SSL como o mecanismo de rastreio da 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

Se suas sessões HTTP não forem persistentes, ou seja, os dados da sessão são perdidos quando o servidor de aplicativos é novamente iniciado ou não são compartilhados no cluster:
  • 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.
    • [AIX Solaris HP-UX Linux Windows][IBM i]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.
      • [AIX Solaris HP-UX Linux Windows][IBM i]Verifique Registros de JVM para obter as mensagens de erro do banco de dados apropriadas.
      • [z/OS]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):

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)

Conforme determinado pela especificação das páginas JSP (JavaServer Pages), tais páginas executam por padrão um request.getSession(true), de modo que uma sessão seja criada caso não haja nenhuma sessão para o cliente. Para impedir que as páginas JSP criem uma nova sessão, configure o escopo da sessão como false no arquivo .jsp, utilizando a seguinte diretiva de página:
<% @page session="false" %>
[AIX Solaris HP-UX Linux Windows][IBM i]

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.

Após aplicar o PK25740, conclua as seguintes etapas para efetuar logout dos usuários do aplicativo após a expiração da sessão HTTP.
Atenção: A propriedade com.ibm.ws.security.web.logoutOnHTTPSessionExpire se aplica apenas aos aplicativos que usam o login de formulário.
  1. No console administrativo, clique em Segurança > Segurança Global.
  2. Em Propriedades Customizadas, clique em Novo.
  3. No campo Nome, insira com.ibm.ws.security.web.logoutOnHTTPSessionExpire.
  4. No campo Valor, digite true.
  5. Clique em Aplicar e Salvar para salvar as alterações na configuração.
  6. Ressincronize e reinicie o servidor.
Reautenticações Inesperadas: Quando você configura a propriedade customizada com.ibm.ws.security.web.logoutOnHTTPSessionExpire como true, reautenticações inesperadas podem ocorrer quando você está trabalhando com vários aplicativos da Web. Pelo padrão, cada aplicativo da Web possui sua própria sessão HTTP exclusiva, mas o navegador da Web possui um cookie de sessão. Para resolver esse problema, você pode alterar a configuração de sessão HTTP ao fornecer a cada aplicativo uma configuração exclusiva de nome ou de caminho de cookie de sessão. Como resultado, cada aplicativo obtém seu próprio cookie de sessão. Alternativamente, você pode configurar diversos aplicativos da Web com o mesmo enterprise application para compartilhar a mesma sessão HTTP. Para obter mais informações, consulte o tópico Montagem para que os dados de sessão possam ser compartilhados.

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.

O Suporte IBM possui documentos e ferramentas que podem economizar tempo reunindo informações necessárias para resolver problemas. Antes de abrir um relatório de problemas, consulte a página de Suporte.

Ícone que indica o tipo de tópico Tópico de Referência



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rtrb_httpsessprobs
Nome do arquivo: rtrb_httpsessprobs.html