header(Location) und Mozilla Firebird...

[neogrande]

Hi,

ich habe hier ein Login-Script gebastelt, welches gleich nach dem Betätigen des Login-Buttons die Login-Befehle ausführt und dann die Seite neulädt (wegen dem Problem der POST-Daten, die sonst beim Klick auf zurück wieder gesendet werden)

Sieht also so aus:

  $self = $_SERVER["PHP_SELF"];
  if ($s_user->getLogin())
  {
    $s_user_seri = serialize($s_user);
    $_SESSION["s_user_seri"] = $s_user_seri;
    header("Location: $self");
  } 

Das gesamte Script (ist natürlich noch ne Menge mehr) wird nun oben in normale HTML-Dateien includet. Funktioniert dort auch super in Opera, Firefox und IE.

Nun gibt es aber noch eine 500-zeilige admin.php, die auch mit diesem Script geschützt wird.
Hier funktioniert das ganze nur noch im Opera und IE. Firefox scheint nach dem Login die Seite einfach nicht neuzuladen und komischerweise sieht man wieder das normale Login-Script.

Wenn man vorher versucht, sich mit einem anderen User (der die Seite nicht sehen darf) anzumelden, kommt wie gewollt die Meldung, dass man keine Rechte hat. Wenn man sich nun wieder mit dem richtigen Account anmelden will, bleibt auch diese Meldung bestehen! Es scheint also gar keine Verarbeitung des Forumlars stattzufinden (wie gesagt- bei den normalen HTML-Dateien geht alles)

Wenn ich den header mal absichtlich unterbinde (ein echo davor setze) wird das Script auch in der admin.php normal ausgeführt (bis auf die Warnung, dass der header nicht gesendet wurde.)
Aber dann wäre ja der Schutz vor dem Zurück-Button wieder hin :-(

Ist bekannt, dass Mozilla Firefox irgendwelce Probleme mit der header("Location")-Funktion hat?

[Wurzel]

- gib mal eine vollständige url an => http://www.bla.....
- häng session-name & -id mit an

dann sollte es auch SICHER mit allen browsern klappen

[neogrande]

Interessant, jetzt gings genau einmal, aber jetzt liefert er wieder das gleiche Ergebnis

Cache ist aus und die Sessions werden auch zwischen den Tests beendet (Extra-Script).

Das Anhängen der Session-ID will ich eigentlich nicht (scheint ja auch nicht zu helfen), da sie zu leicht manipulierbar bzw. weiterversendbar wird. Deswegen machte ich das ganze mit Cookies.
Die Lebensdauer der Session-Cookies ist 3600 sek.
Und in der admin.php wird auch nix session-mäßiges verwendet.

[neogrande]

Ein kleiner Nachtrag:

Ich hab jetzt testweise die cookies deaktiviert und somit nur noch auf die angehängte Session-Variable verlassen.
Das Ergebnis:

Mal gehts, mal gehts nicht, mal gehts in feiner Unregelmäßigkeit.

Wenn ich allerdings meinen Browser so einstelle, dass er bei jedem Cookie fragt, und ich dann jedesmal manuell ablehne - dann gehts immer.

Ebenso geht es immer, wenn ich die session_id wieder aus der Weiterleitung rausnehme, und alles cookies manuell annehme.

Dies lässt vermuten, dass es dem Browser sonst zu schnell geht, was ich allerdings sehr merkwürdig finde...
Firefox ist doch kein lahmer...

[asp2php]

mach mal:

$self = 'http://'.$_SERVER['SERVER_NAME'].':'.
$_SERVER['SERVER_PORT'].'/'.$_SERVER["PHP_SELF"].'?'.SID; 

wie ist es dann?

[neogrande]

Es wird offensichtlich gar keine Weiterleitung gemacht (auch bei deiner Version).
Übrigends hast du einen kleinen Fehler: zwischen SERVER_NAME und PHP_SELF kommt kein "/".
Dies führte erst mal zu einer Weiterleitung auf irgendeine *.ms-Seite. Sehr lustig (zumal mein Chef das grad mal testen wollte...)

Dies sehe ich daran, dass in der URL noch der Parameter "?cookie=test" erscheint bei dem Login-Formular.
(Bei der Cookie-Test-Funktion funktioniert die Weiterleitung offensichtlich)
Dieser müsste nach der Weiterleitung wegsein, da er nur beim Erstellen des Login-Scripts gemacht wird.
Ist er aber nicht.

Da der Admin meines Servers auch eben gekommen ist und auch sehr verdutzt war, schauen wir uns jetzt mal die Apache-Logs an...

[asp2php]

Original geschrieben von neogrande

Übrigends hast du einen kleinen Fehler: zwischen SERVER_NAME und PHP_SELF kommt kein "/" ...

das kommt von C&P , weil in meinem Code nicht $_SERVER['PHP_SELF'] folgt sondern was anderes

[neogrande]

Ich habe mir mal von meinem Administrator ein Debug-Script geben lassen, welches mir den Zustand der POST-, GET-, SESSION- und COOKIE-Variablen zeigt.

Und auch das zeigt mir, dass offensichtlich die Seite überhaupt nicht neu geladen wird (das header wird also nicht ausgeführt).

Wenn ich cookies manuell erlaube und es dann funktioniert, sehe ich, dass das serialisierte Nutzerobjekt richtig in der Session gespeichert wird, dass das Cookie ordnungsgemäß gesetzt wurde, und das die POST-Daten ordentlich gesendet wurden.

Momentan sehe ich als einzige Möglichkeit, auf das Neuladen zu verzichten, wodurch das Problem der POST-Daten wieder auftritt.
So'n Mist.

[wahsaga]

Original geschrieben von neogrande
Und auch das zeigt mir, dass offensichtlich die Seite überhaupt nicht neu geladen wird (das header wird also nicht ausgeführt).

kann der Location-header denn überhaupt noch "ausgeführt" werden?

(oder hast du vielleicht bereits eine ausgabe davor gemacht, und die fehlermeldung aber unterdrückt/das error reporting geknebelt?)

[asp2php]

ganz am Anfang des Script bitte folgendes einfügen:

ob_start(); 

wie ist es nun?

[neogrande]

Ich muss mich mal wieder korrigieren, die Seite wird neugeladen,
PHP braucht 0.0061s dafür.

Allerdings sind die Session-Variablen nicht gesetzt.
Das Session-Cookie ist gesetzt.
Das sagt das Debug-Script.

Firefox scheint aber was anderes zu machen, denn bei einem Klick auf zurück fragt er mich, ob der die POST-Daten erneut senden soll, was ja eigentlich nach der Weiterleitung nicht passieren dürfte.

In den Logs zeigt sich, dass Mozilla die Seite, die eigentlich nach den Logins aufbauen soll, anfängt, aufzubauen (templates werden vom Webserver gezogen, aber nicht alle...)
Und dann schiebt sich da doch was anderes dazwischen, genau vermag ich es aber nicht zu sagen...

[asp2php]

was heiss neugeladen? =weitergeleitet? schon mit ob_start() probiert?

[neogrande]

Ja, neugeladen stand hier für weitergeleitet, sorry.

ob_start()

Das scheint das Problem zu beheben.
Ganz sicher kann ich mir natürlich nicht sein, da das Problem ja nicht 100%ig erklärbar war.

Ich danke dir von ganzem Herzen.

Hat diese Pufferung irgendwelche negativen Auswirkungen? Oder dauerts halt einfach etwas länger, falls mal ne große Seite kommt?


Der Blick in die logs sorgte auch für Aufklärung anderer Art Mein Code zieht teilweise Templates doppelt, was so nicht sein sollte. Da kommt noch Arbeit auf mich zu

[asp2php]

Original geschrieben von neogrande
Das scheint das Problem zu beheben.

d.h. du hast vor header irgendwo in deinem Wald von include schon Ausgaben gemacht, daher kann header nicht funz. Die Pufferung verlangsam IMHO nicht, wenn überhaupt, dann in meinen Augen unwesentlich .

[neogrande]

Soviel header habe ich nicht (2 im Script um genau zu sein).
Und meine Includes sind die config-Dateien und ein paar Klassen, die nur im Fehlerfall Ausgaben machen, was aber nicht passiert.

Und wenn wirklich schon eine Ausgabe stattgefunden hätte, hätte es erstens in keinem Browser geschehen dürfen und zweitens wäre eine entsprechende Warnung gekommen.
Deswegen meine Vermutung, das der Firefox die Anfragen irgendwie verdreht (was an den Apache-Logs auch etwas zu sehen war).

Fakt ist, dass das Script schon aufgebaut wird (ein teil der Templates wird gezogen) und danach wird erst weitergeleitet und neu aufgebaut.

Das ist z.B. auch im Opera so (ohne ob_start()).
Es werden erst alle Templates vom Webserver gezogen (u.a. auch 4 mal ein Listen-Template) und dann wird weitergeleitet und die Templates werden nochmal gezogen. Merkwürdig. Aber dort funktionierte es.
Firefox scheint dann wohl schon einen Teil ausgegeben zu haben (was man aber hätte sehen müssen)