Hoe een session op naam te destroyen
Ik maak in mijn WordPress plugin (contactformulier) gebruik van een sessie om via php 'rand' random nummer te genereren en vast te houden:
Code (php)
1
2
3
2
3
session_name('my-session');
session_start();
$_SESSION['rand'] = isset($_SESSION['rand']) ? $_SESSION['rand'] : rand(100, 999);
session_start();
$_SESSION['rand'] = isset($_SESSION['rand']) ? $_SESSION['rand'] : rand(100, 999);
En ik unset de sessie variabele met:
Nu blijft de website steeds vaker 'hangen', maar als ik de sessie verwijder uit broncode, loopt alles weer prima.
Ik denk dat dit te maken heeft met dat ik niet de volledige sessie destroy?
Zo ja, functie 'session_destroy' gebruiken werd me afgeraden inzake eventueel andere lopende sessies.
Ik hoopte het op te lossen met het geven van een naam aan de sessie, maar kan nergens vinden hoe ik een sessie op naam kan destroyen.
Iemand een idee?
Guido
Gewijzigd op 13/03/2015 15:22:57 door Guido -
Bedoel je hiermee dat session_destroy wel degelijk kan en dit eventuele andere sessies niet in gevaar brengt?
Guido
Wat probeer je nu precies te bereiken? probeer je alleen van die $_SESSION['rand'] af te komen?
staat die regel 3 hierboven nu altijd direct achter de session_start()?
Dan zal er direct bij een page-refresh een nieuwe $_SESSION['rand'] aangemaakt worden.
Waarom trouwens die session_name()?
1) als pagina met mijn formulier geladen wordt wordt ook een sessie gestart en random gegenereerd nummer getoond
2) gebruiker vult formulier in en neemt random gegenereerd nummer over
3) gebruiker drukt op submit
4) als alles (dus ook nummer) goed ingevuld is wordt formulier verstuurd
5) ik gebruik unset($_SESSION['rand']) om nummer na stap 4 weer te verversen
6) nieuw formulier met nieuw nummer wordt getoond (stap 1)
De session_name was een gok...
Als ik de sessie verwijder, is website weer op snelheid, dus ergens gaat er iets fout...
Moet ik de sessie niet sowieso destroyen? Dus:
Guido
Gewijzigd op 13/03/2015 20:53:33 door Guido -
Quote:
Nu blijft de website steeds vaker 'hangen', maar als ik de sessie verwijder uit broncode, loopt alles weer prima.
Maar ligt dit puur aan het sessie-gebruik, of aan een logische fout bij het gebruik van sessies? Ik denk eerlijk gezegd het laatste.
Als je een sessie blijft gebruiken waarin één variabele zit met een random getalletje dan zou dit niet zo'n enorme performance deuk moeten opleveren. Tenzij er wellicht iets speciaals aan de hand is? Kan webserver gerelateerd zijn, maar als je een beetje een fatsoenlijke host hebt zou ik dit toch wat dichter bij huis (=in je eigen code) zoeken.
Nu je het zegt, dit probleem doet zit alleen voor als ik site lokaal draai, via xampp.
Dus mogelijk zit daar het probleem.
Is dit overigens wel de reguliere manier om alles te beeindigen:
Heb zelf niet veel verstand van sessies zoals je merkt, maar ik kom zowel unset als unset + destroy tegen op het www. Vandaar deze vraag.
Guido
Gewijzigd op 13/03/2015 22:22:28 door Guido -
Dus ook je inlog, kleur keuze of wat een ander script er maar inzette.
Maar 'hangen' was dus 'traag'?
In dat geval: bij session-name is er in de comments een opmerking over de traagheid van die functie
session_start(); is voldoende en werkt prima, kan je alles in onderbrengen.
session_destroy(); is voldoende om te beeindigen.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<?php
// @see php.net/session_destroy
// Empty $_SESSION.
$_SESSION = array();
// Do not close the session as this will make it readonly, preventing the physical file from being deleted.
// Delete session cookie.
if (ini_get('session.use_cookies')) {
$params = session_get_cookie_params();
setcookie(
session_name(),
'',
time() - 42000,
$params['path'],
$params['domain'],
$params['secure'],
$params['httponly']
);
}
// Destroy the session.
session_destroy();
?>
// @see php.net/session_destroy
// Empty $_SESSION.
$_SESSION = array();
// Do not close the session as this will make it readonly, preventing the physical file from being deleted.
// Delete session cookie.
if (ini_get('session.use_cookies')) {
$params = session_get_cookie_params();
setcookie(
session_name(),
'',
time() - 42000,
$params['path'],
$params['domain'],
$params['secure'],
$params['httponly']
);
}
// Destroy the session.
session_destroy();
?>
(en je moet uiteraard de sessie wel eerst starten)
Gewijzigd op 13/03/2015 23:50:58 door Thomas van den Heuvel
Overigens schijnt session_destroy niet de sessie variabelen te unsetten:
session_destroy() destroys all of the data associated with the current session. It does not unset any of the global variables associated with the session
Daarom lijkt me unset($_SESSION['rand']) ook zinvol, ook al vraag ik me stiekem af wat mijn variabele nog kan doen zonder lopende sessie..
Guido
Guido vd L op 14/03/2015 01:17:36:
Daarom lijkt me unset($_SESSION['rand']) ook zinvol, ook al vraag ik me stiekem af wat mijn variabele nog kan doen zonder lopende sessie.
Sessiebestanden van vernietigde sessies worden niet direct verwijderd. De garbage collector (gc) wordt slechts met een kans van session.gc_probability : session.gc_divisor = 1 : 100 = .01 aan het werk gezet. Daardoor zijn er na het vernietigen van de sessie toch nog tmp-bestanden aanwezig met (mogelijk) vertrouwelijke informatie. Bovendien kosten die bestanden schijfruimte.
Je kunt daarmee afrekenen door $_SESSION = array() te gebruiken voordat je de sessie vernietigt.
Nog een afsluitende vraag, in mijn plugin heb ik 2 verschillende formulieren waarin ik een sessie start. 2 sessies tegelijk starten kan niet. Is dit een reguliere manier om te checken of al een sessie bestaat:
Lastige van het www is de vele verschillende oplossingen en meningen, oftewel, wat is correct en wat niet ;-) ?!
Guido
Gewijzigd op 14/03/2015 23:33:27 door Guido -
Start je sessie gewoon op een vaste plaats...
Guido
PHP < 5.4.0:
Guido vd L op 16/03/2015 14:55:12:
Kan het kwaad om een sessie te laten doorlopen (alleen variabele te unsetten), ook al is die sessie 'leeg'?
Nee, dat kan geen kwaad — al helemaal niet als de sessie toch al leeg is. Er zit een kleine performancewinst in het niet voortdurend verwijderen van verlopen sessies. De garbage collector doet dat automatisch, maar brengt zelf wat overhead met zich mee in de vorm van schijftoegang voor het wissen van de sessiebestanden, dus kan deze juist beter niet voortdurend aan het werk worden gezet.
Deelt jouw plugin de sessions niet met de andere functies van de wp-site?
Zo ja, dan lijkt het me niet heel handig om heel het $_SESSION array leeg te maken, omdat jouw formpje is gepost.