Configurer le suivi de session

Vous pouvez configurer la génération de rapports de suivi de session pour l'agent de navigateur APM.

Par défaut, l'agent de navigateur APM crée des cookies de suivi de session qui assurent le suivi de l'activité d'un navigateur unique jusqu'au redémarrage du navigateur. Cela peut s'écarter de ce que le serveur d'applications utilise. Plus précisément, il peut suivre les données avant et après la connexion et la déconnexion. L'élément sessionId ne correspond pas à l'élément sessionId qui peut être présent dans les fichiers journaux. Certaines approches peuvent aider à aligner le serveur sessionId sur les rapports du navigateur. Lorsque l'objectif est de s'assurer que les sauts de session sont appliqués uniquement sur les pages de connexion/déconnexion, ce qui peut être fait en utilisant uniquement ce scénario.

Ajouter des sauts de session

Un appel de document.ApmSdk.resetSession() dans le code javascript garantit que la session existante est fermée et que la nouvelle session est démarrée. Cette opération permet d'isoler les interactions avant l'appel de cette fonction des interactions. L'ajout de cette option à la page de connexion ou à la page de destination de la déconnexion (et du délai d'expiration) peut aider à garantir que les pauses de session dans les rapports de l'agent du navigateur correspondent aux pauses de l'expérience client.

Exemple de code javascript qui déclenche un saut de session :

<script language="text/javascript">
   if (document.ApmSdk) {       
       document.ApmSdk.resetSession();
   }
</script>

Aligner le navigateur SessionId avec le serveur SessionId

Une autre approche pour aligner la session de serveur sur la session de navigateur consiste à aligner le paramètre Id utilisé pour identifier une session. Certaines méthodes sont décrites ci-dessous.

L'exposition brute sessionId peut affaiblir la CSRF

L'exposition de sessionId à javascript et à APM pourrait affaiblir les protections CSRF (Cross-Site Request Forgery).

L'avantage d'un sessionId identique (dans les journaux de serveur et APM) doit être comparé à l'impact sur les mesures de sécurité. Un hachage à sens unique peut rendre l'unicité identique sans compromettre les protections. Cela nécessite la même fonction de hachage dans les cas où les journaux du serveur et les journaux de l'agent du navigateur sont liés l'un à l'autre.

Les exemples ci-dessous utilisent la valeur sessionId brute, et non une fonction de hachage particulière :

Obtention de l'application sessionId vers l'agent de navigateur APM

Il existe plusieurs façons d'obtenir sessionId du serveur d'applications vers l'agent de navigateur.
  • Initialiser apmrum.sid à partir du code d'application

    Cela nécessite la capacité du code d'application à exposer le fichier sessionId actif dans le code HTML résultant. Le code d'application doit produire du code html/javascript qui initialise la propriété apmrum.sid avec sessionId.

    Le code d'application s'ajoute au corps du code HTML comme suit :

    <script language="text/javascript">
       window.apmrum = window.apmrum || {};
       window.apmrum.sid = '<?PHP echo getSessionId(); ?>';
    </script>
  • Afficher le cookie sessionId et demander à l'agent de navigateur de l'utiliser

    Si l'application sessionId n'est pas protégée par l'indicateur HttpOnly, l'agent de navigateur peut être configuré pour lire et utiliser la valeur du cookie sessionId.

    Examinez le code HTML ci-dessous à l'aide du nom de cookie du serveur d'applications, dans ce cas 'JSessionId' :

    <script language="text/javascript">
       window.apmrum = window.apmrum || {};
       window.apmrum.tracking_cookie = 'JSessionId';
    </script>