[php] Sessies en nog een vraagje ...

[Verwijderd]

Hallo "Kenners",

Ja ik kom hier niet zo vaak dus sorry als de vraag aleens gesteld is, maar ik zit nu vast met een php probleempje en ik kom er niet meer uit, dus vandaar !
Het probleem is als volgt ... ik heb een loginsysteem gemaakt met sessies alleen zoals jullie weten is de standaard bestaansduur van een sessie 24 min. (1440 sec.) ! Dus dan ben je na 24 min. weer uitgelogd en dat moet ik juist niet hebben.
We draaien gewoon op linux server en in asp heb je een functie session.timeout, maar in php heb je pas zo'n vergelijkbare functie in latere versies van php. Dus nu wil ik de bestaansduur van een sessie vergroten alleen dat lukt niet helemaal op de een of andere vage rede.
Ik heb via htaccess in php.ini de localvalue van session.gc_maxlifetime verhoogd ! Das ook gelukt alleen de sessies vervielen toch na 24 min. ! En met phpinfo() gaf ie wel weer dat de waarde van die localvalue ook echt verhoogd was. Maarja dat werkte dus niet.
Toen heb ik het geprobeerd door
<?php
ini_set("session.gc_maxlifetime","getal");
?>
bovenaan het script te zetten en ff getest met getal = 1, maarja dat werkte ook al niet.
Dus nou is de vraag hoe komt dat of hoe kan ik in ieder geval die sessies langer laten bestaan.


En dan had ik nog een klein tweede vraagje. Als je een pagina hebt gemaakt met if en else en submit enz. en een formuliertje en je wilt controleren of het _POSTS van de variabelen via dezelfde pagina zijn verstuurd hoe doe je dat ? En dan met randvoorwaarden dat je geen sessies mag gebruiken en geen cookies en met ref. sowieso niet, want dat pakt ie niet bij iedereen dus das niet handig. Is er dan nog een andere manier om dat te checken en hoe ?

Hopelijk kan iemand me hiermee helpen.

Vr. Gr.

Maarten

[drm]

Maarten17:
Hallo "Kenners",

Ook hallo, en welkom

Ja ik kom hier niet zo vaak dus sorry als de vraag aleens gesteld is, maar ik zit nu vast met een php probleempje en ik kom er niet meer uit, dus vandaar !

Met de search kom je altijd een eind, hoor.

Het probleem is als volgt ... ik heb een loginsysteem gemaakt met sessies alleen zoals jullie weten is de standaard bestaansduur van een sessie 24 min. (1440 sec.) ! Dus dan ben je na 24 min. weer uitgelogd en dat moet ik juist niet hebben.
We draaien gewoon op linux server en in asp heb je een functie session.timeout, maar in php heb je pas zo'n vergelijkbare functie in latere versies van php. Dus nu wil ik de bestaansduur van een sessie vergroten alleen dat lukt niet helemaal op de een of andere vage rede.
Ik heb via htaccess in php.ini de localvalue van session.gc_maxlifetime verhoogd ! Das ook gelukt alleen de sessies vervielen toch na 24 min. ! En met phpinfo() gaf ie wel weer dat de waarde van die localvalue ook echt verhoogd was. Maarja dat werkte dus niet.
Toen heb ik het geprobeerd door
<?php
ini_set("session.gc_maxlifetime","getal");
?>
bovenaan het script te zetten en ff getest met getal = 1, maarja dat werkte ook al niet.

Waarom ben je er zo zeker van dat je de directive gc_maxlifetime moet hebben Ik denk namelijk dat 't ook nog wel 's aan 'session.cookie_lifetime' zou kunnen liggen. Daar al aan gedacht?

En dan had ik nog een klein tweede vraagje. Als je een pagina hebt gemaakt met if en else en submit enz. en een formuliertje en je wilt controleren of het _POSTS van de variabelen via dezelfde pagina zijn verstuurd hoe doe je dat ? En dan met randvoorwaarden dat je geen sessies mag gebruiken en geen cookies en met ref. sowieso niet, want dat pakt ie niet bij iedereen dus das niet handig. Is er dan nog een andere manier om dat te checken en hoe ?

De HTTP_REFERER is de meest logische oplossing, maar zoals je zelf al aangeeft niet gewenst.

Je kunt dan in het formulier een bepaalde "hash" genereren, die je ook meestuurt met het formulier, waarbij de "afvanger" van het formulier tevens checkt of de hash wel de goeie is.

Eventueel kun je met Javascript ook de "referer" versturen, waarbij je in de onload van je body een form element toevoegt met de naam 'referer', en de waarde van location.href.

Hopelijk kan iemand me hiermee helpen.

Vr. Gr.

Maarten

Over groeten onder je posts staat hier toevallig nog wat

[Verwijderd]

Ah thx voor je reactie ! Okay groeten zal ik niet meer doen ! Alleen ik heb het net ff snel getest met een formuliertje:

<?php
ini_set("session.cookie_lifetime",1);

if(!IsSet($_POST['submit'])):

$_SESSION['test'] = 'test';
echo '<form action="x" name="formnaam" method="post">';
echo '<input type="submit" name="submit" value="Verstuur">';
echo '</form>';

else:

if(!IsSet($_SESSION['test'])){
echo 'nee';
}
else{
echo 'ja';
}

endif;
?>

Maar na 1 sec. bestaat de sessie nog steeds ?

[Verwijderd]

Trouwens ik zie net dat "session.cookie_lifetime" standaard op 0 staat ? Dus dat kan het sowieso dan toch niet zijn of hoe zit dat ?

[ACM]

cookie duur op 0 == geldig tot einde van browser sessie

[ Voor 7% gewijzigd door ACM op 10-03-2003 18:25 ]

[Verwijderd]

Ah okay ! Ook wel logisch, maar dan is dat dus niet de waarde waarmee ik de bestaansduur van een sessie kan verlengen, want hoe doe ik dat dan ?

[ACM]

Wel degelijk, want de bestaansduur van de sessie zal de kleinste van de tijden aannemen voor cookie_lifetime en gc_maxlifetime

Als de cookie-timeout op een lage waarde staat ligt het daaraan, als de gc-lifetime te laag staat zal het daar pas aan liggen, voorlopig is de cookie-timeout waarsch de boosdoener.

[Verwijderd]

Maar session.cookie_lifetime staat bij mij op 0, dus t/m einde browser sessie, dus in dit geval is de waarde 1440 van gc-lifetime toch de kleinste en zal de sessie die waarde als levensduur aannemen, dus zou het met gc-lifetime moeten werken toch ? Maar dat doet ie niet ?

[Verwijderd]

De definitie is trouwens als volgt. (Er staat ook een opmerking bij misschien dat het daar iets mee te maken heeft alleen die opmerking kan ik niet helemaal goed bevatten):

session.gc_maxlifetime integer
session.gc_maxlifetime specifies the number of seconds after which data will be seen as 'garbage' and cleaned up.

Opmerking: If you are using the default file-based session handler, your filesystem must keep track of access times (atime). Windows FAT does not so you will have to come up with another way to handle garbage collecting your session if you are stuck with a FAT filesystem or any other fs where atime tracking is not available.

[ACM]

Ik begrijp echt helemaal niet meer wat je probleem is.
Je haalt een opmerking aan waaruit blijkt dat sessies te lang blijven bestaan en ziet dat als een potentieel probleem voor het te kort duren van je sessies?

Leg eens helemaal precies uit wat er niet goed gaat en leg dan niet uit wat je wil doen, maar wat je wil bereiken en waarom dat niet lukt.

[Verwijderd]

Okay in het kort is het probleem: Nu blijven sessies 1440 sec. staan en ik wil dat ze iets van 69120 sec. blijven staan.
Als je die definitie ziet als voorbeeld dan was het in ieder geval niet m'n bedoeling geweest om dat erneer te zetten, omdat ik niet precies snap wat ze in die opmerking enz. willen zeggen, maar ik d8 misschien heeft het ermee te maken.

Als ik bijvoorbeeld onderstaande doe om te testen of ik de maxlifetime kan wijzigen dan geeft ie gewoon als echo 1440 sec. ipv in dit geval bijv. 60 sec. ?

ini_set("session.gc_maxlifetime", "60");
session_start();
echo get_cfg_var('session.gc_maxlifetime');

[Verwijderd]

drm schreef op 10 March 2003 @ 17:55:
Je kunt dan in het formulier een bepaalde "hash" genereren, die je ook meestuurt met het formulier, waarbij de "afvanger" van het formulier tevens checkt of de hash wel de goeie is.

Zo'n hash kan je maken door een hash van de data en een geheim woord te nemen, toch?

md5($_POST['bla'].$_POST['blub'].$_POST['blop'].'S3cr3tPa$$w0rd');

[Verwijderd]

Nog even toelichting op jouw reactie "Wel degelijk, want de bestaansduur van de sessie zal de kleinste van de tijden aannemen voor cookie_lifetime en gc_maxlifetime" ...
Want cookie_lifetime staat op 0 standaard en zo ook op onze server en gc_max staat op 1440 sec. ! En met 0 bedoelden ze dus de tijd tot het sluiten van de browser dus pakt ie gc_max toch en is cookie_lifetime niet het probleem, want zoals jij het zegt, vat ik het op dat als bijvoorbeeld cookie_lifetime op bijv. 1300 sec. staat en die gc_max op 1440 sec. dat dan de levensduur van de sessie 1300 sec. zal blijven hoe hoog je gc_max ook zet, dus dan zou het inderdaad aan cookie_lifetime kunnen liggen.
Maar dat is het geval niet, omdat die waarde op 0 staat, dus gc_max < cookie_lifetime ongeacht de waarde van gc_max, omdat cookie_lifetime de tijd is t/m sluiten browser.

Of begrijp ik hiermee jou nu verkeerd ?

[irondog]

Omdat ik ook met sessies bezig ben, wil ik ff op dit onderwerp inhaken.

Wanneer wordt de rommel in /tmp weggegooid? /tmp/sess_*

Ik ben de enige gebruiker van mijn webserver (hoop ik) en na het sluiten van mijn browser zouden alle sessies dood moeten zijn, maar de files aangemaakt in /tmp blijven bestaan.

Moet ik zelf trouwens op een of andere manier met php, sessies beeindigen of hoef ik me hier totaal niet druk over te maken en komt ELKE sessie ooit aan een eind?

[martinvw]

dat is de garbage collection waar het hier over gaat die gc maar mij is eigenlijk niet duidelijk hoe dat precies werkt maar nu weet je waar je op moet zoeken.

[Verwijderd]

Irondog: Heeft jouw "cookie_lifetime" waarde wel de waarde 0 dan ? Misschien dat het daaraan zou kunnen liggen als ie een andere waarde heeft dan 0.

[irondog]

Verwijderd schreef op 11 maart 2003 @ 17:13:
Irondog: Heeft jouw "cookie_lifetime" waarde wel de waarde 0 dan ? Misschien dat het daaraan zou kunnen liggen als ie een andere waarde heeft dan 0.

Bedankt voor de reactie. De cookie lifetime is idd 0 voor session cookies.

misschien moet ik mijn vraag anders stellen..

Als ik een session niet sluit met session_destroy() dan blijft er rommel
achter in mijn /tmp directory. Logisch: niemand heeft erom gevraagd om
de sessie af te ronden.

Aangezien een session cookie (standaard) bestaat
totdat de user zijn browser sluit of totdat er 24 minuten
voorbij zijn, kan een sessie verlopen zonder dat ik de kans heb gehad om
session_destroy() aan te roepen.

Hoe moet ik dit probleem opvangen? Moet ik hier zelf (als nette
programmeur) rekening mee houden?
Ik kan me voorstellen dat ik session-id's op moet slaan in een database
en zelf voor elke gemaakte sessie een geschikt einde moet kiezen. Maar
hoe? Ik kan me dus niet voorstellen dat ik bij elke request van een
bezoeker eerst mijn database moet afgaan op verlopen sessies. Een
gestarte session direct stoppen aan het einde van een script is een
oplossing, maar dat maakt het gebruik van sessies overbodig.

[martinvw]

ahum, daar is de ingebouwde carbage collection voor, zoals ik al eerder zei

session.gc_probability integer
session.gc_probability specifies the probability that the gc (garbage collection) routine is started on each request in percent. Defaults to 1.

session.gc_maxlifetime integer
session.gc_maxlifetime specifies the number of seconds after which data will be seen as 'garbage' and cleaned up.

Note: If you are using the default file-based session handler, your filesystem must keep track of access times (atime). Windows FAT does not so you will have to come up with another way to handle garbage collecting your session if you are stuck with a FAT filesystem or any other fs where atime tracking is not available.

Maar jah, als je dus fat filesysteem gebruikt dan moet je dus zelf een script schrijven wat de boel schoon houd.

Maar aangezien je het over /tmp heb zal je wel linux/unix draaien en geen fat systeem hebben, dus als je vind dat het te lang blijft staan kan je de session.gc_probability omhoog moeten gooien zodat niet in 1% van de gevallen gekeken wordt wat er verstreken is en dus weg kan maar in een hoger percentage van de gevallen.

[ Voor 101% gewijzigd door martinvw op 11-03-2003 19:18 ]

[irondog]

M4rt1nvW schreef op 11 March 2003 @ 19:05:
ahum, daar is de ingebouwde carbage collection voor, zoals ik al eerder zei

Maar aangezien je het over /tmp heb zal je wel linux/unix draaien en geen fat systeem hebben, dus als je vind dat het te lang blijft staan kan je de session.gc_probability omhoog moeten gooien zodat niet in 1% van de gevallen gekeken wordt wat er verstreken is en dus weg kan maar in een hoger percentage van de gevallen.

Ok, dat is duidelijkere taal
Dus ik hoef zelf geen session management in te bouwen om te voorkomen dat er rommel 8er blijft. Elke sessie loopt in princiepe ooit een keer af en ik hoef niet voor elke gemaakte sessie een session_destroy() te doen.

drm schreef op 10 March 2003 @ 17:55:
[nohtml]
[...]
De HTTP_REFERER is de meest logische oplossing, maar zoals je zelf al aangeeft niet gewenst.

Je kunt dan in het formulier een bepaalde "hash" genereren, die je ook meestuurt met het formulier, waarbij de "afvanger" van het formulier tevens checkt of de hash wel de goeie is.

Eventueel kun je met Javascript ook de "referer" versturen, waarbij je in de onload van je body een form element toevoegt met de naam 'referer', en de waarde van location.href.

Ik weet niet waarom je dat zou willen doen. Veiligheid?? Daar is geen sprake van als je de eerste oplossing niet gebruikt en waarom zou dat niet altijd werken? Bovendien heeft lang niet elke paranoia nerd javascript aanstaan.

Als je een hash genereert in het formulier zelf, is dat doorzichtig en te reproduceren (dus ook te exploiteren) en dat wilde je toch voorkomen? Met de laatste twee oplossingen heb je het slechts een beetje moeilijker gemaakt.

[Verwijderd]

En weet iemand ook nog het antwoord op de vraag van die sessie duur verlengen, want ik weet nog steeds geen oplossing.

[chris]

Ga eens na waarom het "sessie" heet....en natuurlijk heeft ook php een manual. Hierin staat onder het kopje sessions heel mooi deze functie. dit is dus een typisch voorbeeld van R*T*F*M

[Verwijderd]

Ja okay maar daar staat dat je je sessie kunt verlengen door hem in een cookie te gooien, maar als iemand zijn cookies uitgeschekeld heeft staan, werkt het dan toch niet en dan moet ie ook werken of zie ik nu iets verkeerd ??

edit:

Ik heb alles nog even voor de zekerheid getest maar dit is dus echt niet typisch een voorbeeld van R*T*F*M ! Dit is denk ik typisch een voorbeeld van een user die het probleem te simpel inschat, maar hoe zou het volgens jou dan precies moeten, want alles wat er in die faq staat heb ik ook allang gelezen en ook allemaal al uitgetest.

edit:

Aaaaaaaaaaaaaah !! Yes yes yes ! Volgens mij heb ik een oplossing gevonden voor het probleem ... kostte wel ff 2 dagen allerlei dingen proberen, maarja ik weet nu wel hoe t zit.
Je hebt ini_set dir doe het niet, maar ini_alter wel. Ik kwam die _alter toevallig ergens tegen en ik d8 mmz laat ik die eens proberen. Ik heb nergens letterlijk gevonden dat het zo wel werkt en dat verbaast me wel een beetje, want een sessie tijd verlengen en verkorten lijkt me toch ie vrij standaards in php. Maar goed met onderstaand voorbeeldje heb ik het getest door na 2 sec. de sessie te laten vervallen en dat werkt !

ini_alter("session.gc_maxlifetime", "2");
session_start();

if(!IsSet($_POST['submit'])):

$_SESSION['test'] = 'test';
echo '<form action="'.$PHP_SELF.'" name="formnaam" method="post">';
echo '<input type="submit" name="submit" value="Verstuur">';
echo '</form>';

echo get_cfg_var('session.referer_check');
echo ini_get('session.referer_check');
echo get_cfg_var('session.gc_maxlifetime');
echo ini_get('session.gc_maxlifetime');

else:


if(!IsSet($_SESSION['test'])){
echo 'nee';
}
else{
echo 'ja';
}

echo get_cfg_var('session.gc_maxlifetime');


endif;

[ Voor 97% gewijzigd door drm op 12-03-2003 15:43 ]

[Verwijderd]

Hmmz ik ben verder gaan testen, maar op de een of andere vreemde manier werkt dit toch ook niet. Nog iemand ideeen ?

[Verwijderd]

Ja ik ben weer ff paar uur verder wezen zoeken en heb wel nog het volgende gevonden alleen ik begrijp niet 100 % wat ze ermee bedoelen, maar volgens mij heeft het wel met dit probleem te maken. Wat bedoelen ze precies met: ?

*******

Session Garbage Collection Observation:

It appears that session file garbage collection occurs AFTER the current session is loaded.

This means that:
even if session.gc_maxlifetime = 1 second,
if someone starts a session A and no one starts a session for an hour,
that person can reconnect to session A and all of their previous session
values will be available (That is, session A will not be cleaned up even
though it is older than gc_maxlifetime).

*******