Sessionverfolgung konfigurieren
Sie können das Session Tracking-Reporting für den APM-Browser-Agent konfigurieren.
Standardmäßig erstellt der APM-Browser-Agent eine Session-Tracking-Cookies, mit denen die Aktivitäten eines eindeutigen Browsers verfolgt werden, bis der Browser neu gestartet wird. Dies kann von dem abweichen, was der Anwendungsserver verwendet. Insbesondere können Daten vor und nach der Anmeldung und Abmeldung verfolgt werden. Die sessionId
stimmt nicht mit der sessionId
überein, die möglicherweise in Logdateien vorhanden ist. Es gibt einige Ansätze, die helfen könnten, den Server sessionId
an das Browser-Reporting anzupassen. Wenn Sie nur sicherstellen möchten, dass Sessionunterbrechungen auf Anmeldungs-/Abmeldeseiten angewendet werden, können Sie nur dieses Szenario aktivieren.
Sessionumbrüche hinzufügen
Ein Aufruf von document.ApmSdk.resetSession()
im javascript-Code stellt sicher, dass die vorhandene Session geschlossen ist und die neue Session gestartet wird. Dadurch werden die Interaktionen isoliert, bevor diese Funktion aus den Interaktionen danach aufgerufen wurde. Wenn Sie diese Option entweder zur Anmeldeseite oder zur Landingpage der Abmeldung (und zum Timeout) hinzufügen, können Sie sicherstellen, dass die Sessionunterbrechungen im Browser-Agent-Reporting mit den Unterbrechungen der Kundenerfahrungen übereinstimmen.
javascript-Beispielcode, der einen Session Break auslöst:
<script language="text/javascript">
if (document.ApmSdk) {
document.ApmSdk.resetSession();
}
</script>
Browser SessionId mit Server SessionId ausrichten
Eine alternative Methode zur Ausrichtung der Serversession an der Browsersession besteht darin, die Id
zur Identifizierung einer Session auszurichten. Im Folgenden werden einige Vorgehensweisen beschrieben.
Raw sessionId-Exposition könnte CSRF schwächen
Die Exposition von sessionId
gegenüber javascript und APM könnte den CSRF-(Cross-Site Request Forgery-)Schutz schwächen.
Der Vorteil identischer sessionId
(in Serverlogs und APM) sollte gegenüber den Auswirkungen auf Sicherheitsmaßnahmen abgewogen werden. Ein Einweg-Hash könnte die Einzigartigkeit identisch machen, ohne den Schutz zu gefährden. Dies würde dieselbe Hash-Funktion erfordern, wenn die Serverlogs und Browser-Agent-Logs miteinander verknüpft sind.
Die folgenden Beispiele verwenden den RAW-Wert sessionId
, keine bestimmte Hash-Funktion:
Anwendung sessionId wird an APM-Browser-Agent abgerufen
sessionId
vom Anwendungsserver zum Browser-Agent abzurufen.
-
apmrum.sid aus Anwendungscode initialisieren
Dazu muss die Funktion im Anwendungscode die aktive
sessionId
im resultierenden HTML-Code bereitstellen. Der Anwendungscode sollte HTML-/javascript-Code erzeugen, der die Eigenschaftapmrum.sid
mitsessionId
initialisiert.Der Anwendungscode fügt den Text des HTML-Codes wie folgt hinzu:
<script language="text/javascript"> window.apmrum = window.apmrum || {}; window.apmrum.sid = '<?PHP echo getSessionId(); ?>'; </script>
-
sessionId
-Cookie verfügbar machen und Browser-Agent anweisen, es zu verwendenWenn die Anwendung
sessionId
nicht durch das FlagHttpOnly
geschützt ist, kann der Browser-Agent so konfiguriert werden, dass er den Wert aus demsessionId
-Cookie liest und verwendet.Beispiel für die folgende HTML mit dem Namen des Anwendungsservercookies, in diesem Fall
'JSessionId'
:<script language="text/javascript"> window.apmrum = window.apmrum || {}; window.apmrum.tracking_cookie = 'JSessionId'; </script>