Introduzione
Un cookie è un pacchetto di dati che il server chiede al browser di trattenere (salvandolo in memoria o su disco) e rendere disponibile durante le comunicazioni che seguiranno.
Tecnicamente le informazioni contenute nei cookie vengono scambiate tramite header ("intestazioni") durante le connessioni HTTP tra client e server, questo è il metodo più utilizzato per ovviare al problema dell'assenza di stato nel WEB.
L'unico modo affidabile affinchè il server possa distinguere l'appartenenza delle molteplici richieste che gli giungono è che sia il navigatore a dire in qualche modo "Hei! Sono sempre io": la funzione di un cookie è essenzialmente questa: se accettato diviene una sorta di "etichetta" che identificherà il client ad ogni successivo contatto.
Perchè i cookie?
Ecco alcuni casi esemplari nei quali mantenere traccia del navigatore diventa una necessità:
1) quando si vogliono personalizzare le esperienze dei visitatori in base alle pagine che hanno già visitato (es. banner pubblicitari).
2) Desideriamo evitare che l'utente, quando si muove all'interno di un'area riservata, sia costretto a ripetere il login ad ogni pagina
3) In un sito di e-commerce: mantenere nel carrello, fino al momento dell'acquisto, la memoria delle scelte effettuate durante la navigazione.
4) Contatori visite, contatori utenti online ecc.
I cookie non rappresentano l'unica soluzione al problema dell' assenza di stato nel WEB, tuttavia rimangono il sistema più versatile e diffuso.
Quando ci occuperemo delle sessioni, in un prossimo articolo, vedremo quali sono le altre possibilità.
È anche vero che i "biscottini" si sono guadagnati una fama un po' ambigua nell'immaginario comune
e che vi è chi preferisce disabilitarne la ricezione, ma è importante mettere l'utente nella condizione di capire che nel 99% dei casi si tratta di uno strumento al servizio dei navigatori.
Ad ogni modo, proprio con lo scopo di fare chiarezza sull'argomento, alla fine di questo articolo dedicheremo uno spazio ai cookie "cattivi" e al loro funzionamento.
Tipi di cookie
Si è già accennato al fatto che i cookie possono essere immagazzinati sia nella memoria volatile dell'applicazione client, che sul disco sotto forma di file di testo.
Nel primo caso si tratta di cookie ai quali non viene impostata una scadenza e pertanto sono temporanei: verranno automaticamente eliminati al momento della chiusura della finestra del browser e di tutte le finestre "figlie" (ad esempio quelle aperte dopo il click su un link con TARGET="_blank"), vengono anche chiamati "magic cookies" (in quanto compaiono e scompaiono).
I cookie persistenti al contrario, se non cancellati manualmente, possono restare memorizzati sul client per mesi o anni a seconda del termine di validità con cui vengono impostati.
Questa distinzione è importante perchè da essa dipende la portata con cui le applicazioni lato-server saranno in grado di tracciare l'utente.
Inviare i coookie con Php
setcookie() è la funzione predefinita di php per inviare un "Set-Cookie HTTP Response Header", cioè la richiesta al client da parte del server di memorizzare un cookie; tale header deve contenere 6 parametri che corrispondono ai possibili argomenti della funzione.
sintassi di setcookie()
boolean setcookie ( string name [, string value [, int expire [, string path [, string domain [, int secure]]]]])
Soltanto i primi due argomenti sono obbligatori mentre gli altri parametri, se non specificati, verranno impostati automaticamente secondo i valori di default che vedremo tra poco.
Name e Value
rappresentano rispettivamente la variabile con cui è identificabile il cookie ed il suo contenuto.
Fornire un Value vuoto ("") nel 99% dei casi equivale a cancellare un cookie già esistente identificato con Name (vedi pù avanti "Eliminare i cookie").
Expire (default = 0)
la scadenza determina per quanto tempo il cookie rimarrà memorizzato dal client: impostarla a 0 o tralasciare questo valore equivale a settare un "magic cookie".
Path (default= directory corrente)
Indica il percorso sul server per il quale il cookie sarà valido.
Una stringa come "/mydoc" stabilirà la leggibilità anche all'interno delle directory "mydoc", "mydocuments", "mydoc_new" e loro sottodirectory;
al contario "/mydocs/pagina.php" renderà i dati ricevibili soltanto nella pagina indicata esplicitamente.
A differenza di quanto accade per il DOMAIN, è possibile settare un ambito diverso da quello in cui viene eseguito lo script che invia l'header: in parole povere ciò significa che uno script può creare un cookie che non sarà poi in grado di leggere.
Se Path non verrà specificato il cookie si intenderà valido solo per i percorsi compresi nell'ambito della directory in cui si trova la pagina che lo ha inviato.
All'opposto il percorso "/" è il più ampio immaginabile, e rappresenta l'intera documentRoot del webserver.
Il parametro Path è stato pensato per evitare che, ad esempio, una pagina presente nel percorso "/utenti/utente1" possa leggere il cookie inviato da una pagina presente in "/utenti/utente2".
Domain (per default il domain completo del server, es. www.html.it)
Indica il dominio per il quale il cookie è valido, può trattarsi di un nome dominio come un indirizzo IP. La verifica sul dominio avviene in modo molto rigoroso: uno script appartenente a www.dominio1.com non vedrà accettata dal client la sua richiesta di memorizzare un cookie con un parametro domain differente (ad esempio www.dominio2.com).
Allo stesso tempo un cookie impostato in un dominio non sarà leggibile da un altro.
La verifica viene detta per "tail match", ovvero "corrispondenza di coda":
il confronto su di essa da parte del browser procede da destra verso sinistra, inoltre la stringa del Domain deve contenere almeno due caratteri "." (punto).
Quindi ad esempio "html.it" sarà una stringa valida sia per freephp.html.it che freeasp.html.it (ed i cookie risulteranno condivisibili tra i diversi dominii) ma non per "myhtml.it".
È bene ricordare che uno stesso domain non può settare più di 20 cookie e che la dimensione massima accettata dal client è di 4 kilobyte ciascuno (incluso lo spazio occupato dai parametri).
Secure (default= 0)
Se impostato su "1" (TRUE) il cookie potrà essere inviato soltanto se si tratta di una connessione sicura (HTTPS).
Consiglio anche la lettura delle specifiche di Netscape: vengono dati per scontati alcuni degli aspetti che abbiamo appena visto ma se ne svelano altri piuttosto interessanti.
Alcuni esempi con setcookie()
<?php
/***
Invia un cookie temporaneo, di nome "HelloCoookie", contenente la stringa "Ciao!"
Path e Domain verranno settati automaticamente in base alle regole illustrate nella pagina precedente
***/
setcookie("HelloCookie","Ciao!") ;
/***
Un modo diverso per inviare un cookie temporaneo
***/
setcookie ("HelloCookie2","Hola!",0,"","",0);
/***
Invia un cookie persistente (1 h, cioè 3600 secondi), la scadenza può essere fissata sia con time() che con mktime()
***/
$valore="Questo è un cookie persistente" ;
setcookie ("CookieDurevole", $valore,time()+3600) ;
/***
Invia un cookie temporaneo se si tratta di una connessione sicura, vengono anche specificati Path (la home directory dell' utente "heller" su un server unix-like) e Domain.
***/
setcookie ("",$value, 0, "/~heller/", "freephp.html.it", 1);
?>
Cookie multiplo es.1
<?php
/***
pagina
"sendcookie.php"
***/
setcookie ("saluto[italiano]", "ciao!");
setcookie ("saluto[inglese]", "hello!");
setcookie ("saluto[spagnolo]", "hola!");
echo('<a href="getcookie.php">Vai a getcookie.php</a>') ;
?>
Il risultato di questo codice è quello di inviare 3 differenti cookie, ma al momento di leggere i loro valori questi saranno comodamente reperibili all'interno di un array che li raccoglie come fossero uno solo, ecco in quale modo
<?php
/***
pagina
"getcookie.php"
***/
echo("Elenco saluti<br><br>");
foreach ($_COOKIE["saluto"] as $key => $value){
echo("Il saluto ".$key." è ".$value) ;
}
?>
Cookie multiplo es.2
Visto che il numero di cookie che un domain può inviare è limitato, mentre un singolo cookie può pesare fino a 4 k, non escluderei la possibilità di "imbottire" di variabili la stringa da memorizzare e poi recuperarle effettuando un explode() come nell'esempio seguente.
Inserire le variabili
<?php
$genere_articolo="003" ;
$id_articolo="1234" ;
$quantity="2" ;
$tipo_spedizione="1" ;
$stringa=$genere_articolo."|".$id_articolo."|".$quantity."|".$tipo_spedizione ;
setcookie("acquisto[3]","$stringa",time()+360000) ;
?>
Recuperare i valori
<?php
list($genere_articolo,$id_articolo,$quantity,$tipo_spedizione)=explode("|",$_COOKIE["acquisto"][3]) ;
?>
Non sono convinto che questo sia il modo migliore di progettare un carrello per la spesa in un sito di e-commerce,
ma lo script dimostra come con qualche astuzia sia possibile racchiudere più valori in un solo cookie.
Metodi alternativi a setcookie()
Essendo un cookie inviato tramite header è ovviamente possibile utilizzare anche la funzione header() di Php (anzichè la più comoda setcookie()), in realtà per i più pignoli questa potrebbe divenire una scelta obbligata visto che alcune versione meno recenti di Explorer sembrano rispondere a setcookie() in modo non del tutto soddisfacente.
Esempio con header()
<?php
header ("Set-Cookie: testCookie=questo è un test; expires=Friday, 1-Jan-2050 00:00:00 GMT; path=/; domain= freephp.html.it ;");
?>
Da notare che in questo caso il formato della data deve essere obbligatoriamente in inglese e GMT: l'utilizzo di header() rispecchia perfettamente la stringa con cui il server invia l'intestazione al client (vedi le specifiche di Netscape per maggiori dettagli sui formati del "Set-Cookie HTTP Response Header").
Inoltre, dato che è possibile settare un cookie anche in html attraverso i tag META, quella che segue potrebbe essere una soluzione "artigianale" ma funzionante con qualsiasi browser (almeno in teoria).
<html>
<head>
<?php
echo("<META HTTP-EQUIV="Set-Cookie" CONTENT="testCookie=questo è un test ; expires=Sunday, 01-Jan-00 01:10:00 GMT; path=/; ">") ;
?>
</head>
<body>
.
.
.
Possibili problemi
La chiamata di setcookie() restituisce TRUE nel caso in cui vada a buon fine, oppure FALSE qualora si verifichino degli errori...ed eccone uno frequente:
"Warning: Cannot add header information - headers already sent by (output started at g:wwwprovasessionick.php:1) in c:wwwprovesessionibadcookie.php on line 3"
Essendo il cookie un header non può essere inviato dopo che verso il browser sia già stato emesso un qualsiasi output: se ci capiterà di leggere un simile avvertimento teniamo presenti i consigli forniti nell'articolo sul buffering dell'output.
Purtroppo setcookie() non è in grado di dire nulla sulla predisposizione del client a ricevere o rifiutare i cookie (restituirà TRUE in ogni caso), quindi per ottenere questa informazione dovremo ricorrere allo stratagemma descritto successivamente in questo articolo.
Prelevare i valori salvati
Se nel file di configurazione di Php l'opzione register_globals è settata su "On" i valori inseriti si possono reperire facilmente attraverso il nome del cookie stesso, tuttavia per le ben note ragioni di sicurezza questa opzione è ora deprecata ed è consigliabile utilizzare l'array associativo $HTTP_COOKIE_VARS oppure $_COOKIE (quest'ultimo introdotto a partire dalla versione 4.1 di Php).
Esempio
<?php
/***
Se non esiste alcun cookie
***/
if(empty($HTTP_COOKIE_VARS)){
$message="Visita freephp.html.it!" ;
/***
Invia un cookie temporaneo
***/
setcookie("adv",$message) ;
/***
Refresh della pagina per poter leggere i dati appena inviati
***/
header("Location: ".$_SERVER["PHP_SELF"]) ;
}
/***
Se il cookie esiste e register_globals= On
***/
elseif(isset($adv)){
echo($adv) ;
}
/***
Se esiste l'array $_COOKIE (php >= 4.1) e se l'array non è vuoto (cioè se il cookie è stato inviato con successo)
***/
elseif (isset($_COOKIE)&& !empty($_COOKIE)){
echo($_COOKIE["adv"]) ;
}
/***
Se nessuna delle ipotesi precedenti si avvera ricorriamo all'array $HTTP_COOKIE_VARS
***/
else{
echo($HTTP_COOKIE_VARS["adv"]) ;
}
?>
Le poche righe di codice appena esaminate impostano il cookie "adv" se questo già non esiste, altrimenti tentano di leggerlo fornendoci diversi esempi su come rendere disponibile all'interno dello script il valore memorizzato.
In questo caso, svolgendosi all'interno della stessa pagina sia l'invio che il recupero, dopo la chiamata di setcookie() diventa necessario effettuare un refresh.
Sfortunatamente un cookie non è immediatamente leggibile durante la stessa elaborazione che lo ha creato.
L'esempio tuttavia presenta un grosso difetto poichè genererebbe un loop infinito qualora il client rifiutasse i cookie e, se così fosse, tutti i tentativi di invio fallirebbero senza neppure permetterci di intercettare un messaggio di errore.
Capire se il client accetta i cookie
Il fatto che il valore salvato non sia immediatamente disponibile durante la richiesta di creare un cookie, comporta che non c'è modo di capire in anticipo se il browser lo accetterà.
Esistono delle soluzioni Javascript che consentono questo accertamento preventivo, ma se siamo alla ricerca di un metodo affidabile e perfettamente valido per qualsiasi browser dobbiamo ricorrere necessariamente a Php.
Lo script seguente può fare al caso nostro.
<?php
/***
Se l'array $_COOKIE è vuoto possono esserci 2 ragioni:
1) non sono ancora stati inviati cookie
2) sono stati inviati ma il browser li rifiuta
***/
if(empty($_COOKIE)){
/***
Se non risultano cookie e la variabile "cookieTest" (passata attraverso la query_string) non esiste, significa che ancora non ne è stato inviato alcuno.
***/
if(!isset($_GET["cookieTest"])){
$message="questo è un test" ;
/***
Quindi invio il cookie di prova
***/
setcookie("test",$message) ;
/***
Effettuiamo il refresh per leggere il cookie di prova appena inviato, e "marchio" il test passando via query_string la variabile "cookieTest"
***/
header("Location: ".$_SERVER["PHP_SELF"]."?cookieTest=1") ;
}
else{
/***
La variabile "cookieTest" esiste, quindi il cookie di prova è stato inviato ma evidentemente il browser lo ha rifiutato.
***/
$abilitato=0 ;
}
}
/***
L'array $_COOKIE non è vuoto quindi il browser accetta i cookie
***/
else{
$abilitato=1 ;
}
/*-----
Solo dimostrativo, non inserire nelle proprie pagine
-----*/
if($abilitato){
echo("Il tuo browser accetta i cookie, ecco la lista di quelli presenti<br><br>") ;
foreach($_COOKIE as $key=>$value){
echo("NOME: ".$key." VALORE: ".$value."<br><br>") ;
}
}
else{
echo("Il tuo browser rifiuta i cookie") ;
}
/*-----
fine dimostrativo
-----*/
?>
Il codice andrebbe incluso, prima di qualsiasi altro elemento, all'inizio di ogni pagina in cui vogliamo verificare la disponibilità del client ad accettare i cookie.
Chi opera con una versione di Php precedente alla 4.1 dovrà sostituire $_COOKIE con $HTTP_COOKIE_VARS, oppure adottare un metodo per garantire la compatibilità.
Eliminare i cookie
Se desideriamo far sì che il browser elimini un cookie che ha già memorizzato abbiamo due alternative.
Esempio:
<?php
/***
Una chiamata a setcookie() settando un valore vuoto per il cookie da cancellare.
***/
setcookie("nome_cookie_da_cancellare","") ;
?>
Alcuni browser hanno fatto riscontrare qualche malfunzionamento, fortunatamente esiste un'alternativa considerata più efficace.
Esempio più efficace
<?php
/***
Passare al cookie già esistente anche una data di scadenza anteriore al presente, inserendo nella chiamata tutti i parametri utilizzati a suo tempo per inviarlo.
Esempio per un coookie con scadenza 1 h.
***/
setcookie ("nome_cookie_da_cancellare","", time() - 3600,$path,$domain,0);
?>
Cosa memorizzare nei cookie?
"E adesso che ho imparato come funzionano cosa ci metto??"
Non esiste una risposta univoca a questa domanda, fondamentalmente un cookie (nei limiti dei 4K consentiti) può contenere qualsiasi stringa.
Nella prima pagina di questo articolo sono state elencate le 4 esigenze fondamentali che giustificano il ricorso ad una tecnica di tracciamento del navigatore, è a discrezione dello sviluppatore utilizzare i dati nel modo che ritiene migliore.
Personalmente trovo ideale il sistema adottato dalle sessioni: nel cookie non vengono salvate informazioni intellegibili ma soltanto un codice univoco che ad ogni richiesta collega l'utente a dati conservati in modo sicuro sul server.
Memorizzare soltanto un id univoco rende anche più semplice condividere un cookie tra dominii differenti, passando tale codice attraverso la query string e ricreando il cookie nel nuovo domain sarà possibile mantenere traccia dell'utente nel corso della navigazione tra diversi siti affiliati.
L'argomento potrebbe sembrare complicato, ma in un articolo di prossima uscita ci occuperemo proprio di illustrare dettagliatamente alcuni esempi concreti.
In ogni caso non è una buona idea affidare ai cookie dati come username e password: in primo luogo perchè viaggerebbero continuamente in chiaro dal client al server, inoltre, come se non bastasse, chiunque abbia accesso al PC potrebbe dare un'occhiata nella directory in cui i cookie persistenti vengono conservati.
Chi non ha particolari esigenze di sicurezza potrebbe prendere in considerazione la possibilità di criptare le informazioni sensibili da immagazzinare e poi effettuare un confronto con quelli conservati sul server... in ogni caso non si tratta di un bello stile con cui realizzare applicazioni "sicure".
Questioni di sicurezza
Di certo sarebbe una pessima soluzione quella di utilizzare un cookie per l'accesso ad un'area riservata se si identificassero gli utenti, una volta autenticati, nel modo seguente:
<?php
//pseudocodice
if nome_utente e password verificati
//pseudocodice
setcookie("autenticato",1) ;
?>
Chiunque scoprendo (o immaginando) il metodo per memorizzare l'avvenuto login potrebbe creare un normale file di testo con i parametri del cookie e inserirlo nell'apposita cartella del proprio browser.
E memorizzando il cookie soltanto nella RAM come quello dell'esempio appena visto?
Non sarebbe una soluzione molto più accettabile: per accertarvene provate lo script seguente inserendo nella funzione simula_cookie() l'indirizzo di una qualsiasi pagina php che fornisca un phpinfo().
<?php
function simula_cookie($host,$path){
$dati="" ;
$fp = fsockopen ($host, 80, $errno, $errstr,30);
socket_set_blocking ($fp,1) ;
if (!$fp) {
echo "$errstr ($errno)<br>n";
}
else{
fputs ($fp, "GET /$path HTTP/1.1rnHost: $hostrn");
fputs($fp,"Cookie:pluto=".urlencode('cane di Topolino')."; topolino=".urlencode('roditore padrone di Pluto').";rnrn") ;
while (!feof($fp)) {
$dati.= fgets ($fp,2048);
}
}
fclose ($fp);
echo($dati) ;
}
/*
Inserite come path l'indirizzo di una pagina dove vi sia un phpinfo()
*/
simula_cookie("www.dominio.xxx","test/info.php") ;
?>
Senza scendere in dettagli possiamo dire che si tratta di una connessione socket che simula la richiesta di un file al server nel modo in cui farebbe un browser: dopo qualche secondo di attesa otterremo stampato il consueto risultato del phpinfo(), ma controllando la voce "cookies" della tabella "HTTP Headers Information" risulta evidente che il nostro script ha imitato perfettamente anche la presenza di un cookie come se questo fosse stato memorizzato sul client.
Se invece di una pagina di prova si fosse trattato di un documento contenuto nell'area riservata, protetta così ingenuamente, il nostro script l'avrebbe raggiunto senza difficoltà inviando qualcosa tipo:
<?php
//connessione socket
fputs($fp,"Cookie: autenticato=1" ;rnrn") ;
//lettura documento
//chiusura connessione
?>
I cookie di terze parti, ovvero quelli "cattivi"
I cosiddetti "cookie di terze parti" sono quelli che hanno messo in cattiva luce l'intera categoria dei "biscottini" e fra poco capiremo il perchè.
Si tratta di cookie che vengono settati da un dominio totalmente differente da quello sulle cui pagine stiamo navigando....ma non avevamo detto che questo era impossibile?
Infatti è così, la pagina appartenenete al dominio www.xyz.net non può inviare un cookie con parametro "Domain=www.abc.net", in quanto verrebbe rifiutato, tuttavia esistono un paio di stratagemmi per aggirare l'ostacolo.
1)Iframe
Il metodo più semplice è quello di utilizzare un tag <iframe></iframe> (magari con dimensione pari a 0) in cui richiamare la pagina appartenente all'altro dominio, in questo modo si creerebbe una sorta di finestra dalla quale il cookie "estraneo" può essere settato. Questa soluzione richiede però la complicità del webmaster del sito in cui è stata predisposta la pagina con il frame "inline", mentre esiste un'alternativa più raffinata...
2)Cookie da un'immagine
Presentiamo subito lo script d'esempio che poi commenteremo.
- logoazienda.php: lo script del dominio www.abc.net che genera il cookie e il banner
<?php
/***
Pagina
"logoazienda.php"
genera un'immagine ma invia anche un cookie
***/
/***
Forza il mime_type e dice al browser come dovrà interpretare l'output che gli viene inviato (cioè come un'immagine
.gif)
***/
Header("Content-type: image/gif") ;
/***
Invia il cookie con il proprio domain
***/
SetCookie("spy","id_nav_ty6748392jturyd",time()+ 3600000,"/","www.prova.com") ;
if(isset($_COOKIE["spy"])){
/***[pseudocodice]
1) Se il cookie è già presente registra la pagina di provenienza dell'utente ($_SERVER["HTTP_REFERER"])
2) Aggiorna il database con i siti visitati dal navigatore a cui è stato assegnato quell'id
[/pseudocodice]***/
}
/***
L'immagine che compare nel banner pubblicitario
***/
$immagine="logo_azienda.gif" ;
/***
Legge il file d'immagine e invia l'output
***/
$fp=fopen($immagine,"rb") ;
$dati_immagine=fread($fp,filesize($immagine)) ;
fclose($fp) ;
echo($dati_immagine) ;
?>
pag_banner.html: appartiene al dominio www.xyz.net, visualizza il banner e indirettamente invia il cookie di terze parti
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body>
<img src="http://www.abc.net/immagini/logoazienda.php" width=100 height=30><br>
qui sopra
</body>
</html>
Come funziona esattamente?
"logoazienda.php" è uno script del dominio www.abc.net e genera un'immagine che dovrà comparire in un banner in "pag_banner.html", appartenente al sito www.xyz.net.
"pag_banner.html" contiene il normale collegamento al banner (<img src="http://www.dominio-estraneo.com/immagini/logoazienda.php" width=100 height=30>), però "logoazienda.php" è uno script che viene eseguito e anzichè limitarsi a generare l'immagine del banner invia anche il cookie "straniero".
Qual è lo scopo dei cookie di terze parti?
Possono rivelarsi molto utili al webmaster che voglia capire quante volte il logo del proprio sito venga visualizzato all'interno di un circuito per scambio banner, o che desideri monitorare in quali dominii esso venga esposto maggiormente.
Purtroppo è possibile farne anche un uso molto scorretto: invadere la rete con i propri banner (magari pagando fior di quattrini chi li espone) e raccogliere delle vere e proprie statistiche sui percorsi dei navigatori e sulle loro preferenze, tutto ciò con l'obiettivo di rivendere le preziose informazioni al miglior offerente.
Oggi i cookie di terze parti hanno vita difficile in quanto il browser più diffuso nella rete, MSIE 6, dopo anni di placida acquiscenza ha improvvisamente irrigidito le proprie impostazioni sulla privacy e, anche ad un livello di protezione medio, li rifiuta sistematicamente (spesso ingiustificatamente).
L'unico modo in cui il "povero webmaster onesto" possa farli accettare è dotare il sito di una "versione compatta dell'informativa sulla privacy"
..."ovviamente" Internet Explorer non applicherà alcun controllo sul reale rispetto delle garanzie a tutela del navigatore presenti nell' informativa.
Conclusioni
Ci siamo occupati a fondo di uno degli strumenti più utili nelle mani di un webmaster, purtroppo causa della loro intrinseca natura di dipendenza dal client non è possibile escludere completamente stranezze nel funzionamento dei cookie legate al tipo di browser utilizzato dal navigatore (o dalla versione dello stesso).
Allo sviluppatore non resta che sperimentare il più possibile, e magari tenere d'occhio i commenti inseriti dagli utenti sull' apposita pagina del manuale online (una vera miniera di informazioni).
Questo articolo piuttosto teorico è una premessa indispensabile alla comprensione delle applicazioni pratiche, che esamineremo in un tutorial di prossima uscita.
