[php] Sessie variabele verdwijnt

[Tommetje]

Ik ben op dit moment bezig met een klein, simpel inlogformulier voor een website, maar ik loop tegen een probleem aan: mijn sessie variabele verdwijnt. De ene keer is dat na een pageview, de andere keer pas na een x aantal keren.

Heb hiervoor even de volgende testcase opgezet:

PHP: page1.php

<?php
    session_start();

    $_SESSION [ 'test' ] = 'hoi';
    
    var_dump ( session_id() );
    var_dump ( $_SESSION );
?>

Deze pagina zet een sessie variabele met de naam test.

PHP: page2.php

<?php

    session_start();

    var_dump ( session_id() );
    var_dump ( $_SESSION );
?>

Deze pagina laat puur de sessie variabele zien. Ik ga dus naar page1.php en zie dat de variabele wordt aangemaakt, ga ik daarna naar page2.php dan kán het een aantal keren goed gaan, maar na een willekeurig aantal keren zie ik de variabele niet meer.

Ik heb al diverse dingen geprobeerd, gezocht op GoT en google en instellingen veranderd, zoals het toevoegen van:

code:

ini_set ( 'session.use_trans_sid', true);

Al deze dingen halen niets uit. Mijn php versie is 4.4.2-1.1 (verouderd! Ik weet 't, maar ja hostingbedrijf hè..). Ben op dit moment ten einde raad en hoop dat jullie me hier bij kunnen helpen.

[Razr]

Ik heb iets soortgelijks meegemaakt bij een hosting. Het ging bij mij wel om Windows hosting i.c.m. een ASP.NET applicatie. Hier was de oorzaak dat blijkbaar de manager van de sessies (IIS Worker Process dacht ik) regelmatig werd gerecycled waardoord ik ook al mijn sessie variabelen kwijt was. De oplossing bij mij was om de sessie variabelen bij te houden in een database. Ik weet niet of dit bij PHP ook een optie is?

[Tommetje]

Hm ik heb een hosting die Linux draait met als webserver Apache. Geen idee of hier voor zo'n dergelijke applicatie bestaat? Het rare is dat de variabelen kwijtraken, terwijl de sessie wel gewoon blijft bestaan (en de sessie-id dus hetzelfde blijft). Sessie variabelen bijhouden in een database is een optie, maar dat zie ik meer als symptoombestrijding, het moet op mijn manier toch ook mogelijk zijn?

[Luqq]

Zou niet moeten werken, maar probeer eens iets met:

http://nl.php.net/session_register

?

[Tommetje]

Had ik al geprobeerd, maakt geen verschil, helaas. Nog steeds dezelfde fout. Toch bedankt voor je suggestie.

[ Voor 3% gewijzigd door Tommetje op 25-03-2009 19:08 ]

[HuHu]

Maakt je hoster gebruik van meerdere servers die achter een loadbalancer hangen? Want dan wordt je sessie op de ene server gestart, maar als de loadbalancer je even later naar een tweede server stuurt ben je de sessie kwijt.

Oplossing is dan om sessies in de database te stoppen. Of iets anders, maar dat is meestal ingewikkelder dan een database gebruiken.

[ Voor 12% gewijzigd door HuHu op 25-03-2009 19:10 ]

[frickY]

Veranderdt je session_id ook? Dan wordt het session_cookie niet (goed) opgeslagen of terug gegeven.
Veranderdt hij niet, dan kan het de garbagecollector van de sessionhandler zijn. Kun je de inhoud van de tmp-dir zien waar de sess-files opgeslagen worden?

[ Voor 3% gewijzigd door frickY op 28-03-2009 19:40 ]

[ID-College]

frickY schreef op woensdag 25 maart 2009 @ 19:11:
Veranderd je session_id ook? Dan wordt het session_cookie niet (goed) opgeslagen of terug gegeven.
Veranderd hij niet, dan kan het de garbagecollector van de sessionhandler zijn. Kun je de inhoud van de tmp-dir zien waar de sess-files opgeslagen worden?

Veranderd is met een T schat, we hebben het over de persoonsvorm.
Daarnaast verandert die niet, dat heeft hij namelijk in zijn 2de replay gezegd

[Tommetje]

HuHu schreef op woensdag 25 maart 2009 @ 19:10:
Maakt je hoster gebruik van meerdere servers die achter een loadbalancer hangen? Want dan wordt je sessie op de ene server gestart, maar als de loadbalancer je even later naar een tweede server stuurt ben je de sessie kwijt.

Dit durf ik niet zeker te zeggen, heb je enige idee hoe ik hier achter kan komen? Maar ik ben ook niet m'n hele sessie kwijt, alleen de variabelen.

frickY schreef op woensdag 25 maart 2009 @ 19:11:
Veranderd je session_id ook? Dan wordt het session_cookie niet (goed) opgeslagen of terug gegeven.

Zoals eerder gezegd verandert het sessie-id niet.

Veranderd hij niet, dan kan het de garbagecollector van de sessionhandler zijn. Kun je de inhoud van de tmp-dir zien waar de sess-files opgeslagen worden?

Jup in deze map kan ik de sess-files zien en openen, maar ook hierin zie ik de variabele niet meer nadat hij 'verdwenen' is.

[Cartman!]

Beetje n dooddoener misschien, maar waarom uberhaupt blijven bij n host die nog PHP4 draait?

[GlowMouse]

Tommetje schreef op woensdag 25 maart 2009 @ 19:20:
[...]
Jup in deze map kan ik de sess-files zien en openen, maar ook hierin zie ik de variabele niet meer nadat hij 'verdwenen' is.

Vlak voor een request fout gaat, bestaat dat bestand met inhoud dan nog?

[CH4OS]

ID-College schreef op woensdag 25 maart 2009 @ 19:17:
Veranderd is met een T schat, we hebben het over de persoonsvorm.
Daarnaast verandert die niet, dat heeft hij namelijk in zijn 2de replay gezegd

offtopic:
Als we toch over spelling gaan muggenziften, het is reply, als in reactie. Geen replay, als in herhaling.

En als ik het zo lees, is er idd een loadbalancing probleem die dit veroorzaakt.

Cartman! schreef op woensdag 25 maart 2009 @ 19:47:
Beetje n dooddoener misschien, maar waarom uberhaupt blijven bij n host die nog PHP4 draait?

Daar zullen wel genoeg redenen voor zijn. En waarom overstappen vanwege dit? Contact opnemen met support afdeling van de hoster moet voldoende zijn om dit op te lossen. Overstappen naar andere host hoeft dit niet per se op te lossen.

[ Voor 3% gewijzigd door CH4OS op 25-03-2009 21:05 ]

[mocean]

Luqq schreef op woensdag 25 maart 2009 @ 19:02:
Zou niet moeten werken, maar probeer eens iets met:

http://nl.php.net/session_register

?

Op deze pagina staat wel:
// Use of $_SESSION is preferred, as of PHP 4.1.0

Dus dat geld ook al voor de TS, zou moeten werken dus!

Als symptoombestrijding kan je de variabelen ook in een Cookie te stoppen bijvoorbeeld.

[Gomez12]

Kan ook gewoon de garbage collector zijn als de hoster de site's niet goed gescheiden heeft, dat de garbage collector van de ene site ook de sessies van de andere site weggooit.
Al verscheidene hosters meegemaakt die dit niet goed geregeld hebben, daarom al enige tijd altijd een eigen tmp directory in gebruik ( buiten de web-dir uiteraard )

[zwippie]

Doe je een redirect om naar page2.php te gaan? Dan helpt misschien een session_write_close() voor de header().

[HuHu]

Tommetje schreef op woensdag 25 maart 2009 @ 19:20:
[...]
Dit durf ik niet zeker te zeggen, heb je enige idee hoe ik hier achter kan komen? Maar ik ben ook niet m'n hele sessie kwijt, alleen de variabelen.

Je kunt kijken of de $_SERVER['SERVER_ADDR'] veranderd op het moment dat je je sessie verliest. Dan weet je dat je op dat moment verbinding hebt met een andere server (ander IP adres) die je sessie niet heeft.

Blijft dat adres gelijk, dan is er een probleem met de garbage collection en worden je sessies te snel opgeruimd door de hosting provider. Dan kun je een eigen map maken waar je de (file-based) sessies in stopt, of overschakelen op een database. In beide gevallen moet je dan zelf zorg dragen voor het verwijderen van de sessies.

[HuHu]

zwippie schreef op woensdag 25 maart 2009 @ 21:55:
Doe je een redirect om naar page2.php te gaan? Dan helpt misschien een session_write_close() voor de header().

De data zit al in de sessie, want hij krijgt het een aantal maal op zijn scherm te zien nadat het initieel is weggeschreven. In principe is session_write_close() niet nodig, maar indien het wél nodig is geeft PHP een warning (of zelfs een error) dat je hem vergeten bent.

[Cartman!]

GJtje schreef op woensdag 25 maart 2009 @ 20:00:
Daar zullen wel genoeg redenen voor zijn. En waarom overstappen vanwege dit? Contact opnemen met support afdeling van de hoster moet voldoende zijn om dit op te lossen. Overstappen naar andere host hoeft dit niet per se op te lossen.

Soms weten mensen niet beter. Waarom op een versie blijven werken die sinds eind 2007 depricated is? Ik ben benieuwd waarom de TS perse op PHP4 wil blijven werken. Wellicht is het iets waar ie nooit over na gedacht heeft.

edit: vergelijk t maar dat velen voor gek worden uitgemaakt omdat ze nog met IE6 werken...

[ Voor 7% gewijzigd door Cartman! op 25-03-2009 22:22 ]

[Tommetje]

GlowMouse schreef op woensdag 25 maart 2009 @ 19:54:
[...]

Vlak voor een request fout gaat, bestaat dat bestand met inhoud dan nog?

Nope, vlak voordat een request fout gaat, is het bestand verwijderd. Als ik dan weer een request doe, staat 't bestand er wel weer, maar wel leeg..

zwippie schreef op woensdag 25 maart 2009 @ 21:55:
Doe je een redirect om naar page2.php te gaan? Dan helpt misschien een session_write_close() voor de header().

Nee ik doe geen redirect naar page2.php, de code die ik in de topicstart gegeven heb is alle code die op dit moment (in mijn testcase) gebruik. Zoals HuHu al zegt, krijg ik de eerste x aantal keren wel de variabele te zien op het scherm.

HuHu schreef op woensdag 25 maart 2009 @ 22:07:
[...]

Je kunt kijken of de $_SERVER['SERVER_ADDR'] veranderd op het moment dat je je sessie verliest. Dan weet je dat je op dat moment verbinding hebt met een andere server (ander IP adres) die je sessie niet heeft.

Het ip-adres wat ik dan krijg, verandert wel af en toe, maar niet op het moment dat ik een sessie verlies. Het lijkt er op dat er dus twee servers zijn die geloadbalanced (is dit een woord? ) worden, maar op alle twee de servers heb ik wel de sessie variabele nog. De variabele verdwijnt niet op het moment dat er van server veranderd wordt..

Dus ik zal een eigen map moeten maken op mijn sessies op te slaan? Is er nog een mogelijkheid om de hoster te benaderen met dit probleem? Kunnen zij hier 'makkelijk' iets aan doen? Ik heb uit eerdere ervaring sowieso niet echt het idee dat ze erg meewerkend en welwillend zijn..

Cartman! schreef op woensdag 25 maart 2009 @ 22:22:
[...]

Soms weten mensen niet beter. Waarom op een versie blijven werken die sinds eind 2007 depricated is? Ik ben benieuwd waarom de TS perse op PHP4 wil blijven werken. Wellicht is het iets waar ie nooit over na gedacht heeft.

Waar lees jij dat ik perse op PHP4 wil blijven werken? Ik zou ook het liefst met de nieuwste versie van PHP5 willen werken, maar dat kan helaas niet. Deze website bouw ik in opdracht van een klant, die (helaas) net weer voor een jaar een contract heeft afgesloten bij deze hostingprovider. Ik zou eventueel kunnen vragen voor 'n update van PHP, maar hier heb ik weinig vertrouwen (zie bovenstaande...).

Tot nu toe bedankt voor alle reacties.

[Verwijderd]

Tommetje schreef op woensdag 25 maart 2009 @ 22:49:

Waar lees jij dat ik perse op PHP4 wil blijven werken? Ik zou ook het liefst met de nieuwste versie van PHP5 willen werken, maar dat kan helaas niet. Deze website bouw ik in opdracht van een klant, die (helaas) net weer voor een jaar een contract heeft afgesloten bij deze hostingprovider. Ik zou eventueel kunnen vragen voor 'n update van PHP, maar hier heb ik weinig vertrouwen (zie bovenstaande...).

Hoelang gaat die hosting provider garanderen dat alles blijft werken? PHP 4.x is hartstikke End-of-Life.

[Tommetje]

Verwijderd schreef op woensdag 25 maart 2009 @ 22:51:
[...]

Hoelang gaat die hosting provider garanderen dat alles blijft werken? PHP 4.x is hartstikke End-of-Life.

Good question. Geen idee dus. Ik ga ze morgen sowieso eens bellen en dit probleem voorleggen en eens vragen of een upgrade naar PHP 5 mogelijk is.

[Matis]

Tommetje schreef op woensdag 25 maart 2009 @ 22:58:
Good question. Geen idee dus. Ik ga ze morgen sowieso eens bellen en dit probleem voorleggen en eens vragen of een upgrade naar PHP 5 mogelijk is.

Ik vind van een webhost dat je de keuze moet krijgen welke PHP versie je mag draaien. Je kan zelfs eisen (niet dat dat veel zin heeft, maar je kan t altijd proberen) om PHP 5.x.x te installeren.

Ik heb bij Sohosted de keuze tussen PHP 4.4.8 of 5.2.6. Natuurlijk heb ik hem op V5 staan.

Ik hoor wel wat de klantenservice. Ik heb dit zelf nog nooit meegemaakt, maar ik werk meestal met coockies. Maar jij zegt dat die ook verdwijnen. Is het toevallig geen cahce-up van je browser? Heb je het al op een andere pc met een andere browser geprobeerd?

[Cartman!]

Ik heb gewoon (voordat er begonnen wordt) de eis dat er PHP 5.2.6+ met PDO_MySQL draait op linux met apache en mod_rewrite ondersteuning. Zijn gewoon je requirements.

Ik mag hopen dat wat de hosting hun per jaar kost een fractie is wat ze jou betalen voor die website. Stel gewoon voor dat jij dan het eerste jaar de dubbelgemaakte kosten voor je rekening neemt als ze moeilijk doen over wisselen van provider en leg ze ook uit waarom dit beter is (veiliger, stabieler, etc).

Overigens ben ik het met toamatis eens dat je moet kunnen kiezen wat je wilt gebruiken.

[Tommetje]

Thanks voor de reacties. Ivm drukte in 't weekend kom ik hier graag maandag op terug.
Ik heb het nu even (tijdelijk) opgelost doormiddel van cookies. Zo kunnen ze in 't weekend tenminste inloggen.

[GlowMouse]

Tommetje schreef op woensdag 25 maart 2009 @ 22:49:
[...]

Nope, vlak voordat een request fout gaat, is het bestand verwijderd. Als ik dan weer een request doe, staat 't bestand er wel weer, maar wel leeg..

Als hij verwijderd is, dan is je sessie lifetime te kort of werkt de garbage collector niet goed. Eerste is op te lossen door de lifetime te verhogen, tweede kun je proberen te verhelpen door je eigen sessieopslagdir te gebruiken.