Problemas de sesión HTTP

Utilice la información de resolución de problemas para resolver problemas al crear o utilizar sesiones HTTP (Hypertext Transfer Protocol).

Para ver y actualizar los valores del gestor de sesiones descritos aquí, utilice la consola administrativa. Selecciones el servidor de aplicaciones que alberga la aplicación problemática y, a continuación, en Propiedades adicionales, seleccione Contenedor web y Gestor de sesiones.

[AIX Solaris HP-UX Linux Windows][IBM i]Si el problema no figura descrito aquí o si ninguno de estos pasos soluciona el problema:

Las sesiones HTTP no se crean o se pierden entre solicitudes.

De forma predeterminada, el gestor de sesiones utilizan cookies para almacenar el ID de sesión en el cliente entre solicitudes. A menos que intente evitar que se efectúe un seguimiento de sesiones basado en cookies, asegúrese de que los cookies fluyen entre WebSphere Application Server y el navegador:
  • Asegúrese de que el recuadro de selección Habilitar cookies esté seleccionado en la propiedad Mecanismo de rastreo de sesiones.
  • Asegúrese de que los cookies estén habilitados en el navegador desde el que está realizando la comprobación o en el navegador desde el que los usuarios acceden a la aplicación.
  • Compruebe el dominio de los cookies especificado en el gestor de sesiones (para ver o actualizar los valores de los cookies, en la propiedad Mecanismo de seguimiento de sesiones > Habilitar cookies, pulse Modificar).
    • Por ejemplo, si el dominio de los cookies se establece como ".myCom.com", se debe acceder a los recursos utilizando el nombre de dominio. Ejemplo: http://www.miEmpresa.com/myapp/servlet/sessionservlet.
    • Si se establece la propiedad del dominio, asegúrese de que comienza por un punto (.). Determinadas versiones de Netscape no aceptan cookies si el nombre de dominio no comienza por un punto. Internet Explorer reconoce el dominio con o sin un punto. Por ejemplo, si el nombre de dominio se establece en miempresa.com, modifíquelo por .miempresa.com de modo que tanto Netscape como Internet Explorer reconozcan el cookie.
      Nota: Cuando los servidores están en hosts diferentes, asegúrese de que los cookies de sesión fluyen en todos los servidores configurando un direccionador frontal como, por ejemplo, un servidor web con el plug-in o estableciendo el dominio de los cookies.
  • Compruebe la Vía de acceso de cookie especificada en el gestor de sesiones. Compruebe si el URL que da problemas está jerárquicamente bajo la vía de acceso de cookie especificada. Si no es así, corrija la vía de acceso del cookie.
  • Si se ha establecido la propiedad Antigüedad máxima de cookie, asegúrese de que la fecha y la hora de la máquina (el navegador) del cliente sea la misma que la del servidor, incluido el huso horario. Si la diferencia de hora entre el cliente y el servidor supera la "Antigüedad máxima de cookie", entonces cada acceso será una sesión nueva ya que el cookie caduca después de cada acceso.
  • Si tiene varios módulos web dentro de una aplicación empresarial que rastrean sesiones:
    • Si desea tener distintos valores de sesión entre los módulos web en una aplicación empresarial, asegúrese de que cada módulo web especifica una vía de acceso o un nombre de cookie diferente, o
    • Si los módulos web dentro de una aplicación empresarial utilizan una vía de acceso y un nombre de cookie comunes, asegúrese de que los valores de la sesión HTTP como, por ejemplo, la "antigüedad máxima de cookie", son los iguales para todos los módulos web. De lo contrario, el comportamiento de los cookies es imprevisible y depende de qué aplicación crea la sesión. Tenga en cuenta que esto no afecta a los datos de sesión, que son mantenidos por separado por el módulo web.
  • Compruebe el flujo de cookies entre navegador y servidor:
    1. En el navegador, habilite el "indicador de cookies". Active el servlet y asegúrese de que se solicita el cookie.
    2. [AIX Solaris HP-UX Linux Windows][IBM i]En el servidor, habilite el rastreo del gestor de sesiones. Habilite el rastreo para el componente gestor de sesiones HTTP utilizando la especificación de rastreo "com.ibm.ws.session.*=all=enabled". Una vez habilitado el rastreo, active la sesión utilizando el servlet o JSP y siga las instrucciones para realizar un vuelco y examinar la salida de rastreo.
    3. Acceda al servlet de sesión desde el navegador.
    4. El navegador le solicita el cookie. Tome nota de jsessionid.
    5. Vuelva a cargar el servlet, tome nota del cookie si se envía uno nuevo.
    6. Compruebe el rastreo de sesiones, busque el ID de sesión y efectúe un rastreo de la solicitud por hebra. Verifique que la sesión es estable entre las solicitudes web:
      • Busque getIHttpsession(...) que es el inicio de la solicitud de sesión.
      • Busque releaseSession(..) que es el fin de la solicitud del servlet.
  • Si está utilizando la reescritura de URL en lugar de cookies:
    • Asegúrese de que no haya página HTML estáticas en la vía de acceso de navegación de su aplicación.
    • [AIX Solaris HP-UX Linux Windows][IBM i]Asegúrese de que los servlets y los archivos JSP implementen correctamente la reescritura de URL. Para obtener información detallada y un ejemplo, consulte Opciones de seguimiento de sesiones.
  • Deprecated feature Deprecated feature: El seguimiento de sesiones utilizando el ID de SSL está en desuso en WebSphere Application Server versión 7.0. Puede configurar el seguimiento de sesiones para utilizar cookies o modificar la aplicación para utilizar la reescritura de URL.depfeat
    Si está utilizando SSL como el mecanismo de rastreo de sesiones:
  • Si está en un entorno de clúster (de varios nodos), asegúrese de que tiene habilitada la persistencia de sesiones.

Las sesiones HTTP no son persistentes

Si las sesiones HTTP no son persistentes, es decir, si los datos de la sesión se pierden cuando el servidor de aplicaciones se reinicia o si no se comparten entre el clúster:
  • Compruebe el origen de datos.
  • Compruebe las propiedades de los valores de persistencia del gestor de sesiones:
    • Si intenta beneficiarse de la persistencia de sesiones, compruebe que la persistencia se haya establecido en Base de datos.
    • [AIX Solaris HP-UX Linux Windows][IBM i]La persistencia también se puede establecer en Réplica de memoria a memoria.
    • Si está utilizando la Persistencia basada en base de datos:
      • Compruebe que se haya especificado correctamente el nombre JNDI del origen de datos en el gestor de sesiones.
      • Especifique el ID de usuario y la contraseña correctos cuando acceda a la base de datos.

        Tenga en cuenta que estos valores se han de comprobar con las propiedades de un origen de datos existente en la consola de administración. El gestor de sesiones no crea automáticamente una base de datos de sesiones en su nombre.

      • El origen de datos debe ser no JTA, por ejemplo, no XA.
      • [AIX Solaris HP-UX Linux Windows][IBM i]Consulte en los registros cronológicos de la JVM los mensajes de error de base de datos adecuados.
      • [z/OS]Consulte en el registro los mensajes de error de base de datos adecuados.
      • En DB2, para los tamaños de fila que no sean de 4 K debe asegurarse de que el tamaño de fila especificado coincida con el tamaño de página de DB2. Asegúrese de que el nombre del espacio de tablas se haya especificado correctamente.
    • Si utiliza la persistencia basada en memoria (disponible sólo en un entorno de despliegue de red):

La sesión se comparte entre varios navegadores en la misma máquina cliente.

Este comportamiento depende del navegador. Varía entre proveedores de navegadores y también puede variar según si el navegador se inicia como un nuevo proceso o como un subproceso de una sesión de navegador existente (por ejemplo, pulsando Ctrl+ N en Windows).

La propiedad "Antigüedad máxima de cookie" del gestor de sesiones también afecta a este comportamiento, si los cookies se utilizan como el mecanismo de rastreo de sesiones. Si la antigüedad máxima se establece en algún valor positivo, todas las instancias del navegador comparten los cookies, lo cual persiste en el archivo del cliente durante la antigüedad máxima especificada.

La sesión no se invalida inmediatamente después de que transcurra el intervalo de tiempo excedido de sesión especificado.

La hebra de proceso de invalidación del gestor de sesiones se ejecuta cada x segundos para invalidar cualquier sesión no válida, donde x se determina según el intervalo de tiempo de espera excedido de sesión especificado en las propiedades del gestor de sesiones. Para obtener el valor predeterminado de 30 minutos, el valor aproximado de x es de 300 segundos. En este caso, se puede tardar hasta 5 minutos (300 segundos) en superar el umbral de tiempo de espera excedido de 30 minutos para que se invalide la sesión concreta.

Se están creando sesiones no deseadas mediante JSP (JavaServer Pages)

Según requiere la especificación de JSP (JavaServer Pages), los JSP efectúan de forma predeterminada una solicitud de tipo request.getSession(true), de modo que se crea una sesión si no existe ninguna para el cliente. Para impedir que los JSP creen una sesión nueva, establezca el ámbito de sesión en false en el archivo .jsp utilizando la directiva de página que se indica a continuación:
<% @page session="false" %>
[AIX Solaris HP-UX Linux Windows][IBM i]

Los datos de sesión de un cliente pueden ser vistos por otro cliente

En raras ocasiones, normalmente debido a errores de la aplicación, los datos de sesión de un cliente pueden ser vistos por otro cliente. Esta situación se conoce como un cruce de datos de sesión. Cuando la propiedad personalizada DebugSessionCrossove se establece como true, el código se habilita para detectar y anotar instancias de cruces de datos de sesión. Las comprobaciones se llevan a cabo para verificar que sólo se acceda, o se haga referencia a, la sesión asociada a la solicitud. Los mensajes se registran, si se detectan discrepancias. Estos mensajes proporcionan un punto de partida para depurar este problema. Esta comprobación adicional sólo se realiza cuando se ejecuta en la hebra de asignación gestionada por WebSphere, no en las hebras creadas por el usuario.

Si desea obtener más información sobre cómo establecer esta propiedad, consulte el artículo Propiedades personalizadas del contenedor Web.

No se finaliza la sesión de los usuarios después de que caduca su temporizador de sesión HTTP

Si los usuarios de WebSphere Application Server inician la sesión en una aplicación y se mantienen desocupados durante un período de tiempo mayor al valor de tiempo de espera de sesión HTTP especificado, la información de los usuarios no se invalida y los credenciales de usuario permanecen activos hasta que se produce un tiempo de espera excedido de la señal LTPA.

Después de aplicar PK25740, efectúe los pasos siguientes para desconectar a los usuarios de la aplicación, después de que haya caducado la sesión HTTP.
Atención: La propiedad com.ibm.ws.security.web.logoutOnHTTPSessionExpire sólo se aplica a aplicaciones que utilizan el inicio de sesión de formulario.
  1. En la consola administrativa, pulse Seguridad > Seguridad global.
  2. En propiedades personalizadas, pulse Nuevo.
  3. En el campo Nombre, escriba com.ibm.ws.security.web.logoutOnHTTPSessionExpire.
  4. En el campo Valores, escriba true.
  5. Pulse Aplicar y guarde los cambios de la configuración.
  6. Vuelva a sincronizar y reinicie el servidor.
Reautenticaciones inesperadas: Si establece la propiedad personalizada com.ibm.ws.security.web.logoutOnHTTPSessionExpire en true, es posible que se produzcan reautenticaciones inesperadas cuando trabaje con varias aplicaciones web. De forma predeterminada, cada aplicación web tiene su propia sesión HTTP única, pero el navegador web tiene una cookie de sesión. Para corregir este problema, puede cambiar la configuración de la sesión HTTP asignando a cada aplicación un nombre de cookie de sesión o un valor de vía de acceso único. Como resultado, cada aplicación obtiene su propia cookie de sesión. Opcionalmente, puede configurar varias aplicaciones web con la misma aplicación empresarial para que compartan la misma sesión HTTP. Para obtener más información, consulte el tema Ensamblaje para poder compartir los datos de sesión.

Se pueden producir excepciones durante el tiempo de ejecución al actualizar las aplicaciones donde está habilitada la persistencia de sesiones

Los usuarios que tienen la persistencia de sesiones habilitada y ejecutan actualizaciones de la aplicación durante el tiempo de ejecución pueden experimentar excepciones inesperadas después de que se reinicie la aplicación.

Si se han realizado actualizaciones que cambian los atributos guardados, entonces es posible que todas las sesiones creadas por la aplicación asociada deban invalidarse antes de la actualización de la aplicación si la aplicación no puede manejar estos cambios. En esta situación, todos los objetos de sesión deben eliminarse también del programa de fondo. Consulte la información sobre la invalidación de sesiones HTTP para obtener más información sobre cómo eliminar estas sesiones correctamente.

El soporte de IBM tiene documentos y herramientas que le pueden ahorrar tiempo en la recopilación de la información necesaria para resolver los problemas. Antes de abrir un informe de problema, consulte la página del servicio de soporte:

Icon that indicates the type of topic Reference topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rtrb_httpsessprobs
File name: rtrb_httpsessprobs.html