Ihre Sitzung ist abgelaufen, bitte melden Sie sich erneut an.

  • Hallo,

    kann jemand erklären, wie genau die Sitzungen bei aktivierten Cookies und das Erneuern der Sitzung per Javascript im Hintergrund genau ablaufen?

    Mein Verständnis bisher ist folgendes:
    Im ACP kann man die Option Gültigkeitslänge einer Sitzung session_timeout festlegen, beispielsweise 1800 Sekunden = 30 Minuten. Ein Benutzer ruft eine Seite auf und schließt den Tab nicht (er liest beispielsweise die vielen langen Beiträge auf der Seite im Thema und braucht dafür länger als die eingestellte Gültigkeitslänge). Er besucht in weiteren Tabs die Seite ebenfalls nicht. Kurz bevor die Sitzung ausläuft, versucht ein Javascript die Sitzung zu erneuern (siehe WCF.js WCF.System.KeepAlive). Das schlägt nun fehl, beispielsweise weil man in dem Moment keine Internetverbindung hat (man ist zum Beispiel mobil online und hat gerade keinen Empfang). Davon merkt man als Benutzer erst mal nichts, sondern liest munter das Thema weiter. Nachdem die Sitzung nicht erneuert werden konnte, stoppt das Javascript den Versuch die Sitzung zu erneuern. Nach 40 Minuten, also 10 Minuten nachdem die Sitzung abgelaufen ist, versucht der Benutzer einen Beitrag auf dieser Themenseite zu liken oder über die Schnellantwort eine Antwort zu verfassen. Nun bekommt er die Meldung "Ihre Sitzung ist abgelaufen, bitte melden Sie sich erneut an.". Ruft er daraufhin die Startseite auf, um sich neu anzumelden, oder lädt den Tab neu, ist er durch die Cookies wieder automatisch eingeloggt und hat eine neue Session.

    Falls ich den Prozess oben richtig verstanden und erklärt habe, stellt sich mir nun folgende Frage: Wieso wird die Sitzung nicht beim Liken oder Schnellantwort Verfassen bereits erneuert? Die Cookies werden ja auch bei diesen Anfragen mitgeschickt. Entsprechend sollte man, auch nachdem die Sitzung abgelaufen ist, diese bei diesen AJAX Anfragen erneuern können.

    Das aktuelle Verhalten, dass der Benutzer die Meldung "Ihre Sitzung ist abgelaufen, bitte melden Sie sich erneut an." angezeigt bekommt, aber sobald er die Seite neu lädt trotzdem bereits angemeldet ist, erscheint mir nicht sonderlich intuitiv. Meinen Benutzern wohl auch nicht, da ich sonst nicht darauf angesprochen werden würde, wieso dieser Fehler auftrete.

  • Display Spoiler
    Paket Entwickler Version Aktualisierungsdatum
    WoltLab Community Framework WoltLab GmbH 2.1.9 pl 1 25. Dezember 2015, 10:09
    User Conversation System WoltLab GmbH 2.1.4 13. November 2015, 16:49
    User Infraction System WoltLab GmbH 2.1.1 13. November 2015, 16:49
    WoltLab Burning Board WoltLab GmbH 4.1.9 22. Dezember 2015, 12:50
    Moderierte Benutzergruppen WoltLab GmbH 2.1.2 13. November 2015, 16:50
    Impressum WoltLab GmbH 2.1.0 13. November 2015, 16:50
    Datenimport WoltLab GmbH 2.1.7 22. Dezember 2015, 12:50
    WBB: Beliebte Beiträge hervorheben Stefan Haas 1.0.1 20. November 2015, 09:38
    DotaSource Reborn Stefan Haas; Mario Schlipf 1.0.0 13. November 2015, 16:54
    Hierarchische Checkbox Listen Stefan Haas 1.0.0 13. November 2015, 18:45
    Neueste Beiträge und Themen Stefan Haas 1.0.1 19. November 2015, 21:09
    Sanktion: Aus Benutzergruppe entfernen Stefan Haas 1.0.0 13. November 2015, 18:53
    WBB: Likes limitieren Stefan Haas 1.0.0 13. November 2015, 18:55
    WordPress Bridge Stefan Haas 1.0.0 13. November 2015, 18:55
    Time To Quit Sascha "SoftCreatR" Greuel 1.0.0 pl 1 13. November 2015, 18:56
    MediaElement.js Integration Sascha "SoftCreatR" Greuel 1.1.1 13. November 2015, 18:56
    MediaProvider PIP Thurnax.com 1.0.0 13. November 2015, 18:56
    MediaProvider Collection The_Waiters 1.0.3 pl 1 13. November 2015, 18:56
    BBCode Tabmenü geramy, nerdus 1.0.7 13. November 2015, 18:58
    TeamSpeak3 Viewer Gregor Ganglberger 1.0.7 13. November 2015, 18:59
    UZ Community Bot 2 - SimplePie API Udo Zaydowicz 2.0.0 13. November 2015, 19:23
    UZ Community Bot 2 Udo Zaydowicz 2.0.8 13. November 2015, 19:23
    Erweiterte Einstellmöglichkeiten für Benutzer und Administratoren norse 1.0.0 15. November 2015, 19:14
    Template: Truncate HTML Stefan Haas 1.0.0 19. November 2015, 19:51
    Favicons Joshua Rüsweg 1.0.0 20. November 2015, 10:48
    Multihunter Marcel Beckers, YoureCom 2.0.9 25. November 2015, 09:03
    Global Modificationlog Joshua Rüsweg 1.0.1 27. November 2015, 20:08
    Tooltips on Top KittMedia Productions 1.0.2 27. November 2015, 20:09
    Benutzer-Löschungen-Protokoll Sascha "SoftCreatR" Greuel 1.1.0 pl 2 27. November 2015, 20:09
    User Deletion Log: Burning Board Sascha "SoftCreatR" Greuel 1.0.0 27. November 2015, 20:09
    Große Like Benachrichtigung Stefan Haas 1.0.0 1. Dezember 2015, 10:06
    Zur Desktop Ansicht wechseln Stefan Haas 1.0.0 10. Januar 2016, 17:58
    Erweitertes Smiley System Stefan Haas 1.0.0 15. Januar 2016, 21:41
    Paketlisten-Export Sascha "SoftCreatR" Greuel 1.0.1 19. Januar 2016, 13:02

    @T1N0
    Viele Eigenentwicklungen, daher mein Verdacht, dass es auch an uns liegen könnte. Aber sicher, dass das Problem bei dir nicht auftritt unter den im Startbeitrag geschilderten Umständen? Also wenn "WCF.System.KeepAlive" versucht die Sitzung zu erneuern, ist keine Internetverbindung vorhanden und im Anschluss abgeschickte Likes / Schnellantworten funktionieren dann trotzdem bei dir?

  • Ein anderes Beispiel, welches mir gerade passiert ist: Man hat ein Thema im Forum im Browser geöffnet. Man fährt den PC oder Laptop in den Ruhezustand / Standby / Energiesparmodus. Nach Ablauf der Session fährt man das Gerät wieder hoch. Benutzt man nun die Like oder Schnellantwort Funktion, sollte die Fehlermeldung erscheinen.

    Ich werde nachher eine unveränderte, lokale WBB Installation anfertigen und das ganze versuchen zu reproduzieren.

  • Auszug aus dem Burning Board 4.0 | Handbuch,

    Quelle: https://www.woltlab.com/attachment/891…-board-4-0-pdf/

    Daraus verstehe ich dass diese 1800 Sekunden nur dann relevant sind, wenn ein Browser die Sitzung in den Cookies nicht speichert. Demnach wird die Session aus den Cookies erneut ausgelesen sobald das Forum wieder besucht wird und man sich zuvor nicht aus geloggt hatte. Daher wird es auch vollkommen irrelevant sein ob die Internetanbinung abbricht, der Rechner herunter gefahren wird usw.

    Zumindest betrieb ich diese Forensoftware mittlerweile auf mehreren Foren die ich installiert hatte und hatte bisher noch keine Probleme damit.
    Auch mit meinem jetzigem aktuellem Forum was ich betreibe habe ich diese Probleme nicht.

    Der Fehler müsste man daher an anderer Stelle suchen, wobei mir hierbei zunächst mal die Cookie-Domain dabei einfällt.
    Stimmt diese nicht könnte es durch aus sein dass hier die Session nicht mehr aufgenommen werden kann.

    In meinem Fall ist sie identisch mit meiner Domain.

    Es können aber auch Erweiterungen daran schuld sein, was du selbst herausfinden musst.
    Am besten durch ein Ausschlussverfahren, in dem du als Testform dein Forum als Kopie nochmals einrichtest und eine Erweiterung nach der anderen deinstallierst oder alles was du selbst verändert hast.

  • Ein anderes Beispiel, welches mir gerade passiert ist: Man hat ein Thema im Forum im Browser geöffnet. Man fährt den PC oder Laptop in den Ruhezustand / Standby / Energiesparmodus. Nach Ablauf der Session fährt man das Gerät wieder hoch. Benutzt man nun die Like oder Schnellantwort Funktion, sollte die Fehlermeldung erscheinen.

    Dagegen lässt sich auch nicht viel machen, denn nach einer gewissen Inaktivität läuft die Sitzung ab und wird gelöscht. Solange der Browser weiter läuft wird im Hintergrund regelmäßig (Ablaufzeit in Minuten - 1, d.h. bei 30 Minuten Gültigkeit alle 29 Minuten) eine Anfrage an den Server geschickt um die Sitzung aktiv zu halten. Im Standby/Ruhezustand laufen die Prozesse nicht mehr aktiv weiter weshalb die Sitzung regulär abläuft.

  • @Xoon
    Ich werde es ausprobieren und hier dann Bescheid geben, was ich als Quelle identifiziert habe.

    @Alexander Ebert
    Das stimmt natürlich. Aber der Benutzer muss sich ja, wenn er nach Ablauf der Sitzung eine andere Seite im Forum aufruft, bei aktivierten Cookies, ebenfalls nicht neu anmelden. Wieso wird also in diesem Fall, also nach dem Herunterfahren und neu hochfahren, bei einem Like, einer Schnellantwort oder ähnlichem (sprich bei jeder AJAX Action) die Session nicht erneuert? Kann durchaus sein, dass es dafür technische Gründe aufgrund der Architektur der Actions gibt oder es an etwas anderem liegt. Nur kann ich es noch nicht nachvollziehen.

    Nochmal die Fakten:
    - Cookies sind aktiviert
    - Wenn der Benutzer nach Session Timeout ohne Erneuerung der Session die Seite aufruft, wird er automatisch eingeloggt
    - Wenn der Benutzer auf einer bereits offenen Seite, jedoch mit Session Timeout, eine AJAX Action auslöst, bekommt er die "Sitzung ist abgelaufen" Fehlermeldung

    Könnte man bei AJAX Actions, wie bei einem regulären Aufruf der Seite, nicht ebenfalls eine neue Session anhand der übermittelten Cookies starten?

  • Das Problem ist hierbei, dass es zwei verschiedene Arten von Cookies gibt:

    • Login-Cookie
      Sorgt beim Seitenaufruf dafür, dass man automatisch angemeldet wird
    • Session-Cookie
      Enthält die Session-ID und ist bei abgelaufenen Session ungültig

    Alle Formulare einschließlich AJAX-Requests erfordern den so genannten "Security Token", dies ist ein zufällig generierter Wert der direkt mit der Session verbunden ist. Dieser verhindert das Dritte ohne dein Wissen Aktionen im Kontext deines Benutzerkontos durchführen können (siehe auch https://de.wikipedia.org/wiki/Cross-Site-Request-Forgery [CSRF]).

    Um die Sicherheit zu gewährleisten müssen bei einer Aktion sowohl die Session-ID als auch der passende Security-Token übermittelt werden, sie stellen damit gewissermaßen zwei Teile eines Schlüssels dar. Bei einem CSRF-Angriff macht sich der Angreifer zu nutze, dass der Browser den Cookie mit der Session-ID selbstständig beilegt, der Security-Token wird aber nicht im Browser gespeichert sondern wird im HTML der Seite zur Verfügung gestellt.

    Wenn die Session abgelaufen ist und server-seitig gelöscht wurde geht auch der Security-Token verloren (bzw. wird ungültig), wobei der Cookie mit der Session-ID in deinem Beispiel weiterhin bestehen bleibt. Der Login-Cookie darf bei ungültiger Session-ID <> Security-Token-Kombination nicht verwendet werden, da andernfalls der Schutz gegen CSRF vollkommen ad absurdum geführt wird - mit anderen Worten er würde ausgehebelt werden.

    Anders verhält es sich beim Neuladen der Seite, in dem Fall wird bei abgelaufener Session und gültigem Login-Cookie eine neue Session angelegt und im HTML der Seite wird der passende Security-Token angegeben, alle ab da an getätigten Anfragen an den Server bleiben bis zum Ablauf der Session gültig.


    Zusammengefasst lässt sich sagen: So verständlich dein Wunsch ist, er ist technisch nicht machbar ohne die absolut notwendigen Sicherheitsmaßnahmen über Bord zu werfen.

  • @Alexander Ebert
    Danke für die sehr ausführliche und einleuchtende Erklärung. Das Problem habe ich verstanden und die naive Lösung , man könne das Login-Cookie verwenden, ist damit vom Tisch.

    Allerdings will ich mich an einen weiteren Versuch machen, das Problem potentiell zu lösen oder dessen Auftreten zu vermindern. Zu unterscheiden sind zwei Ursachen:

    • Der Benutzer hat ausgerechnet eine Minute vor Ablauf der Session keine Internetverbindung
    • Der Benutzter öffnet eine Seite, fährt in den Ruhezustand und dann nach einer undefiniert langen Zeit wieder hoch mit der noch immer offenen Seite

    Im ersten Fall könnte ich die Dauer einer Session beispielsweise von 30 auf 60 Minuten erhöhen und zusätzlich das KeepAlive Javascript so ändern, dass es nicht eine Minute vor Ablauf der Session, sondern mehrmals, beispielsweise nach 15, 30, 45 und 59 Minuten versuch die Session zu erneuern. Dadurch hat das Gerät mehrmals die Chance die Session zu erneuern. Diese Lösung nagt etwas mehr an der Leistung des Servers, dürfte aber prinzipiell keine anderen Nachteile mit sich bringen, oder?

    Im zweiten Fall könnte ich mir lediglich vorstellen, dass man extrem lange Session Zeiten einrichtet und wird beispielsweise einen Tag später das Gerät wieder eingeschaltet, versucht das Javascript wieder die Session zu erneuern. Aus der Sicherheitsperspektive gebe es sicherlich einiges zu beachten, beispielsweise der Login an öffentlichen Geräten, bei welchen der Benutzer vergisst sich auszuloggen und seine Session ewig erhalten bleibt. Das könnte man aber sicherlich derart lösen, dass die Session nur bei gesetztem Login Cookie (was man an öffentlichen Geräten für gewöhnlich deaktiviert) lange / unbegrenzt erhalten bleibt. Alternativ könnte man der Plugin eine Funktion nachrüsten, dass der Benutzer spezielle Geräte bestimmen kann und nur deren Sessions bleiben lange erhalten. Gibt es andere Risikofaktoren für sehr lange Sessionzeiten zu beachten?


    Zu dem Problem mit dem unverständlichen beziehungsweise wenig intuitiven Text der Fehlermeldung fällt mir noch ein, dass man im Falle einer Cookie Session zumindest den Text der Fehlermeldung anders gestalten könnte im Vergleich zur Nicht-Cookie Session. Ich werde mal schauen, ob ich diese Unterscheidung in der Sprachvariable durch Überprüfung auf {$tpl.cookie.wcf_password|empty} machen kann.

  • Sicherlich kann man auf die eine oder andere Weise diese Problematik entschärfen, allerdings ist dies stets mit einem gewissen Nachteil bis hin zur Schwächung der Sicherheitsmaßnahmen verbunden.

    Ich kann die Motivation hinter diesem Vorhaben voll und ganz verstehen, allerdings habe ich Vorbehalte gegen dieses Vorgehen und möchte keine Hilfestellung dazu liefern. Ich stehe voll und ganz hinter den von uns getroffenen Maßnahmen und sehe eine Verschiebung weg von der Sicherheit hin zu Komfort kritisch. Bitte verstehe dies nicht als grundsätzliche Ablehnung deines Vorhabens, ich möchte lediglich an meinen Prinzipien hinsichtlich der Sicherheit unserer Produkte festhalten.

  • allerdings habe ich Vorbehalte gegen dieses Vorgehen und möchte keine Hilfestellung dazu liefern.

    Die Sicherheit des WCF in meiner Community aushebeln bekomme ich ganz alleine hin :P

    Nochmal etwas ernster dazu: Ihr selbst erlaubt bei der session_timeout Option eine Dauer von 10 Minuten bis 24 Stunden. Was spricht dagegen, wenn eine Session länger als 24 Stunden gültig ist? Beziehungsweise welches Angriffsszenario macht längere Dauern für Sessions gefährlich? Ich hoffe, ich nehme mit meinen Fragen nicht zu viel deiner Zeit in Anspruch. Ein einfacher Link wie beim CSRF Szenario reicht mir schon, dann kann ich mich selbst in das Szenario einlesen.

    Das gleiche gilt für das mehrmalige versuchen ein KeepAlive auszuführen, beispielsweise zwei mal: Ein mal nach der Hälfte und ein mal eine Minute vor Ablauf, wie es jetzt schon der Fall ist: Handelt es sich bei dem einmaligen Versuch ebenfalls um einen Sicherheitsaspekt oder geht es dabei rein um die Belastung des Servers, dass es nur ein mal versucht wird?

    Ich werde vermutlich Änderungen, welche tatsächlich etwas an den Sessions ändern, erst mal unterlassen und nur den Text der Fehlermeldung versuchen anzupassen, sodass die Benutzer wissen, dass sie vor dem Ausführen der nächsten Aktion die Seite neuladen müssen. Zusätzlich werde ich die Session Dauer von 30 auf voraussichtlich 60 Minuten erhöhen, da wir öfter mal viele lange Beiträge haben, sodass man durchaus länger als eine halbe Stunde zum lesen brauchen kann und sich dann wundert, wieso der Like nicht funktioniert.

  • Was ich aber nicht ganz verstehe ist dass wenn ich meine Website in mehreren Tabs im selben Browser offen habe und in einem Tab arbeite (auf der Website surfe, Postings schreibe), dann erhalte ich bei den anderen Tabs die Meldung "Deine Sitzung ist abgelaufen" wenn ich dort weiter surfen möchte. Warum ist das so? Hier müsste doch immer dasselbe Session Cookie geprüft werden oder bekommt etwa jeder Tab eine eigene Session?

  • Prinzipiell sollte das Problem nicht auftreten, solange durchgehen eine Internetverbindung besteht, da die Session dann automatisch (solange der Tab geöffnet ist) verlängert wird. Das sollte bei dir entsprechend eine andere Ursache haben.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!