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.

[AIX Solaris HP-UX Linux Windows][IBM i]Si votre incident n'est pas décrit ici ou qu'aucune de ces procédures ne le résout, procédez comme suit :

Les sessions HTTP ne sont pas créées ou sont perdues entre les demandes

Par défaut, le gestionnaire de sessions utilise des cookies pour stocker les ID de session sur le client entre les demandes. Sauf si vous prévoyez de ne pas effectuer de suivi des sessions à l'aide de cookies, vérifiez comme suit que ces cookies circulent entre WebSphere Application Server et le navigateur :
  • 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 Mécanisme de suivi de session > Propriété Activer les cookies, cliquez sur 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.
  • 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 :
    1. Sur le navigateur, activez "invite du cookie". Accédez au servlet et assurez-vous que le cookie reçoit une invite.
    2. [AIX Solaris HP-UX Linux Windows][IBM i]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.
    3. Accédez au servlet de session à partir du navigateur.
    4. Le navigateur réclame le cookie ; notez le jsessionid.
    5. Rechargez le servlet, notez le cas échéant le nouveau cookie envoyé.
    6. 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.
    • [AIX Solaris HP-UX Linux Windows][IBM i]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.
  • Fonction obsolète 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
    Si vous utilisez SSL comme mécanisme de suivi de session :
  • Dans un environnement de groupe (plusieurs noeuds), vérifiez que la persistance de session est activée.

Sessions HTTP non persistantes

Si vos sessions HTTP ne sont pas persistantes, c'est-à-dire si les données de session sont perdues lorsque le serveur d'applications redémarre ou si elles ne sont pas partagées sur le cluster :
  • 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.
    • [AIX Solaris HP-UX Linux Windows][IBM i]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).
      • [AIX Solaris HP-UX Linux Windows][IBM i]Recherchez dans les journaux JVM les messages d'erreur de base de données appropriés.
      • [z/OS]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) :

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

Comme l'exige la spécification JSP (JavaServer Server Pages), les fichiers JSP exécutent pas défaut une instruction request.getSession(true), de sorte qu'une session et créée lorsqu'il n'en existe aucune pour le client. Pour éviter que les fichiers JSP ne créent une nouvelle session, affectez la valeur false à la portée de la session, dans le fichier .jsp, à l'aide de la directive page :
<% @page session="false" %>
[AIX Solaris HP-UX Linux Windows][IBM i]

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.

Après avoir appliqué le correctif PK25740, effectuez les étapes suivantes pour déconnecter les utilisateurs de l'application après expiration de la session HTTP.
Avertissement : La propriété com.ibm.ws.security.web.logoutOnHTTPSessionExpire s'applique uniquement aux applications qui utilisent la connexion par formulaire.
  1. Dans la console d'administration, sélectionnez Sécurité > Sécurité globale.
  2. Dans Propriétés personnalisées, cliquez sur Nouvelle.
  3. Dans la zone Nom, entrez com.ibm.ws.security.web.logoutOnHTTPSessionExpire.
  4. Dans la zone Valeur, entrez true.
  5. Cliquez sur Appliquer et sauvegarder pour enregistrer les modifications dans votre configuration.
  6. Resynchronisez puis redémarrez le serveur.
Ré-authentifications inattendues : Lorsque vous affectez la valeur "true" à la propriété personnalisée com.ibm.ws.security.web.logoutOnHTTPSessionExpire, des authentifications inattendues peuvent se produire si vous utilisez plusieurs applications Web. Par défaut, chaque application Web possède une session HTTP en propre mais le navigateur Web ne possède qu'un seul cookie de session. Pour corriger ce problème, vous pouvez modifier la configuration des sessions HTTP en affectant à chaque application un cookie de session ou un paramètre de chemin spécifique. Suite à cela, chaque application aura son propre cookie de session. Vous pouvez également configurer plusieurs applications Web avec la même application d'entreprise afin qu'elles partagent toutes la même session HTTP. Pour plus d'informations, voir la rubrique Assemblage permettant le partage des données de session.

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.

Le service de support IBM dispose de documents et d'outils qui peuvent vous aider à collecter plus rapidement les informations dont vous avez besoin pour résoudre votre incident. Avant d'ouvrir un rapport d'incident, consultez la page du service de support :

Icône indiquant le type de rubrique Rubrique de référence



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rtrb_httpsessprobs
Nom du fichier : rtrb_httpsessprobs.html