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.
- Las sesiones HTTP no se crean o se pierden entre solicitudes.
- Las sesiones HTTP no son persistentes
- La sesión se comparte entre varios navegadores en la misma máquina cliente.
- La sesión no se invalida inmediatamente después de que transcurra el intervalo de tiempo excedido de sesión especificado.
- Se están creando sesiones no deseadas mediante JSP (JavaServer Pages)
Los datos de sesión de un cliente pueden ser vistos por otro cliente
- No se finaliza la sesión de los usuarios después de que caduca su temporizador de sesión HTTP
- Se pueden producir excepciones durante el tiempo de ejecución al actualizar aplicaciones donde está habilitada la persistencia de sesiones
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
- Revise el tema Sugerencias para la resolución de problemas del gestor de sesiones HTTP para obtener los pasos generales para la depuración de problemas relacionados con el gestor de sesiones.
Revise el tema Visión general de tareas: gestión de sesiones HTTP para obtener información acerca de cómo configurar el gestor de sesiones y los métodos recomendados para utilizarlo.
- Compruebe si el problema se ha identificado y está documentado consultando el soporte en línea disponible (ideas y sugerencias, notas técnicas y arreglos).
- Si no encuentra su problema listado, póngase en contacto con el equipo de soporte de IBM.
Las sesiones HTTP no se crean o se pierden entre solicitudes.
- 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 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.
, pulse - 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:
- En el navegador, habilite el "indicador de cookies". Active el servlet y asegúrese de que se solicita el cookie.
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.
- Acceda al servlet de sesión desde el navegador.
- El navegador le solicita el cookie. Tome nota de jsessionid.
- Vuelva a cargar el servlet, tome nota del cookie si se envía uno nuevo.
- 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.
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.
- Si está utilizando SSL como el mecanismo de rastreo de sesiones:
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
- Asegúrese de que ha habilitado SSL en IBM HTTP Server o iPlanet HTTP.
Revise Opciones de seguimiento 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
- 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.
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.
Consulte en los registros cronológicos de la JVM los mensajes de error de base de datos adecuados.
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):
- Revise Réplica de memoria a memoria
- Revise las propiedades de los dominios de réplica internos de su gestor de sesiones.
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)
<% @page session="false" %>
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
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.
- En la consola administrativa, pulse Seguridad > Seguridad global.
- En propiedades personalizadas, pulse Nuevo.
- En el campo Nombre, escriba com.ibm.ws.security.web.logoutOnHTTPSessionExpire.
- En el campo Valores, escriba true.
- Pulse Aplicar y guarde los cambios de la configuración.
- Vuelva a sincronizar y reinicie el servidor.
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.