session wird trotz geöffneten browserfenster geschlossen

[Roger]

hallo!

ich habe ein problem, und zwar wird eine session gelöscht, wenn ich längere zeit (ca. 15min) nicht im browserfenster aktiv bin.
wenn ich dann die session mit if (!isset($_SESSION["kunde"]["name"])) abfrage, bekomme ich ein false zurück.
bei den session werten (maxlifetime, etc) wurde nicht geändert. das sind die standardwerte. ist meine abfrage vielleicht fehlerhaft? wenn nicht, wie kann ich mein problem umgehen?

gruß.
roger.

[Tom]

Hello,

maxlifetime ist Standard = 1440 sec = 24 Minuten. Allerdings weiß ich nicht, ob das dann auch die minlifetime ist, oder ob der GC (Garbage Colletcor) nicht schon früher aktiv wird.

Die Alternative wäre ja, die Sessions erst nach der Registrieung (Login) des Users zuzuteilen und dann immer wieder die Selbe zu nehmen. Damit kein Sicherheitsloch entsteht, übermittelt man dann einen zusätzlichen "Login-Cookie", der in der Session eingetragen wird und bei jedem Zugriff geprüft wird.

Damit der GC die Sessiondateien nicht löscht, musst Du einfach nur das Leserecht (r) auf das Session-Verzeichnis entziehen, nicht das Pfad-Recht (x)!

Dann kann der GC nicht mehr das Verzeichnis browsen und lässt die Sessiondateien in Ruhe.

Grüße

Tom

[wahsaga]

hi,

maxlifetime ist Standard = 1440 sec = 24 Minuten. Allerdings weiß ich nicht, ob das dann auch die minlifetime ist, oder ob der GC (Garbage Colletcor) nicht schon früher aktiv wird.

sessions haben AFAIK keine solche "minlifetime".
der GC sollte sich hüten, eine noch aktive session - die also nicht explizit beendet wurde, oder ihre maxlifetime überschritten hat - einfach so wegzuputzen.

gruss,
wahsaga

[Tom]

Hello,

maxlifetime ist Standard = 1440 sec = 24 Minuten. Allerdings weiß ich nicht, ob das dann auch die minlifetime ist, oder ob der GC (Garbage Colletcor) nicht schon früher aktiv wird.

sessions haben AFAIK keine solche "minlifetime".
der GC sollte sich hüten, eine noch aktive session - die also nicht explizit beendet wurde, oder ihre maxlifetime überschritten hat - einfach so wegzuputzen.

Ja, das sollte man denken. Allerdings habe ich dieses hibbelige Verhalten des GC auch schon ein paarmal feststellen können. Vielleicht hat PHP da noch einen Bug und keiner hat's wirklich gemerkt bisher?

Andersherum liegen die Sessiondateien manchmal auch noch 24 Stunden später im Verzeichnis. Man sollte daher explizit durch session_destroy() und setCookie("PHPSESSID"); (<-- oder besser session_name()) die Session vernichten.

...tbc...

Grüße

Tom

[Roger]

Hello,

ups, ich dachte bisher, dass es 1440 minuten sind (wäre eigentlich erklärbar, da es eine runde anzahl stunden (24) zurückgibt) - nicht sekunden.

kann ich denn diesen zeitwert nicht hochsetzen, das müsste doch eigentlich mein problem schon beheben? (manuell in der php.ini, oder per befehl?)
 mit "ca. 15min" kann nat. auch 24min sein... :S

gruß.
roger.

[wahsaga]

hi,

kann ich denn diesen zeitwert nicht hochsetzen, das müsste doch eigentlich mein problem schon beheben? (manuell in der php.ini, oder per befehl?)

natürlich kannst du ihn "hochsetzen" - für was sollen konfigurationsoptionen denn sonst gut sein? :-)

der genau name ist session.gc_maxlifetime - suche in deiner php.ini danach.

gruss,
wahsaga

[Tom]

Hello,

natürlich kannst du ihn "hochsetzen" - für was sollen konfigurationsoptionen denn sonst gut sein? :-)

der genau name ist session.gc_maxlifetime - suche in deiner php.ini danach.

Soweit ich mich erinnere musst Du aber den Apachen (bzw PHP) danach neu starten, damit er's merkt.

Grüße

Tom

[wahsaga]

hi,

Soweit ich mich erinnere musst Du aber den Apachen (bzw PHP) danach neu starten, damit er's merkt.

das ist m.W. bei jeder änderung an der php.ini der fall.

gruss,
wahsaga

[Roger]

hi,

yo danke. lol. so ganz newbie bin ich nun auch wieder nicht :) aber besser man erwähnt es, bevor es einem wieder vorgehalten wird.

ich suche aber nach dem befehl, den man benutzen kann um die max_lifetime bei der gestarteten session hochzusetzen. wenn ich das in der ini ändere, dann mach ich das ja für alle seiten, die (virtuell) auf dem server sind. mir wäre es aber lieber, wenn ich das nur für die eine seite/domain/homepage machen könnte...

gruß.
roger.

[Thomas Luethi]

Hallo,

ich suche aber nach dem befehl, den man benutzen kann um die max_lifetime bei der gestarteten session hochzusetzen. wenn ich das in der ini ändere, dann mach ich das ja für alle seiten, die (virtuell) auf dem server sind. mir wäre es aber lieber, wenn ich das nur für die eine seite/domain/homepage machen könnte...

In der Tabelle
http://www.php.net/manual/de/ref.session.php#AEN86124
steht:
Bezeichnung:      session.gc_maxlifetime
Grundeinstellung: "1440"
Aenderbar:        PHP_INI_ALL

Somit sollte es AFAIK moeglich sein, den Wert von einem
Script aus mit ini_set() zu aendern.
http://www.php.net/manual/de/function.ini-set.php

Man moege mich korrigieren, wenn ich damit falsch liege...

Gruesse,

Thomas

[Tom]

Hello,

In der Tabelle
http://www.php.net/manual/de/ref.session.php#AEN86124
steht:
Bezeichnung:      session.gc_maxlifetime
Grundeinstellung: "1440"
Aenderbar:        PHP_INI_ALL

Somit sollte es AFAIK moeglich sein, den Wert von einem
Script aus mit ini_set() zu aendern.
http://www.php.net/manual/de/function.ini-set.php

Dann müsste er das aber machen, BEVOR er die Session startet, da durch session_start() auch der GC angestoßen wird. Sofern meine Logic stimmt, würde _dieses_ Script dann nur Sessions killen (lassen), bei denen die entsprechend eingestellte maxlifetime abgelaufen ist.  Das hat also nix mit der eigenen Session zu tun.

Da die Lebensdauer nur mit dem LastTouch der Datei verglichen wird, gibt es mMn keine Möglichkeit, eine einzelne Session länger leben zu lassen. Alle gleich, oder gar nicht killen.

Ich bezweifle auch, dass die Instanz des GC tatsächlich was von der INI-Veränderung im Script mitbekommt. Müsste man mal in den Quellcode von PHP reinschauen.

Grüße

Tom

[Roger]

Hallo,

muss ich dann ini_set() vor jedem session_start() ausführen, oder reicht es, beim ersten mal den aufruf zu machen?

ps: hab's dann doch in der ini geändert (5400s). mich interessiert aber dennoch die set_ini lösung...

gruß.
roger.

[TomIRl]

Wahsaga,
Mal ne Frage:
Kannst Du bei Dir auf dem Server die php.ini einfach so editieren?
Die meisten Provider haben doch da relativ restriktive Einschränkungen.
Warum Du nicht?

Tom

[wahsaga]

hi,

Kannst Du bei Dir auf dem Server die php.ini einfach so editieren?

natürlich, mein lokaler webser auf dem ich teste, ist eben _mein_ lokaler webserver.

Die meisten Provider haben doch da relativ restriktive Einschränkungen.
Warum Du nicht?

natürlich habe ich die bei meinem provider auch.

gruss,
wahsaga

[TomIRL]

»

natürlich, mein lokaler webser auf dem ich teste, ist eben _mein_ lokaler webserver.

Naja gut :-) ich hab mich immer nur gewundert, was bei mir lokal geht muß ja auf meinem Server nicht unbedingt gehen.

natürlich habe ich die bei meinem provider auch.

Alles kalr ich dachte Du leistest Dir den Luxux einen Server Dein eigen zu nennen, weil ist ja doch relativ teuer.
Aber jetzt ists mir klar.

Viele Grüße aus Berlin

TomIRL

[wahsaga]

hi,

natürlich, mein lokaler webser auf dem ich teste, ist eben _mein_ lokaler webserver.
Naja gut :-) ich hab mich immer nur gewundert, was bei mir lokal geht muß ja auf meinem Server nicht unbedingt gehen.

nein. behauptet ja auch keiner.
auf deinem eigenen server kannst du die konfiguration ändern, wie es beliebt.
auf dem deines providers musst du halt mit dem klar kommen, was dein provider dich machen lässt.

das ändert aber nichts daran, das der beschriebene weg der übliche ist, um die einstellung zu ändern.
wenn der provider das nicht zulassen will, wird er seine gründe haben.

Alles kalr ich dachte Du leistest Dir den Luxux einen Server Dein eigen zu nennen, weil ist ja doch relativ teuer.

diesen "luxus" werden sich sicher einige der forumsteilnehmer leisten, die grössere projekte ihr eigenen nennen.
meine seite ist nur ein kleines privates blog, ein eigener server wäre als massiver overkill ;-)

gruss,
wahsaga

[Andreas-Lindig]

Hallo Roger,

Ich habe ein ähnliches Prblem. Das passiert nach einiger Zeit und zwar besonders (oder nur?), wenn ein anderer Client auch auf die Anwendung (allerdings mit anderer Session) zugreift.

bisher vergeblich gesucht. Diese max_lifetime Werte u.ä. (mir fallen die Variablen im Moment nicht ein) stehen jedenfalls bei mir auch absolut auf Standard-Werten und Änderungen haben nichts an dem Verhalten geändert.

Wird bei Dir die Session ganz gelöscht oder nur deren Inhalt?

Gruß, Andreas

[e7]

Hi,

ich verstehe euer Problem nicht - der Webserver bzw. PHP schließt die Session, wenn 24 Minuten kein Kontakt mehr zum Client war, was auch bei geöffneten Browserfenstern im Normallfall so ist. PHP hat in diesem Falle anzunehmen, dass der Nutzer nicht mehr auf der Seite surft, und schließt somit die Session, um Speicher freizugeben sowie Missbrauch zu verhindern.

Ein ähnliches Verhalten zeigen auch Freemail-Dienste, die über die WEboberfläche abgefragt werden - wenn ihr die Seite meinetwegen 1 Stunde im Browser "verschimmeln" lasst, und dann auf reloadet, wird euch eine Passwortabfrage vorgesetzt. Alles zu gunsten der Sicherheit.

Falls ihr dieses durchaus sinnvolle Verhalten umgeht wollt - entweder, wie gesagt die Lifetime in der php.ini hochsetzen, oder ganz auf die eingebauten Funktionen zur Session-Verwaltung verzichten und einfach ein eigenes System aufbauen. Ist gar nicht mal so schwer...

E7

[Tom]

Hello,

ich verstehe euer Problem nicht - der Webserver bzw. PHP schließt die Session, wenn 24 Minuten kein Kontakt mehr zum Client war, was auch bei geöffneten Browserfenstern im Normallfall so ist. PHP hat in diesem Falle anzunehmen, dass der Nutzer nicht mehr auf der Seite surft, und schließt somit die Session, um Speicher freizugeben sowie Missbrauch zu verhindern.

Hier war aber von 15 Minuten die Rede, obwohl maxlifetime noch auf 1440 stand...

Und das passt eben nicht.

Grüße

Tom

[Andreas-Lindig]

Hier war aber von 15 Minuten die Rede, obwohl maxlifetime noch auf 1440 stand...

so ist es. Bei mir manchmal schon nach 3(!) Minuten. MANCHMAL! völlig undurchschaubar.

Gruß, Andreas