AW: Probleme mit der neuen Forensoftware
Mifft, jetzt habe ich dann doch länger als 30 Minuten genraucht, um den Beitrag unten zu editieren - zum Glück hatte ich mir den Text vorher rauskopiert
Also, dann ist der Grund gefunden. Das ist aber ein technisches Problem. So ein Forum wie dieses ist eine sogenannte "Webanwendung" (wird mit dem Browser bedient und das "Frontend" ist eine "Internetseite"). Diesem zugrunde liegt der Dienst HTTP, der bereits Anfang der 80er Jahre entwickelt wurde. der ursprüngliche Zweck war *nur*, statische Textdokumente anzuzeigen und die Möglichkeit der Verlinkung zu geben - "dynamische" Anwendungen, die Benutzereingaben erfordern waren zwar vorgesehen, aber zu Anfang nicht in einer Interaktiven Form; diese Anforderung kam erst später.
Das Problem ist das zugrunde liegende Protokoll, HTTP: dieses basiert auf einem Request-Response-Prinzip: der Browser stellt genau eine Anfrage und erhält darauf genau eine Antwort. Wie man sieht, taucht hier nirgends das Wort "Session" auf: solche waren zu Anfang gar nicht vorgesehen. Deshalb wurden Mechanismen entwickelt, um eine Serie von HTTP-Request-Response-Zyklen zu einer Session zusammenfassen zu können: nur so lassen sich interaktive Webanwendungen wie diese Forensoftware überhaupt erst entwickeln.
Die Statuslose Natur des HTTP-Protokolls birgt aber genau aufgrund dieser Eigenschaft das eigentliche Problem eines darüber gestülpten Session-Mechanismus: wann ist die Session zuende? Wir erinnern uns, HTTP bedeutet ausschließlich: Browser stellt Anfrage, Server antwortet. D.h. einen Mechanismus zu entwickeln, der für verschiedene Benutzer verschiedene Sessions verwalten kann (i.e. nachverfolgen, wo war der Benutzer, welche Daten hat er eingegeben, welche Seite wird als nächste angezeigt usw.) ist einfach: man muß nur jeder Session einen eindeutigen Wert (Token oder Session ID genannt) mitgeben, der in jedem Request und in jeder Response steckt. Solange dies gegeben ist, ist die Session aktiv.
Beendet der Benutzer die Session aktiv, kann man einfach den Session Key verfallen lassen, kommt der Benutzer später wieder, wird er zunächst nicht erkannt und ein neuer Session Key wird vergeben. Erst nach erfolgter Anmeldung kann der Session Key einem bestimmten Benutzer zugeordnet werden (davor ist er "Gast" und kann in den allermeisten Software Varianten das System nur eingeschränkt nutzen).
Jetzt wird aber langsam deutlich, wo das eigentliche Problem liegt: eine Session aufzubauen ist einfach, habe ich gerade in zwei Sätzen erklärt. Eine Session aktiv abzubauen ist ebenfalls kein Problem, siehe darüber.
Aber was passiert denn, wenn
- der Benutzer das Haus verläßt, aber den Computer und Browser angeschaltet läßt?
- der Browser/PC abstürzt oder abgeschaltet wird, ohne sich in der Webanwendung abgemeldet zu haben?
- der Benutzer in der Adreßzeile des Browsers eine andere Adresse manuell eintippt?
- der Benutzer die "Zurück / Vorwärts"-Knöpfe seines Browsers benutzt (die Seiten können dann unter bestimmten Voraussetzungen allein aus dem Cache des Browsers dargestellt werden, der Server "erfährt" von dieser "Navigation" nichts)?
Es sind noch eine Reihe anderer Szenarios denkbar, die die Verwaltung von Sessions für den Server erschweren - um's nochmal deutlich zu machen: der Grund dafür ist der fehlende Status im HTTP-Protokoll - außer "sende genau eine Antwort auf jede eintreffende Frage" kann dieses Protokoll recht wenig (was es im übrigen so robust macht).
Offene Sessions sind ein Sicherheitsproblem. Auch wenn die Session Keys heutzutage kryptographisch erzeugt werden, besteht dennoch die Möglichkeit, Session Keys durch "normale" Kommunikation abzhören, da sie ja in jedem Request / Response enthalten sind. Natürlich gibt es auch dagegen Schutzmechanismen (zum Beispiel, indem man die gesamte Session nur verschlüsselt überträgt (z.B. mit SSL: HTTPS)), aber wenn wir uns unsere radioforen.de da oben anschauen, steht da in der Adreßzeile "
http://..." (<-- ha-ha, da wollte die Forumsoftware schlauer sein als ich und hat da URL-Tags drum gebastelt - klicken kann man den Link trotzdem nicht
) - nix "s", also keine Verschlüsselung. Bedeutet: auf dem Weg zwischen Server und Browser kann an jeder Stelle jemand sitzen, Dein Paket lesen (das Bild vom "Senden" eines Paketes ist eigentlich unvollständig, es ist mehr ein "kopiere zum nächsten Knoten, bei Erfolg lösche die lokale Kopie"-Mechanismus...) und daraus den Session Key extrahieren.
Gelingt dieses jemandem, der übles vorhat, so kann ihm nichts besseres passieren, als daß die Session offen gelassen wird: dann kann er sie nämlich einfach übernehmen, entführen, hijacken, indem er ein gefälschtes Paket mit dem richtigen Session Key an den Server sendet: da der Benutzer ja bereits authentisiert und authorisiert ist, reicht der Session Key als *alleinige* Legitimation, mit dem Server zu kommunizieren. Andere IP-Adresse? Kein Problem für den Server: er weiß ja nicht, ob Dein Rechner vielleicht ein Notebook ist, das Du mitgenommen und in einem anderen Netz wieder aktiviert hast.
Aus genau diesen Gründen gibt es die Möglichkeit, Sessions automtisch ablaufen zu lassen (nach einer in der Regel einstellbaren Zeit an Inaktivität). Genau dieses passiert, wenn das Häkchen "immer angemeldet bleiben" *nicht* aktiviert ist. Das ist ein Schutz, damit die Wahrscheinlichkeit, daß jemand unbefugt Euren Account verwenden kann eingeschränkt ist. Dieses ist *sehr* empfehlenswert, wenn man zum Beispiel in unverschlüsselten WLANs unterwegs ist, oder sich zum Beispiel von einem öffentlichen PC (z.B. im Internet Cafe) anmeldet. Die beste Methode in solchen Fällen ist natürlich, am Ender der Sitzung diese aktiv zu beenden, aber auch hier kann ja etwas unvorhergesehenes passieren, so daß man vielleicht den PC noch schnell herunterfährt, aber die Session nicht aktiv beendet hat: wie oben beschrieben, der Server *kann* das nicht merken, das gibt das Protokoll nicht her.
Der Vollständigkeit halber sei angemerkt, daß es natürlich auch hier Mechanismen gibt, den man einsetzen könnte um festzustellen, ob die Seite noch geöffnet ist - Stichworte "Heartbeat", asynchrone Kommunikation, AJAX,... aber auch das hat wieder Nachteile, zum Einen muß so eine Lösung natürlich entwickelt (, gesichert und getestet) werden und zum anderen bedeutet das permanente Kommunikation zwischen Browser und Server. Bei den Nutzern von radioforen.de sicherlich noch überschaubar, aber wenn man an Anwendungen wie Amazon, eBay oder andere Riesen denkt, käme man da schon auf ganz schöne Datenmengen in der Summe, die überwiegend nur dazu dienen, festzustellen, ob die Seite noch offen ist (man kann das natürlich mit "Nutzdaten" kombinieren - aber trotzdem!). Insofern muß ein Software-Entwickler schon auch eine gewisse Kosten-Nutzen-Rechnung anstellen, ob dieses Feature wichtig genug ist, um den Entwicklungsaufwand zu rechtfertigen.
Der (mal wieder) langen Rede kurzer Sinn: ich kann Eure Bedenken nachvollziehen, möchte aber darauf hinweisen, daß Eure Erwartungen (aufgrund tief liegender Probleme) recht schwierig zu erfüllen sind. Im Prinzip habt Ihr (leider) keine Wahl, als die Umstände als gegeben hinzunehmen. Ich kenne die Software nicht, deshalb weiß ich nicht, ob sie über die entweder-oder-Wahl "immer angemeldet bleiben" hinaus weitere Möglichkeiten der Session-Kontrolle bietet - aber ich befürchte, daß die Software mehr einfach nicht hergibt. Daher habt Ihr nur die Wahl zwischen der Pest und der Cholera: entweder Ihr bleibt "immer angemeldet" (so mache ich das von allen stationären Rechnern, von denen aus ich radioforen.de verwende) Oder Ihr laßt den Haken weg (mache ich bei unsicheren Netzen und / oder öffentlichen PCs.
LG
McCavity
