[PHP/ZF] Sessions blijven niet staan

[Anoniem: 298643]

Goedemiddag,

Ik heb een webapp die gebruik maakt van Zend_Auth (Zend Framework) icm Zend_Session om login te autoriseren en op te slaan. Het gaat allemaal prima, maar over een voor mij nog niet bekende tijd word de sessie vernietigd. (daar ga ik vanuit, aangezien de PHPSESSID nog steeds in de client staat als cookie, en _SESSION niets meer print) Ik heb onderhand al de onderstaande opties ingesteld.

Zend_Session::setOptions(
array(
'remember_me_seconds' => time() + 10368000,
'cookie_lifetime' => time() + 10368000,
'gc_maxlifetime' => 2592000
)
);

Het leek mij erop dat de garbage collector de sessies verwijderde. Maar nu ik dit heb ingesteld lijkt het nog steeds niet goed te gaan. Weet iemand of het voldoende is om de maxlifetime in de Zend_Session in te stellen (voor Zend_Session::start()) ? Of moet ik dit nog echt in php.ini veranderen ofzo?

Alvast mijn dank, ben onderhand mijn haren uit m'n kop aan het trekken door dit probleem.

[Voor 5% gewijzigd door Anoniem: 298643 op 01-06-2011 12:59]

[Precision]

Heb je relevante code zodat we kunnen zien of je niet ergens iets mist?

[Anoniem: 298643]

Dat zou ik wellicht vanavond even kunnen fixen, maar nu nog niet. Ben op kantoor en kan ik niet echt even een van huis uit projectje hier uitgebreid gaan openen.

Overigens, weet je misschien wel of de GC settings in Zend_Session zetten voldoende is? (ik gebruik trouwens alleen bepaalde componenten van Zend Framework, niet de complete application model.

P.s. ik vind de beschikbare documentatie van Zend_Auth niet echt bepaald duidelijk...

[Anoniem: 146875]

Kijk eens of er wel sessiebestanden aangemaakt worden. Sessie zijn gewoon bestandjes ergens in een directory dus als die verdwijnen (of nooit aangemaakt worden) weet je al meer

[Anoniem: 298643]

Het lijkt me dat die sowieso aangemaakt worden, want zodra ik inlog en ik print _SESSION, zie ik gewoon de variabel die ik in mijn Zend_Auth storage heb gezet middels ->write(..); Zou _SESSION af kunnen wijken met de echte sessies bestanden? Daarnaast, ik blijf ook wel een tijdje gewoon ingelogd (meerdere urenen meerdere browser sessies).

[thioz]

@Niels ... $_SESSION is eigenlijk gewoon de inhoud van het bestand.

Maar het is wel normaal dat je sessie verloopt na een bepaalde tijd van inactiviteit ...

http://framework.zend.com...l_session_management.html

hier staat best handige info over de eventuele global instellingen

[Anoniem: 298643]

thioz schreef op woensdag 01 juni 2011 @ 16:11:
@Niels ... $_SESSION is eigenlijk gewoon de inhoud van het bestand.

Maar het is wel normaal dat je sessie verloopt na een bepaalde tijd van inactiviteit ...

http://framework.zend.com...l_session_management.html

hier staat best handige info over de eventuele global instellingen

Bedankt voor je reactie thioz,

Ja, dat bedoelde ik dus ook. Dus daarmee vang ik dus in feite af dat ik nog bestanden moet gaan checken...

Dat mijn sessies vervallen, begrijp ik, maar als ik de gc_maxlifetime op 2592000 zet, moet ik het daarmee toch afvangen? Dan kan de garbage collector toch niet zomaar binnen een dag al sessies gaan lopen verwijderen?
EDIT: voor de duidelijkheid, dit laatste doe ik dus via Zend_Session::setOptions(), vlak voor ik in mijn bootstrapper Zend_Session::start() aanroep

[Voor 8% gewijzigd door Anoniem: 298643 op 01-06-2011 16:49]

[thioz]

@NIels,

Ikzelf vindt het hele GC verhaal een beetje 'vreemd' ik zie de sessiedata niet echt als 'garbage' namelijk ... tenzij deze niet meer gebruikt wordt.

in principe zou het volgende moeten werken

ini_set(‘session.gc_maxlifetime’, $maxlifetime);

Deze zou echter alleen voor het initieren van je sessie werken.

Ik vind trouwens een dag wel erg lang voor een sessie en zou dan eerder overgaan tot het bijhouden van 'remember me' cookie.

[Anoniem: 298643]

Ja, daar is de garbage collector voor, lijkt mij. Want uit documentatie begrijp ik, dat de "gc_maxlifetime" staat voor het aantal seconden inactiviteit van een sessie voordat de garbage collector hem mag verwijderen. Zo zijn er nog twee settings voor de GC: probability en dividor. Wat standaard op 1 en 100 staat, waardoor de kans 1 op 100 word dat de GC gerunt word bij session_start().

Wat bedoel je precies met een "remember me" cookie?

Edit:
Ik heb geloof ik een grove fout begaan met het gebruiken van "Zend_Session::rememberMe()" na "Zend_Session::start()". Ik verwacht dat na deze aanpassing al het één en ander opgelost is. Daarnaast heb ik ook nog voor de zekerheid de garbage collector vars aangepast a.d.h.v. .htaccess:

php_value session.gc_maxlifetime 2592000
php_value session.gc_divisor 100 (stond op 1000, vond ik een beetje overdreven, kans van 1 op 1000)

Edit 2:
Ik zie nu ook ineens regeneratie in het PHPSESSID, wat eerst niet gebeurde. Wat mij lijkt dat de sessie nu bij elke aanvraag opnieuw word gekoppeld. Lijkt mij dat rememberMe() voor start() toch de oplossing was.

Zodra je PHPSESSID niet word geregenereerd, veranderd er dus ook niets aan de sessie, waardoor je dus alleen bij inloggen je sessie aanpast/maakt. Daardoor denkt de garbage collector: oude sessie waar al niets meer mee word gedaan! Bekijk het lekker, weggooien!

[Voor 54% gewijzigd door Anoniem: 298643 op 01-06-2011 20:58]

[thioz]

Met een remember me cookie bedoel ik echt een cookie die een lange tijd blijft staan en die ervoor zorgt dat iemand die eigenlijk uitgelogd is toch automatisch weer ingelogd wordt.

Volgens de meeste docs moeten alle settings ook gedaan worden voor je sessie init ja.

[Voutloos]

thioz schreef op woensdag 01 juni 2011 @ 21:35:
Met een remember me cookie bedoel ik echt een cookie die een lange tijd blijft staan en die ervoor zorgt dat iemand die eigenlijk uitgelogd is toch automatisch weer ingelogd wordt.

Zonder server state is een dergelijk cookie bijzonder onveilig.

Populairste implementatie (zie tweakers ) is een cookie met lange levensduur met daarin het id van een sessie in de db. De db table moet je zelf gaan opruimen, maar het is wel een stuk robuuster + ondersteunt direct meerdere frontends. Bovendien kan je dan ook eenvoudig alle sessies van 1 user beeindigen etc.

[thioz]

@Voutloos ... dat bedoelde ik eigenlijk ook ... al was mijn verwoording mischien iets te simpel

[Anoniem: 298643]

@thioz, dat is al de hele tijd de bedoeling geweest eigenlijk, alleen wilde het niet werken omdat de sessie niet werd vernieuwd en daardoor ook werd opgeschoont door de garbage collector. De cookie die ik gebruikte was alleen een sessie id en deze cookie werd minimaal een jaar in de browser bewaard. Dus... een "remember me" cookie?

@voutloos, ik gebruik momenteel dus een PHPSESSID cookie, waarin alleen een sessie id staat die refereerd naar mijn server-side sessie. Dit is volgens jou onveilig? Overigens word deze sessie id zelfs elke request vernieuwd in de cookie zowel server sessie. Wat is er veiliger aan het opslaan in de db?

[Voutloos]

Je server-side sessie == server state.

Hetgeen ik quotte zou geïnterpreteerd kunnen worden als "zorg voor een cookie welke zelfstandig genoeg data bevat om iemand opnieuw in te loggen" en dat zou een behoorlijk slecht plan zijn.

---

Overigens moet je met name een sessie id regeneren op het moment dat eindgebruiker een andere rechtenset krijgt (bijv. login/logout), en dat is om security redenen (zoek maar op session fixation).

Als je het echter elke hit regenereert, ga je tegen problemen aanlopen bij gebruik van meerdere tabs, frames etc. Je kan dan beter gewoon ervoor zorgen dat je sessie data verandert zonder de gebruiker (browser) lastig te vallen. Bijv. een triviale wijziging als de timestamp van je laatste hit in de sessie bijhouden.

edit:
^ Is wel een beetje symptoombestrijding, het liefst fix je inderdaad in ieder geval definitief de gc instellingen

[Voor 60% gewijzigd door Voutloos op 02-06-2011 14:10]

[Freeaqingme]

die gc_maxlifetime, die wordt toch uit je php.ini file gelezen door een cronjob die vervolgens alle sessie files ouder dan dat verwijdert? Als dat inderdaad het geval is, en je gebruikt de standaard php backend, dan dien je /die/ value te updaten, dan gaat een .htaccess file er niets aan veranderen.