nicht angemeldet
Session geht sporadisch verloren / Teil 3 (Sessions austauschen gegen...???))
TS
AugeHallo Forum,
ich habe keine Lust mehr, nach dem Grund zu suchen, warum bei mir sporadisch immer wieder Sessions verloren gehen. Dadurch, dass es eben nur sehr sporadisch auftritt, bindet die Fehlersuche unglaublich viel Zeit und kostet Nerven.
Frage: Welche Alternative habe ich zum Sessionmanagement? Kann ich es komplett austauschen? Wenn ja, gegen was? Meine bisherige Idee wäre, lediglich eine Session-ID zu generieren und hierzu zugehörig sämtliche (ehemaligen) Sessioninhalte in eine DB zu verfrachten. Ist das viel langsamer als Sessions?
Ich hatte auch schonmal an HTML5-local storage gedacht, das ich in anderen Situationen schonmal als sehr hilfreich empfinde. Da scheint mir aber die DB-Lösung sehr viel komfortabler zu sein.
Bin für Tips oder Anregungen zum Thema weiterhin dankbar.
Lukas
-
Tach!
Frage: Welche Alternative habe ich zum Sessionmanagement? Kann ich es komplett austauschen? Wenn ja, gegen was? Meine bisherige Idee wäre, lediglich eine Session-ID zu generieren und hierzu zugehörig sämtliche (ehemaligen) Sessioninhalte in eine DB zu verfrachten. Ist das viel langsamer als Sessions?
Das kommt darauf an, wie performant der Datenbankzugriff im Vergleich zum Dateizugriff ist. Das hängt von vielen Faktoren ab und wenn das pauschal beantwortet wird kann das bei dir doch ganz anders sein.
Das Austauschen des Speichermanagements muss nicht unbedingt zum Erfolg führen, besonders dann nicht, wenn der Fehler im Arbeiten mit der Session selbst zu finden sein sollte.
Ich hatte auch schonmal an HTML5-local storage gedacht, das ich in anderen Situationen schonmal als sehr hilfreich empfinde. Da scheint mir aber die DB-Lösung sehr viel komfortabler zu sein.
Ist es denn eine Lösung, die Daten auf dem Client zu verwalten? Ist das eine SPA oder vergleichbar? Wenn die Daten im localStorage oder sessionStorage liegen, kennt der Server die nicht und kann damit nicht ohne eine explizite Übertragung arbeiten (zum Vergleich: Cookies werden implizit übertragen). Zudem kann man die auf dem Client recht leicht ändern. Für unwichtige Sachen (z.B. nach welcher Spalte die Tabellendaten sortiert sind) sind die Clientspeicherungen ok, aber bei sicherheitstechnischen wie Gruppenzugehörigkeiten hört die Freundschaft auf.
dedlfix.
-
Hallo Lukas,
ich habe keine Lust mehr, nach dem Grund zu suchen, warum bei mir sporadisch immer wieder Sessions verloren gehen. Dadurch, dass es eben nur sehr sporadisch auftritt, bindet die Fehlersuche unglaublich viel Zeit und kostet Nerven.
Nicht verzweifeln. Auch solch einen Fehler kann man finden, wenn man genug über das System weiß. Und das Wissen über das System kann man sich schrittweise beschaffen.
Du kannst doch feststellen, wann eine Session neu gestartet wurde. Hierfür kannst Du dann die Umgebungsbedingungen speichern lassen und später auswerten, ob die Session neu gestartet wurde, weil es so vorgesehen war, oder weil die alte verloren gegangen ist.
Frage: Welche Alternative habe ich zum Sessionmanagement? Kann ich es komplett austauschen? Wenn ja, gegen was? Meine bisherige Idee wäre, lediglich eine Session-ID zu generieren und hierzu zugehörig sämtliche (ehemaligen) Sessioninhalte in eine DB zu verfrachten. Ist das viel langsamer als Sessions?
Solange dir nicht klar ist, was da im Sessionmanagement überhaupt passiert, ist ein Austausch der Schicht nicht zu empfehlen. Eine Sessiondatei wird von PHP beim Start geöffnet, gesperrt, gelesen, desesialisiert und als "Array" im Speicher gehalten. Beim Script-Shutdown wird der Speicherinhalt wieder serialisiert und in die Sessiondatei zurückgeschrieben, dann die Sessiondatei wieder freigegeben.
Du könntest auf einem von Dir kontrollierbaren Server z.B. zur Analyse auch iNotify einsetzen, um festzustellen, wann und von wem die Sessiondateien angefasst werden.
Ich hatte auch schonmal an HTML5-local storage gedacht, das ich in anderen Situationen schonmal als sehr hilfreich empfinde. Da scheint mir aber die DB-Lösung sehr viel komfortabler zu sein.
Ist datenschutzrechtlich garantiert ehrlicher. Dann muss aber der gesamte Datenwust immer zwischen Client und Server hin- und her geschickt werden. In Bezug auf die Sicherheit und Stabilität des Programmes ist das negativ zu bewerten. Der User könnte dadurch Daten in die Hand bekommen, die ihn nichts angehen und die Sicherheit gefähren.
Beschreib bitte noch einmal dein System bzw. stelle eine Liste der Links auf die Threads hier im Forum zusammen, die das Problem betreffen. Dann können wir uns nochmal einlesen.
Grüße
TS-
Hi TS,
Nicht verzweifeln. Auch solch einen Fehler kann man finden, wenn man genug über das System weiß. Und das Wissen über das System kann man sich schrittweise beschaffen.
Hast schon ganz richtig erkannt. Verzweifelungstat :-)
Und sowohl Du, als auch Dedlfix haben natürlich recht, dass ggf. sicherheitsrelevante Daten auf dem Userclient nichts zu suchen haben, von der Daten hin und her Schaufelei mal ganz abgesehen. Also fliegt diese Lösung schonmal raus.
Du kannst doch feststellen, wann eine Session neu gestartet wurde. Hierfür kannst Du dann die Umgebungsbedingungen speichern lassen und später auswerten, ob die Session neu gestartet wurde, weil es so vorgesehen war, oder weil die alte verloren gegangen ist.
Irgendwie glaube ich nach wie vor nicht so recht daran, dass wirklich das Sessionmanagement daran schuld ist. Ich glaube, meine Anwendung verliert die Daten aus der Konfigurationsdatei, nur habe ich keine Ahnung, wie das überhaupt passieren kann, wenn zu Begin jeden Skriptes vorab diese Konfigurationsdatei includet wird. Ich habe jetzt nochmal Folgendes gemacht: Bisher habe ich mir eine Mail gesendet, wenn $_SESSION['Nutzer'] "empty" war. Ich habe das jetzt mal insoweit geändert, dass zuvor nochmal auf empty($irgendeineVariableAusDerKonfiguration) zu erweitern. Denn innerhalb der Konfigurationsdatei befoindet sich auch eine Variable, die für die SESSION absolut unabgingbar ist.
Beschreib bitte noch einmal dein System bzw. stelle eine Liste der Links auf die Threads hier im Forum zusammen, die das Problem betreffen. Dann können wir uns nochmal einlesen.
Gute Idee. Es geht hier mit Teil1 los: Teil 1 Und geht hier mit Teil2 weiter: Teil 2
Lukas
-
Hi,
Du kannst doch feststellen, wann eine Session neu gestartet wurde. Hierfür kannst Du dann die Umgebungsbedingungen speichern lassen und später auswerten, ob die Session neu gestartet wurde, weil es so vorgesehen war, oder weil die alte verloren gegangen ist.
Du hast recht, soweit hatte ich jetzt noch nicht gedacht, dass einige meiner Session-Neustarts ja auch berechtigt sind. Vielleicht werden doch viel weniger Sessions verloren als ich es jetzt so dramatisch sehe... Kannst Du mir mal näher erklären, was und wie ich das angehen kann? Eine Idee, festzustellen, ob die Session zurecht neu gestartet wurde, habe ich schon. Aber welche "Umgebungsbedingingen" meinst Du, soll ich speichern lassen?
Irgendwie glaube ich nach wie vor nicht so recht daran, dass wirklich das Sessionmanagement daran schuld ist. Ich glaube, meine Anwendung verliert die Daten aus der Konfigurationsdatei, nur habe ich keine Ahnung, wie das überhaupt passieren kann, wenn zu Begin jeden Skriptes vorab diese Konfigurationsdatei includet wird. Ich habe jetzt nochmal Folgendes gemacht: Bisher habe ich mir eine Mail gesendet, wenn $_SESSION['Nutzer'] "empty" war. Ich habe das jetzt mal insoweit geändert, dass zuvor nochmal auf empty($irgendeineVariableAusDerKonfiguration) zu erweitern. Denn innerhalb der Konfigurationsdatei befoindet sich auch eine Variable, die für die SESSION absolut unabgingbar ist.
Das hat sich übrigens (zumindest bisher) als Schritt in die "falsche" Richtung erwiesen, bzw. mein Verdacht wurde nicht erhärtet. Es ist also doch die Session selber, die verloren geht.
Eine allgemeine Frage habe ich auch noch:
Wenn ein User ausgelogt wird (von mir aus gerechtfertigt), den Browser nicht schließt und sich neu einloggt, generiert php dann eine neue Session-ID? Bisher gehe ich davon aus...
Lukas
-
Tach!
Wenn ein User ausgelogt wird (von mir aus gerechtfertigt), den Browser nicht schließt und sich neu einloggt, generiert php dann eine neue Session-ID? Bisher gehe ich davon aus...
Nicht solange der Client den alten Cookie mitbringt. Es wird dann gegebenenfalls eine neue Session-Datei mit demselben Namen angelegt.
dedlfix.
-
Hi dedlfix,
Nicht solange der Client den alten Cookie mitbringt. Es wird dann gegebenenfalls eine neue Session-Datei mit demselben Namen angelegt.
Ok. Gut zu wissen.
Lukas
-
-
-
-
-
Hallo Lukas,
ich habe da gerade mal eine Funktion rausgepult aus eienm Projekt, in dem ich ähnliche Probleme hatte. Vielleicht hilft sie Dir als Anregung?
function sessioncheck() { ## prüft, ob Cookies für eine Session-Führung akzeptiert wurden ## benötigt die eigene Konstante: UC_SESSION_NAME if(!defined('UC_SESSION_NAME')) return false; ## keine Vorgabe für Session-Name vorhandem. if (isset($_COOKIE[UC_SESSION_NAME])) { session_name(UC_SESSION_NAME); ## gibt es schon eine Sessiondatei zum erhaltenen Session-Cookie? if (file_exists(session_save_path() . '/sess_' . $_COOKIE[UC_SESSION_NAME])) return true; } return false; }Grüße
TS-
Hallo Lukas,
ich habe da gerade mal eine Funktion rausgepult aus eienm Projekt, in dem ich ähnliche Probleme hatte. Vielleicht hilft sie Dir als Anregung?
Hi TS,
ja, hilft. Jetzt warte ich auf den nächsten Sessionverlust, dann sehen wir weiter. Danke erstmal.
Lukas
-
ja, hilft. Jetzt warte ich auf den nächsten Sessionverlust, dann sehen wir weiter. Danke erstmal.
So, jetzt hatte ich seither 2 Logouts (übrigens beide berechtigt und gewollt, weil User zu lange untätig war). Beide Sessiondateien sind nach wie vor existent. Bei einem lieferte mir der Browser auch ein zugehöriges $_COOKIE['PHPSESSID']. Im anderen Fall war dieses ($_COOKIE['PHPSESSID']) leer oder nicht vorhanden. In beiden Fällen war die SessionID aber über session_id() auslesbar.
Frage: Kann ich hieraus etwas deuten? Wenn ja, was?
Nebenfrage: Was mir, unabhängig meines Problems der verlorenen Sessions immer wieder mal auffällt: Fast immer kann ich die Cookiedaten in Klartext auslesen. Aber ab und an, so wie eben, steht dort nur Buchstaben-/Zahlensalat drin. Als wären sie verschlüsselt. Kann mir das einer erklären?
Lukas
-
Tach!
So, jetzt hatte ich seither 2 Logouts (übrigens beide berechtigt und gewollt, weil User zu lange untätig war). Beide Sessiondateien sind nach wie vor existent. Bei einem lieferte mir der Browser auch ein zugehöriges $_COOKIE['PHPSESSID']. Im anderen Fall war dieses ($_COOKIE['PHPSESSID']) leer oder nicht vorhanden. In beiden Fällen war die SessionID aber über session_id() auslesbar.
Frage: Kann ich hieraus etwas deuten? Wenn ja, was?
Ja klar, du kannst da hineininterpretieren, was immer du willst. Zum Beispiel könnte man sehen (eher im Sinne, wie Wahrsager etwas sehen), dass dem zweiten Browser der Session-Cookie abgelaufen war. Aber das kann auch ganz andere Ursachen haben, warum der den Cookie nicht mitsendet, oder warum der auf dem Weg verlorenging.
Dass die session_id() auslesbar war, liegt wohl am vorherigen session_start(), welches eine ID aus den entsprechenden Requestdaten nimmt oder sie erzeugt.
Nebenfrage: Was mir, unabhängig meines Problems der verlorenen Sessions immer wieder mal auffällt: Fast immer kann ich die Cookiedaten in Klartext auslesen. Aber ab und an, so wie eben, steht dort nur Buchstaben-/Zahlensalat drin. Als wären sie verschlüsselt. Kann mir das einer erklären?
Das kann die jeweilige Anwendung machen wie sie will. Nicht immer ist Unlesbares verschlüsselt, es kann auch eine Zufallszeichenfolge sein, wie bei der Session-ID.
dedlfix.
-
Hi dedlfix,
Ja klar, du kannst da hineininterpretieren, was immer du willst. Zum Beispiel könnte man sehen (eher im Sinne, wie Wahrsager etwas sehen), dass dem zweiten Browser der Session-Cookie abgelaufen war. Aber das kann auch ganz andere Ursachen haben, warum der den Cookie nicht mitsendet, oder warum der auf dem Weg verlorenging.
Naja, zumindest ist das gut möglich, weil zwischen den beiden Seitenaufrufen in diesem Fall mehr als 24 Std. vergangen waren.
Dass die session_id() auslesbar war, liegt wohl am vorherigen session_start(), welches eine ID aus den entsprechenden Requestdaten nimmt oder sie erzeugt.
Ja, ok.
Nebenfrage: Was mir, unabhängig meines Problems der verlorenen Sessions immer wieder mal auffällt: Fast immer kann ich die Cookiedaten in Klartext auslesen. Aber ab und an, so wie eben, steht dort nur Buchstaben-/Zahlensalat drin. Als wären sie verschlüsselt. Kann mir das einer erklären?
Das kann die jeweilige Anwendung machen wie sie will. Nicht immer ist Unlesbares verschlüsselt, es kann auch eine Zufallszeichenfolge sein, wie bei der Session-ID.
Klar, was ich aber nicht verstehe: Mal so, mal so, bei ein und derselben Anwendung?
Lukas
-
Hallo
Nebenfrage: Was mir, unabhängig meines Problems der verlorenen Sessions immer wieder mal auffällt: Fast immer kann ich die Cookiedaten in Klartext auslesen. Aber ab und an, so wie eben, steht dort nur Buchstaben-/Zahlensalat drin. Als wären sie verschlüsselt. Kann mir das einer erklären?
Das kann die jeweilige Anwendung machen wie sie will. Nicht immer ist Unlesbares verschlüsselt, es kann auch eine Zufallszeichenfolge sein, wie bei der Session-ID.
Klar, was ich aber nicht verstehe: Mal so, mal so, bei ein und derselben Anwendung?
Cookies werden, auch von einer Anwendung, zu unterschiedlichen Zwecken erzeugt. Mal ist es das schon erwähnte Session-Cookie, in dem nur die kryptisch anmutende ID steht, mal sind es „echte“ Nutzdaten, wie die zuletzt aufgerufene Seite oder der Zeitpunkt des Aufrufs oder etwas ganz anderes. Manche Inhalte lassen sich mit einem Blick zuordnen, andere erscheinen kryptisch, selbst wenn sie es tatsächlich nicht sind.
Was bei dir konkret der Fall ist, können wir ohne Kenntnis der Inhalte und der dazugehörigen Programmfunktionen nicht wissen. Auf der anderen Seite und allerdings ist es mit an Sicherheit grenzender Wahrscheinlichkeit keine gute Idee, diese konkreten Inhalte hier zu veröffentlichen. Für den Programmcode gilt das nur bedingt, aber nur mit beiden Informationen kann ein Außenstehender mit Sicherheit sagen, welche Infos in jedem der Cookies steht.
Tschö, Auge
--
Wo wir Mängel selbst aufdecken, kann sich kein Gegner einnisten.
Wolfgang Schneidewind *prust*-
HI Auge,
Cookies werden, auch von einer Anwendung, zu unterschiedlichen Zwecken erzeugt. Mal ist es das schon erwähnte Session-Cookie, in dem nur die kryptisch anmutende ID steht, mal sind es „echte“ Nutzdaten, wie die zuletzt aufgerufene Seite oder der Zeitpunkt des Aufrufs oder etwas ganz anderes. Manche Inhalte lassen sich mit einem Blick zuordnen, andere erscheinen kryptisch, selbst wenn sie es tatsächlich nicht sind.
Wundert mich trotzdem. Mal sind alle Cookies kryptisch, mal sind alle in Klartext.
Na ok, ich denke, es ist nicht mit dem Hauptproblem ursächlich zusammenhängend, daher laß ich es einfach im Raum stehen...
Danke Dir für Deinen Hinweis,
Lukas
-
-
Hallo Lukas,
Naja, zumindest ist das gut möglich, weil zwischen den beiden Seitenaufrufen in diesem Fall mehr als 24 Std. vergangen waren.
puh
24 Stunden sind eine lange Zeit für eine Session unter derselben Session-ID.
Ich habe irgendwie immer noch das Bauchgefühl, dass Du zwischen quasi-physischer Sessionschicht (Cookie, Sessiondatei, Garbage-Controller, etc.) und Login noch nicht sauber unterschieden hast und die Probleme daher rühren...
Alleine der quasi-physische Teil beinhaltet mindestens einen Roundturn und setzt deshalb eine strenge Reihenfolge der Schritte voraus. Solange man das nicht verinnerlicht hat, bleibt das emulierte "Sessionmanagement" mit einer Scriptsprache im Client-Server-Umfeld (HTTP/s) ein Buch mit mindestens 3 Siegeln.
Darunter liegt dann auch immer noch die TCP/IP-Session, die auch noch Berücksichtigung verlangt, wenn es um das Fertigschreiben von Dateien (z. B. bei Userabort) usw. geht...
Grüße
TS-
Hallo TS,
Naja, zumindest ist das gut möglich, weil zwischen den beiden Seitenaufrufen in diesem Fall mehr als 24 Std. vergangen waren.
puh
24 Stunden sind eine lange Zeit für eine Session unter derselben Session-ID.
Naja, was will ich machen. Ich habe dem Cookie 3800 Sek. mitgegeben, somit sollte der Garbage Collector sich drum kümmern. Ok, wenn das mein Hauptproblem wäre, würde ich mich selber ums Löschen kümmern. Ich denke aber, es ist nicht mein Hauptproblem. Und die 24 Std. (oder vielleicht warens auch nur 20 oder 18, es war jedenfalls vom Vortag) ist einfach erklärt. Der User läßt den Rechner laufen ohne ihn auszuschalten und am nächsten Tag will er weiter im System arbeiten...
Ich habe irgendwie immer noch das Bauchgefühl, dass Du zwischen quasi-physischer Sessionschicht (Cookie, Sessiondatei, Garbage-Controller, etc.) und Login noch nicht sauber unterschieden hast und die Probleme daher rühren...
Kannst Du hier etwas näher drauf eingehen? Ich verstehe nicht genau, was Du meinst.
Alleine der quasi-physische Teil beinhaltet mindestens einen Roundturn und setzt deshalb eine strenge Reihenfolge der Schritte voraus. Solange man das nicht verinnerlicht hat, bleibt das emulierte "Sessionmanagement" mit einer Scriptsprache im Client-Server-Umfeld (HTTP/s) ein Buch mit mindestens 3 Siegeln.
Auch hier bleibst Du sehr abstrakt. Warum denn? Welche Schritte meinst Du denn konkret? Was meinst Du mit "einem Roundturn"?
Lukas
-
Hallo Lukas,
Naja, zumindest ist das gut möglich, weil zwischen den beiden Seitenaufrufen in diesem Fall mehr als 24 Std. vergangen waren.
puh
24 Stunden sind eine lange Zeit für eine Session unter derselben Session-ID.
Naja, was will ich machen. Ich habe dem Cookie 3800 Sek. mitgegeben, somit sollte der Garbage Collector sich drum kümmern. Ok, wenn das mein Hauptproblem wäre, würde ich mich selber ums Löschen kümmern. Ich denke aber, es ist nicht mein Hauptproblem.
3800 Sekunden sind ja nur ca. 63 Minuten. Der "Session-Cookie" sollte nur mittels session_start() erzeugt werden. Und dann hat er eine Gültigkeitsdauer von 0 (Null Sekunden). Das führt dazu, dass er vom Browser beim Schließen der Instanz besseitigt wird (werden sollte).
Die Gültigkeit der physischen Session (also der Sessiondatei) auf dem Server wird nur von der Konfigurationseinstellung "session.gc_maxlifetime" bestimmt (im wesentlichen...) bzw. bei Debian-Hosts von der Einstellung für den Cron-Job.
Dazu gibt es leider ganz viel zu lesen:
https://debianforum.de/forum/viewtopic.php?f=8&t=128855
Der Cron-Job holt sich also noch Einstellungen von PHP. Ich steige da leider selber noch nicht ganz durch, inwieweit Virtual-Host-Umgebungen mit veränderten session.save_path berücksichtigt werden...
Jedenfalls solltest Du die session.gc_maclifetime hochsetzen, wenn dir die Sessiondateien nicht lange genug zur Verfügung stehen. Allerdings beinhaltet eine höhere Einstellung auch immer mehr Sicheheitsrisiko.
Grüße
TS-
Ich steige da leider selber noch nicht ganz durch, inwieweit Virtual-Host-Umgebungen mit veränderten session.save_path berücksichtigt werden...
Dann lass Dir helfen. Ich habe meine ärmlichen Englisch- und Shellkenntnisse mal benutzt und die Skripte verschiedener Linux- und PHP-Versionen gelesen.
In allen von mir gefundenen Varianten werden nur php.ini in bzw. unterhalb von /etc/php oder /etc/php5 berücksichtigt. Teilweise wird nach bestimmten Unterverzeichnissen (z.B. apache2, php[5], php[5]-fpm gesucht.) Teilweise wird der Pfad zum sessionsavedor UND die maxlifetime aus dort befindlichen php.ini-Dateien ausgelesen. Teilweise wird php mit der oder den verschiedenen php.ini gestartet und mit Skriptlets gefüttert, welche die Einstellungen zurückgeben.
Teilweise findet das in /usr/lib/php[5]/maxlivetime UND /usr/lib/php[5]/sessionclean, teilweise NUR in /usr/lib/php[5]/sessionclean statt.
In einer anderen gefundenen Variante ist der Pfad zum Session-Dir fest in /usr/lib/php5/sessionclean notiert.
Fazit:
In allen Varianten gilt also: Was nicht in /etc/php[5]/php.ini oder /etc/php[5]/*/php.ini steht wird nicht berücksichtigt. Das ist auch der kleinste Nenner.
-
Tach!
Der Cron-Job holt sich also noch Einstellungen von PHP. Ich steige da leider selber noch nicht ganz durch, inwieweit Virtual-Host-Umgebungen mit veränderten session.save_path berücksichtigt werden...
Es gelten immer die zur Laufzeit geladen Werte aus php.ini nebst anderen Quellen. Welche das konkret sind, kann man durch einen Aufruf von phpinfo() herausbekommen. Dazu kommen noch .user.ini oder .htaccess. Obendrein kann das Script auch noch selbst Hand anlegen und für dessen Laufzeit andere Werte nehmen (session_*()-Funktionen ini_set()). Der Garbage Collector von PHP läuft mit den Einstellungen, die zum Zeitpunkt von session_start() aktuell waren.
Andere Tools, wie spezielle Aufräumprogramme in diversen Linux-Distributionen, laufen mit deren Einstellungen, wo auch immer sie die herhaben. Wenn es PHP-Scripts sind, dann gilt sinngemäß der obige Absatz. Die werden dann vermutlich so aufgerufen, das sie eine zentrale Konfiguration berücksichtigen (was man aus dem Aufruf herauslesen können sollte) und individuelle Änderungen auf nicht-zentraler Ebene ignorieren. Was sollen sie auch sonst machen? Die können ja schlecht die gesamte Webserverkonfiguration und alle Script-Inhalte durchforsten, um alle Individ- und Eventualitäten zu finden. -- Wenn es keine PHP-Script sind, die den PHP-GC nehmen, sondern eine eigene Auräum-Routine anwerfen, dann hilft dir nur Code-Analyse.
dedlfix.
-
Hallo TS, dedlfix und alle anderen,
ich nutze in meinem System öfter mal header("location..."). Ist es korrekt, dass man zuvor den Session Write Prozess manuell setzen sollte "session_write_close();"? So wie hier gesagt...
Lukas
-
Hallo Lukas,
ich nutze in meinem System öfter mal header("location..."). Ist es korrekt, dass man zuvor den Session Write Prozess manuell setzen sollte "session_write_close();"? So wie hier gesagt...
Nein, das ist Bullshit. PHP macht einen exclusive lock auf Session-Files um konkurrierende Zugriffe und race conditions zu verhindern; wenn die Session von einem Script geöffnet wurde, dann warten alle anderen Requests auf das Ende dieses Script (oder bis du
session_write_close()aufrufst, das löst den exklusiven Lock auch).LG,
CK-
Hi CK,
Nein, das ist Bullshit. PHP macht einen exclusive lock auf Session-Files um konkurrierende Zugriffe und race conditions zu verhindern; wenn die Session von einem Script geöffnet wurde, dann warten alle anderen Requests auf das Ende dieses Script (oder bis du
session_write_close()aufrufst, das löst den exklusiven Lock auch).Danke für den Hinweis, ich konnte mir das auch nict vorstellen, deshalb die Nachfrage. Aber kannst mal nach suchen, das findest Du wirklich häufig als Tip im Netz.
Lukas
-
-
Hallo und guten Morgen,
ich nutze in meinem System öfter mal header("location..."). Ist es korrekt, dass man zuvor den Session Write Prozess manuell setzen sollte "session_write_close();"? So wie hier gesagt...
Gar nicht so uninteressant die Frage :-)
Wie ist der zeitliche Ablauf? Frühestens nach Beginn der Scriptlaufzeit fird die Session gestartet, also die Sessiondatei auch gesperrt für andere Requests. Da die Header zuerst ausgegeben werden, könnte bei lange laufenden Scripten also schon mal ein Location-Header beim Browser landen, obwohl das Script auf dem Server noch läuft. Wann reagiert der Browser nun auf diese Umleitungsbitte? Muss dazu erst die Verbindung geschlossen worden seín (also das Script beendet), oder reagiert er sofort, wenn der Header (ggf. alle Header) bei ihm angekommen sind? Wie könnte man das testen?
Denn wenn der Browser sofort nach Eintreffen des Header-Blocks mit der Auswertung deer Header und damit der Umleitung beginnen würde, würde er damit auch die Verbindung kappen. Das würde im Script zu einem User-Abort führen. Ggf. noch nicht fertig geschriebene Daten würden dann fehlen.
Nach meinem Verständnis müssten die Sessiondaten aber trotz verfrühtem Script-Shutdown noch geschrieben werden, denn diese Funtionalität ist im Script-Shutdown-Prozess verankert.
Was allerdings fehlen könnte, wären einzelne Session-Elemente, deren Inhalt erst nach dem vom Browser feranlassten Script-Shutdown geändert werden würden. Der Session-Save-Prozess kann ja immer nur das aktuelle Abbild abspeichern.
Ein "ignore_user-abort()" müsste dann allerdings auch helfen. Dafür müsste nbur sichergestellt werden, dass keine Zombies erzeugt werden, also Endlosschleifen bei ausgeschaltetem Timeout hinterlassen werden.
Grüße
TS-
Hallo TS,
Nach meinem Verständnis müssten die Sessiondaten aber trotz verfrühtem Script-Shutdown noch geschrieben werden, denn diese Funtionalität ist im Script-Shutdown-Prozess verankert.
Exakt.
Was allerdings fehlen könnte, wären einzelne Session-Elemente, deren Inhalt erst nach dem vom Browser feranlassten Script-Shutdown geändert werden würden. Der Session-Save-Prozess kann ja immer nur das aktuelle Abbild abspeichern.
Nein. Nach einem User-Abort passiert nichts mehr in den Session-Daten, denn - hence the name - das Script wird abgebrochen. Außer man nutzt
ignore_user_abort(), dann wird das Script aber auch nicht abgebrochen, die Session nicht geschlossen und der Lock nicht aufgehoben und alle anderen warten.LG,
CK-
Hallo und guten Morgen,
Was allerdings fehlen könnte, wären einzelne Session-Elemente, deren Inhalt erst nach dem vom Browser veranlassten Script-Shutdown geändert werden würden. Der Session-Save-Prozess kann ja immer nur das aktuelle Abbild abspeichern.
Nein. Nach einem User-Abort passiert nichts mehr in den Session-Daten, denn - hence the name - das Script wird abgebrochen. Außer man nutzt
ignore_user_abort(), dann wird das Script aber auch nicht abgebrochen, die Session nicht geschlossen und der Lock nicht aufgehoben und alle anderen warten.Das beantwortet noch nicht die Fragen, wann ein Header am Client ausgewertet wird und ob die Auswertung eines Location-Headers am Client auf dem Server als User-Abort wahrgenommen wird.
Und wenn ich zu http://php.net/session_register_shutdown recherchiere, scheint diese Funktion ja neu zu sein. Das session_write_close() scheint also doch nicht Bestandteil des Shutdown-Stapels gewesen zu sein?
Demnach war Lukas also doch schon nahezu auf dem richtigen Weg?
Grüße
TS-
Hallo TS,
Das beantwortet noch nicht die Fragen, wann ein Header am Client ausgewertet wird und ob die Auswertung eines Location-Headers am Client auf dem Server als User-Abort wahrgenommen wird.
Keine Ahnung, wenn dich das interessiert probiere es halt aus. Für die Frage ist es irrelevant.
Und wenn ich zu http://php.net/session_register_shutdown recherchiere, scheint diese Funktion ja neu zu sein.
Neu? Die Funktion ist mit 5.4.0 eingeführt worden - das ist von 2012 und schon einige Zeit EOL. Alt wäre hier die richtigere Bezeichnung.
Das session_write_close() scheint also doch nicht Bestandteil des Shutdown-Stapels gewesen zu sein?
Doch. Vorher wurde das IIRC über die Funktion
register_shutdown_functiongehandhabt.Demnach war Lukas also doch schon nahezu auf dem richtigen Weg?
Nope, sorry :)
LG,
CK
-
-
-
-
-
-
-
-
-
-
-
-