Incidents de session HTTP
Utilisez les informations d'identification et de résolution des incidents pour les problèmes liés à la création ou à l'utilisation de sessions HTTP (Hypertext Transfer Protocol).
Pour afficher et mettre à jour les paramètre du gestionnaire de sessions présenté ici, utilisez la console d'administration. Sélectionnez le serveur d'applications qui héberge l'application qui pose problème, puis sous Propriétés supplémentaires, sélectionnez Conteneur Web, puis Gestionnaire de sessions.
- Les sessions HTTP ne sont pas créées ou sont perdues entre les demandes
- Sessions HTTP non persistantes
- Session partagée entre plusieurs navigateurs sur la même machine client
- Session non invalidée immédiatement après le délai d'expiration de session fixé
- Sessions non demandées créées par fichiers JavaServer Pages
Des données de session destinées à un client sont consultées par un autre client
- Les utilisateurs ne sont pas déconnectés après l'expiration du délai de la session HTTP
- Des exceptions peuvent survenir durant la phase d'exécution, lors de la mise à jour d'applications pour lesquelles la persistence de session est activée
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
- Pour les procédures de débogage des incidents liés au gestionnaire de sessions, voir Conseils pour l'identification et la résolution des problèmes liés au gestionnaire de sessions HTTP.
Pour plus d'informations sur la configuration du gestionnaire de sessions et les meilleures pratiques d'utilisation, reportez-vous à Présentation des tâches : gestion des sessions HTTP.
- Vérifiez dans le support disponible en ligne (conseils et astuces, notes techniques et correctifs) si votre incident a été identifié et documenté.
- Si vous n'y trouvez aucune information utile, contactez le support IBM.
Les sessions HTTP ne sont pas créées ou sont perdues entre les demandes
- Assurez-vous que la case Activer les cookies est cochée dans la propriété Mécanisme de suivi de session.
- Vérifiez que les cookies sont activés sur le navigateur à partir duquel vous testez ou à partir duquel vos utilisateurs accèdent à l'application.
- Vérifiez le domaine Cookie indiqué dans le gestionnaire de sessions (pour afficher ou
mettre à jour les paramètres des cookies, dans Modifier).
- Par exemple, si le domaine du cookie est défini comme ".myCom.com", les ressources doivent être accédées à l'aide du nom de domaine. Exemple : http://www.myCom.com/myapp/servlet/sessionservlet.
- Si la propriété du domaine est définie, assurez-vous qu'elle commence par un point (.). Certaines
versions de Netscape n'acceptent pas de cookies lorsque le nom de domaine ne commence pas par un point. Internet
Explorer accepte les domaines avec ou sans point. Par exemple, si le nom de domaine est mycom.com,
remplacez le par .mycom.com pour que Netscape comme Internet Explorer accepte le cookie. Remarque : Lorsque les serveurs sont sur des hôtes différents, assurez-vous que les cookies de session passent par tous les serveurs en configurant un routeur frontal, tel qu'un serveur Web, avec le plug-in ou en paramétrant le domaine Cookie.
, cliquez sur - Vérifiez le chemin du cookie indiqué dans le gestionnaire de sessions. Vérifiez si l'URL qui pose problème se trouve sous le chemin du cookie spécifié dans la hiérarchie. Si tel n'est pas le cas, modifiez le chemin du cookie.
- Si la propriété Age maximal du cookie est définie, vérifiez que l'heure et la date de la machine client (navigateur) sont identique à ceux du serveur, y compris le fuseau horaire. Si la différence d'heure entre le client et le serveur est supérieure à la valeur "Age maximal du cookie", chaque accès sera une nouvelle session car le cookie expire une fois cet accès effectué.
- Si vous disposez de plusieurs modules Web dans le cadre d'une application
d'entreprise de suivi de sessions :
- si vous souhaitez avoir différents paramétrages de session aux sein des modules Web d'une application d'entreprise, vérifiez que chaque module Web désigne un chemin ou un nom de cookie différent ;
- si les modules Web d'une application d'entreprise utilisent le même nom et chemin de cookie, vérifiez que les paramètres de session HTTP, tels que "Age maximal du cookie", sont identiques pour tous les modules Web. Dans le cas contraire, le comportement du cookie risque d'être imprévisible et dépendra de l'application qui crée la session. Notez que cela n'affecte pas les données de session, que le module Web gère séparément.
- Vérifiez la circulation du cookie entre le navigateur et le serveur :
- Sur le navigateur, activez "invite du cookie". Accédez au servlet et assurez-vous que le cookie reçoit une invite.
Sur le serveur, activez la trace du gestionnaire de sessions. Pour activer le traçage pour le composant Gestionnaire de sessions HTTP, utilisez la spécification de trace "com.ibm.ws.session.*=all=enabled". Une fois le traçage activé, testez votre session à l'aide d'un servlet ou d'un fichier JSP, puis conformez-vous aux instructions de vidage et de consultation de la sortie de trace.
- Accédez au servlet de session à partir du navigateur.
- Le navigateur réclame le cookie ; notez le jsessionid.
- Rechargez le servlet, notez le cas échéant le nouveau cookie envoyé.
- Vérifiez la trace de session et recherchez l'ID de session, puis tracez la
demande par l'unité d'exécution. Vérifiez comme suit que la session est stable pour toutes les demandes Web :
- Recherchez getIHttpsession(...) qui marque le début de la demande de session.
- Recherchez releaseSession(..) qui marque la fin de la demande de servlet.
- Si vous utilisez la réécriture d'URL ou lieu de cookies :
- Vérifiez qu'il n'y a pas de pages HTML statiques dans le chemin de navigation de votre application.
Vérifiez que vos servlets et fichiers JSP mettent correctement en oeuvre la réécriture d'URL. Pour plus d'informations et un exemple, reportez-vous à Options de suivi des sessions.
- Si vous utilisez SSL comme mécanisme de suivi de session :
Fonction obsolète: Le suivi de session utilisant l'ID SSL est obsolète dans WebSphere Application Server version 7.0. Vous pouvez configurer le suivi de session en vue de l'utilisation de cookies ou modifier l'application en vue de l'utilisation de la réécriture d'URL.depfeat
- Vérifiez que SSL est activé sur votre serveur IBM HTTP Server ou iPlanet HTTP.
Reportez-vous à la rubrique Options de suivi des sessions.
- Dans un environnement de groupe (plusieurs noeuds), vérifiez que la persistance de session est activée.
Sessions HTTP non persistantes
- Vérifiez la source de données.
- Vérifiez les propriétés des paramètres de persistance du gestionnaire de sessions :
- Si vous prévoyez de tirer profit de la persistance de session, vérifiez que la valeur de la persistance est Base de données.
La valeur de la persistance peut également être Réplication de mémoire à mémoire.
- Si vous utilisez la Persistance basée sur base de données :
- Vérifiez que le nom JNDI de la source de données est correctement indiqué dans le gestionnaire de sessions.
- Entrez l'ID utilisateur et le mot de passe requis pour accéder à la base
de données.
Notez que ces paramètres doivent être comparés aux propriétés d'une source de données existante dans la console d'administration. Le gestionnaire de sessions ne crée pas automatiquement pour vous une base données de session.
- La source de données ne doit pas être de type JTA (non compatible XA).
Recherchez dans les journaux JVM les messages d'erreur de base de données appropriés.
Recherchez dans les journaux les messages d'erreur de base de données appropriés.
- Avec DB2, pour les tailles de ligne de plus de 4k vérifiez que la taille indiquée correspond à la taille de page DB2. Vérifiez que le nom d'espace table est correctement indiqué.
- Si vous utilisez une persistance à base de mémoire (disponible uniquement dans un environnement de déploiement réseau) :
- Révisez Réplication mémoire-à-mémoire.
- Reportez-vous à Propriétés des domaines de réplication internes de votre gestionnaire de sessions.
Session partagée entre plusieurs navigateurs sur la même machine client
Ce comportement dépend du navigateur. Il varie suivant les fournisseurs de navigateur et selon que le navigateur est lancé en tant que nouveau processus ou en tant que sous-processus d'une session de navigateur existante (par exemple en appuyant sur Ctl-N sous Windows).
La propriété Age maximal du cookie du gestionnaire de sessions affecte également ce comportement, si les cookies sont utilisés comme mécanisme de suivi de session. Si l'âge maximal est une valeur positive, toutes les instances de navigateur se partagent les cookies, qui sont conservés sur fichier sur le client pour la durée indiquée.
Session non invalidée immédiatement après le délai d'expiration de session fixé
L'unité d'exécution du processus d'invalidation du gestionnaire de sessions s'exécute toutes les x secondes pour annuler toutes les sessions incorrectes, x étant basé sur le délai d'expiration de session indiqué dans les propriétés du gestionnaire de sessions. Pour une valeur par défaut de 30 minutes , x est arrondi à 300 secondes Dans ce cas, cela peut prendre jusqu'à 5 minutes (300 secondes) avant que le seuil du délai d'expiration de 30 minutes d'une session particulière soit invalidé.
Sessions non demandées créées par fichiers JavaServer Pages
<% @page session="false" %>
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Des données de session destinées à un client sont consultées par un autre client
Dans de rares situations, généralement liées à des erreurs d'application, des données de session destinées à un client peuvent être consultées par un autre client. On parle alors de croisement des données de session. Lorsque la propriété personnalisée DebugSessionCrossover a la valeur true, un code est activé pour détecter et consigner des instances de croisement des données de session. Des vérifications sont effectuées en vue de contrôler que seule la session associée à la requête est accédée ou utilisée. En cas d'incohérences, des messages sont consignées. Ces messages servent de point de départ pour la résolution de l'incident. Cette vérification supplémentaire est uniquement effectuée sur une unité d'exécution de distribution gérée par WebSphere et non sur les unités d'exécution créées par l'utilisateur.
Pour des informations supplémentaires sur la définition de cette propriété, voir Propriétés personnalisées du conteneur Web.
Les utilisateurs ne sont pas déconnectés après l'expiration du délai de la session HTTP
Si les utilisateurs de WebSphere Application Server se connectent à une application et restent inactifs pour une durée supérieure à la valeur du délai d'attente de session HTTP, les informations utilisateur ne sont pas invalidées et les données d'identification de l'utilisateur restent actives jusqu'à expiration du délai d'attente de jeton LTPA.
- Dans la console d'administration, sélectionnez Sécurité > Sécurité globale.
- Dans Propriétés personnalisées, cliquez sur Nouvelle.
- Dans la zone Nom, entrez com.ibm.ws.security.web.logoutOnHTTPSessionExpire.
- Dans la zone Valeur, entrez true.
- Cliquez sur Appliquer et sauvegarder pour enregistrer les modifications dans votre configuration.
- Resynchronisez puis redémarrez le serveur.
Des exceptions peuvent survenir durant la phase d'exécution, lors de la mise à jour d'applications pour lesquelles la persistance de session est activée
Les utilisateurs pour lesquels la persistance de session est activée et qui exécutent des mises à jour d'applications lors de l'exécution peuvent rencontrer des exceptions inattendues après le redémarrage de l'application.
Si des mises à jour qui modifient les attributs enregistrés ont eu lieu, toutes les sessions créées par l'application associée risquent d'être invalidées avant la mise à jour de l'application si cette dernière ne peut pas traiter ces modifications. Dans ce cas, tous les objets de session doivent également être supprimés de l'arrière-plan. Consultez les informations d'invalidation de session HTTP pour apprendre à supprimer correctement ces sessions.