Session Problem mit AJAX

[Daniel1987]

Hi Leute,

habe ein Problem, welches ihr sicher kennt. Wenn ich einen Request starte, aber die Session abgelaufen ist sollte im besten Fall der Request erst gar nicht starten.

Tut er aber.

Ich habe das Problem so gelöst, dass in der angeforderten Datei die aktuelle Session auf gültigkeit überprüft wird. Ist die Session abgelaufen gibts ein

Code:
die('logout');zurück!

in meiner ajax datei sieht das nun so aus:

Code:
function send(containerID)
{
 var Container = document.getElementById(containerID);

if(XMLHTTP.readyState < 4)
 {
  Container.innerHTML = 'wait...';
 }

if(XMLHTTP.readyState == 4)
 {
  if(XMLHTTP.responseText == 'logout')
  {
   return document.location.href="/index.php?logout=1";
  }

Container.innerHTML = XMLHTTP.responseText;
 }
}

Ich sag mal so: es klappt. Ist aber, wie ich finde, keine schöne Lösung. Welche Erfahrung habt ihr diesbezüglich gemacht?

[Michael]

Hi!

Also ich sag mal, es kommmt drauf an, auf welche Weise Du die Session überträgst.

Ich nehm mal an, Du benutzt nicht PHPSESSID, da dabei normalerweise eine Session erst mit dem Schließen des Browserfensters abläuft.
Auf Cookies mit vorbestimmten Timeout kannst Du Dich hier auch nur bedingt verlassen, da ja nicht jeder User Cookies zuläßt.

Idealerweise müßte hier eigentlich Deine SID als Variable im Javascript gespeichert sein. Javascript muß man ja als Voraussetzung ansehen, da ansonsten Dein Ajax nicht laufen würde.

Wenn Dir dann das Beenden Serverseitig nicht gefällt, schreib die Regel, wann die Session gelöscht werden soll direkt ins Javascript und beende mit dem Löschen direkt die Ajax-Abfrage, ohne nochmal über den Server zu gehen.

Schönen Gruß!
Michael

[Daniel1987]

Ich benutze $_SESSION['userid'] und $_SESSION['userpw']

[Michael]

Ich benutze $_SESSION['userid'] und $_SESSION['userpw']

Hmmmmm... dann haste ein ziemlich geringes Sicherheitsbedürfnis.

Ein Gedankenspiel:

User "Bernd" sitzt in nem Internetcafe, surft gerade auf Deiner Seite, hat sich eingeloggt und wird vom Nachbarn, der ne Tasse heiße Schokolade hat rein zuufällig angerempelt. Die Schokolade schwappt über, die Klamotten sind ruiniert. Bernd stürmt ins Bad um zu retten, was noch zu retten ist und der Nachbar setzt sich vor Bernds PC, sucht schnell nach den Session-Daten (die entweder bei den Cookies, oder gar in der Adresszeile stehen) und verschwindet anschließend spurlos.
Tags drauf stellt Bernd fest, daß er sich nicht mehr in seinem Account einloggen kann. Das Passwort wurde geändert, oder der Account gar gelöscht.

Warum? Weil der böse unerkannte Nachbar nicht nur Bernds Session-ID, sondern sogar Name und Passwort bekam!
Selbst wenn das Passwort verschlüsselt ist: Was hindert ihn dran, seine eigene Session so umzuschreiben, daß sie das verschlüsselte Passwort beinhaltet?
Und selbst wenn Du ne Möglichkeit hast, das irgendwie zu blockieren: Was ist mit Rainbow-Tables?

Also: Session-IDs haben durchaus ihren Sinn.
Eine zufällig generierte alphanumerische Folge zum Abgleich, die nach Ablauf nutzlos wird und auch während der aktiven Phase dem armen Bernd nicht gleich den Account kostet, weil man bei solchen Feldern wie Passwortänderung auch immer zur Sicherheit nach dem alten Passwort fragt.

Aber nochmal zu der Frage, wie Du eine weitere Abfrage unterbindest (auch wenn da der andere Zweig drauf ebenfalls eingeht) :

Original von Sven Rautenberg:

Der Server MUSS prüfen, ob die Session gültig ist - ansonsten manipuliert ein Angreifer diese clientseitige Prüfung aus der Website heraus und greift dann auch auf abgelaufene Sessions zu.

Natürlich muß er das ... AUCH !

aber nichts hindert Dich daran, eine Vorabkontrolle clientseitig zu unternehmen um sich eine weitere Abfrage zu sparen.

Schönen Gruß!

Michael

[Michael]

autsch ...
ich glaub, ich sollte besser 2mal nachdenken, bevor ich solchen Text schreibe.

Sorry Daniel, ich wollt Dich nicht verunsichern.
Natürlich wird bei $_SESSION nur die ID zum Browser hin übertragen, während die anderen Variablen serverseitig gespeichert werden.

*mich mal besser verkrümel und Feierabend mach*

[Daniel1987]

Ich wurde auch schon gerade sehr schwach, meines Erachtens ist das sehr sicher, übertragen wird da nix, zumindest nix was man nutzen könnte um irgendwas zu manipulieren. Es sei den der Kerl mit der Hose voller Kaffee ist auf dem Klo und der andere Kerl ändert seine Login Daten und logt sich auch, aber das kann in jedem System passieren. ;-)

[Sven Rautenberg]

Moin!

Wenn Dir dann das Beenden Serverseitig nicht gefällt, schreib die Regel, wann die Session gelöscht werden soll direkt ins Javascript und beende mit dem Löschen direkt die Ajax-Abfrage, ohne nochmal über den Server zu gehen.

Der Server MUSS prüfen, ob die Session gültig ist - ansonsten manipuliert ein Angreifer diese clientseitige Prüfung aus der Website heraus und greift dann auch auf abgelaufene Sessions zu.

Klar, der Extra-Request scheint überflüssig, aber prinzipbedingt kann der Client nicht wissen, wann der Server die Session für abgelaufen oder ausgeloggt hält (muß ja nicht nur durch zeitlichen Ablauf passieren, kann ja auch in einem anderen Browserfenster auf "Logout" geklickt werden). Es ist also unumgänglich, dass der Request erfolgt. Auch ohne AJAX würde der User irgendwo klicken, einen Request auslösen, und als Ergebnis "Session ungültig" erleben.

So ist halt das Leben.

- Sven Rautenberg

[Daniel1987]

Ich hab das System nun umgestellt und denke, dass es besser ist die PHP-Seite per:

die(header("Location: ".$CONFIG['root']));

ändern zu lassen und dann im AJAX Teil das hier zu schreiben:

if(XMLHTTP.status == 200)
{
 Container.innerHTML = XMLHTTP.responseText;
}
else
{
      alert("Error has occurred with status code:  "+XMLHTTP.status);
}

Nur leider gibt der IE den Statuscode 302 nicht wieder, weiß jemand wieso? FF und Opera arbeiten da tadellos... bzw. kennt einer Gründe dafür?

[Daniel1987]

Ich sehe gerade wenn ich:

alert(XMLHTTP.status);

for den IF Teil schreibe kommt der Statuscode 200... Aber wieso?

[Sven Rautenberg]

Moin!

Ich sehe gerade wenn ich:

alert(XMLHTTP.status);

for den IF Teil schreibe kommt der Statuscode 200... Aber wieso?

Vielleicht weil der IE deinem Redirect einfach folgt.

Ein Redirect hielte ich auch nicht für eine vernünftige Antwort auf "Session abgelaufen" - erst recht nicht einen Redirect auf die Startseite.

Warum verschlimmerst du deine Lösung? Die erste Form war doch prima - vielleicht bis auf die eher unelegante Beendigung des PHP-Skriptes mit die().

- Sven Rautenberg

[Dani1987]

Mein Script ist so aufgebaut das es ein:

die(header("Location: ".$CONFIG['root']));

gibt wenn die Session vorbei ist. Und wenn ich eine Datei mittels Ajax aufrufe und die Seite dann 302 wiedergibt heißt das nix anderes als das die Session vorbei ist.

die(header("Location: ".$CONFIG['root']));

Wird nun auch von allen Browsern befolgt, allerdings wird die Seite in dem innerhtml teil angezeigt, es wird also von allen Browsern eine 200 wiedergegeben. Ich versteh nicht wieso da nichtmal vom FF eine 302 kommt...

[wahsaga]

hi,

Wird nun auch von allen Browsern befolgt, allerdings wird die Seite in dem innerhtml teil angezeigt, es wird also von allen Browsern eine 200 wiedergegeben. Ich versteh nicht wieso da nichtmal vom FF eine 302 kommt...

Siehe meine andere Antwort - es ist nicht Sinn der Sache, dass der Nutzer von XMLHttpRequest sich mit solchen Feinheiten des HTT-Protokolls selber herumschlagen muss.

Oder würdest du, wenn bspw. auf einen Request nur ein 304 Not Modified als Antwort kommt, selber einen Cache implementiert haben wollen, aus dem du dir die zuvor bereits angeforderten Daten selber wieder raussuchen musst?

Nein, auch bei einem 301/302 mit Location-Header möchte ich nicht selber noch mal einen erneuten Request nach der "Weiterleitungs-Adresse" starten müssen - dem ggf. automatisch zu Folgen, und mir die "eigentliche" Antwort zu liefern, erwarte ich vom Gespann Browser/Script-Engine.

gruß,
wahsaga

[wahsaga]

hi,

for den IF Teil schreibe kommt der Statuscode 200... Aber wieso?

Vielleicht weil der IE deinem Redirect einfach folgt.

XMLHttpRequest _soll_ ja auch "einfach" sein - dass der Nutzer sich noch selber mit tieferen Aspekten von HTTP wie Redirects oder auch Caching (304) herumschlägt, kann eigentlich kaum Sinn der Sache sein.

Einen 304 als Antwort auf einen XMLHttpRequest gibt m.E. kein Browser dem Nutzer (Script-Schreiber) weiter - wenn das bei einem Redirect je nach Browser anders gehandhabt wird, muss man wohl sehen, wie man darauf reagiert.

Ein Redirect hielte ich auch nicht für eine vernünftige Antwort auf "Session abgelaufen" - erst recht nicht einen Redirect auf die Startseite.

Ja, sehe ich genauso.

gruß,
wahsaga