DOM (Document Object Model) manipolato attraverso un linguaggio ECMAScript come JavaScript o JScript per mostrare le informazioni ed interagirvi;

Transcript

1 Capitolo 5 AJAX AJAX è uno strumento di sviluppo per la realizzazione di applicazioni web interattive. La sua tecnologia si basa su uno scambio asincrono di dati in background fra web browser e server, che consente l aggiornamento dinamico di una pagina web senza esplicito ricaricamento da parte del browser, e i dati sono richiesti al server e caricati in background senza interferire con il comportamento della pagina esistente. Normalmente le funzioni richiamate sono scritte con il linguaggio JavaScript. AJAX è multi-piattaforma utilizzabile su molti sistemi operativi, architetture informatiche e browser, ed esistono numerose implementazioni open source di librerie e framework. Come DHTML o LAMP, AJAX non è una tecnologia individuale, ma piuttosto è un gruppo di tecnologie che utilizza una combinazione di: HTML (o XHTML) e CSS per il markup e lo stile; DOM (Document Object Model) manipolato attraverso un linguaggio ECMAScript come JavaScript o JScript per mostrare le informazioni ed interagirvi; l oggetto XMLHttpRequest per l interscambio asincrono dei dati tra il browser dell utente e il server. In alcuni framework e in certe situazioni, può essere usato un oggetto Iframe invece di XMLHttpRequest per scambiare i dati con il server e, in altre implementazioni, come script aggiunti dinamicamente (JSON); in genere viene usato XML come formato di scambio dei dati, anche se di fatto qualunque formato può essere utilizzato, incluso testo semplice, HTML preformattato, JSON e perfino EBML. Questi file sono solitamente generati dinamicamente da script lato server. Le applicazioni web che usano AJAX richiedono browser che supportano le tecnologie necessarie. Tra questi browser si includono: Mozilla, Firefox, Opera, Konqueror, Safari, Internet Explorer e Chrome. Tuttavia, per specifica, Opera non supporta la formattazione degli oggetti XSL. 5.1 Cenni storici L acronimo AJAX, che significa esattamente Asynchronous JavaScript And XML (JavaScript asincrono ed XML), è stato enunciato per la prima volta da Jesse Garrett, nel 18 Febbraio 2005, come titolo di un post all interno del suo blog. Non si tratta di una nuova tecnologia, ma di un concetto utilizzato per sviluppare applicativi avanzati e particolari come Gmail o Google Maps. Il concetto è in parte espresso nell acronimo scelto, un utilizzo asincrono di JavaScript che attraverso l interfacciamento con XML, può permettere ad un client di richiamare informazioni lato server in modo veloce e trasparente, allargando gli orizzonti delle rich internet applications. Questo tipo di applicazioni fino a poco tempo fa erano legate principalmente alle tecnologie Flash o Java (con le applet), oppure all introduzione l iframe (nel 1996 in Internet Explorer 3), che molti sviluppatori sfruttarono modificando l attributo sorgente (src) della pagina racchiusa e simulando così un refresh trasparente di una parte di contenuti il che emulava, in modo non certo pulito, un interazione asincrona. Nel 1998 Microsoft cominciò a sviluppare la tecnologia chiamata Remote Scripting, con lo scopo di creare una tecnica più elegante per richiamare contenuti differenti ed è in questo periodo, seppur con 29

2 30 CAPITOLO 5 AJAX nome differente, che AJAX venne utilizzato per la prima volta, per poi evolversi in versioni più mature fino a diventare un oggetto vero e proprio, noto ora come XMLHttpRequest. Il motivo principale di tanto successo è che solo ultima- Figura 5.1: Il logo di AJAX mente il Remote Scripting ha suscitato lo stupore degli addetti ai lavori nel vedere cosa Google fosse riuscita a fare all interno dei suoi applicativi senza necessità di Flash Player o Java Virtual Machine, mantenendo comunque la compatibilità con molteplici browser di utenti che per diversi motivi non potevano usufruire di JavaScript. Come spesso è accaduto negli ultimi anni, molti hanno preso spunto da Google ed il web, noto per la sua immediatezza propositiva, è stato in grado in poco più di un anno di applicare in numerose occasioni applicativi basati su AJAX, considerando molto spesso e fin da subito, a differenza di quanto accadde per Flash ed Applets anni prima, due delle problematiche più diffuse del web attuale: accessibilità ed usabilità. 5.2 Confronto con applicazioni tradizionali Le applicazioni web tradizionali consentono agli utenti di compilare moduli e, quando questi moduli vengono inviati, viene inviata una richiesta al web server. Il web server agisce in base a ciò che è stato trasmesso dal modulo e risponde bloccando o mostrando una nuova pagina. Dato che molto codice HTML della prima pagina è identico a quello della seconda, viene sprecata moltissima banda, e visto che una richiesta fatta al web server deve essere trasmessa su ogni interazione con l applicazione, il tempo di reazione dell applicazione dipende dal tempo di reazione del web server. Questo comporta che l interfaccia utente diventa molto più lenta di quanto potrebbe essere. Le applicazioni AJAX, d altra parte, possono inviare richieste al web server per ottenere solo i dati che sono necessari (generalmente usando JavaScript per mostrare la risposta del server nel browser). Come risultato si ottengono applicazioni più veloci (la quantità di dati scambiati fra il browser ed il server si riduce), ed anche il tempo di elaborazione da parte del web server si riduce poiché la maggior parte dei dati della richiesta sono già stati elaborati. Molti siti, ad esempio, usano le tabelle per visualizzare i dati, e per cambiare l ordine di visualizzazione delle righe, con un applicazione tradizionale l utente dovrebbe cliccare un link nell intestazione della tabella che invierebbe una richiesta Figura 5.2: Confronto di come un applicazione web tradizionale elabora l interazione dell utente e come invece lo fa un applicazione AJAX al server di ricaricare la pagina con il nuovo ordine. Il web server allora invierebbe una nuova query SQL al database ordinando i dati come richiesto, la eseguirebbe, prenderebbe i dati e ricostruirebbe da zero la pagina web rinviandola integralmente all utente. Usando le tecnologie AJAX, questo evento potrebbe essere eseguito con un JavaScript lato client che genererebbe dinamicamente una vista dei dati con il DHTML. Un altro esempio potrebbe essere la scelta di un nuovo nickname in fase di creazione di un account in un sito web, nel caso classico, se il nome che abbiamo scelto fosse già esistente, dovremmo compilare tutto il modulo ed accorgerci solo dopo aver atteso il caricamento della pagina di

3 5 3 DESCRIZIONE 31 conferma che il nome è già esistente e dobbiamo cambiarlo, invece con AJAX può essere introdotto un controllo sull evento onchange o onkeyup della casella di testo che ci può informare tempestivamente che il nome inserito non è valido, magari evidenziando il testo in rosso utilizzando i css e dei JavaScript (vedremo che questo l ho implementato in QuASE). 5.3 Descrizione Parlando di AJAX parliamo di un oggetto specifico: XMLHttpRequest. A seconda del browser usato prende nomi differenti o viene richiamato in maniera differente. Nel caso di Internet Explorer, ad esempio, questo oggetto è restituito da un ActiveXObject mentre nei browsers alternativi più diffusi (Firefox, Safari, Opera, ecc.) XML- HttpRequest è supportato nativamente, cosa che dovrebbe accadere anche per IE dalla versione 7. Questo oggetto permette di effettuare la richiesta di una risorsa (con HTTP) ad un server in modo indipendente dal browser, e nella richiesta è possibile inviare informazioni, ove opportuno, sotto forma di variabili di tipo get o di tipo post in maniera simile all invio dati di un form. La richiesta è asincrona (vedi figura 5.3), il che significa che non bisogna necessariamente attendere che sia stata ultimata per effettuare altre operazioni, cambiando radicalmente il flusso dati tipico di una pagina web. Generalmente infatti il flusso è racchiuso in due passaggi alla volta, richiesta dell utente (link, form o refresh) e risposta da parte del server per poi passare, eventualmente, alla nuova richiesta da parte dell utente. L incomodo di questo ciclo è l attesa che trascorre tra una richiesta dell utente e la risposta del server, ma con l aggiunta di AJAX si perde questa linearità e mentre l utente è all interno della stessa pagina le richieste sul server possono essere numerose e completamente indipendenti. Figura 5.3: Confronto di come i componenti delle applicazioni AJAX interagiscono tra loro e quello che invece accade nelle applicazioni web classiche Chi conosce già JavaScript, HTML e CSS, trova abbastanza semplice entrare nel mondo della programmazione AJAX. In particolare è bene conoscere l attributo innerhtml di un elemento o le specifiche DOM create appositamente per aggiungere, popolare o modificare elementi della pagina. Nei casi più semplici non si fa altro che sovrascrivere il contenuto di un elemento del documento visualizzato e quello che serve è solo una funzione in grado di restituirci l elemento richiesto. Le funzioni più note per fare questo sono getelementbyid e getelementsbytagname ed entrambe possono essere sfruttate per usare il metodo innerhtml oppure il DOM. Ad esempio getelementbyid è un metodo dell oggetto document, la pagina visualizzata, e cerca al suo interno un tag HTML con un particolare valore dell attributo id (questo metodo, come altri, non è compatibile con vecchie versioni di IE). Altri punti importati da conoscere per un utilizzo approfondito di AJAX sono: i metodi del DOM per la creazione avanzata di contenuti strutturati, innestati, dinamici; i metodi del DOM per la creazione, gestione e manipolazione di dati XML; le gestioni di intervalli di tempo multipli o incrociati attraverso l uso di setintervall o settimeout; la conoscenza di almeno un linguaggio lato server; la conoscenza di almeno un tipo di database, gestibile attraverso il linguaggio server side scelto; la conoscenza delle misure di sicurezza necessarie per rendere meno vulnerabile il codice lato server;

4 32 CAPITOLO 5 AJAX la conoscenza delle misure di sicurezza necessarie per evitare sql injections sul database; la capacità organizzativa per la gestione di più flussi dati asincroni; la conoscenza di HTML, CSS, XML (al di fuori di ambienti di sviluppo visuali WYSIWYG come DreamWeaver, FrontPage, ecc.). la programmazione e lo sviluppo Object Oriented, sia JavaScript che server side. 5.4 I metodi Definito l oggetto, è indispensabile conoscerne metodi e parametri al fine di sfruttarlo al meglio a seconda delle necessità. La lista dei metodi è diversa per i diversi browser, ecco quindi una lista dei metodi supportati da tutti i browsers AJAX compatibili : open send abort getallresponseheaders getresponseheader setrequestheader Questi metodi permettono di effettuare le varie operazioni asincrone. open Il primo ad essere usato per effettuare una chiamata asincrona è il metodo open, il quale è definito dal W3C [20] per accettare 5 parametri: open ( method, u r i [, async ] [, u s e r ] [, password ] ) Il primo parametro è una stringa che indica il metodo di invio dati che può essere get o post. La differenza principale tra questi due metodi è la stessa di un normale form HTML: scegliendo get le variabili verranno appese alla pagina selezionata (MyView.php?codice=valore codice), mentre utilizzando post queste verranno inviate in modo invisibile all utente e senza i limiti tipici del get. Entrando nel dettaglio, il limite principale di una chiamata get, non direttamente presente in post, è il numero di caratteri che si possono inviare (che varia a seconda del browser), solitamente pari ad un massimo di 256 (vedremo nella sezione 11.1 nella pagina 83 come è stato affrontato questo limite riscontrato nella Gesitone Documentale del QuASE). D altro canto è molto più comodo e semplice inviare questi dati sotto forma di link e sarà quindi cura dello sviluppatore scegliere il metodo più idoneo per quel tipo di scambio dati. Per il metodo post il limite può essere imposto dal server dell host che fornisce il servizio, configurato per non ricevere più di un certo numero di Bytes di dati per ogni richiesta post, solitamente pari ad 8Mb (un limite trascurabile per la maggior parte delle applicazioni). Il secondo parametro del metodo open è il nome della pagina da leggere, rappresentato anch esso da una stringa, che può essere descritto con indirizzo assoluto (" index.php"), oppure come percorso relativo ("View/ViewMenu.php" se ci si trova in " ferrolieassociati.it/ [...]/www/"). Il terzo parametro è un valore booleano da impostare a true se la richiesta da effettuare è di tipo asincrono. send Altro metodo da utilizzare per effettuare una richiesta in get è: send ( data ) Ecco un esempio di come effettuare una semplice richiesta get inviando un valore nullo:

5 5 5 I PARAMETRI 33 a j a x. open ( get, MyView. php? c o d i c e=v a l o r e c o d i c e, t r u e ) ; // i n i z i a l i z z o l a r i c h i e s t a i n get a j a x. send ( n u l l ) ; // e f f e t t u o l a r i c h i e s t a Per una chiamata post bisogna invece impostare comunque degli headers prima di effettuarla. Questi headers sono una serie di coppie chiave/valore specifici per uno scambio dati via internet, e in questo caso bisogna specificare la coppia con nome content-type e valore application/x-www-form-urlencoded ed usare send() per inviare le variabili spedendo anche queste come coppie chiave/valore; questo a differenza del metodo get in cui le variabili potevano essere contenute nell indirizzo. Ecco un esempio: a j a x. open ( p o s t, MyView. php, t r u e ) ; // i n i z i a l i z z o l a r i c h i e s t a i n p o s t a j a x. s e t R e q u e s t H e a d e r ( content type, a p p l i c a t i o n /x www form u r l e n c o d e d ) ; // imposto i l g i u s t o header a j a x. send ( c o d i c e=v a l o r e c o d i c e ) ; // e f f e t t u o l a r i c h i e s t a i n v i a n d o l a v a r i a b i l e e i l suo v a l o r e Per chiudere la connessione con il server, oltre al tipo di contenuti è consigliabile impostare un altro header dal nome connection e con contenuto pari a close: a j a x. s e t R e q u e s t H e a d e r ( c o n n e c t i o n, c l o s e ) ; abort Se si ha bisogno di interrompere le operazioni di invio o ricezione, si può usare abort(), ad esempio subito dopo una operazione di send. Questo metodo non ha bisogno di parametri e termina immediatamente la trasmissione dati. getallresponseheaders e getresponseheader Questi due metodi servono per fornire, una volta effettuata l operazione, le informazioni sugli headers rilasciati dal server che ha risposto alla chiamata. a l e r t ( a j a x. g e t A l l R e s p o n s e H e a d e r s ( ) ) ; // l i s t a d i t u t t i g l i h e a d e r s r e s t i t u i t i d a l s e r v e r a l e r t ( a j a x. getresponseheader ( content type ) ) ; // i n f o r m a z i o n i su un s i n g o l o header Va sottolineato che questi ultimi due metodi non sono utilizzabili subito dopo l invio dei dati, ma solo una volta ricevuta la risposta dal server. Queste istruzioni possono essere quindi inserite all interno della funzione che gestirà l evento onreadystatechange che si verifica alla ricezione della risposta. 5.5 I parametri La lista dei parametri comunemente supportati dai vari browsers è la seguente: readystate status statustext responsetext responsexml onreadystatechange L unico a non essere pienamente supportato è statustext, il quale potrebbe non essere assegnato su Opera.

6 34 CAPITOLO 5 AJAX readystate Il primo e fondamentale parametro da considerare durante uno scambio dati in AJAX è readystate: è una variabile di tipo intero, con valori che vanno da 0 a 4; è un parametro di sola lettura che rappresenta in ogni istante lo stato della richiesta. Gli stati che la richiesta può assumere sono: 0 Uninitialized l oggetto XMLHttpRequest esiste, ma non è stato richiamato alcun metodo per inizializzare una comunicazione; 1 Open è stato richiamato il metodo open() ed il metodo send() non ha ancora effettuato l invio dati; 2 Sent il metodo send() è stato eseguito ed ha effettuato la richiesta; 3 Receiving i dati in risposta cominciano ad essere letti; 4 Loaded l operazione è stata completata. Questo ordine (ancora da [20]) non è sempre identico e non è sfruttabile allo stesso modo su tutti i browsers. L unico stato supportato da tutti è il 4, che a prescindere dalla riuscita dell operazione, comunicherà che l oggetto non avrà più nulla da fare e che il cambio di stato dello stesso non andrà oltre quel valore. Quando readystate assume un valore pari a 3, cosa che non sempre accade soprattutto qualora la richiesta dovesse fallire, si possono già conoscere alcuni headers restituiti dal server come la lunghezza del testo (content-length), il tipo di testo restituito (txt, html o xml) e quanto testo è stato ricevuto in quel momento grazie alla lunghezza della stringa responsetext. Queste informazioni, purtroppo non reperibili sulle varie versioni di IE (forse dalla versione 7), potrebbero essere utilizzate per creare una sorta di preload, comunicando all eventuale visitatore a che punto è la sua richiesta e quanto manca alla ricezione completa dei dati, operazione non molto differente da quella presente molto spesso nei siti in Flash, che permette quindi di non lasciare l utente in balia dell attesa. L ultima considerazione da fare per lo stato 3 è che lo stesso potrebbe essere riassegnato diverse volte, soprattutto durante la lettura di documenti XML. status Per sapere effettivamente se lo scambio dati sia avvenuto con successo, il parametro status contiene esattamente il codice HTTP di risposta restituito dal server. Se l interazione ha successo status contiene il valore 200 (per la descrizione di tutti i valori possibili si consiglia [21]). statustext Possiamo trovare la descrizione del codice HTTP ritornato dal server nel parametro statustext. Questo parametro è supportato in quasi tutti i browsers, ma per avere la certezza che questo corrisponda esattamente al codice restituito, sarebbe meglio creare un oggetto apposito contenente un insieme di coppie chiave/valore in grado di fornire sempre il giusto significato dello stato. responsetext e responsexml Il nome dei parametri responsetext e responsexml rispecchia il tipo di dati restituiti dal server ad operazione ultimata. La differenza principale tra i due è che mentre responsetext è un dato di tipo stringa ad interazione ultimata, responsexml potrebbe essere un oggetto null qualora i dati restituiti non dovessero essere un documento XML e quindi un oggetto utilizzabile come tale. Lo scopo del parametro responsetext è infatti quello di poter ricevere comunque informazioni dal server. Ad esempio, una pagina richiamata ma non più presente genera un errore con status pari a 404 ed il più delle volte il server darà una comunicazione di servizio che informerà l utente dell assenza del documento. Questa risposta potrebbe non essere un documento XML e per questo è utile leggere il responsetext contenente il testo restituito dal server. Sapendo che qualora il testo restituito sia un documento XML, responsetext verrebbe comunque assegnato con la sua rappresentazione testuale, molti sviluppatori sfruttano quest ultimo parametro per ricevere dei contenuti a prescindere dalla natura degli stessi, semplificando le operazioni di parsing necessarie per un XML ed avendo subito a disposizione quanto letto.

7 5 6 GESTIRE L ATTESA 35 onreadystatechange Questo parametro serve ad assegnare una funzione al variare dello stato di readystate. 5.6 Gestire l attesa Con l utilizzo di accorgimenti temporali, utilizzando ad esempio settimeout, si può controllare il tempo di risposta client-server e soprattutto si possono implementare diversi metodi per evitare richieste stressanti od inutili al server (disabilitando nuove richieste uguali entro un lasco di tempo stabilito), ma in certi casi è bene affrontare il problema dell attesa da parte dell utente. Si deve informare in qualche che la richiesta è stata fatta ed eventualmente il suo esito. Si può aggirare il problema usando semplicemente i loader: elementi grafici leggeri che eliminano la sensazione di un attesa statica rappresentando la percentuale di caricamento con l ausilio di una barra di progressione, oppure con del testo esplicito, o con le classiche gif animate (alcuni simpatici esempi sono in [22]). 5.7 Considerazioni lato utente Vantaggi L impressione di avere a che fare con pagine apparentemente più interattive, dinamiche e professionali è praticamente immediata. L effetto novità si aggiunge prepotentemente alla lista, stuzzicando la curiosità del navigatore. Questi aspetti apparentemente futili hanno permesso, però, a tecnologie come Flash di affermarsi nel contesto web. Questo perché l interesse collettivo è la ricerca di informazioni, ma si preferisce navigare dove le informazioni sono presentante nel modo più semplice e veloce possibile. Ci sono librerie dedicate, facilmente integrabili in applicativi AJAX e capaci di impressionare gli utenti. La compatibilità praticamente totale con i browser più diffusi ed il supporto nativo, o integrabile, dell oggetto XMLHttpRequest contribuiscono ulteriormente allo sviluppo di Rich Internet Applications, allargando i campi di impiego per gli sviluppatori e coinvolgendo sempre di più i navigatori. Altro vantaggio è l ottenere modifiche dinamiche e leggere sulle pagine, come i suggerimenti sui campi di ricerca o il controllo del tipo di dati inseriti in un form, in grado di suggerire parole presenti e velocizzare l inserimento. Svantaggi Gli utenti che non dispongono di connessioni veloci sono i più penalizzati, perché devono caricare, almeno al primo accesso, una mole di dati consistente rappresentata dai vari file JavaScript. Si potrebbe non disporre di un browser aggiornato, oppure avere il JavaScript disabilitato, o l assenza dell oggetto XMLHttpRequest. In questi casi si scaricano centinaia di bytes che non verranno mai usati a causa del controllo a posteriori utilizzato per conoscere la reale compatibilità con AJAX. Questi aspetti puramente tecnici sono spesso raggirabili, grazie ad una stesura degradabile dell applicativo da parte dello sviluppatore o grazie al caricamento dinamico del JavaScript proposto dopo aver verificato la compatibilità del browser. Un problema importante è che, senza l adozione di adeguate contromisure, le applicazioni AJAX possono rendere non utilizzabile i tasti di avanti e indietro del browser: con questo tipo di applicazioni, infatti, non si naviga da una pagina all altra, ma si aggiorna di volta in volta una singola parte del medesimo documento, e proprio per questo i browser, che sono programmi orientati alla pagina, non hanno possibilità di risalire ad alcuna di tali versioni intermedie. Google, nella sua Google Maps, ha sviluppato una possibile soluzione al problema: invece di usare XMLHttpRequest quando l utente clicca sul bottone di ricerca, il risultato della ricerca viene inviato in un iframe invisibile, dal quale le informazioni sono portate nella pagina visibile. Solo un attento design delle applicazioni AJAX permette di risolvere adeguatamente questi aspetti. Oltre ad essere un vincolo di navigazione, questo problema è anche un vincolo per l indicizzazione o la possibilità di segnalare ad altri la pagina visualizzata. Questo accade perché il comando gestito da JavaScript non è portabile come un link e scrivere ad un amico l indirizzo attualmente visitato ed eventualmente modificato tramite AJAX non è possibile se non dando delle indicazioni precise sulle operazioni svolte una volta arrivati nella pagina in oggetto. La soluzione a questi problemi non è semplice ed i motivi sono diversi:

8 36 CAPITOLO 5 AJAX in primo luogo creare un gestore eventi in grado di aggiungere cambiamenti alla history del browser può risultare un operazione complessa per via dei diversi standard o funzioni presenti nei diversi browser; in secondo luogo l indicizzazione di un solo link, per chi non ha JavaScript o non può usufruire di tale tecnologia, diventerebbe praticamente impossibile. 5.8 Considerazioni lato server Vantaggi Con AJAX il server non ha necessità di trasferire tutta la pagina per ogni interazione, ma solo la porzione necessaria all operazione richiesta, e questo rende sensibilmente più veloce l interazione per l utente e favorisce il risparmio di banda. C è una ricaduta anche in termini di calcoli da effettuare: l interprete PHP, l accesso al database, e altri calcoli necessari per la costruzione della pagina possono venire fatti solo al primo accesso, rendendo le richieste al server più snelle ed il server può rispondere in modo più efficiente. Anche siti con migliaia di utenti simultanei non dovranno quindi operare su tutte le parti dell applicativo, migliorando la possibilità di gestire mole di utenti elevata. Allo stesso tempo una parte dei calcoli può essere data in gestione al browser, così da sfruttare la potenza del PC-client e distribuire il carico su tutti, piuttosto che sul solo host. Svantaggi Se non gestite in modo completo, molte richieste al server possono essere inutili perché già fatte in un arco breve di tempo. Altro problema concreto è il suggest (l autocompletamento in digitazione), se implementato male. Se per ogni lettera digitata si effettua una query al database, il numero di operazioni si moltiplica in modo esponenziale, tanto che il server rischia di rallentare o di intasarsi piuttosto che essere alleggerito. La gestione dell evento onkeypress (o in alternativa onkeyup) fatta ad hoc dovrebbe quindi valutare se una richiesta con quelle lettere sia già stata fatta ed in caso mostrarla grazie alla memorizzazione sul client dei risultati precedenti, oppure richiamare nuovamente il server solo dopo qualche istante e non immediatamente, eliminando l operazione qualora l utente dovesse cambiare idea in quel lasso di tempo, ad esempio nel caso abbia sbagliato a scrivere un carattere o abbia cancellato la parola da cercare. Salvo un archivio dati particolarmente contenuto, è altrettanto sconsigliabile restituire un riscontro dopo aver digitato la sola prima lettera come lo è dopo aver scritto dei caratteri inutili quali spazi, virgole, punti o altro. In questo caso solo dei rigorosi controlli client potrebbero salvaguardare il server, ma allo stesso tempo questo dovrebbe impedire operazioni di ricerca inutili ed avere quindi a sua volta altrettanti controlli sul testo da cercare. Altri esempi potenzialmente pesanti da gestire potrebbero esse i contatori di utenti on-line, le chat rinfrescate ogni mezzo secondo, o gli aggiornamenti di dati statistici troppo frequenti, e in questi casi l unica soluzione è trovare il giusto compromesso tra necessità effettiva della frequenza di aggiornamento e calcoli da eseguire per effettuarla. 5.9 Sicurezza Lato client Da quanto detto fin ora, verrebbe quasi da pensare ai client come a dei piccoli muletti ausiliari ai quali delegare qualunque tipo di operazione. Questo non dovrebbe accadere, se non nella giusta misura, poiché mentre il server ha del codice compilato o interpretato, ma comunque non visibile ad occhi indiscreti, il JavaScript o i cookies sul client, non dovrebbero mai contenere informazioni sensibili quali password, numeri di carte di credito, informazioni riservate dalla legge sulla privacy o codici segreti. Allo stesso tempo bisogna essere molto cauti nell inviare informazioni anche da parte del server, poiché potrebbe essere semplice replicare una richiesta asincrona da una pagina differente da quella proposta, per tentare di leggere dati che si vorrebbero proteggere o non rendere pubblici.

9 5 9 SICUREZZA 37 La verifica del client è un operazione complessa perché la pagina di provenienza potrebbe non essere veramente quella riscontrata e l unica soluzione per uno scambio dati asincrono sicuro è l utilizzo di un area protetta tramite SSL o altri sistemi dedicati. Soprattutto nelle aree di amministrazione sarebbe quindi consigliabile non inviare fin da subito tutto il codice di gestione interna, ma aggiungerlo dinamicamente solo dopo aver effettuato il login. Se si ha a che fare con un area protetta che non prevede un utilizzo degradabile delle operazioni possibili, conoscere tutto il codice addetto a gestire le operazioni potrebbe aumentare in modo più o meno consistente la possibilità di ricevere attacchi esterni. Altra accortezza è quella di verificare sempre che le funzioni utilizzate lato client siano compatibili con tutti i browser previsti all interno dell area di amministrazione. Infatti, qualora una funzione non dovesse essere supportata a pieno ed il browser dovesse tentare lo stesso di utilizzarla si potrebbero aggiornare dati in modo errato o mostrare anomalie all utente. Lato server Un errore purtroppo comune, e non recente, è quello di fare affidamento solo sul codice client. L errore è presumere che sia solo un certo client con un certo codice ad inoltrare le richieste e che tali richieste rispettino a pieno le regole imposte dallo sviluppatore. Esistono diversi applicativi che non solo non verificano le autorizzazioni dell utente, ma danno per scontato che se il codice client ha la possibilità di inviare solo un numero, ad esempio un id, questo arrivi sicuramente sotto forma di un intero maggiore di zero. Leggendo il codice client, creandosi una semplice form HTML, ed inviando una richiesta tipo id=0 or id>0 si potrebbero spolverare decine di database attualmente online, archivi di news, utenti o altro ancora. Il mito da sfatare è quindi che l uso di AJAX sia pericoloso intrinsecamente. Non esistono controindicazioni specifiche per la sicurezza se non controllare che il dato in ingresso corrisponda al tipo di dato previsto, a prescindere che sia un operazione da svolgere all interno di un area di amministrazione o all interno di una qualunque pagina destinata agli utenti (prevenendo le SQL injections). Qualunque sia il prodotto proposto, questo dovrebbe essere prima sicuro senza JavaScript, da aggiungere solo al fine di alleggerire alcune operazioni. Si potrebbe pensare ad un controsenso, ma invece di ricevere tante richieste quanti sono gli eventuali errori, il client potrebbe aiutare l utente a non sbagliare richiesta permettendo al server di controllarne ed elaborarne solo una presumibilmente corretta.

10 38 CAPITOLO 5 AJAX