Consigli sull'usabilità, sicurezza e posizionamento in campo Ajax

Consiglio spassionatamente, durante le fasi di programmazione, di controllare ogni richiesta di tipo asincrono onde evitare attacchi di tipo cross site o SQL Injection dovuti all'esposizione che queste pagine possono avere.
I controlli da effettuare lato server devono pertanto garantire una risposta anche nel caso in cui vengano chiamate, da parte di malintenzionati, in modo non conforme al normale flusso derivante dall'utilizzo dell'applicazione web che ne fa uso. E' opportuno quindi inserire una serie di controlli sui parametri inviati al fine di evitare il ritorno di errori che possono fungere da breccia per conseguenti attacchi ed eseguire un debugging meticoloso per far emergere eventuali criticità da correggere.

La questione è importante anche per richieste effettuate in maniera genuina in quanto la risposta determinerà ciò che l'utente si aspetta di avere ed una risposta non gestita il cui codice di status non sia 200 potrebbe creare dei problemi di usabilità e confondere la navigazione da parte dell'utente.

Un'add-on funzionale su Firefox dove è possibile verificare il risultato delle richieste ed il relativo flusso è Firebug. Di seguito un esempio di chiamata Ajax in GET ad una pagina PHP presente sul mio sito per il controllo dei dati derivanti dal social network Facebook per la pagina desiderata. Sia il nome del social ("s=fb") che della pagina ("url=...") sono passati come parametro in querystring.

Fig. 1 - AJAX - Esempio di una chiamata e risposta vista con Firebug

Il risultato, 16, è fornito dall'elaborazione della chiamata e sarà mostrato nell'opportuno contatore del relativo social in maniera asincrona, pertanto la pagina sarà già visibile mentre in background viene calcolato il numero di condivisioni con l'evidente vantaggio di non dover attendere tale risposta che ritarderebbe notevolmente la visualizzazione del contenuto principale della pagina.

Considerando che può intercorrere un lasso di tempo più o meno lungo dalla chiamata alla risposta è di fondamentale importanza far capire all'utente che dovrà attendere qualche istante prima di poter visualizzare il risultato. Un loader, come mostrato nell'esempio in questione di cui riporto la relativa porzione di codice, può essere una soluzione efficace:

var responseDIV = document.getElementById("id_contenitore");
responseDIV = '<img src="images/loader.gif" alt="" />';

L'assenza di un segnale visivo potrebbe disorientare il navigatore che comincerebbe a cliccare nuovamente sulla call to action per rieffettuare la richiesta sovraccaricando conseguente ed inutilmente il server, basti pensare ad un numero cospicuo di utenti che possono avere lo stesso problema.

Un fatto da tenere in considerazione, anche se al giorno d'oggi data la natura delle applicazioni web non è più così tanto diffuso, riguarda quella percentuale di navigatori che hanno il Javascript disattivato nei loro browser. Per garantire il corretto funzionamento del sito o dell'applicazione web anche in casi come quello citato può essere buona norma fornire insieme all'azione Javascript (ad esempio l'onclick su di un link) il link effettivo alla pagina richiamata asincronamente o ad una pagina dedicata dove viene mostrato il risultato in base ai parametri selezionati.
Questo può garantire una migliore gestione lato SEO evitando che alcuni contenuti possano non essere letti dai crowler.

Consiglio di non abusare di questa tecnologia ma di limitarla là dove può ritenersi utile per velocizzare le operazioni lato client evitando il refresh di tutta una pagina per il controllo o la visualizzazione di poche informazioni. Non ha senso al contrario caricare tutta una pagina in Ajax, sia lato utente che dal punto di vista dello sviluppatore.
Importante è non lasciare eventuali controlli di valori in input solo a carico dell'Ajax ovvero, in un form dove richiedo ad esempio l'immissione di un indirizzo email posso controllare tramite Ajax a runtime (onkeypress) o all'onblur l'integrità dell'indirizzo per evitare di comunicare all'utente l'eventuale presenza di errori nel formato ma lo stesso controllo, per ragioni di sicurezza, lo dovrò effettuare anche nella pagina in cui verrà indirizzato il submit (per evitare che venga processata con parametri nocivi generando errori e conseguenti falle di sistema).

Per semplificare il lavoro ed evitare problemi di compatibilità tra più istanze ci sono dei framework Javascript che fanno la maggior parte del lavoro sporco lasciando all'utente il minimo di istruzioni indispensabili, garantendo compatibilità cross-browser e facilità di implementazione. Uno tra i più noti è jQuery con il quale per effettuare una chiamata, ad esempio in POST, ed ottenere un risultato come nel codice di presentazione dell'oggetto xmlHttpRequest posto nel primo articolo della seguente guida basta utilizzare il seguente codice:

$.post("/pagina_chiamata.asp",{ param: parametri, timeStamp: new Date().getTime() },
function(data) {
    $("#id_contenitore").html(data);
});