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

Es gibt einige Möglichkeiten, 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 Eigenschaft apmrum.sid mit sessionId 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 verwenden

    Wenn die Anwendung sessionId nicht durch das Flag HttpOnly geschützt ist, kann der Browser-Agent so konfiguriert werden, dass er den Wert aus dem sessionId-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>