BETA
Sommario
Per comunicare con la redazione per la posta di BETA scrivere a info@beta.it. È possibile utilizzare anche il Forum di discussione di BETA, all'indirizzo http://www.beta.it/forum

Indice

Prendiamo spunto da questo messaggio per approfondire uno degli argomenti più in voga attualmente nei salotti del Web, i famigerati "cookie", i biscotti che si scambiano quotidianamente milioni di Browser e server nel mondo. Chiariamo alcuni concetti e del perchè non c'è da nulla da temere dai cookie bensì da altre procedure che li utilizzano.
Subject: Cookies
From:
Massimo Barberio
Date: Fri Mar 21 08:20:26 CET 1997
 Vorrei avere maggiori informazioni sull'oggetto "Cookie".
Grazie
Risponde Luciano Giustini

I cookies sono file di testo posti nel nostro computer e gestiti dal Browser Web. Nel caso di Netscape e Windows, questo file è cookies.txt posto nella directory di Netscape. Nel caso di Internet Explorer e Windows, e' un insieme di file sparsi per la directory cookies posta sotto la directory di Windows stesso, creando un file per ogni cookie. Alla Microsoft vanno pazzi per sprecare spazio e fare confusione, ma passiamo oltre :-)
Dicevamo sono gestiti dal Browser. In realtà chi passa i dati da scrivere non è il Browser ma il server oppure delle procedure JavaScript o Java (penso anche ActiveX e VBScript, ma non ne sono sicuro). D'ora in poi prenderemo per assunto l'utilizzo di Netscape Navigator in quanto è quello che conosco meglio, e anche lo strumento più idoneo per gli sviluppatori che vogliono fare delle prove.
Diciamo subito che i cookies non sono oggetti pericolosi, o almeno non involontariamente, come vedremo dopo. Tutto quello che viene scritto nei file cookie non è inventato dal server o dal webmaster di un sito, o dal perfido direttore del marketing che vuole carpirvi ogni segreto sulla vostra vita virtuale. No, ogni cookie viene scritto con dati generati dall'utente, o comunque reperibili in altro modo, come il tipo di Browser, il numero di accessi a certi settori, e via dicendo. Possiamo dire dunque che i cookie sono informazioni generate dall'utente nella sua navigazione ma rese persistenti per averle scritte da qualche parte. Aggiungiamo il fatto che queste informazioni, risiedendo nel computer dell'utente, possono essere cancellate in qualsiasi momento (semplicemente rimuovendo la riga interessata), e abbiamo capito che non si tratta di nulla di pericoloso. Anzi, nella stragrande maggioranza dei casi l'utilizzo del cookie è un servizio in più, per il navigatore, reso dal sito, che può mettergli a disposizione particolari pagine personalizzate, o riconoscerlo dandogli solo le informazioni che desidera e così via.

Un esempio pratico
Un cookie è una riga di testo scritta appunto nel file cookie. Ogni riga non può superare 4KB in dimensione e ogni sito (dominio) non può scrivere più di 20 cookie. Infine, in tutto ci possono essere 300 cookie, quindi 300 righe. Come si scrive un cookie? Facciamo un esempio: una pagina su Internet contiene molte cose interessanti, e per questo il suo gestore ci ha messo un bel contatore...ma volendo spuntare qualche sponsorizzazione, questi vuole sapere anche quante volte la stessa persona la visita, per avere un'idea dell'interesse continuato che la pagina riesce a generare, e quindi la "fedeltà" che comporta. Per fare questo anzitutto usa un cookie, e scrive presso l'utente un identificatore la prima volta che passa di lì. In JavaScript la relativa istruzione avrà questa sintassi:

<SCRIPT LANGUAGE="JavaScript"> function ScriviId() { document.cookie("TiConoscoMascherina=1; expires=Sunday, 31-Dec-97 12:00:00 domain=pagine.sito.it path=/mia_pagina;"); } </SCRIPT> In realtà la funzione completa necessita anche di una procedura che vada a vedere se esiste già il cookie con il nome TiConoscoMascherina e una che incrementa il valore 1 di tante volte quante sono le visite. Lascio al lettore l'esercizio di scriverle :-))
Dunque vediamo i campi interessanti. Ogni cookie ha un nome e un valore, in questo caso TiConoscoMascherina e 1. Gli altri campi sono opzionali ma consigliati. Il valore expires, per esempio, se omesso fa si che il cookie termini con la connessione corrente: puff! Il campo domain di default è posto al TLD dal Browser se non diversamente specificato. In questo caso sarebbe stato .sito.it e potrebbe interferire con altri eventuali cookie posti dal webmaster del sito. Il path, infine, è la directory del sito su cui il cookie deve agire. Se si vuole che il cookie sia utilizzabile da tutto il sito, il valore da porre è "/".

I valori possono essere archiviati?
Si è usato JS, ma poteva essere uno script CGI (utilizzando la variabile ambientale HTTP_COOKIE), o Java, o altro ancora. L'importante è capire il sistema. Quando ci ricollegheremo alla pagina in questione, un altra procedura leggerà il valore TiConoscoMascherina e poi... finisce qui. Infatti, l'utilizzo dei cookie è prettamente on-line e gestito da routine di controllo, ma per archiviare i dati presso il server è necessario memorizzarli, per esempio su un database tramite un POST (FORM ACTION=POST).
Qui possono esserci delle "trappole", intese come un qualcosa non comunicato all'utente. Proseguendo sull'esempio fin qui raccontato possiamo suppore che il gestore di questa pagina sia un po' birichino, e ponga una innocua immagine sulla pagina, che magari deve essere cliccata per forza per accedere alle parti interessanti, dietro alla quale si cela una istruzione FORM con METHOD=POST. Cosa succede quando l'utente clicca sull'immagine? Una procedura legge il valore del (o dei) cookie interessato; pone il valore in una variabile; pone la variabile dentro un campo INPUT di tipo HIDDEN; pone il tutto dentro una FORM con METHOD POST; al click la variabile viene salvata sul server.
In questi casi il nostro beneamato Netscape ci viene in aiuto e ci avvisa che stiamo inviando qualcosa al server. Attenzione, non quegli inutili avvisi sui cookie, che di per sè non costituiscono nessunissimo pericolo, perchè sono valori locali resi persistenti (io consiglio di togliere l'avviso), ma i più generali avvisi di invio di una form e di una form via e-mail. Io consiglio quindi di tenere abilitati questi due avvisi che a molti sembreranno un'inutile scocciatura, ma permettono di essere avvertiti in tempo di eventuali dati inviati senza che l'utente sia informato.

Nota importante
Una cosa che ritengo doveroso far notare e che spesso è fonte di dubbi o incomprensioni, è la ritrasmissione dei cookie al solo server che li ha generati. Se la vostra pagina scrive un cookie con la procedura che abbiamo visto sopra, automaticamente come prima stringa della riga viene scritto il dominio di appartenenza. Tutti i dati che voi avete scritto potranno essere letti solo dalla vostra pagina o, se come path avete messo "/", solo dal vostro sito. Nessun altro potrà leggere i dati che voi avete posto nel cookie.

Cosa fare e cosa no
Tornando ai cookie, so che molti rispondono sempre di NO alla richiesta di scrittura, pensando che questo sia la panacea di tutti i mali. Certo, in questo modo il vostro sito birichino non utilizzerà i valori del cookie e non potrà sapere proprio tutto quello che vuole, ma forse dimenticano (o non sanno) l'esistenza delle variabili d'ambiente restituite dal Browser al server. Queste contengono molte più cose interessanti di quanto si possa pensare, e non sono bypassabili. Così, oltre a non ottenere nessuna sicurezza, rendono la vita molto più difficile a coloro (come chi scrive :-) che utilizzano i cookie con correttezza e per rendere servizi aggiuntivi agli utenti. Per esempio la Main Page di BETA, ultimamente, alla prima visita chiede di registrarsi con un proprio nominativo. E' ben spiegato che vengono utilizzati i cookie e che i dati verranno salvati localmente, come esplicitamente evidenziato dalla presenza di un bottone.

Un esempio utile di cookie
Invece di sapere quante volte si accede alle pagine, molti siti offrono dei servizi più "seri", se vogliamo, ai propri visitatori, utilizzando i cookie per riconoscerli e offrirgli delle pagine "su misura". Uno dei casi meglio strutturati e interessanti per lo studio dei cookie è la "Netscape PowerStart", reperibile a partire dall'indirizzo http://personal.netscape.com/custom/page/show_page.html

Indirizzi utili
http://www.netscape.com/newsref/std/cookie_spec.html
http://www.packet.com/garfinkel
http://www.illuminatus.com/cookie

Riceviamo e volentieri pubblichiamo


Subject: SCANNER
From:
Ufficio Stampa DADAnet Italia
Date: Wed, 19 Mar 1997 20:27:01 +0100
Salve,
le comunico che e' attivo DADAScanner 
http://scanner.dada.it

E' un nuovo Magazine elettronico di opinione e commenti con redazioni in
tutta l'Italia.

Si punta sulle notizie, ma soprattutto sui commenti, sulle recensioni, 
insomma sulle idee. 
La scommessa di DADAScanner e' infatti quella di tentare di uscire dagli
schemi delle solite pubblicazioni elettroniche, per sviluppare
unĈinformazione puntuale, in grado di soddisfare gli interessi di un
pubblico sempre piu' ampio, ma anche per incentivare discussioni e
riflessioni fra i navigatori di Internet.
La scelta degli argomenti che caratterizzano DADAScanner non e' certo
casuale. Ci interessa dire la nostra su dischi, film e libri, dando risalto
anche a opere e autori meno noti, ma non per questo meno interessanti. 
Lo spazio live e' dedicato agli spettacoli e alle performance in genere
(dagli eventi teatrali ai concerti, ma anche mostre, convegni), quello
strips alle vignette ed abbiamo previsto anche una sezione dedicata ai
racconti. I primi ad andare on line saranno i primi tre episodi della saga
"Intronet", che giÓ dalla seconda puntata prevede un attivo interscambio fra
lĈautore e i lettori.
Non poteva ovviamente mancare in una rivista telematica una riflessione
sullo web e quindi uno specifico spazio a questo dedicato, ma anche in
questo abbiamo cercato di dare un taglio diverso dal solito, meno
prevedibile. La stessa cosa vale per gli ospiti che, come dicevamo, oltre a
rispondere alle domande di DADAScanner, sono a diretto contatto con i
lettori tramite E-mail.

DADASCANNER e' in Web sulla rete DADAnet Italia

Riceviamo e (ridacchiando :-) volentieri pubblichiamo


Subject: Windipendence Day
From:
Andrea Nenni
Date: Sun, 16 Mar 97 14:18:10 +0100

            >>>>>>>>>>>>> Windipendence day <<<<<<<<<<<<<<<

Comandante Alieno: "Armiere, inquadri la prima citta' di quegli
schifosi terricoli".
Armiere Alieno: "Inquadrata. New York, sull'isola di Manhat~1."
CA: "Aprire il fuoco!"

Pausa musicale. Sul monitor compare la scritta "Sei sicuro di voler
incenerire i 1 oggetti selezionati?"; l'armiere seleziona SI. Pausa.
Sovrimpressa a New York, compare una processione di foglietti
svolazzanti, che vengono inceneriti, uno ad uno, da raggi laser di
vari colori. Compare un messaggio: "SYSTRAY ha eseguito una istruzione
non ammessa all'indirizzo 017AC:00008 e sara' terminato."

Fuori, New York e' sempre intatta.

Preoccupato, l'armiere verifica il pannello di controllo (Impostazioni)
e sfoglia le varie cartelline. Aprendo "Armamento", viene sciorinata una
lunga teoria di voci, alcune in grigio, altre decorate da un cerchietto
giallo con un punto esclamativo.

La cartella "Proprieta'" informa che le armi per distruzione spazio-terra
sono
            "La periferica non e' installata, non funziona
             correttamente, o non tutti i driver sono stati
             installati. Errore 010".

L'armiere seleziona "Guida - Risoluzione problemi", e viene informato che
deve
            "Verificare che i cavi di collegamento siano inseriti
             e le armi ricevano corrente.

             Verificare che ci siano proiettili nel caricatore, se
             l'arma ne prevede uno.

             Se l'arma continua a non funzionare, contattare l'
             armiere."

L'armiere tenta eroicamente di contattare se stesso, si inlooppa e muore.

Dopo alcuni minuti, il programmatore capo scopre che la causa del
conflitto e' da ricercarsi in un gestore del carburante installato
poco fuori Betelgeuse e poi rimosso, ma i settaggi del quale permangono
nei registri di configurazione dell'astronave.

Le procedure di reinizializzazione prevedono che l'astronave ritorni in
orbita oltre Plutone e da li' ricominci l'avvicinamento alla Terra.

Poco oltre Marte, il pannello di controllo si anima e, verificando che
l' ID del nuovo armiere differisce dal precedente, snocciola alcune
pagine allusive sulla pirateria informatica. Ricevuto l'OK, procede a
reinstallare la versione precedente del software, corredata di errore,
costringendo l'astronave a tornare per la terza volta su Plutone.

Qui, dopo aver esiliato i softwaristi su Caronte, aver reinstallato
oculatamente tutti i drivers dai CD-ROM, e aver saturato il canale
subspaziale di assistenza on-line, l'astronave riparte. Purtroppo, per
motivi di compatibilita', puo' usare solo i motori a impulso a 16 bit,
ed arriva sulla Terra solo un mese piu' tardi.

Nuovamente sopra New York, il comandante ordina di aprire il fuoco.
Stavolta, un laconico messaggio informa che la periferica "destroyer"
e' gia' in uso da oltre un mese, e un comando di distruzione e' gia'
in coda. Si desidera svuotare la coda?

Pazzo di rabbia, il comandante da' l'ordine; immediatamente, compare una
scritta su uno sfondo di nubi che informa dell'imminente arresto del
sistema. Dopo un paio di minuti, mentre i navigatori tentano di impedire
la catastrofe, una scritta arancio su sfondo nero annuncia orgogliosa che
il sistema e' fermo. Un improvviso scossone spiaccica tutti gli occupanti
contro le pareti, spedendo l'astronave in orizzontale a parecchi
chilometri
al secondo.

Priva di supporto anti-G, la grande astronave perde rapidamente quota,
in rotta di collisione con una inerme citta' costiera.

Ma questa storia non avra' un lieto fine: un imprevisto windshear alza
l'astronave quel tanto che basta per farla precipitare nell'oceano,
risparmiando Seattle.


Principale Sommario Informazioni Redazione Browser

Copyright © 1994-97 BETA. Tutti i diritti riservati