Session-Problem nach Update auf 4.3.10

[srob]

Moin moin!

1und1 und Schlund führen zur Zeit Updates auf PHP 4.3.10 durch. Seit gestern habe ich plötzlich auf allen möglichen Seiten bei diesen beiden Providern Probleme mit Sessions. Eingegrenzt (und reproduzierbar) stellt sich die Problematik so dar:

Es gibt eine Anmeldeseite (User/Pwd), Benutzer ruft mit Klick auf "Anmelden" dasselbe Skript noch einmal auf, nach erfolgreichem Überprüfung der eingegebenen Daten mit einer DB wird eine Session gestartet, u.a. eine Variable gesetzt wird und auf die Hauptseite des Benutzerzugangs umgeleitet:

@session_start();
  $_SESSION['cRegistriert'] = 'sstmreg';
  printf('<meta http-equiv="refresh" content="0; URL=http://blahblah/hauptseite.php?%s=%s" />',session_name(),session_id());

Alle auf dieser Hauptseite verlinkten Skripte machen zu Beginn folgende Überprüfung:

@session_start();
  if($_SESSION['cRegistriert'] != 'sstmreg')
    {
    header("Location: http://".$_SERVER['HTTP_HOST'].dirname($_SERVER['PHP_SELF'])."noaccess.htm");
    session_unset();                     // nicht bei allen Skripten
    session_destroy();
    setcookie(session_name(),"",0,"/");  // nicht bei allen Skripten
    exit;
    }

Das funktioniert auf Dutzenden von Seiten seit Monaten, teilweise Jahren einwandfrei. Seit den Umstellungen auf PHP 4.3.10 fliegt man an dieser Stelle aus der Session raus. Bei jenen (älteren) Skripte, die nur session_destroy() aufrufen, kann man mit der History-Funktion des Browsers wieder zur Anmeldung zurück; danach läuft die Session stabil, wenn man allerdings lange genug innerhalb der Seite hin- und herklickt, fällt man irgendwann doch wieder raus - das ist aber nicht reproduzierbar.

Der Effekt tritt auf mit FireFox, IE 5.0 und 6.0 unter Win2k, Mozilla 1.2, Netscape 7.0 und Opera 6.0 unter WinXP.

Wie ich verschiedentlich gelesen habe, gibt es alle möglichen Probleme mit dem Update auf 4.3.10 (das "nur" Bugfixes enthielte und völlig unproblematisch sei), und einige Provider rudern nach massiven Kundenbeschwerden wieder zurück nach der Vorgängerversion. Eine häufige Ursache scheint der Zend Optimizer zu sein, der nur in der aktuellsten Version fehlerfrei mit 4.3.10 arbeitet (scheint bei meinen Problemprovidern nicht in Anwendung zu sein).

Beide Provider untersuchen den Fall, räumen auch ein, daß es eine Flut an Beschwerden gäbe - jedoch weniger, als man zunächst angenommen hätte. Die Mühlen mahlen sehr langsam, meine Anwender steigen mir berechtigterweise aufs Dach...

Habe ich Leidensgenossen? Fällt jemand dazu etwas ein?

TIA Robert

[aames]

Hallo srob,

»»allerdings lange genug innerhalb der Seite hin- und herklickt, fällt man irgendwann doch wieder raus - das ist aber nicht reproduzierbar.

ich hab da ein ganz ähnliches problem, kanns auch reproduzieren, die session wird beendet, wenn ein link aktuelleseite.php#top aufgerufen wird, der ein popup onClick öffnet.
Die aktuelle seite bleibt erhalten, will ich aber auf eine andere zugreifen, die ebenfalls die session benötigt, muss ich mich neu einloggen.
Keine Ahnung, ob es sich hier um das geliche problem handelt, ich find das aber auch mysteriös und hab da bisher keine erklärung für.

shcöne grüße

alex

[Andreas Korthaus]

Hallo!

Das funktioniert auf Dutzenden von Seiten seit Monaten, teilweise Jahren einwandfrei. Seit den Umstellungen auf PHP 4.3.10 fliegt man an dieser Stelle aus der Session raus. Bei jenen (älteren) Skripte, die nur session_destroy() aufrufen, kann man mit der History-Funktion des Browsers wieder zur Anmeldung zurück; danach läuft die Session stabil, wenn man allerdings lange genug innerhalb der Seite hin- und herklickt, fällt man irgendwann doch wieder raus - das ist aber nicht reproduzierbar.

Gut, als erstes solltest Du nicht gleichzeitig $_SESSION und session_unset() verwenden, dazu steht im Manual: http://de3.php.net/manual/en/function.session-unset.php

Note:  If $_SESSION (or $HTTP_SESSION_VARS for PHP 4.0.6 or less) is
used, use unset() to unregister a session variable, i.e. unset
($_SESSION['varname']);.

Caution
Do NOT unset the whole $_SESSION with unset($_SESSION) as this will
disable the registering of session variables through the $_SESSION
superglobal.

Ich würde das eher wie im Manual beschrieben machen: http://de3.php.net/manual/en/function.session-destroy.php
(da steht das übrigens auch nochmal: "Note:  Only use session_unset() for older deprecated code that does not use $_SESSION.")

Aber ich weiß nicht ob es damit zu tun hat. Du müsstest mal noch genauer eingrenzen was passiert. Du sagst, "man fliegt raus"? Das heißt

if($_SESSION['cRegistriert'] != 'sstmreg')

ist TRUE? Hast Du geprüft ob es anfangs reingeschrieben wird? Wann genau fehlt denn dieser Wert wieder?

Wie ich verschiedentlich gelesen habe, gibt es alle möglichen Probleme mit dem Update auf 4.3.10 (das "nur" Bugfixes enthielte und völlig unproblematisch sei), und einige Provider rudern nach massiven Kundenbeschwerden wieder zurück nach der Vorgängerversion. Eine häufige Ursache scheint der Zend Optimizer zu sein, der nur in der aktuellsten Version fehlerfrei mit 4.3.10 arbeitet (scheint bei meinen Problemprovidern nicht in Anwendung zu sein).

Also es gibt wohl Probleme mit MSSQL, die meisten anderen Probleme haben mit der Verwendung einer veralteten Zend-Extension zu tun, meist Zend Optimizer, so dass Zend das inzwischen sogar dick auf die Startseite gesetzt hat: http://zend.com/

Du könntest also mal in der phpinfo() gucken ob überhaupt, und wenn ja welche Version dort verwendet wird.

Grüße
Andreas

[srob]

Hallo Andreas,

danke für Dein Feedback!

Gut, als erstes solltest Du nicht gleichzeitig $_SESSION und session_unset() verwenden, dazu steht im Manual: http://de3.php.net/manual/en/function.session-unset.php

Ja, wohl wahr... Ich hatte in der Vergangenheit verschiedentlich das Problem, eine Session nach Ablauf nicht "totzukriegen". Der Dreiklang (session_unset/session_destroy/setcookie) als absolut letaler Schlag gegen die Session ist ein empirisches Ergebnis - will sagen: Produkt planlosen Rumprobierens, das den gewünschten Effekt liefert ("Denn sie wissen nicht, was sie tun..."). Ich werde mich eingehender mit Deiner Anregung beschäftigen!

Aber ich weiß nicht ob es damit zu tun hat. Du müsstest mal noch genauer eingrenzen was passiert. Du sagst, "man fliegt raus"? Das heißt
if($_SESSION['cRegistriert'] != 'sstmreg')
ist TRUE?

Ja.

Hast Du geprüft ob es anfangs reingeschrieben wird?

Ja.

Wann genau fehlt denn dieser Wert wieder?

Wert wird in die Sessionvariable geschrieben, Seite mit META-Refresh wird zurückgegeben, diese leitet auf eine andere PHP-Seite, dort ist die Session noch ok. Sobald auf dieser Seite ein Link auf ein anderes Skript angeklickt wird, ist (in den aufgerufenen Skripten) die Session nicht mehr existent. Mir kam vor einer Stunde so eine Ahnung, was die Ursache für das Problem sein könnte... Da ich dazu noch experimentieren muß, berichte ich später.

Eine häufige Ursache scheint der Zend Optimizer zu sein,...
...haben mit der Verwendung einer veralteten Zend-Extension zu tun, meist Zend Optimizer,

Sag ich ja!

Du könntest also mal in der phpinfo() gucken ob überhaupt, und wenn ja welche Version dort verwendet wird.

Ich hatte das als erstes geprüft und fand keine Angaben zum Optimizer. Die technischen Hotlines bei den Providern sagten, daß es den nicht gibt.

TIA Robert

[srob]

Hallo Andreas,

ich hab's!

Aber ich weiß nicht ob es damit zu tun hat. Du müsstest mal noch genauer eingrenzen was passiert. Du sagst, "man fliegt raus"? Das heißt

Das hätte mich sicher auch auf die richtige Spur gebracht. Die Ursache für das Problem liegt hier: bei etlichen der Links, die auf den Seiten innerhalb des Session-geschützten Bereiches liegen, fehlt die Weitergabe der Session-ID per URL. Also statt:

href="blah.php?testid=4711&amp;PHPSESSID=c912c89a8ce86e3c734e4b886efd8843"

nur

href="blah.php?testid=4711"

Das liegt daran, daß die betroffenen Links nicht direkt im Quelltext stehen, sondern abhängig von Benutzerrechten et al. in PHP-Funktionen komponiert und in die HTML-Quelle eingefügt werden. In diesen Funktionen scheine ich mir über die Jahre angewöhnt zu haben, die Session-ID nicht anzuhängen. Das habe ich jetzt testender Weise nachgeholt - voilà, geht!

So recht blicke ich noch nicht durch, warum es bislang problemlos funktionierte und mit 4.3.10 plötzlich nicht mehr. Das gibt einen Berg an Arbeit, jetzt alle Leichen in diversen Kellern ausfindig zu machen und zu beseitigen! Danach wird es angezeigt sein, mehr Wissen bezüglich Session-Management aufzubauen.

Danke für die Unterstützung!

TIA Robert

[Christian Seiler]

Hallo srob.

So recht blicke ich noch nicht durch, warum es bislang problemlos funktionierte und mit 4.3.10 plötzlich nicht mehr.

Wie ist session.use_trans_sid gesetzt sowie url_rewriter.tags?

Viele Grüße,
Christian

[srob]

Hallo Christian!

Hallo srob.

Ich heiße übrigens: Robert.

Es gibt keine lokalen Änderungen gegenüber den Defaults von 1und1:

Wie ist session.use_trans_sid gesetzt

off

sowie url_rewriter.tags?

a=href,area=href,frame=src,form=fakeentry,fieldset=

Interressant - Deine Frage ließ mich noch einmal in das ChangeLog für 4.3.10 blicken, offensichtlich ist mit #22154 im Bereich von session.use_trans_sid etwas gelaufen... Woran denkst Du?

TIA Robert

[Christian Seiler]

Hallo Robert,

Ich heiße übrigens: Robert.

Ok. ;-)

Es gibt keine lokalen Änderungen gegenüber den Defaults von 1und1:

Wie ist session.use_trans_sid gesetzt

off

Tja, das ist das Problem. Deswegen wird die Session-ID nicht automatisch an alle Links angehängt (use_trans_sid ist nämlich genau die Einstellung). Ich wette, session.use_trans_sid war vorher on. Du kannst session.use_trans_sid allerdings erst in PHP 5 im Script ändern, siehe auch Bug #24693.

sowie url_rewriter.tags?

a=href,area=href,frame=src,form=fakeentry,fieldset=

Das ist OK.

Interressant - Deine Frage ließ mich noch einmal in das ChangeLog für 4.3.10 blicken, offensichtlich ist mit #22154 im Bereich von session.use_trans_sid etwas gelaufen... Woran denkst Du?

Der Bug hat nichts mit Deinem Problem zu tun. Wenn use_trans_sid deaktiviert ist, dann werden Session-IDs nicht automatisch an Links angehängt, sonst schon.

Viele Grüße,
Christian

[srob]

Hallo Christian!

Es gibt keine lokalen Änderungen gegenüber den Defaults von 1und1:

Wie ist session.use_trans_sid gesetzt
off
Tja, das ist das Problem. Deswegen wird die Session-ID nicht automatisch an alle Links angehängt (use_trans_sid ist nämlich genau die Einstellung). Ich wette, session.use_trans_sid war vorher on.

Wette halb gewonnen? Schlund sagt, daß diese Einstellung in der php.ini seit 4.3.8 off ist, vorher war sie on. Allerdings sagt man dort auch, daß man bis gestern Mittag 4.3.8 laufen hatte; somit hätte es schon vorher diese Session-Probleme geben müssen.

Du kannst session.use_trans_sid allerdings erst in PHP 5 im Script ändern, siehe auch Bug #24693.

Hast Du da irgendwie die Finger drin? Oder was ist das für ein Absender: chris_se at gmx dot net?

Ich habe mir eine lokale php.ini mit

session.use_trans_sid=1

angelegt, und es geht! Allerdings hagelt es dann auf manchen Seite eine Reihe von weiteren Fehlern, die ich mir noch nicht näher ansehen konnte... Da ich mir jetzt erst die Probleme bei den 1und1-Projekte vorgenommen habe, muß das noch warten.

hth Robert

[srob]

Ich habe mir eine lokale php.ini mit

session.use_trans_sid=1

angelegt, und es geht! Allerdings hagelt es dann auf manchen Seite eine Reihe von weiteren Fehlern, [...]

Eher Warnungen, etwa:

Warning: Missing argument 2 for naload() in /homepages/4/d17017858/htdocs/libft2.php on line 479

Da gibt es Funktionen, die ich mit einer variablen Parameterzahl aufrufe und in der Attributliste bei fehlendem Parameter keinen Defaultwert aufweisen:

function NaLoad($vnNID,$vlOld)

Jetzt:

function NaLoad($vnNID,$vlOld=false)

Schön, was sich so alles tut...

hth Robert

[Christian Seiler]

Hallo Robert,

Wette halb gewonnen? Schlund sagt, daß diese Einstellung in der php.ini seit 4.3.8 off ist, vorher war sie on. Allerdings sagt man dort auch, daß man bis gestern Mittag 4.3.8 laufen hatte; somit hätte es schon vorher diese Session-Probleme geben müssen.

Die hatten bis gestern Mittag bestimmt session.use_trans_sid auf On, welche PHP-Version sie hatten, weiß ich allerdings nicht.

Du kannst session.use_trans_sid allerdings erst in PHP 5 im Script ändern, siehe auch Bug #24693.

Hast Du da irgendwie die Finger drin? Oder was ist das für ein Absender: chris_se at gmx dot net?

Das bin ich, ja.

Viele Grüße,
Christian

[molily]

Du kannst session.use_trans_sid allerdings erst in PHP 5 im Script ändern, siehe auch Bug #24693.

Ich bin immer wieder verblüfft, wie kooperativ und kommunikativ diese Menschen doch sind.
»Es wäre sehr sinnvoll, wenn das und das möglich wäre.« - »Das ist nicht möglich.« - »Warum?« - »Weil es eben so ist.« - »Das ist aber unlogisch.« - ... - »Hier, so kann man es doch lösen.« - »Das geht so nicht.« - »Doch, man muss nur das und das machen.« - ... ... ... »Der Fehler wurde behoben.«
Das ist wirklich kafkaesk. Dass du den Nerv hast, an so etwas dranzubleiben...

Mathias