Configurar seguimiento de sesión

Puede configurar informes de seguimiento de sesión para el agente de explorador de APM.

Por defecto, el agente de explorador de APM crea cookies de seguimiento de sesión que realizan un seguimiento de la actividad de un explorador único hasta que se reinicia el explorador. Esto podría desviarse de lo que utiliza el servidor de aplicaciones. Más específicamente, podría realizar un seguimiento de los datos antes y después del inicio de sesión y el cierre de sesión. sessionId no coincide con sessionId que puede estar presente en los archivos log. Hay algunos enfoques que pueden ayudar a alinear el servidor sessionId con los informes del explorador. Cuando el objetivo es asegurarse de que solo se aplican saltos de sesión en las páginas de conexión/cierre de sesión, que se pueden realizar instrumentando solo este escenario.

Agregar saltos de sesión

Una llamada a document.ApmSdk.resetSession() en código javascript garantizará que la sesión existente esté cerrada y que se inicie la nueva sesión. Al hacer esto, aislará las interacciones antes de que se llame a esta función de las interacciones después de ella. Agregar esto, tanto a la página de conexión como a la página de llegada de desconexión (y timeout), puede ayudar a garantizar que los saltos de sesión en los informes del agente del explorador coincidan con los saltos de las experiencias del cliente.

Código javascript de ejemplo que dispara un salto de sesión:

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

Alinee el explorador SessionId con el servidor SessionId

Un enfoque alternativo para alinear la sesión del servidor con la sesión del explorador es alinear Id que se utiliza para identificar una sesión. A continuación se describen algunas formas de hacerlo.

La exposición bruta sessionId podría debilitar CSRF

La exposición de sessionId a javascript y APM podría debilitar las protecciones de CSRF (falsificación de solicitudes entre sitios).

El beneficio de sessionId idéntico (en logs de servidor y APM) debe sopesarse con el impacto en las medidas de seguridad. Un hash de un solo sentido podría hacer que la unicidad sea idéntica sin poner en peligro las protecciones. Esto requeriría la misma función hash en los casos en que los logs del servidor y los logs del agente del explorador estén enlazados entre sí.

Los siguientes ejemplos utilizan el valor raw sessionId, no una función hash concreta:

Obteniendo la aplicación sessionId en el agente de explorador de APM

Hay algunas formas de obtener sessionId del servidor de aplicaciones al agente de explorador.
  • Inicializar apmrum.sid desde el código de aplicación

    Esto requiere la capacidad del código de aplicación para exponer el sessionId activo en el html resultante. El código de aplicación debe producir un código html/javascript que inicializa la propiedad apmrum.sid con sessionId.

    El código de aplicación se agrega al cuerpo del código html como el siguiente:

    <script language="text/javascript">
       window.apmrum = window.apmrum || {};
       window.apmrum.sid = '<?PHP echo getSessionId(); ?>';
    </script>
  • Exponer la cookie sessionId e indicar al agente del explorador que la utilice

    En los casos en los que la aplicación sessionId no está protegida por el indicador HttpOnly, el agente de explorador se puede configurar para leer y utilizar el valor de la cookie sessionId.

    Muestra el html siguiente utilizando el nombre de cookie del servidor de aplicaciones, en este caso 'JSessionId':

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