Le "sessioni" nello sviluppo web
Scritto da Marco Balestra Tue, 04 Dec 2007 09:10:00 GMT
Una delle più belle leggende metropolitane relative allo sviluppo web è quella che riguarda "le sessioni".
Indubbiamente uno strumento potente, purtroppo fondamentalmente frainteso.
L'intezione di questo intervento è quella di stroncare due dei luoghi più comuni e più sbagliati legati all'uso delle sessioni nello sviluppo web.
La natura del web
La comunicazione via web è stateless, e lo è a causa della sua stessa natura (basata sul protocollo HTTP).
Questo non vale in caso di applet (java o flash o altro) lanciate dentro una pagina web, ma per questo discorso ci limitiamo a parlare di tecnologie web vere e proprie: html e dhtml, ovvero javascript (compreso AJAX).
"Stateless" significa che ogni contatto tra il client ed il server deve ricominciare daccapo.
Non c'è una continua relazione tra client e server, non c'è modo di sapere per il server se il client è sempre connesso, se ha chiuso la finestra o altro.
Ogni chiamata, ogni richiesta, deve essere trattata come se fosse la prima chiamata che il client (browser) fa al server.
Per evitare di dovere ogni volta ricominciare tutto daccapo (ad esempio spedire ogni volta nome utente e password per farsi riconoscere) il protocollo HTTP prevede la possibilità (non l'obbligo) che il server faccia ricordare alcune stringhe di testo sul client, i cosiddetti "cookies".
Primo luogo comune: la sessione come alternativa ai cookies
Si tratta di uno dei luoghi comuni più diffusi, spesso e volentieri si sentono frasi come "usiamo la sessione, non i cookies", oppure si asserice che la sessione serva "per chi non ha i cookie abilitati", come è accaduto anche su it.comp.macintosh.
Non è strano che questo luogo comune sia arrivato su it.comp.macintosh, in fondo è un luogo comune.
L'aspetto triste è che l'impoverimento tecnico di ICM ha fatto sì che passasse inosservato, che nessuno rispondesse; neanche i top posters.
Il fondamento è la logica all'origine: la possibilità di registrare i dati della visita nei cookies dell'utente contro quella di registrarli in una area temporanea di memoria del server (la "sessione") associata al visitatore.
L'errore, invece, nasce dalla non conoscenza effettiva della tecnica utilizzata.
Il punto è: come avviene l'associazione?
Come fa il server ad associare quella finestra di quel browser a quella specifica sessione?
Indovinate... Ma sì: con un cookie!
Questo cookie contiene il "session-id", ed i dati della visita sono poi registrati sul server.
La semplice prova pratica è che nessuno dei sistemi di sessioning attualmente in uso nei vari web framworks funziona se i cookie non sono abilitati.
Tecnicamente sarebbe possibile appoggiandosi al meccanismo di riconoscimento esclusivamente server-side operato da Apache con l'autenticazione di tipo Basic o Kerberos, ma la pretesa degli ambienti di sviluppo web (ASP, JSP e tutti i framework in genere) di girare indipendentemente dal server web e dalla sua configurazione effettiva rende questa prospettiva di fatto non realizzabile.
Una integrazione a quanto detto…
Mar1o mi fa giustamente notare che la sessione (ovvero il session-id) può essere conservato modificando ogni singolo URL presente sulla pagina, in modo da evitare di utilizzare cookies.
Questo è effettivamente vero, ed a volte utilizzato, ma tecnicamente presenta alcuni sostanziali svantaggi che ne limitano l'applicabilità e la diffusione:
- Tutti gli URI presenti vanno modificati, e questo include anche tutti gli URI per le action dei Form, in GET o in POST che siano.
- Un cookie viaggia con tutte le richieste HTTP nello stesso ambito secondo "SOP" (server e directory di competenza), e quindi anche ad esempio con le richieste AJAX. In caso di session-id legato alla URI invece javascript non potrebbe chiamare sempre la stessa URI per le sue richieste, ma dovrebbe modificarsi e/o associare la sicurezza ad una forma diversa di trasmissione della session-id.
- Infine l'embed del session-id nella URI di tutte le richieste implica la necessità di un web server in grado di manipolare correttamente la richiesta, tipicamente Apache con mod_redirect o simili, ed una configurazione di sito (o file .htaccess) scritti ad-hoc.
Diciamo che comunque nella stragrande maggioranza dei casi "la sessione" significa comunque un cookie di session-id registrato sul browser.
Secondo luogo comune: la sessione per ovviare alla natura stateless
La scoperta dei meccanismi automagici porta quasi inevitabilmente chi non conosce la natura del media che sta utilizzando a fare una gran confusione, ed a riempirsi la testa di castelli di idee sbagliate.
La sessione è un esempio clamoroso di questo effetto, diffuso soprattutto tra gli sviluppatori ASP/JSP, ma anche la convinzione che il Send/Redirect possa essere inviato al client in qualunque momento (anche dopo l'output) non è uno scherzo da poco.
In completa inosservanza di queste queste errate convinzioni, però, il protocollo alla base è sempre l'HTTP.
E per quanto si cerchi di convincerlo a diventare una interfaccia applicativa la sua natura rimarrà sempre stateless: potrà sempre chiudersi senza dire "ciao", potrà sempre fare "back" nel browser per quanti barbatrucchi cerchino di impedirlo, potrà sempre creare una nuova finestra per una navigazione indipendente senza chiederne il permesso e senza informarne il server.
Sono sempre più contenta di aver mollato ICM.
In realtà c'è /chi/ l'ID di sessione lo propaga negli URI (penso a PHP configurato in un certo modo - non che sia una idea particolarmente geniale ma insomma...). Ma non è il caso del link da cui è partito quel post su ICM, direi.
s/post/thread/
Hai ragionissima, Mar10, è una opzione a cui non avevo pensato. In effetti apre una terza via che alcuni usano (ad esempio anche il forum di faqintosh ! :-D), ma che non sono portato a considerare come strumento di effettivo front-end applicativo.