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
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 propiedadapmrum.sid
consessionId
.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 utiliceEn los casos en los que la aplicación
sessionId
no está protegida por el indicadorHttpOnly
, el agente de explorador se puede configurar para leer y utilizar el valor de la cookiesessionId
.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>