|
|
 |
XCVI. Funzioni di gestione della sessione
Il supporto delle sessioni in PHP consiste nel mantenere certi dati
attraverso accessi successivi.Questo vi dà la capacità di costruire
applicazioni più consone alle vostre esigenze e di accrescere le qualità
del vostro sito web.
Se avete dimestichezza con la gestione delle sessioni di PHPLIB, noterete
che alcuni concetti sono simili al supporto dele sessioni in PHP.
Al visitatore che accede al vostro sito web viene assegnato un id unico,
il cosidetto id di sessione. Questo viene registrato in un cookie sul
lato utente o è propagato tramite l'URL.
Il supporto delle sessioni vi permette di registrare numeri arbitrari di
variabili che vengono preservate secondo richiesta.Quando un visitatore
accede al vostro sito, PHP controllerà automaticamente (se session.auto_start è
settato a 1) o su vostra richiesta (esplicitamente tramite
session_start() o implicitamente tramite
session_register()) se uno specifico id di
sessione sia stato inviato con la richiesta. In questo caso , il
precedente ambiente salvato viene ricreato.
Tutte le variabili registrate vengono serializzate dopo che la richiesta
è finita. Le variabili registrate che non sono definite vengono marcate
come indefinite. All'accesso successivo, queste non vengono definite
dal modulo di sessione fino a quando l'utente non le definisce più tardi.
La configurazione di track_vars e
register_globals
influenza come le variabili di sessione vengono memorizzate una e più volte.
Nota:
In PHP 4.1.0, $_SESSION è disponibile come variabile
globale proprio come $_POST,
$_GET, $_REQUEST e così via.
$HTTP_SESSION_VARS non è sempre globale,
$_SESSION lo è sempre. Per questo motivo,
global non dovrebbe essere usato per
$_SESSION.
Se track_vars è
attiva e register_globals
non è attiva, solo i membri dell'array associativo globale
$HTTP_SESSION_VARS possono essere registrati come
variabili di sessione.
Le variabili di sessione ripristinate saranno disponibili
nell'array $HTTP_SESSION_VARS.
Esempio 1.
Registrare una variabile con track_vars
attiva
|
<?php
if (isset($HTTP_SESSION_VARS['count'])) {
$HTTP_SESSION_VARS['count']++;
}
else {
$HTTP_SESSION_VARS['count'] = 0;
}
?>
|
|
L'uso di $_SESSION (o
$HTTP_SESSION_VARS con PHP 4.0.6 o precedente) è
raccomandato per sicurezza e leegibilità del codice.Con
$_SESSION o
$HTTP_SESSION_VARS, non c'è bisogno di usare le funzioni
session_register()/session_unregister()/session_is_registered().
Gli utenti possono accedere alla variabile di sessione come a una
variabile normale.
Esempio 2.
Registrare una variabile con $_SESSION.
|
<?php
if (!isset($_SESSION['count'])) {
$_SESSION['count'] = 0;
} else {
$_SESSION['count']++;
}
?>
|
|
Esempio 3.
Resettare una variabile con $_SESSION.
|
<?php
unset($_SESSION['count']);
?>
|
|
Se register_globals
è attiva, allora tutte le variabili globali possono essere registrate
come variabili di sessione e le variabili di sessione saranno ripristinate
in corrispondenza delle variabili globali.
Dal momento che PHP ha bisogno di sapere quali variabili globali sono
registrate come variabili di sessione , gli utenti devono registrare le
variabili con la funzione session_register() mentre
$HTTP_SESSION_VARS/$_SESSION
non ha bisogno di usare session_register().
Esempio 4.
Registrare una variabile con register_globals
attiva
|
<?php
if (!session_is_registered('count')) {
session_register("count");
$count = 0;
}
else {
$count++;
}
?>
|
|
Se entrambe track_vars e
register_globals
sono attivate, allora le variabili globali e le entrate di
$HTTP_SESSION_VARS/$_SESSION
riporteranno lo stesso valore per variabili già registrate.
Se l'utente usa session_register() pre registrare una variabile di sessione,
$HTTP_SESSION_VARS/$_SESSION
non avranno questa variabile nell'array fino a che non sarà caricata
dall'archivio di sessione.(i.e. fino alla prossima richiesta)
Ci sono due metodi per propagare l'id di sessione:
I Cookies
Un parametro dell'URL
Il modulo di sessione supporta entrambi i metodi. I cookies sono ottimi,
ma dal momento che possono non essere a disposizione (i clients non sono
costretti ad accettarli ), non possiamo dipendere da questi.
Il secondo metodo incorpora l'id di sessione direttamente negli URL.
PHP ha la capacità di farlo in modo trasparente quando compilato con
--enable-trans-sid. Se attivate questa opzione,
gli URL relativi saranno modificati per contenere l'id di sessione
automaticamente. In alternativa, potete usare la costante
Alternatively, you can use the constant
SID che è definita, se il client non ha mandato
il cookie appropriato. SID può avere la forma di
session_name=session_id o può essere una stringa vuota.
L'esempio seguente dimostra come registrare una variabile e come collegare
una pagina all'altra correttamente usando SID.
Esempio 5. Contare il numero di accessi di un singolo utente |
<?php
if (!session_is_registered('count')) {
session_register('count');
$count = 1;
}
else {
$count++;
}
?>
Salve visitatore , hai visitato questa pagina <?php echo $count; ?> times.<p>;
<?php
?> (<?=SID?> può essere usato se short tag è attivo)
# è necessario per preservare l'id di sessione
# nel caso incui l'utente abbia disattivato i cookies
?>
Per continuare, <A HREF="nextpage.php?<?php echo SID?>">clicca qui</A>
|
|
Il <?=SID?> non è necessario, se
--enable-trans-sid è stato usato per compilare PHP.
Nota:
Gli URL non relativi si presume che puntino a siti esterni e quindi
non hanno il SID , perchè sarebbe rischioso per la sicurezza propagare
il SID a un altro server.
Per implementare l'archiviazione in database , o qualsiasi altro metodo di archiviazione,
avete bisogno di usare session_set_save_handler() per
creare un set di funzioni di archiviazione a livello utente.
Il sistema di gestione delle sessioni supporta un numero di opzioni di configurazione
che potete posizionare nel vostro file php.ini. Ne daremo una breve
spiegazione.
session.save_handler definisce il nome dell'handler
che è usato per archiviare e rilasciare i dati associati a una sessione.
Di default è
files.
session.save_path definisce l'argomento che
è passato all'handler di sessione. Se scegliete handler files di default ,
questo è il percorso dove i files vengono creati.
Di default è /tmp. Se la profondità del percorso
session.save_path è più di 2,
l'accumulo (gc) non sarà effettuato.
| Attenzione |
Se lasciate questo settato a directory leggibile da tutti , come
If you leave this set to a world-readable directory, such as
/tmp (il default), altri utenti sul
potrebbero essere in grado di dirottare le sessioni prendendo la
lista dei files in quella directory.
|
session.name specifica il nome della sessione
che è usata come nome del cookie. Dovrebbe contenere solo caratteri
alfanumerici. Di default è
PHPSESSID.
session.auto_start specifica se il modulo di sessione
inizia una sessione automaticamente su richiesta iniziale.
Di default è 0 (disattivata).
session.cookie_lifetime specifica il tempo di vita insecondi
del cookie che viene mandato al browser. Il valore 0 significa
"fino a che il browser viene chiuso". Di default è
0.
session.serialize_handler definisce il nome
dell'handler che è usato per serializzare/deserializzare
i dati. Al momento, un formato interno di PHP(nome
php) e WDDX è supportato (nome
wddx). WDDX è solo disponibile, se PHP è
compilato con WDDX
support. Il defailt è php.
session.gc_probability specifica la
probabilità , in percentuale ,che la routine gc (garbage collection)
sia cominciata ad ogni richiesta in percentuale. Di default è 1.
session.gc_maxlifetime specifica il numero
di secondi dopo i quali i dati saranno considerati 'spazzatura' e
cancellati.
session.referer_check contiene la sottostringa
con cui volete controllare ogni HTTP referer. Se il referer è stato mandato dal client
e la sottostringa non è stata trovata, l'id incorporato nella sessione verrà
marcato come non valido. Il default è una stringa vuota.
session.entropy_file dà un percorso a
una risorsa esterna (file) che sarà usata come una addizionale
sorgente entropica nella crazione dell'id di sessione. Esempi sono
/dev/random o
/dev/urandom che sono disponibili sulla maggior parte dei
sistemi Unix.
session.entropy_length specifica il numero
di bytes che saranno letti dal file specificato
sopra. Di default è 0 (disattivato).
session.use_cookies specifica se il
modulo userà i cookies per archiviare l'id di sessione sul lato
client. Di default è 1 (attivo).
session.cookie_path specifica il percorso da stabilire
in session_cookie. Di default è /.
session.cookie_domain specifica il dominio
settato in session_cookie. Di default è niente.
session.cache_limiter specifica il metodo di controllo
della cache da usare per le pagine di sessione
(none/nocache/private/private_no_expire/public). Di default è
nocache.
session.cache_expire specifica il tempo-di-vita ,
in minuti , delle pagine nella cache, questo non ha effetto sul
limitatore nocache. Di default è 180.
session.use_trans_sid specifica se il supporto sid trasparente
è attivato o no se attivato compilandolo con
--enable-trans-sid.
Di default è 1 (attivo).
url_rewriter.tags specifica quali html tags sono
riscritti per includere l'id di sessione se il supporto sid trasparente è attivato.
Di default è a=href,area=href,frame=src,input=src,form=fakeentry
Nota:
L'handling di sessione è stato aggiunto in PHP 4.0.
 add a note
User Contributed Notes
Funzioni di gestione della sessione
Osmos
09-May-2004 12:13
Note to the massage from "setec at freemail dot it" (01-Mar-2004 01:41).
For more flexibility I suggest replacing the string
<?php
_safe_set ($parse_url["scheme"], "http");
?>
with the following one:
<?php
_safe_set ($parse_url["scheme"], $_SERVER["HTTPS"] ? "https" : "http");
?>
Afternoon
04-May-2004 06:28
I found a good solution to create a persistent session by storing a persistence flag, ironically, in the session itelf. I start the session (which sends a Set-Cookie with no expiry time), read the flag and then, if the user wants a persistent session, stop and restart the session with the expiry time set using session_set_cookie_params, which then sends a cookie with a good expiry time. This solution has been quickly tested with all major browsers and seems to work.
I have outlined the whole process in my blog: http://aftnn.org/journal/508
Rikahs Design
14-Apr-2004 06:10
When setting url_rewriter.tags parameter in php.ini, make sure that you put quotes around the string portion like this:
url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"
or the PHP won't know what tags to insert the session id into. My web host has a relatively current version of PHP and they still didn't have this parameter configured by default.
nate at 8networks dot com
16-Mar-2004 04:16
Re: $_SESSION can be slooowwwww
Remember $_SESSION varibles are stored and read from a physical drive most of the time. Beside implementing a virtual drive configuration you can also use a faster drive or implement RAID to double access time on the drives you use now.
setec at freemail dot it
01-Mar-2004 07:41
This is a usefull code I have done that allows to make a redirection using headers with full support for sessions and HTTP 1.1.
<?php
function session_redirect ($url = "")
{
function _safe_set (&$var_true, $var_false = "")
{
if (!isset ($var_true))
{ $var_true = $var_false; }
}
$parse_url = parse_url ($url);
_safe_set ($parse_url["scheme"], "http");
_safe_set ($parse_url["host"], $_SERVER['HTTP_HOST']);
_safe_set ($parse_url["path"], "");
_safe_set ($parse_url["query"], "");
_safe_set ($parse_url["fragment"], "");
if (substr ($parse_url["path"], 0, 1) != "/")
{
$parse_url["path"] = dirname ($_SERVER['PHP_SELF']) .
"/" . $parse_url["path"];
}
if ($parse_url["query"] != "")
{ $parse_url["query"] = $parse_url["query"] . "&"; }
$parse_url["query"] = "?" . $parse_url["query"] .
session_name () . "=" .
strip_tags (session_id ());
if ($parse_url["fragment"] != "")
{ $parse_url["fragment"] = "#" . $parse_url["fragment"]; }
$url = $parse_url["scheme"] . "://" . $parse_url["host"] .
$parse_url["path"] . $parse_url["query"] .
$parse_url["fragment"];
session_write_close ();
header ("Location: " . $url);
exit;
}
?>
spagmoid at yahoo dot NOSPAMcom
13-Dec-2003 08:24
WARNING: Yet another dangerous/possibly faulty thing has been added to the session handler, without adequate explanation of it's effects.
referer_check sounds like a great idea - but if you don't understand what it really does, your site could have problems that are very difficult to track down. Especially if you have 2 sites that link back and forth. Consider this: you have a user logged in, happily enjoying a cookie-based session. He clicks on a link to another site. He then clicks a link that returns him to your site, and finds that he is locked out. His session has been reset, even though the SID was not in the URL, it was safely in a cookie. Now consider that he had another browser window open, filling out a 5-page form. When he submits, it will all be lost. A combination of factors on my site has resulted in 10% of new signups being completely LOCKED OUT the last few weeks. For now, DO NOT USE referer_check.
You could easily write your own, that only checks the URL/POST for the session info, rather than the cookie. Then you would also be able to log when it happens. I think this "feature" should be removed - sessions are too important and fragile to be toyed around with.
dan
06-Dec-2003 04:34
If you understand how sessions work in PHP, here's a FREE (GNU) and very well coded custom session handler "package" for use with MySQL. This is extremely useful if you want PHP to handle sessions using a MySQL database, ie, you want to overcome the "slooowww" access to $_SESSION with default settings, you like the idea of custom session handling but are too lazy to set it up (like me =)), you are hosted on a shared server and need session info secured, you'd like to see a really well coded sample of how to take advantage of custom session handling, etc...
The documentation is minimal, so read up on the session.* variables, explore the code, and have fun with it!
http://www.cheetah-soft.com/csh/
To those using a third-party web host, I suggest that you disable persistant connections. Also, note that after going through the "Class Configuration" on the website, the options you selected are very easy to change in the custom generated configuation file.
Thanks to Cheetah Soft, Inc for making it available under GNU!
gzink at zinkconsulting dot com
03-Dec-2003 08:57
A small warning! $_SESSION can be slooowwwww....
I've never heard of this, but it turns out $_SESSION is much slower than any regular array, even an exact copy of $_SESSION. Copying large amounts of data in/out of $_SESSION is seriously slow and each access to $_SESSION is noticeably slower than regular arrays.
The lesson I learned? Don't use $_SESSION in loops that run very much. Even copying data from $_SESSION before the loop won't help a lot if there's a lot of data there due to a delay that can be pretty hefty, almost equal to working directly on $_SESSION with foreach() and actually slower than working directly on $_SESSION if you need to put the data back in the array in my experience. It's better to pass the data another way if possible, i.e. save the SQL query and re-run, store in a database, etc.
Just a warning for those who may be using this array in medium to large loops or trying to pass lots of data. I hope it saves you the hours of optimizing I've had to spend!
-Galen
http://www.zinkconsulting.com/
pautzomat at web dot de
19-Nov-2003 06:05
Be aware of the fact that absolute URLs are NOT automatically rewritten to contain the SID.
Of course, it says so in the documentation ('Passing the Session Id') and of course it makes perfectly sense to have that restriction, but here's what happened to me:
I have been using sessions for quite a while without problems. When I used a global configuration file to be included in all my scripts, it contained a line like this:
$sHomeDirectory = 'http://my.server.com/one/of/my/projects'
which was used to make sure that all automatically generated links had the right prefix (just like $cfg['PmaAbsoluteUri'] works in phpMyAdmin). After introducing that variable, no link would pass the SID anymore, causing every script to return to the login page. It took me hours (!!) to recognize that this wasn't a bug in my code or some misconfiguration in php.ini and then still some more time to find out what it was. The above restriction had completely slipped from my mind (if it ever was there...)
Skipping the 'http:' did the job.
OK, it was my own mistake, of course, but it just shows you how easily one can sabotage his own work for hours... Just don't do it ;)
zombie (at) localm (dotto) oh - arr-gee
09-Aug-2003 10:42
I don't know if this is obvious or not, but since it took me forever to figure it out, i will post it...
<?
ini_set("session.cookie_domain",".artattack.to");
session_start();
print_r($_SESSION);
?>
This will allow cookies/session info to be available to artattack.to as well as its Cnames (ex: www.artattack.to, zombie.artattack.to, squirrel.nut.artattack.to)
All this does is set the domain attribute of the set_cookie() style function sessions use since a "session" is just a cookie on your computer that php looks for that contains your session id.
I assume, therefor that you can do something of the like for cookies in javascript and such.
The silly thing about all this is that it is a "feature" of cookies to be able to span c names/subdomains. This is exactly why set_cookie() has an option domain argument. However, it seems like most of the people have had my problem have not gone in that direction or at least not posted a correct solution on the web. Google just gave me lots of hacked solutions. In my quest, i read articles about apache hacks, setting the serverside session storage folder, using file() from a sub on a file doing a print_r on the session located ont he main server, etc etc. I guess if you really know how cookies work (which i thought i did before all this mess but obviously not) then this problem seems like not much of a problem at all and a simple missunderstanding of what cookies do and why they are cool.
Wizards vs Hackers.
I hope this helps someone.
--
Blaine
webmaster of the art attack
http://artattack.to
orion at dr-alliance dot com
08-Aug-2003 09:52
Session ID's wont be carried over through meta refreshes, so make sure you add the variables (in GET format) to the URL.
IE )
<meta http-equiv=\"refresh\" content=\"1;URL=index.php?PHPSESSID=$PHPSESSID\">
quinn at strangecode dot com
19-Mar-2003 08:10
Do not 'global' a superglobal! If you register a $_SUPERGLOBAL as a global variable (as in... global $_SESSION; within a function definition) strange things happen with some versions of PHP (PHP 4.2.3 on my MacOS X powerbook, but not my PHP 4.2.3 RH 7.3 linux machine). In the case I found, $_SESSION and $HTTP_SESSION_VARS would not reference the same data, and unsetting or accessing the data was inconsistant. Didn't test very far, but obviously this should not be done, and it did wreck havoc for me.
tim at digicol dot de
04-Feb-2003 04:14
Be careful when using ini_set to change the session.gc_maxlifetime value locally for your script:
You will trash other people's sessions when garbage collection takes place (and they will trash yours) regardless of their (your) intended session.gc_maxlifetime, because the session_name is not taken into account during garbage collection.
Create an own directory and set session.save_path to it, so that your session files don't get mixed.
nutbar at innocent dot com
17-Jan-2003 08:44
Someone posted a message here saying you should just all use the MM shared memory management for sessions. I'd like to CAUTION EVERYONE against using it!
I run a few webservers for a webhosting company, and we quickly ran in to PHP pages segfaulting Apache for unknown reasons, until we did a test with sessions. It turns out that the sessions, while using the mm stuff, couldn't keep the data right. I guess it was to do with the file locking issue mentioned in the documentation here (I didn't notice this until now!).
Anyways, if you run a Unix machine that can map virtual memory to a mount point (like tmpfs or shm or whatever it may be called), use this instead. It's volatile like mm, but works. Only thing you don't get is hidden session info so that other people don't know how to open it easily - but it's better than trying to use mm and having the webserver crash all the time!
jules at dsf dot org dot uk
16-Jan-2003 07:13
There are a few comments above about how using sessions might not be secure, but quite apart from session hijacking, there is a mistake that I think a lot of people are making at the moment that everyone needs to stop and make sure they aren't one.
This mistake arises from having the 'register_globals' setting on.
Take the following example code which is meant to maintain a session variable for whether a user is logged in and allow them to log in using a username and password if they aren't logged in, or give an option for logging out if they are:
<?php
session_register ("logged_in");
if (!strcmp($user, "user") && !strcmp($pass, "password"))
$logged_in = 1;
if ($logout)
$logged_in = 0;
if ($logged_in)
echo "logged in. <A href=\"sestest.php?logout=1\">log out</A>";
else
echo "<FORM action=sestest.php method=get>User: <INPUT type=text name=user><BR>Password: <INPUT type=text name=pass><BR><INPUT type=submit></FORM>";
?>
This works fine under normal use, but an attacker can log in without knowing the username or password by accessing '.../sestest.php?logged_in=1', which will set the session variable 'logged_in' to the value 1.
However, once a session variable has been set, it cannot be overridden in this fashion, so one solution is to use code like the code shown above (which has no explanation attached as to why you should do it that way) that uses session_is_registered:
<?php
session_start ();
if (!session_is_registered ("logged_in"))
{
$logged_in = 0;
session_register ("logged_in");
}
...
?>
thebitman at attbi dot com
16-Dec-2002 06:01
[Editor's Note] Locking a session to an IP address will sometimes result in valid user's sessions not being restored. ISPS sometimes use more than one proxy server, the ISP may direct the traffic through a different proxy on each request[/Note]
The easiest (and therefor, most vulnerable) method of validating a session is to just keep a copy of the REMOTE_IP in $_SESSION, and compare it at the beginning of your script. Of course this doesnt prevent someone from blindly sending things to your server and getting no reply, but I think it will do a pretty good job of preventing someone from hijacking your session in order to get ahold of an order confirmation page that has your address and CC# on it.
As a general rule: Keep track of your users. NEVER allow POST data for things like online purchases without making sure that the last page they were on is the page that should be making that POST (and I dont mean checking the referer: header. This kind of thing is what the _SESSION variable can be good for storing)
Jester at free2code dot net
17-Nov-2002 08:50
It seems quite a lot of people have trouble understanding what sessions do and what they're good for.
For a more newbie explanation our tutorial might help you:
http://www.free2code.net/tutorials/programming/php/4/sessions.php
I tried to expplain how to use sessions in as simple terms as possible, for anyone having trouble understanding this page, give it a go.
jmgonzal_NOSPAM_at_NOESPAM_netred_DOT_cl
12-Oct-2002 09:43
If you have problem to download a file from your PHP , and you have IE (any version) and apache for server with SSL, check the reference of: session-cache-limiter
My best solution is change the php.ini from
session.cache_limiter = nocache
to:
session.cache_limiter = private, must-revalidate
twocandles3000@hotmail
14-May-2002 05:34
Storing class instances in session.
As long as a class MUST be declared BEFORE the session starts and unserializes the session info, i'm using this approach.
0: Set in php.ini session.auto_start = 0
1: create myclass.inc where the class is declared.
2: put in another file, say header.inc, this lines of code:
include_once( "myclass.inc" );
session_start();
3: set in php.ini the auto_prepend_file= "path_to_my_file/header.inc"
Following this steps, the session is started at every page and myclass is always available, avoiding to write the session_start() function at every page.
stoiev at ig dot com
20-Mar-2002 03:10
Carefull when you are working in PHP with WML. The arg separator used to put de PHPSESSID variable in URL is '&' by default, and this cause a Compile Error in browsers:
<anchor><go href="index.php?estate=1&PHPSESSID=12345678abcde"></go>
instead of this:
<anchor><go href="index.php?estate=1&PHPSESSID=12345678abcde"></go>
It´s safety include the line:
ini_set ( "arg_separator", "&");
to change the arg separator, it worked in PHP 4.1.2
Another thing that the onpick tag is not defined in the url_rewriter.tags list by default(if there are others, i don´t now). This is must be added in php.ini file.
* In most case the WAP GateWay accepts cookies an the auto-transpass-SID is not necessary, it´s hard to find problems with this.
j dot marloweNOSPAM at gmx dot NO_SPAM dot net
11-Feb-2002 08:47
ricmarques at spamcop dot net
15-Oct-2000 11:16
Regarding session.cache_limiter :
For those of you who - like me - had trouble finding the meaning of the possible values (nocache, public and private), here's the explaination taken from the HTTP 1.1 Specification at
http://www.w3.org/Protocols/rfc2068/rfc2068
"14.9.1 What is Cachable
[snip]
public
Indicates that the response is cachable by any cache, even if it would normally be non-cachable or cachable only within a non-shared cache. (See also Authorization, section 14.8, for additional details.)
private
Indicates that all or part of the response message is intended for a single user and MUST NOT be cached by a shared cache. This allows an origin server to state that the specified parts of the response are intended for only one user and are not a valid response for requests by other users. A private (non-shared) cache may cache the response.
Note: This usage of the word private only controls where the response may be cached, and cannot ensure the privacy of the message content.
no-cache
Indicates that all or part of the response message MUST NOT be cached anywhere. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests.
Note: Most HTTP/1.0 caches will not recognize or obey this directive."
shanemayer42 at yahoo dot com
20-Aug-2000 01:11
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).
| |
sesam_settransaction
