Progetto e realizzazione di una infrastruttura per la registrazione degli eventi su interfacce web...

UNIVERSITÀ DEGLI STUDI DI TRIESTE_______________________________________________________________________________________________________________________________________

FACOLTÀ DI INGEGNERIA

Corso di Laurea in Ingegneria ElettronicaDipartimento di Elettronica, Elettrotecnica ed Informatica

Tesi di Laurea inRETI DI CALCOLATORI

PROGETTO E REALIZZAZIONE DI UNA INFRASTRUTTURA PER LA REGISTRAZIONE DEGLI

EVENTI SU INTERFACCE WEB REMOTE

Laureando: Relatore:

Fabiano Tarlao Prof. Alberto Bartoli

Correlatori:

Prof. Eric Medvet

Ing. Giorgio Davanzo

___________________________________________________________________ANNO ACCADEMICO 2008 - 2009

Alla mia famiglia

Indice

1. Introduzione 1

2. Descrizione applicativo 32.1 Descrizione generale ...........................................................................................................3

2.1.1 GWT-Observer, il client ..............................................................................................32.1.2 GWT-Observer, il server .............................................................................................42.1.3 Modalità di utilizzo .....................................................................................................4

2.1.3.1 Modalità Direct ....................................................................................................52.1.4 Modalità Proxy ............................................................................................................5

2.2 Tecnologie utilizzate ...........................................................................................................62.2.1 Google Widget Toolkit ................................................................................................7

2.3 Flusso dei dati .....................................................................................................................72.3.1 Inizializzazione ..........................................................................................................82.3.2 Trasmissione dei dati ..................................................................................................82.3.3 La richiesta sendTape ..................................................................................................82.3.4 La richiesta sendFrameID ...........................................................................................82.3.5 Chiusura della interazione ...........................................................................................9

2.4 Confronto con soluzioni preesistenti ................................................................................102.4.1 Applicativi e ricerche a livello accademico ..............................................................10

2.4.1.1 CSIP ...................................................................................................................102.4.1.2 USAPROXY ......................................................................................................10

2.4.2 Applicativi in ambito commerciale ...........................................................................112.4.2.1 ClickTale ............................................................................................................11

3. Dati raccolti, descrizione e formato 133.1 Descrizione dei dati raccolti .............................................................................................13

3.1.1 Dati generali sull'interazione .....................................................................................133.1.2 Dati relativi alle azioni dell'utente ............................................................................14

3.1.2.1 Eventi Mouse .....................................................................................................153.1.2.2 Eventi tastiera ....................................................................................................163.1.2.3 Evento scroll della finestra ................................................................................163.1.2.4 Evento ridimensionamento finestra ...................................................................16

3.2 Descrizione fisica dei dati salvati .....................................................................................163.2.1 Convenzioni per i nomi file. .....................................................................................173.2.2 Descrizione della struttura dei dati salvati ................................................................17

3.2.2.1 Lista degli eventi registrati, il Tape ...................................................................183.2.2.2 ActionShot .........................................................................................................183.2.2.3 MouseAction .....................................................................................................193.2.2.4 KeyAction .........................................................................................................203.2.2.5 ScrollAction .......................................................................................................213.2.2.6 ResizeAction .....................................................................................................213.2.2.7 Le informazioni generali sull'interazione ..........................................................22

3.3 Rappresentazione XML dei dati, esempio completo ........................................................24

I

4. Manuale d'uso 294.1 Modalità Direct .................................................................................................................29

4.1.1 Integrazione di GWT-Observer nelle pagine di interesse. ........................................294.1.1.1 Installazione con impostazioni di default ..........................................................294.1.1.2 Configurazioni alternative e vincoli imposti .....................................................30

4.1.2 Installazione del backend GWT-Observer sull'Application Server ...........................314.1.2.1 Deployment dell'applicativo ..............................................................................314.1.2.2 Esempi, collocazione delle risorse web .............................................................314.1.2.3 Problematiche relative alla Same Origin Policy ................................................324.1.2.4 Esempio di configurazione del WebServer, note generali .................................33

4.2 Modalità Proxy .................................................................................................................344.2.1 Guida all'installazione ...............................................................................................354.2.2 Setup dell'application server .....................................................................................354.2.3 Installazione del server ICAP ....................................................................................354.2.4 Installazione dell'URL-rewriter Squirm ....................................................................374.2.5 Installazione e configurazione del proxy HTTP Squid .............................................384.2.6 Configurazione dei browser dell'utente .....................................................................41

5. Implementazione 435.1 Tecnologie utilizzate, approfondimenti ............................................................................43

5.1.1 GWT Google Widget Toolkit ....................................................................................435.1.1.1 Deferred binding e permutazioni .......................................................................435.1.1.2 Linker di default e linker cross site ...................................................................44

5.2 Analisi e progetto ..............................................................................................................455.2.1 Definizione del problema ..........................................................................................455.2.2 Design dell'applicativo ..............................................................................................46

5.2.2.1 ObserverEntryPoint ...........................................................................................465.2.2.2 Sniffer ................................................................................................................465.2.2.3 GWTTapeStream e GWTTapeStreamAsync .....................................................465.2.2.4 ActionShot .........................................................................................................465.2.2.5 ActionShotManager ...........................................................................................475.2.2.6 OnElement e OnElementDetailed .....................................................................475.2.2.7 OnElementManager ...........................................................................................475.2.2.8 Tape ...................................................................................................................475.2.2.9 GWTTapeStreamImpl .......................................................................................485.2.2.10 Record .............................................................................................................485.2.2.11 Diagramma delle classi ...................................................................................50

5.3 Dettagli implementativi ....................................................................................................525.3.1 Sniffer ........................................................................................................................52

5.3.1.1 safeSend, trasmissione dei dati ..........................................................................525.3.1.2 endOfInteraction ................................................................................................525.3.1.3 Gestione degli iframe ........................................................................................53

5.3.2 Classe Tape ................................................................................................................535.3.2.1 Rate limiter ........................................................................................................535.3.2.2 Compressione dei dati ......................................................................................555.3.2.3 Classe OnElementManager ...............................................................................56

5.4 Progetto della modalità Proxy ...........................................................................................585.4.1 Il protocollo ICAP .....................................................................................................585.4.2 Descrizione della modalità Proxy .............................................................................595.4.3 Configurazione dei servizi ........................................................................................60

II

5.4.3.1 Configurazione del server ICAP .......................................................................615.4.3.2 Configurazione dell'URL-rewriter Squirm ........................................................635.4.3.3 squirm.conf ........................................................................................................635.4.3.4 squirm.patterns ..................................................................................................645.4.3.5 Configurazione del proxy HTTP Squid .............................................................64

6. Prestazioni e dimensioni dell'applicativo 676.1 Dimensione dell'applicativo ..............................................................................................676.2 Tempi di caricamento ........................................................................................................68

6.2.1 Modalità direct ..........................................................................................................686.2.2 Modalità Proxy ..........................................................................................................69

6.3 Carico sulla CPU del client ...............................................................................................706.4 Occupazione di banda .......................................................................................................716.5 Impressioni soggettive sulla navigazione .........................................................................726.6 Analisi dei risultati ottenuti ...............................................................................................72

7. Test dell'applicativo 757.1 Test nella modalità Direct .................................................................................................75

7.1.1 TestPages, realizzazione delle pagine di prova .........................................................757.1.1.1 Descrizione dell'applicativo TestPages ..............................................................767.1.1.2 Convenzioni adottate per il salvataggio dei file ................................................787.1.1.3 Scelta delle pagine di prova ...............................................................................79

7.1.2 Esperimenti effettuati ................................................................................................797.1.3 Risultati ottenuti ........................................................................................................80

7.2 Test nella modalità Proxy ..................................................................................................807.2.1 Esperimenti effettuati ................................................................................................807.2.2 Risultati ottenuti ........................................................................................................80

8. Conclusioni 83

9. Ringraziamenti 85

10. Bibliografia 87

III

1. Introduzione

La navigazione di un sito web è ormai un elemento comune ed inevitabile per una larga fetta della popolazione; quotidianamente vengono visitate miliardi di pagine web, con cui gli utenti interagiscono differentemente in base all'interesse che provano per esse, alla facilità di utilizzo del sito e alle abitudini individuali.L'interazione tra uomo e sito web diventa quindi materia per ricerche dalle molteplici finalità tra cui spiccano la realizzazione di nuove tecniche di identificazione dell'utente, nuove tecniche di CAPTCHA e lo studio sulla usabilità delle interfacce web.A livello accademico vi sono ricerche relative alla interazione dell'utente durante la navigazione ma le soluzioni software proposte difettano di alcune caratteristiche, come ad esempio la registrazione della traiettoria del mouse, che sono invece necessarie ai nostri fini.Gli unici applicativi che presentano caratteristiche analoghe a quelle preventivate sono prodotti commerciali specializzati nello studio della usabilità dei siti ma, data la loro natura proprietaria, questi software non forniscono la possibilità di estrarre le informazioni necessarie ai nostri studi.Alla luce di quanto esposto e per poter perseguire gli obiettivi di ricerca sopra citati, si è deciso di sviluppare un applicativo aderente alle specifiche richieste, internamente al laboratorio di Reti di Calcolatori del DEEI dell'Università di Trieste, come argomento di una tesi sperimentale.

Oggetto di questa tesi è la realizzazione della infrastruttura che permetta la registrazione remota delle azioni attuate dagli utenti durante la loro interazione con una interfaccia web.L'infrastruttura che si vuole realizzare deve permettere la registrazione in due modalità distinte:

• direct, nella quale un gestore di un sito registra le azioni svolte dagli utenti sul sito stesso;• proxy, nella quale un amministratore di rete può registrare tutte le azioni intraprese dagli

utenti durante la navigazione libera su qualunque sito internet;

Inoltre, l'infrastruttura progettata deve essere in grado di attuare le precedenti operazioni senza interferire con la navigazione dell'utente.Il progetto si è sviluppato nelle seguenti fasi:

• studio delle tecnologie adottate;• analisi preliminare dell'applicativo per la sola modalità direct;• realizzazione dell'applicativo;• test preliminari della infrastruttura per valutare la fattibilità e il rispetto delle specifiche;

1

• analisi finalizzata alla realizzazione della modalità proxy;• realizzazione della infrastruttura proxy• test della infrastruttura nella modalità proxy;• Test finali delle modalità proxy e direct al fine di verificare il rispetto delle specifiche;

L'obiettivo è stato conseguito con successo; l'infrastruttura realizzata, che nel prosieguo verrà denominata GWT-Observer, è risultata conforme alle specifiche e ha superato i test a cui è stata sottoposta.

2

2. Descrizione applicativo

In questo capitolo si fornirà una descrizione generale dell'applicativo realizzato, GWT-Observer, descrivendo la sua struttura e le principali funzionalità.

2.1 Descrizione generale

L'applicativo realizzato in questa tesi, GWT-Observer, permette di monitorare la navigazione di uno o più utenti all'interno di un sito, raccogliendo informazioni dettagliate sulle azioni intraprese.L'applicativo è costituito da due componenti:

• un client, il quale viene eseguito sui browser degli utenti;• un server che riceve e registra le richieste e i dati inviati dagli applicativi client.

La componente client è costituita da uno script JavaScript che, se integrato in una pagina preesistente ed eseguito nel browser dell'utente, permette il monitoraggio della attività dell'utente stesso.La componente server (backend) di GWT-Observer è costituito da un webservice, realizzato da un servlet Java ed eseguito all'interno di un application server; ad esso verranno inviati i dati riguardanti le interazioni degli utenti.

2.1.1 GWT-Observer, il client

La componente client dell'applicativo è progettata in modo da venir eseguita dal browser dell'utente contestualmente a tutti gli altri elementi della pagina.Tale risultato viene conseguito inserendo una chiamata allo script dell'applicativo all'interno del codice HTML della pagina.Una volta in esecuzione, il client GWT-Observer inizializza la connessione con il servizio backend e inizia il rilevamento delle azioni intraprese dall'utente.Le azioni dell'utente rilevate dall'applicativo sono le seguenti:

• Movimenti e posizione del cursore mouse• Pressione dei tasti del mouse

3

• Velocità della rotella del mouse, mouse wheel• Pressione dei tasti della tastiera• Scroll della finestra• Resize della finestra• Posizione di alcuni elementi grafici nella finestra (rendering della pagina)

Nella trattazione successiva ci si riferirà spesso alle azioni rilevate denominandole eventi; questa scelta è dovuta al fatto che l'azione dell'utente, sia essa un movimento del mouse o la pressione di un tasto, produce appunto un evento che viene poi gestito dagli applicativi.Tali eventi o azioni vengono registrate localmente in attesa di venir inviate al backend e al fine di limitare la quantità di informazioni memorizzate e l'occupazione della banda, l'applicativo attua una decimazione dei dati raccolti al fine di rispettare una frequenza massima di campionamento imposta dallo sviluppatore.Periodicamente il client GWT-Observer si connette al webservice inviando i dati raccolti; sulla base di questi il server provvederà a ricostruire la registrazione complessiva delle azioni dell'utente.Nel caso in cui l'utente o il browser chiudessero la finestra contenente la pagina o avvenisse un caricamento di una nuova risorsa all'interno della finestra corrente, il client cercherà di comunicare la chiusura e quindi la fine della interazione dell'utente con la pagina al servizio backend.

2.1.2 GWT-Observer, il server

La componente server dell'applicativo è progettata in modo da venir eseguita all'interno di un application server conforme alle specifiche JavaEE5.Una volta in esecuzione esso metterà a disposizione un webservice che resterà in attesa di richieste da parte delle controparti client.I client descritti nel paragrafo 2.1.1 potranno quindi contattare il servizio web e inviare con delle richieste i dati rilevati.Il servizio web è progettato in modo da gestire accessi concorrenti di più client e quindi supporta la registrazione di più interazioni1 contemporanee.Alla conclusione della interazione dell'utente con la pagina, opportunamente comunicata dal client, il servizio provvederà al salvataggio della registrazione assieme ad informazioni atte alla identificazione dell'utente o del browser di origine.Tali informazioni saranno quindi disponibili per successive elaborazioni.

2.1.3 Modalità di utilizzo

L'applicativo GWT-Observer può essere impiegato in due modalità distinte, Direct e Proxy:

• Direct, in questa modalità il gestore di un sito può monitorare o registrare il comportamento degli utenti sul sito stesso aggiungendo manualmente il codice di GWT-Observer alle pagine di interesse.

• Proxy, in questa modalità l'amministratore di un proxy può monitorare l'attività degli utenti a lui connessi e rilevare le azioni da essi intraprese su qualunque sito, anche su siti non amministrati dal gestore del Proxy.

1 Si definisce come singola interazione o interazione la successione di azioni e le registrazioni effettuate su una pagina dall'istante del suo caricamento fino alla sua chiusura o al caricamento di un altra pagina all'interno della stessa finestra.

4

2.1.3.1 Modalità Direct

In questa modalità è il gestore a decidere quali pagine dovranno essere monitorate da GWT-Observer.Il gestore del sito procede quindi all'integrazione dell'applicativo in una pagina aggiungendo una riga di codice html nel body o nello head:

<script language="javascript"

src="it.univ.trieste.observer/it.univ.trieste.observer.nocache.js">

</script>

Il codice sopra riportato effettua il caricamento della risorsa JavaScript nocache.js da un indirizzo che è espresso relativamente al path della pagina corrente; nel caso in cui l'URL della pagina risultasse http://sito.net/pagine/pagina.html, la risorsa JavaScript verrebbe ricercata all'URL http://sito.net/pagine/ it.univ.trieste.observer/it.univ.trieste.observer.nocache.js.In alternativa, nel caso si dovessero monitorare molte pagine, è preferibile esprimere l'URL della risorsa JavaScript esprimendo il path in modo relativo alla root del dominio.

<script language="javascript"

src="/it.univ.trieste.observer/it.univ.trieste.observer.nocache.js">

</script>

Utilizzando questa soluzione per qualunque pagina, la risorsa JavaScript viene ricercata all'URL:http://sito.net/ it.univ.trieste.observer/it.univ.trieste.observer.nocache.jsEffettuata questa modifica, il caricamento delle pagine monitorate comporta l'esecuzione nel proprio browser di una istanza del client GWT-Observer; la registrazione dell'interazione ha quindi inizio e le azioni intraprese dall'utente vengono inviate ai servizi web del sito.Nel caso in cui l'utente avesse caricato più pagine monitorate in diverse finestre del browser, l'applicativo è comunque in grado di identificare la finestra di origine dei dati inviati e le registrazioni delle azioni intraprese dall'utente nelle finestre avvengono comunque in modo separato e indipendente l'una dall'altra, senza interferenze o alterazione dei dati registrati. In aggiunta il servizio web realizzato è in grado di registrare contemporaneamente le interazioni di più utenti.

2.1.4 Modalità Proxy

In questa modalità il gestore del server Proxy/GWT-Observer è in grado di monitorare le interazioni degli utenti connessi mentre procedono alla navigazione su qualunque sito internetQuesto controllo avviene integrando GWT-Observer con un server proxy http opportunamente configurato.La topologia che si viene a realizzare è quella rappresentata nella Illustrazione 1 dove una costellazione di computer sono connessi ad internet attraverso il proxy Squid.Nella modalità proxy non è più il gestore del sito ad inserire il codice JavaScript di GWT-Observer nelle pagine ma è il server proxy ad alterare le pagine richieste, inserendo il codice descritto nel par. 2.1.3.1 ( in questo modo si manda in esecuzione un client GWT-Observer in tutte le pagine aperte nei browser degli utenti connessi).

5

Allo stesso modo non è il gestore dei siti visitati a ricevere le registrazioni delle interazione degli utenti ma il gestore dell'AS backend a cui il proxy redirige le richieste; il gestore dell'AS e del proxy potranno essere anche due figure distinte.

2.2 Tecnologie utilizzate

Tecnologie utilizzate per lo sviluppo dell'applicativo:

• Linguaggio di programmazione Java• Google Widget Toolkit• JavaScript e AJAX

Al fine di implementare l'applicativo JavaScript si è scelto di utilizzare il Google Widget Toolkit, GWT, la scelta è stata basata sulle seguenti considerazioni:

• L'applicativo deve essere eseguito su browser differenti e quindi il codice Javascript realizzato deve essere compatibile con la maggior parte di essi.

• GWT2 permette di utilizzare il linguaggio Java sia per lo sviluppo lato client che lato server.

2 Vedi par.2.2.1

6

Illustrazione 1: Topologia della rete realizzata, client connessi al server proxy http di tipo Squid.

• La serializzazione dei dati utilizzando le GWT-RPC permette di trasmettere oggetti Java molto complessi dal client al server senza richiedere la scrittura di codice per gestire la serializzazione o il parsing delle risposte.

Elenco dei software utilizzati per lo sviluppo dell'applicativo:

• ambiente di sviluppo IDE, NetBeans ver. 6.8• Piattaforma JDK 1.6• Google Widget Toolkit, GWT SDK ver. 2.0.0• Libreria: Xstream ver.1.3.1• Application service: GlassFish ver.3• Proxy HTTP: Squid ver.3.0• Server ICAP: GreaseSpoon ver. 1.02• URL redirector(rewriter): Squirm ver.1.26

2.2.1 Google Widget Toolkit

Il kit di sviluppo software (SDK) GWT permette di scrivere applicativi AJAX in linguaggio Java e di compilare i sorgenti dell'applicativo in codice JavaScript ottimizzato.Il compilatore GWT oltre ad ottimizzare il codice JavaScript garantisce la corretta esecuzione dello stesso sulla maggior parte dei browser.L'utilizzo del linguaggio Java consente di programmare l'applicazione lavorando ad un livello di astrazione più elevato e di utilizzare gli stessi strumenti adottati nello sviluppo di una applicazione Java nativa.Sono anche disponibili per gli IDE Eclipse e NetBeans e per alcuni browser dei plugin che permettono il debugging del codice della web application mentre questa è in esecuzione sull' application server (e quindi nella JVM) e sul Browser (ovvero come codice JavaScript all'interno della JsVM). Il GWT implementa una parte delle API standard Java e mette a disposizione una serie di librerie che consentono di accedere e manipolare gli elementi DOM della pagina.Ripiegare su codice nativo JavaScript è necessario solo in rare occasioni quando risulta necessario svolgere operazioni non supportate o per interfacciare l'applicativo GWT con la logica JavaScript preesistente nella pagina o con librerie esterne.

2.3 Flusso dei dati

Si descriveranno in questo paragrafo in modo qualitativo le comunicazioni che intercorrono tra il client GWT-Observer e il server, dal caricamento della pagina sino alla sua conclusione della interazione; si fornirà anche una descrizione delle informazioni scambiate.Dall'inizio dell'esecuzione di GWT-Observer sino alla sua conclusione si possono distinguere tre fasi fondamentali:

• inizializzazione• trasmissione dei dati• chiusura della interazione

7

2.3.1 Inizializzazione

Completato il caricamento della pagina e instanziato il client GWT-Observer, l'applicativo contatterà il servizio server backend al fine di inizializzare la registrazione dell'interazione e prepararsi al successivo invio dei dati.Il client GWT-Observer effettua quindi una richiesta al server denominata getNewID con cui vengono inviati i seguenti dati:

• l'URL della pagina caricata• l'URL della pagina di provenienza (Refer)• informazioni sul browser e il sistema operativo (user agent)

La risposta del server a questa richiesta contiene:• ID, identificativo numerico unico per l'interazione.

Tale identificativo verrà utilizzato dal client in ogni successiva richiesta in modo da identificare in modo univoco l'interazione a cui i dati fanno riferimento.

2.3.2 Trasmissione dei dati

Completata l'inizializzazione (par. 2.3.1 ), l'applicativo client GWT-Observer entra nella fase di rilevamento e trasmissione dei dati.Durante la fase di trasmissione dei dati vengono effettuate dal client GWT-Observer due tipi di richieste denominate sendTape e sendFrameID.

2.3.3 La richiesta sendTape

La richiesta sendTape viene inviata periodicamente al server backend allegando le registrazioni degli eventi contenute nel buffer locale del client; nella richiesta sono inserite le seguenti informazioni:

• ID, identificativo numerico unico della interazione, ricevuto dal server nella fase di inizializzazione.

• Una lista contenente la descrizione degli eventi rilevati assieme all'istante di rilevamento.

La risposta del server contiene la eventuale conferma della avvenuta registrazione dei dati e nel caso di fallimento della spedizione o di risposta negativa da parte del server, il client riesegue immediatamente la richiesta sendTape.Nel caso di un numero elevato di fallimenti il client GWT-Observer interrompe le richieste e cessa la registrazione dei dati.La lista degli eventi inclusa tra gli argomenti della richiesta si può immaginare composta da una serie di “fotogrammi” e il singolo fotogramma contiene informazioni sull'evento comprensive dell'istante di tempo in cui è stato rilevato.Questa lista di eventi o flusso di “fotogrammi” è stato denominato “tape” per analogia, siccome si può immaginare come un vero e proprio filmato della interazione.

2.3.4 La richiesta sendFrameID

La richiesta sendFrameID viene inviata da un client GWT-Observer che gestisce una pagina P

8

solo quando rileva all'interno di un iframe3 della pagina P un'altra istanza attiva del client GWT-Observer. Questa richiesta include le seguenti informazioni:


• SlaveID, identificativo numerico unico della interazione rilevata all'interno di un iframe della pagina.

• Identificativo numerico dell' elemento html iframe corrispondente allo SlaveID rilevato. La richiesta sendFrameID non riceve alcun dato nella risposta dal server, il successo o il fallimento della trasmissione viene comunque rilevato.Va fatta nota che il client GWT-Observer ispeziona4 periodicamente gli iframe contenuti nella pagina e nel caso venisse rilevato un cambiamento nello SlaveID dell'iframe, questo cambiamento sarebbe comunicato al server con una nuova richiesta sendIFrameID.

Il client GWT-Observer caricato in una pagina non può registrare gli eventi che avvengono all'interno degli iframe, questo crea delle zone “invisibili” nella registrazione.Quando nella pagina contenuta in un iframe è in esecuzione un altra istanza di GWT-Observer5, essa attua una registrazione della interazione dell'utente con l'iframe.Si presenta quindi l'opportunità di ricostruire l'interazione dell'utente con la finestra complessiva unendo le registrazioni del client GWT-Observer della pagina principale e quella del client GWT-Observer dell'iframe; a tale fine si è introdotta la richiesta sendFrameID.

2.3.5 Chiusura della interazione

Nel caso di chiusura della finestra o di caricamento di un altra pagina nella finestra corrente l'interazione ha da considerarsi conclusa.Al fine di comunicare la chiusura della interazione, il client GWT-Observer effettua un'unica richiesta denominata endOfInteraction.La richiesta endOfInteraction contiene i seguenti argomenti:


• Una lista contenente la descrizione degli eventi rilevati assieme all'istante di rilevamento.

La chiusura della interazione viene effettuata dal client GWT-Observer con l'obiettivo di spedire i dati memorizzati nel buffer corrente e per comunicare la fine della interazione.Tale richiesta è simile alla sendTape solo che alla endOfInteraction segue la finalizzazione della interazione, da quel momento l'ID identificativo della interazione non sarà più valido.In questo modo il server procederà al salvataggio immediato dei dati e metterà gli stessi a disposizione per una successiva elaborazione.Vi sono dei casi limite in cui il client non riesce ad inviare la richiesta endOfInteraction, in questi

3 L'iframe è un elemento HTML. Analogo al frame, viene utilizzato per mostrare il contenuto di una pagina web, o di una qualsivoglia risorsa, in un riquadro all'interno (inline) della pagina corrente. L'iframe costituisce di fatto una pagina a se. Nel linguaggio HTML l'iframe viene rappresentato tramite il tag <iframe></iframe>.

4 Si vedrà che gli iframe non sono sempre accessibili dalla pagina parent ma dovranno essere verificate delle condizioni come ad esempio l'appartenenza allo stesso dominio. Nel caso in cui l'ispezione del frame non sia possibile l'unico modo per determinare il legame tra le interazioni risulta il ReferURL.

5 Ad esempio nella modalità GWT-Observer/Proxy, il proxy inserisce anche nelle pagine contenute in ogni iframe una istanza del client GWT-Observer; ma la stessa situazione può essere ricreata anche in modalità Direct.

9

casi la chiusura della iterazione sarà gestita attraverso un timeout.

2.4 Confronto con soluzioni preesistenti

Si è effettuata una ricerca al fine di determinare quali software preesistenti forniscono le funzionalità descritte nel paragrafo 2.1 ( o più dettagliatamente il rispetto delle specifiche descritte nel paragrafo 5.2.1 ).

2.4.1 Applicativi e ricerche a livello accademico

A livello accademico sono stati sviluppati applicativi con caratteristiche e finalità simili alle nostre, CSIP e USAPROXY.

2.4.1.1 CSIP

L'applicativo denominato CSIP è utilizzato presso l'Emory University (Atlanta) nella ricerca [1] sulla interazione uomo interfaccia.Lo scopo dello studio è di determinare, attraverso l'osservazione della interazione dell'utente con un motore di ricerca web, se la ricerca effettuata appartiene ad uno stesso segmento (ricerca sullo stesso argomento o refinings) o se la ricerca non ha nulla a che fare con le precedenti.Il loro software presenta le seguenti caratteristiche:

• il client è realizzato con un plugin Firefox;• rileva scroll della finestra, movimenti mouse, pressioni dei tasti in modo simile a quanto

richiesto nelle nostre specifiche;• registrazione attuata su qualunque sito web (simile alla modalità proxy del nostro

applicativo);• effettuano una decimazione delle azioni associate al mouse registrando solo un

movimento del mouse ogni 10.

Caratteristiche non compatibili con le nostre specifiche:

• il loro software necessita dell'intervento dell'utente per l'inserimento del plugin;• il loro software impone l'utilizzo del browser Firefox.

2.4.1.2 USAPROXY

L'applicativo USAPROXY è utilizzato presso l'Università di Monaco, per le ricerche [3] sulla interazione utente-interfaccia web.Le ricerche condotte sono finalizzate alla realizzazione di strumenti per l'analisi della usabilità di un sito web con particolare attenzione per gli applicativi AJAX.I dati raccolti sono quindi utilizzati per determinare il comportamento degli utenti, valutare l'usabilità dell'interfaccia e la tipologia di utente esperto, inesperto (analisi di eventuali esitazioni, velocità della digitazione).La loro infrastruttura presenta le seguenti caratteristiche:

• la loro infrastruttura è costituita da un proxy che inietta il codice JavaScript del client all'interno delle pagine richieste;

10

• Il loro applicativo lato client è costituito da uno script JavaScript;• rileva e notifica gli eventi: resize, focus, blur, unload, mouse click, mouse hover;• raccoglie per ogni elemento HTML le seguenti informazioni: ID, Nome elemento,

sorgente (scr), posizione nel DOM tree;• rileva la posizione del mouse al momento di eventi mouse hover, click od altri eventi

mouse. Non viene però rilevata e registrata la posizione per gli eventi mouse move;• rileva gli eventi scroll e la posizione della finestra;• rileva la pressione tasti.

Caratteristiche assenti nel loro software e appetibili ai nostri fini:

• non seguono le traiettorie del mouse registrando la posizione ad ogni movimento ma rilevano la posizione quando il mouse si posiziona sopra un nuovo elemento della pagina od esce dallo stesso

• Inviano una notevole quantità di dati non necessari ai nostri fini, pur non fornendo dettagli sulla banda occupata questo pone dei dubbi sul rispetto delle nostre specifiche di banda.

2.4.2 Applicativi in ambito commerciale

A livello commerciale le soluzioni sono molteplici, tutte finalizzate allo studio della usabilità dei siti6. Molte di esse implementano gran parte delle funzionalità necessarie ai nostri studi ma data la loro natura proprietaria non vi è la possibilità di estrarre le informazioni necessarie ai nostri studi.Si riporta a titolo esemplificativo l'analisi effettuata sul prodotto ClickTale©.

2.4.2.1 ClickTale

Il loro prodotto permette di monitorare l'attività degli utenti su un sito. Il software invia i dati raccolti ai server ClickTale7 i quali forniscono statistiche sull'uso delle pagine e strumenti atti a valutare l'usabilità dell'interfaccia.Il prodotto ClickTale ricostruisce la forma della pagina in un modo estremamente preciso e la console di amministrazione disponibile sul sito ClickTale presenta allo sviluppatore web o all'amministratore perfino dei filmati dell'interazione.ClickTale non fornisce servizi di identificazione dell'utente o di CAPTCHA basati sull'interazione.Dalla lettura della documentazione dei forum di supporto e delle FAQ si sono identificati maggiori dettagli sul servizio:

• lo sviluppatore web deve includere il codice javascript del client manualmente nel proprie pagine similmente a quanto avviene nella modalità direct del nostro applicativo;

• rileva i movimenti del mouse con una buona frequenza;• il download del client javascript consta in 10KBytes;• comprime i dati prima dell'invio(definito higly compressed package);• invia uno snapshot iniziale della pagina completa e la combina con le azioni successive.

6 Il campo in cui operano questi prodotti è anche denominato Web Analytics.7 Homepage di ClickTale©, http://www.clicktale.com/

11

Caratteristiche non presenti nel loro applicativo e che sarebbero appetibili ai nostri fini:

• non supportano Opera e Chrome;• non offrono un metodo trasparente per inserire il codice in automatico nelle pagine

(simile alla modalità proxy del nostro applicativo).

12

3. Dati raccolti, descrizione e formato

Nel capitolo 2 si è già illustrato in termini generali quali azioni dell'utente vengano rilevate da GWT-Observer e inviate al server backend dell'applicativo e come questi provvede al salvataggio dei dati e alla loro persistenza.Nel presente capitolo si descriverà nel dettaglio quali eventi sono rilevati dal client e con quali convenzioni essi sono salvati su file.

3.1 Descrizione dei dati raccolti

Per ogni tipo di evento rilevato, il client GWT-Observer crea una descrizione appropriata. Si fornirà nel prosieguo una classificazione degli eventi rilevati e un elenco dei dati raccolti per ogni tipo di evento.I dati rilevati si separano in due categorie:

1. Dati che descrivono e identificano l'interazione e che non sono direttamente associati ad azioni intraprese dall'utente durante la navigazione. Questi dati vengono rilevati contestualmente alla inizializzazione della interazione o durante l'esecuzione di GWT-Observer. Saranno trattati nel par.3.1.1 ;es: indirizzo IP dell'utente, sistema operativo.

2. Dati raccolti al fine di descrivere gli eventi e le azioni generate dagli utenti, ognuno di essi viene memorizzato in singole unità assimilabili ai fotogrammi di un filmato (tali fotogrammi verranno denominati ActionShot) e raccolti in una lista ordinata. Ogni fotogramma porta con se l'informazione dell'istante di tempo di registrazione e altre informazioni che differiscono a seconda del tipo di evento rilevato; Saranno trattati nel par.3.1.2 ;es: pressioni tasti, movimenti mouse.

3.1.1 Dati generali sull'interazione

I seguenti dati vengono raccolti dal client (o dal server backend) nei primi istanti di esecuzione e contestualmente alla inizializzazione della interazione:

• ID, identificativo numerico unico della interazione, è generato dal server e deve essere memorizzato assieme ai dati. L'ID della interazione è costituito dal tempo di creazione della interazione e da un valore numerico unico, risulta quindi utile ad identificare l'ordine temporale di creazione delle stesse;

13

• SID, identificativo della sessione HTTP, dato che viene rilevato e memorizzato dal server; può permettere l'identificazione dell'utente quando si opera nella modalità Direct;

• URL, della pagina di cui si sta registrando l'interazione dell'utente (es: www.google.com);• Referrer URL, URL della pagina di provenienza da cui si è arrivati alla pagina corrente o

che risulta essere il “parent”8della pagina corrente;• IP, indirizzo IPV4 o IPV6 dal quale risulta stia avvenendo la navigazione dell'utente.

Esso corrisponde all' indirizzo IP vero dell'utente. Qualora tra client e server vi sia frapposto un NAT o un proxy 9 l'indirizzo IP rilevato non sarà corretto;

• User agent, tipo e versione del browser utilizzati dall'utente (es: Google Chrome, Firefox) e sistema operativo su cui è in esecuzione il browser (es:Windows XP o MacOS);

I seguenti dati vengono raccolti (o determinati) gradualmente durante l'interazione:

• startime, è un numero che rappresenta l'istante di tempo del primo evento registrato nella interazione, ovvero del primo fotogramma;

• endtime, è un numero che rappresenta l'istante di tempo dell'ultimo evento registrato ovvero dell'ultimo fotogramma;

• IframeSlaves, è una lista degli ID delle interazioni che sono state rilevate negli iframe della pagina corrente. Questi ID sono associati all'identificativo del frame come elemento HTML. L'identificativo dell'elemento HTML permetterà in seguito di ricavare la posizione effettiva del frame all'interno della pagina;

3.1.2 Dati relativi alle azioni dell'utente

Il client GWT-Observer inserisce le informazioni relative ad un evento in un fotogramma denominato ActionShot.Il fotogramma di base, ActionShot, è il più semplice e contiene le seguenti informazioni:

• istante di tempo di rilevamento dell'evento;• identificativo numerico del tipo di evento rilevato;• identificativo numerico unico dell'elemento grafico html della pagina che è bersaglio

dell'evento, o nel caso di elemento grafico mai descritto precedentemente viene aggiunta una descrizione dettagliata dell'elemento contenente: tag elemento HTML, posizione assoluta nel documento, dimensione e identificativo10 HTML dell'elemento;

Le azioni dell'utente che appartengono a questa categoria possono essere dei seguenti tipi:

• Movimenti o azioni (Click, doppio click, wheel) effettuate con il Mouse;• Pressione dei tasti della tastiera;• Scroll della finestra;• Ridimensionamento della finestra;

8 Gli iframe inseriti in una pagina vengono considerati dal browser come delle pagine a se stanti. Il documento principale che contiene gli iframe è considerato “parent” dell'iframe stesso. “parent” è anche il nome della proprietà che nel contesto dell'iframe permette l'accesso alle risorse della pagina principale. Per questioni di sicurezza questa operazione è possibile quando iframe e pagina appartengono allo stesso dominio.

9 GWT-Observer/Proxy non interferisce con il rilevamento dell'indirizzo IP.10 Gli elementi HTML possono avere un attributo Id, nel seguente esempio l'elemento div possiede come Id il

nome “gianni”: <h1 id="gianni">Hello World!</h1>

14

A seconda del tipo di evento, la descrizione prodotta dal client GWT-Observer aggiungerà specifiche informazioni al fotogramma di base.

3.1.2.1 Eventi Mouse

Nel caso di azioni prodotte con il Mouse, vengono rilevati e inseriti nel fotogramma i seguenti dati aggiuntivi:

• Coordinata X del cursore del mouse in pixel, relativamente al bordo superiore della finestra;

• Coordinata Y del cursore del mouse in pixel, relativamente al bordo sinistro della finestra;

• Posizione X all'interno del documento in pixel dell'angolo in alto a sinistra della finestra;• Posizione Y all'interno del documento in pixel dell'angolo in alto a sinistra della finestra;• Velocità di rotazione della rotella del mouse;

Si ricorda che la finestra del browser visualizza solo una porzione del documento complessivo, si è quindi deciso di registrare sia la posizione della finestra all'interno del documento che la posizione del mouse all'interno della finestra per permettere di ricavare a posteriori la posizione del cursore del mouse all'interno del documento. Per meglio chiarire il significato dei dati acquisiti l'Illustrazione 2 descrive visivamente il significato delle diverse coordinate.

15

Illustrazione 2: Coordinate all'interno della finestra e del documento.

3.1.2.2 Eventi tastiera

Nel caso di eventi legati alla tastiera, pressione tasto e rilascio, vengono rilevati i seguenti dati aggiuntivi:

• keycode, è il codice del tasto premuto ovvero l'identificativo numerico del carattere;• pressione dei tasti speciali: shift, alt, ctrl, meta, e frecce;

3.1.2.3 Evento scroll della finestra

Nel caso di evento legato allo scroll della finestra vengono salvati i seguenti dati aggiuntivi:

• Posizione X in pixel all'interno del documento dell'angolo in alto a sinistra della finestra;• Posizione Y in pixel all'interno del documento dell'angolo in alto a sinistra della finestra;

3.1.2.4 Evento ridimensionamento finestra

Nel caso di ridimensionamento della finestra, causato dall'intervento dell'utente o dalla logica della pagina, viene generato un fotogramma denominato ResizeAction; tale fotogramma contiene le seguenti informazioni aggiuntive:

• nuova dimensione della finestra in pixel;• informazioni sullo scroll all'interno del documento;• una lista di descrizioni dettagliate degli elementi HTML (uno snapshot11 della pagina);

La descrizione dettagliata degli elementi HTML è analoga a quella inserita negli ActionShot introdotti all'inizio del paragrafo 3.1.2 .La necessità di inviare nuovamente le informazioni relative agli elementi HTML della pagina nasce dal fatto che al ridimensionamento segue un nuovo rendering12 della pagina; le informazioni sugli elementi HTML precedetemene inviate al server non sono più valide e devono essere aggiornate. Il ResizeAction non viene generato solo nel caso di ridimensionamento della finestra ma anche qualora vi fosse l'esigenza di acquisire uno snapshot della pagina..Subito dopo l'inizializzazione GWT-Observer genera un ResizeAction come snapshot iniziale, al fine di inviare una descrizione degli elementi html di maggior interesse presenti nella pagina ( ad esempio bottoni, aree di testo..).

3.2 Descrizione fisica dei dati salvati

Come già anticipato nel paragrafo 2.1.2 i dati relativi alle interazioni vengono raccolti dal server e salvati su file. Al fine di permettere una elaborazione successiva e una ispezione manuale dei dati raccolti, il

11 Snapshot, istantanea fotografica, termine comunemente utilizzato anche per indicare una immagine che riproduce la visuale del desktop intero o di una applicazione come visualizzata sul monitor dell'utente.

12 Con il termine rendering si indica l'operazione con cui il codice della pagina viene tradotto nella pagina visualizzata sul monitor e presentata all'utente. Il risultato finale del rendering dipende da alcuni fattori tra cui il browser utilizzato.

16

salvataggio viene effettuato contemporaneamente in due formati diversi:

• binario, è una serializzazione dei dati raccolti su file binario;• XML, è una serializzazione dei dati effettuati in formato XML, leggibile ed editabile con

un editor di testo;

3.2.1 Convenzioni per i nomi file.

Tutti i files contenenti le registrazioni delle interazioni vengono salvati sull'application server all'interno della directory /WEB-INF relativa all'applicativo GWT-Observer.Il salvataggio binario delle informazioni relative alle interazioni viene effettuato su un unico file denominato TapeDB.Il salvataggio in XML dei dati viene effettuato su più files, un file per interazione, i cui nomi seguono la seguente convenzione: IP-ID_interazione.xml.Come esempio si consideri la registrazione della interazione con identificativo numerico ID 1264457427969003 e attuata da un computer avente indirizzo IP 192.168.2.2, essa verrebbe salvata su un file con il seguente nome: 192.168.2.2-1264457427969003.xml.Essendo l'identificativo della interazione un numero crescente, il nome dei files permette di riconoscere facilmente l'ordine temporale di creazione delle interazioni.

3.2.2 Descrizione della struttura dei dati salvati

Al fine di descrivere nel dettaglio i dati raccolti si userà la rappresentazione XML degli stessi, la seguente trattazione varrà anche come guida alla interpretazione dei dati registrati in formato XML.Si riporta di seguito un estratto esemplificativo di una interazione registrata in formato XML:

<it.univ.trieste.client.utils.Tape serialization="custom">

<unserializable-parents/>

<vector>

<default>

<capacityIncrement>0</capacityIncrement>

<elementCount>8</elementCount>

<elementData>

...

</elementData>

</default>

</vector>

<it.univ.trieste.client.utils.Tape>

<default>

<endTime>1267806347508</endTime>

<numTape>4</numTape>

<startTime>1267806335492</startTime>

<ID>12678063901680000</ID>

<SID>f26476e394484756e8f0b10e57bc</SID>

<URL>http://192.168.0.224:8080/GWT-Observer/</URL>

...

<userIP>192.168.0.66</userIP>

</default>

17

</it.univ.trieste.client.utils.Tape>


All'interno nel file XML si possono distinguere chiaramente due parti, all'inizio del file vi è la lista vector degli eventi (ActionShot) rilevati in ordine temporale come descritti nel paragrafo 3.1.2 , nella seconda parte, inserita tra i tag XML default, vi sono i dati generali sulla interazione già descritti nel paragrafo 3.1.1 .

3.2.2.1 Lista degli eventi registrati, il Tape

Tutti i fotogrammi sono raccolti all'interno di una lista denominata Tape, si riporta di seguito un estratto in cui si è riportata la rappresentazione XML di una lista Tape contenente due elementi.



<vector>

<default>



<elementData>

<it.univ.trieste.client.utils.shots.MouseAction>

<time>1267127711668</time>

<eventType>64</eventType>

<scrollTop>0</scrollTop>

<scrollLeft>0</scrollLeft>

<x__Win>1500</x__Win>

<y__Win>212</y__Win>

</it.univ.trieste.client.utils.shots.MouseAction>


<time>1267127711708</time>




<x__Win>1500</x__Win>



</elementData>

</default>

</vector>


All'interno di questa lista vengono inseriti le registrazioni dei singoli eventi, gli ActionShot.

3.2.2.2 ActionShot

Come già accennato nel par. 3.1.2 il salvataggio del singolo campione o fotogramma avviene in un oggetto di tipo ActionShot, esso raccoglie i seguenti attributi (comuni anche a tutti gli altri eventi) di cui si riporta la serializzazione in formato XML:

<it.univ.trieste.client.utils.shots.ActionShot>

<time>1264457483619</time> (Istante di tempo di rilevamento, valore

18

intero)

<eventType>64</eventType> (Identificativo numerico del tipo di evento)

<onElement> (Identifica l'elemento bersaglio dell'evento)

...

</onElement>

</it.univ.trieste.client.utils.shots.ActionShot>

L' ActionShot è il fotogramma di base, esso include l'istante di campionamento, un intero che descrive la tipologia di evento e un oggetto della classe OnElement (o in alternativa un OnElementDetailed).L'oggetto di tipo OnElement include solo un identificativo unico, denominato HASH13,dell'elemento della pagina:

<onElement>

<hashElement>16</hashElement> (Identificativo elemento, valore intero)

</onElement>

Un oggetto OnElementDetailed viene usato al posto di OnElement nel caso in cui l'elemento bersaglio non sia mai stato descritto precedentemente, in questo caso maggiori informazioni vengono incluse:

<onElement class="it.univ.trieste.client.utils.element.OnElementDetailed">

<hashElement>17</hashElement> (identificativo elemento)

<ID>gino</ID> (ID HTML dell'elemento come da tag: <div

ID="gino"></div>)

<nodeName>H1</nodeName> (il tipo di elemento, esempi: INPUT,

EXTAREA, IFRAME)

<absoluteLeft>437</absoluteLeft> (posizione margine sinistro

dell'elemento)

<absoluteRight>763</absoluteRight> (posizione margine destro dell'elemento)

<absoluteBottom>122</absoluteBottom> (posizione margine inferiore dell'elemento)

<absoluteTop>86</absoluteTop> (posizione margine superiore dell'elemento)

<extrainfo></extrainfo> (elemento XML opzionale, ad esempio contiene

URL nel caso di iframe)

</onElement>

Nel caso in cui l'elemento HTML bersaglio dell'evento appartenga ad una lista di esclusione, l'elemento XML OnElement verrà completamente omesso dall'ActionShot.Il significato della lista esclusione è quella di omettere nella descrizione il riferimento a quegli elementi grafici o strutturali della pagina che sono privi di interesse14.

3.2.2.3 MouseAction

Nel caso di un evento legato al Mouse, devono essere registrate le coordinate relative al

13 La documentazione del GWT definisce tale identificativo numerico HASH, ma contrariamente a quanto possa suggerire il nome è garantita l'unicità dello stesso e quindi non vi può essere una collisione tra identificativi di elementi HTML diversi. Per i dettagli:http://google-web-toolkit.googlecode.com/svn/javadoc/2.0/com/google/gwt/core/client/JavaScriptObject.html

14 La lista è hardcoded, modificarla necessità un intervento sul codice e una ricompilazione dell'applicativo

19

puntatore e l'eventuale velocità della rotella del mouse (wheel), non serve invece inviare degli attributi relativi all'eventuale click dato che queste informazioni sono incluse nell'attributo intero eventType.Il fotogramma in questo caso è un oggetto di tipo MouseAction e contiene i seguenti dati:


<time>1264457428189</time>


<onElement>

...................

</onElement>

<scrollTop>0</scrollTop> (Coordinate dell'angolo in alto a sinistra

<scrollLeft>0</scrollLeft> della finestra relative al documento)

<x__Win>530</x__Win> (Coordinate relative alla finestra, pixel,

<y__Win>95</y__Win> relativi all'angolo in alto a sinistra)

<y__wheel__speed>3</y__wheel__speed> (Velocità della rotella, come ogni valore

lasciato al default può non apparire, nel

caso di evento non Wheel)


3.2.2.4 KeyAction

Nel caso di eventi legati alla pressione dei tasti, essi si distinguono in due categorie:

• KeyPressed, un evento corrispondente alla lettura di un tasto dall'input; tenere premuto un tasto a lungo può portare ad esempio alla creazione di una successione di KeyPressed;

• KeyUp/Down corrisponde alla pressione e al rilascio del tasto; non viene fornita l'informazione del keycode associato al tasto ma vengono rilevati i tasti speciali;

Nel caso di un KeyPressed viene registrato il keycode corrispondente al tasto mentre la pressione dei tasti speciali viene registrata in attributi booleani opportuni.Nel caso di KeyUp/Down vengono memorizzate le pressioni dei tasti speciali.Per entrambi gli eventi le informazioni raccolte sono inserite in un oggetto di tipo KeyAction; si riporta la rappresentazione XML di un evento KeyPressed:

<it.univ.trieste.client.utils.shots.KeyAction>

<time>1264457467806</time>


<onElement>

<hashElement>4196</hashElement>

</onElement>

<keyPressed>102</keyPressed> (Valore intero del keycode)

<ctrl>false</ctrl> (true quando il tasto è premuto, false altrimenti)

<shift>false</shift> (true quando il tasto è premuto, false altrimenti)

<alt>false</alt> (true quando il tasto è premuto, false altrimenti)

<meta>false</meta> (true quando il tasto è premuto, false altrimenti)

<isArrow>false</isArrow> (true quando il tasto è premuto, false altrimenti)

</it.univ.trieste.client.utils.shots.KeyAction>

20

Nel caso di un evento KeyUp/Down, si può notare l'assenza dell'attributo keycode che non viene registrato:


<time>1264457467806</time>


<onElement>


</onElement>

<ctrl>false</ctrl>

<shift>false</shift>

<alt>false</alt>

<meta>false</meta>

<isArrow>true</isArrow> (es: si stava usando una freccia)


3.2.2.5 ScrollAction

Nel caso di un evento legato allo scroll della finestra le informazioni rilevate vengono inserite in un oggetto di tipo ScrollAction, esso è un fotogramma in cui non viene settato alcun valore al campo OnElement ma vengono inseriti in opportuni attributi le coordinate assolute dell'angolo in alto a sinistra della finestra all'interno del documento.

<it.univ.trieste.client.utils.shots.ScrollAction>

<time>1265144742671</time>


<onElement>

….....

</onElement>

<ScrollTop>65</ScrollTop> (Posizione assoluta in pixell nel documento

della finestra, dall'alto)

<ScroolLeft>0</ScroolLeft> (Posizione assoluta … da sinistra)

</it.univ.trieste.client.utils.shots.ScrollAction>

3.2.2.6 ResizeAction

In caso di evento associato al ridimensionamento della finestra, viene creata una lista di descrizione dettagliate degli elementi grafici e vengono inserite in un oggetto di tipo ResizeShot.Siccome ad un ridimensionamento può seguire un rendering della pagina che modifica la posizione degli elementi vi è la necessità di aggiornare il backend su questi cambiamenti.Il fotogramma ResizeAction porta con se una lista di OnElmentDetailed per i soli elementi già inviati in precedenza, ovvero non si mandano informazioni su tutti gli elementi della pagina ma solo su quelli che sono risultati di interesse durante l'interazione.Il seguente fotogramma o campione contiene una lista di elementi vuota:

<it.univ.trieste.client.utils.shots.ResizeAction>

<time>1265144742498</time>

<eventType>-2</eventType>

21

<alreadySentElements/>

<windowsHeight>558</windowsHeight> (Altezza finestra in pixel)

<windowWidth>1351</windowWidth> larghezza finestra in pixel

<ScrollTop>0</ScrollTop> (analogo allo ScrollaAction)

<ScroolLeft>0</ScroolLeft>

</it.univ.trieste.client.utils.shots.ResizeAction>

Il seguente campione porta con se una lista contenente un elemento:


<time>1265144749992</time>


<alreadySentElements> (inizio della lista di elementi)

<it.univ.trieste.client.utils.element.OnElementDetailed>


<ID>pgtitle</ID>

<nodeName>H1</nodeName>

<absoluteLeft>325</absoluteLeft>

<absoluteRight>1025</absoluteRight>

<absoluteBottom>88</absoluteBottom>

<absoluteTop>64</absoluteTop>

</it.univ.trieste.client.utils.element.OnElementDetailed>

</alreadySentElements> (fine della lista di elementi)

<windowsHeight>558</windowsHeight>

<windowWidth>1351</windowWidth>

<ScrollTop>49</ScrollTop>



Nel caso in cui vi sia la necessità di registrare la descrizione di un solo elemento (OnElement o OnElmentDetailed), quando non si sia verificato un evento particolare, può essere usato il seguente tipo di ActionShot denominato ElementNoAction :

<it.univ.trieste.client.utils.shots.ElementNoAction>

<time>1266178648856</time>



<ID></ID>

<nodeName>IFRAME</nodeName>





</onElement>

</it.univ.trieste.client.utils.shots.ElementNoAction>

3.2.2.7 Le informazioni generali sull'interazione

In questa sezione si descriverà la rappresentazione XML dei dati generali illustrati nel par.3.1.1 .

22

Tra le informazioni raccolte ve ne sono alcune che sono state omesse nella trattazione generale perché legate a questioni di natura implementativa.Si riporta di seguito un esempio delle informazioni generali in versione XML:


<default>




<ID>12678064201780002</ID>

<SID>f26476e394484756e8f0b10e57bc</SID>


<correctlyClosed>true</correctlyClosed>

<iFrameSlaves>

<entry>

<long>12678064202700003</long>

<int>18</int>

</entry>

</iFrameSlaves>

<referURL></referURL>

<userAgent>Mozilla/5.0 (X11; U; Linux i686; it; rv:1.9.1.3) Gecko/20090909 SUSE/3.5.3-1.2

Firefox/3.5.3</userAgent>


</default>


Nell'esempio sono già riconoscibili i dati principali; se ne darà ora una descrizione esaustiva:


Istante di tempo dell'ultimo evento(ovvero ActionShot) registrato nella interazione.


Numero di trasmissioni, o di richieste contenente dati, effettuate dal client durante l'interazione.


Istante di tempo del primo evento registrato nella interazione.

<ID>12678064201780002</ID>

ID unico della interazione.

<SID>f26476e394484756e8f0b10e57bc</SID>

SID, identificativo unico della sessione HTTP associata a questa interazione


URL della pagina di cui si è registrata l'interazione (L'URL utilizzata dal client per identificare e scaricare la pagina) .<correctlyClosed>true</correctlyClosed>

Indica se l'interazione si è chiusa correttamente ovvero se è stata ricevuta la richiesta endOfInteraction (EOI) che informa il server della chiusura della interazione.

23

Vi sono situazioni in cui l'invio dell'EOI potrebbe non avvenire, come nel caso di sessioni dimenticate aperte per ore dall'utente e mai chiuse, o nel caso in cui il client non abbia fatto in tempo ad inviare la richiesta prima della sua finalizzazione da parte del browser.In questi casi, dopo un periodo di inattività scatta un timeout nel server e l'interazione viene salvata settando l'attributo correctlyClosed a false.

<iFrameSlaves>

<entry>

<long>12678064202700003</long>

<int>18</int>

</entry>

</iFrameSlaves>

Lista degli iframe che contengono un altra istanza di GWT-Observer.IframeSlaves contiene l'ID (nel corso della trattazioni questi ID verranno denominati anche SlaveID in modo da indicare la gerarchia che vi è tra le pagine) della istanza contenuta nel frame e l'HASH dell'elemento HTML corrispondente al frame.

<referURL>http://www.repubblica.it/</referURL>

URL da cui è stata caricata la pagina della interazione (o URL di provenienza della navigazione).Nel caso degli iframe indica l'URL della pagina parent (genitore).



Identificativo del tipo di browser e del sistema operativo e architettura.


Indirizzo IP da cui risulta provenire la connessione del client GWT-Observer al server backend.Anche nella modalità GWT-Observer/Proxy questo dato risulta essere corretto siccome si sono implementate nel proxy Squid e nel server ICAP15 delle funzionalità atte alla comunicazione della informazione al server backend.

3.3 Rappresentazione XML dei dati, esempio completo

Per meglio comprendere la struttura complessiva del file XML relativo ad una interazione se ne riporta un esempio completo:



<vector>

<default>



<elementData>


<time>1267806335492</time>


<alreadySentElements>

15 Per i dettagli riguardanti i server ICAP e il proxy Squid si rimanda ai cap.4 e 5.

24



<ID></ID>

<nodeName>INPUT</nodeName>








<ID></ID>






<extrainfo>http://192.168.0.224:8080/GWT-Observer/hello.html</extrainfo>




<ID>it.univ.trieste.observer</ID>






<extrainfo>javascript:''</extrainfo>


</alreadySentElements>

<windowsHeight>847</windowsHeight>

<windowWidth>1680</windowWidth>

<ScrollTop>0</ScrollTop>




<time>1267806343748</time>




<x__Win>1136</x__Win>

<y__Win>34</y__Win>



<time>1267806344371</time>




<ID></ID>

<nodeName>IMG</nodeName>

25





</onElement>



<x__Win>512</x__Win>




<time>1267806369167</time>


<onElement>


</onElement>

<ctrl>false</ctrl>


<alt>false</alt>

<meta>false</meta>

<isArrow>false</isArrow>



<time>1267806369167</time>


<onElement>


</onElement>

<keyPressed>101</keyPressed>

<ctrl>false</ctrl>


<alt>false</alt>

<meta>false</meta>




<time>1267806369260</time>


<onElement>


</onElement>

<ctrl>false</ctrl>


<alt>false</alt>

<meta>false</meta>



</elementData>

</default>

</vector>

26


<default>




<ID>12678063901680000</ID>

<SID>f26476e394484756e8f0b10e57bc</SID>


<correctlyClosed>true</correctlyClosed>

<iFrameSlaves>

<entry>

<long>12678063901790001</long>

<int>18</int>

</entry>

</iFrameSlaves>

<referURL></referURL>




</default>



27

4. Manuale d'uso

Nel presente capitolo si illustreranno nel dettaglio l'utilizzo dell'applicativo, la sua installazione e la sua configurazione.Nel capitolo 2 si è già data una descrizione generale dell'applicativo GWT-Observer e si sono descritte le due modalità di utilizzo :

1. Direct2. Proxy

Nei due casi le modalità di installazione differiscono e verranno trattate separatamente nel paragrafo 4.1 e 4.2 .

4.1 Modalità Direct

Nella modalità Direct l'amministratore di un sito integra GWT-Observer in alcune, o tutte, le pagine al fine di acquisire informazioni dettagliate sull'interazione dell'utente.Il gestore può quindi scegliere se monitorare tutte le pagine del proprio sito o solo alcune di interesse (ad esempio pagine di registrazione e login).L'installazione di GWT-Observer nella modalità Direct si separa in tre fasi:

1. integrazione di GWT-Observer nelle pagine di interesse;2. setup del servizio backend di GWT-Observer su un application server;3. impostazione dell'accesso al servizio backend per i client GWT-Observer;

4.1.1 Integrazione di GWT-Observer nelle pagine di interesse.

4.1.1.1 Installazione con impostazioni di default

L'integrazione di GWT-Observer all'interno di una pagina preesistente avviene aggiungendo alcune righe di codice html alla sezione body o alla sezione head della pagina.

29

Tale codice carica ed esegue il JavaScript dell'applicativo; prendiamo il caso di una pagina avente l'indirizzo http://www.paginamia.com/index.html di cui si riporta un codice esemplificativo :

1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

2 <html>

3 <head>

4 <meta name='gwt:module' content='it.univ.trieste.observer=it.univ.trieste.observer'>

5 <title>Pagina semplice di qualcuno</title>

6 </head>

7 <body>

8 <script language="javascript"

9 src="/GWT-Observer/it.univ.trieste.observer/it.univ.trieste.observer.nocache.js">

</script>

10 <textarea name="lineinput" rows="4" cols="11">

11 Ciao mondo

12 tutto tondo

13 </textarea>

14

15 <input type="submit" value="Clicca che ti passa" name="BottoneMio1" />

16

17 <form name="FormMio" method="POST">

18 <input type="text" name="nome" value="Nomemio" />

19 <input type="text" name="cognome" value="" />

20 </form>

21 <input type="submit" value="Happy Submit" name="SubmitNow" />

22 </body>

23 </html>

Le righe 8-9 rappresentano la modifica attuata al fine di inserire GWT-Observer nella pagina, la riga 4 è facoltativa e può essere omessa.Con le modifiche esposte il client GWT-Observer verrà scaricato dal browser e quindi eseguito all'interno della pagina, comunicando con il servizio web che nella prima configurazione proposta è ubicato al seguente indirzzo:www.paginamia.com/GWT-Observer/it.univ.trieste.observer/network/gwttapestream .Naturalmente si è fatta l'assunzione che le risorse e i servizi relativi a GWT-Observer risultino disponibili alle URL specificate e all'interno dello stesso dominio della pagina (si rimanda per i dettagli al par.4.1.2.3 ), questo viene garantito nel caso in cui la pagina e il backend GWT-Observer siano serviti dallo stesso AS. Nel caso in cui AS e webserver si trovino su host separati, si dovrà provvedere a ricreare la precedente condizione introducendo delle ridirezioni (par.4.1.2.4 ).

4.1.1.2 Configurazioni alternative e vincoli imposti

Il precedente approccio garantisce il funzionamento dell'applicativo nel caso in cui esso sia compilato e installato nella sua configurazione di default vi è però la possibilità di esprimere l'indirizzo delle risorse relative al servizio GWT-Observer fornendo anche una URL assoluta della risorsa JavaScript:

30

In questo teatro operativo lo script del client GWT-Observer è scaricabile con la seguenteURL:

http://132.160.8.12/GWT-Observer/it.univ.trieste.observer/it.univ.trieste.observer.nocache.js

Il servizio web GWT-RPC è raggiungibile per le richieste XHR alla URL:

http://132.160.8.12/GWT-Observer/it.univ.trieste.observer/network/gwttapestream

Si consideri un secondo esempio in cui l'application server appartenga al dominio www.paginamia.com, le risorse del servizio risulterebbero raggiungibili alla URL:

www.pagina.com/GWT-Observer/

URL del client sarà:

http://www.pagina.com/GWT-Observer/ it.univ.trieste.observer/it.univ.trieste.observer.nocache.js

URL del servizio web GWT-RPC:

http://www.pagina.com/GWT-Observer/it.univ.trieste.observer/network/gwttapestream

4.1.2.3 Problematiche relative alla Same Origin Policy

La Same Origin Policy o SOP [10] è un'importante misura di sicurezza introdotta nei browser al fine di impedire ai JavaScript di una pagina di accedere alle risorse o ai metodi di un servizio o di un sito localizzati su un altro dominio.Tale misura è attuata al fine di proteggere delle informazioni, quali i cookies che sono comunemente utilizzate nelle web application a fine di autenticazione.I JavaScript appartenenti alla pagina "http://www.example.com/dir/page.html" potranno accedere ad una risorsa a seconda dell'esito del confronto tra le URL della risorsa e della pagina originaria, nella seguente tabella sono riportati degli esempi per meglio comprendere le restrizioni imposte18:

URL confrontata Risultato Motivo

http://www.example.com/dir/page.html Successo Stesso protocollo e hosthttp://www.example.com/dir2/other.html Successo Stesso protocollo e host

http://www.example.com:81/dir2/other.html Fallimento Stesso protocollo e host,differente portahttps://www.example.com/dir2/other.html Fallimento Differente protocollo

http://en.example.com/dir2/other.html Fallimento Differente hosthttp://example.com/dir2/other.html Fallimento Differente host (devono coincidere)

http://v2.www.example.com/dir2/other.html Fallimento Differente host (devono coincidere)

Vi sono due modi di aggirare la SOP permettendo ad un JavaScript di comunicare con un servizio su un altro dominio:

18 Tabella esemplificativa, fonte Wikipedia [10]

32

1. il webserver o un intermediario devono redirigere19 le richieste dei JavaScript al dominio reale del servizio richiesto.

2. il JavaScript può aggirare la SOP in modo indipendente, utilizzando un workaround, ad esempio caricando dinamicamente la risposta JSON in un tag <script>. Questi workaround non sono applicabili alle GWT-RPC20.

Viste queste limitazioni imposte dalla SOP, i servizi web di GWT-Observer dovranno possedere una URL nello stesso dominio delle pagine da monitorare.In aggiunta la SOP impone che la porta utilizzata per l'accesso ai servizi web sia la stessa utilizzata per l'host della pagina da monitorare.L'uso delle GWT-RPC non permette di aggirare direttamente le limitazioni imposte dalla SOP e nel caso in cui vi fosse la necessità di posizionare il sito, gli elementi statici e i servizi web su host differenti e su domini differenti, vi sarà la necessità di configurare il webserver in modo da redirigere in modo trasparente le richieste ai servizi GWT-Observer. Il browser dell'utente effettuerebbe quindi richieste a risorse e servizi presenti sullo stesso dominio della pagina e non interverrà la SOP ad impedire l'invio delle richieste (par.4.1.2.4 ).

4.1.2.4 Esempio di configurazione del WebServer, note generali

Nel caso in cui la logica del sito, i contenuti statici e i servizi web, risultassero serviti dallo stesso application server non si presenterebbe nessuno dei problemi legati alla SOP21.Nel presente paragrafo si tratterà invece il caso di un webserver (utilizzato per i contenuti della pagine) e un AS (utilizzato per l'esecuzione del backend Observer) installati su host e domini differenti.Questa situazione permette l' integrazione di GWT-Observer all'interno di un sito web preesistente imponendo il minor numero di modifiche alla configurazione precedente.L'integrazione del codice per il client si è già effettuata con l'inserimento di una linea di codice nella pagina; il corretto setup dei servizi web richiede maggiore attenzione e l'adozione di accorgimenti in modo da aggirare la SOP.Al fine di conseguire questo risultato si dovrà configurare il WS in modo da redirigere le richieste corrispondenti a particolari URL verso i servlet dell' AS22, in questo modo il WS opererà per queste richieste alla stregua di un proxy [13].Consideriamo il seguente esempio:

• il server Apache è in esecuzione su www.example.com;• l'Application Server è in esecuzione su servlet.example.com:8080;• il contesto del modulo GWT è /GWT-Observer;• vi è un unico servlet RPC mappato su /GWT-Observer/nomeservizio.

L'obiettivo è di configurare Apache in modo da redirigere la richiesta attuando, in modo trasparente al browser, la seguente modifica della URL:

19 La ridirezione deve avvenire in modo trasparente al browser, una redirezione http non è quindi la strada praticabile, si dovrà invece configurare il webserver in modo da agire da proxy inviando le richieste ricevute all'host corretto per il servizio. Il webserver restituirà le risposte ricevute al browser che quindi avrà l'illusione che i servizi risiedano sul webserver.

20 Il codice della pagina può modificare l'attributo src di un elemento <script> del DOM in modo da caricare all'interno di esso del codice da una pagina al di fuori del dominio del sito. Il codice scaricato contiene i dati richiesti. Per i dettagli su questo meccanismo consultare la documentazione GWT relativa al cross site scripting http://code.google.com/webtoolkit/doc/latest/tutorial/Xsite.html [11]

21 descritti nel paragrafo 4.1.2.3.22 http://code.google.com/webtoolkit/doc/latest/DevGuideServerCommunication.html [11]

33

http://www.example.com/GWT-Observer/nomeservizio --> http://servlet.example.com:8080/GWT-Observer/nomeservizio

La seguente configurazione di Apache realizza la precedente regola:

ProxyPass /GWT-Observer/nomeservizio

http://servlet.example.com:8080/GWT-Observer/nomeservizio

ProxyPassReverse /GWT-Observer/nomeservizio

http://servlet.example.com:8080/GWT-Observer/nomeservizio

La soluzione proposta implementa l'integrazione del server GWT-Observer in esecuzione su un host differente da quello del webserver, aggirando così le limitazioni imposte dalla SOP.

4.2 Modalità Proxy

In alternativa alla modalità Direct, in cui l'amministratore integra GWT-Observer nel proprio sito, la modalità Proxy integra GWT-Observer con un proxy HTTP opportunamente configurato.Lo scopo è quello di monitorare le interazioni degli utenti connessi attraverso il GWT-Observer/Proxy durante la navigazione su qualunque sito internet (illustrazione 3).

34

Illustrazione 3: GWT-Observer/Proxy, elementi costitutivi.

4.2.1 Guida all'installazione

L'illustrazione 3, raffigura la richiesta di una pagina web da parte di un client connesso al proxy. In azzurro sono evidenziati gli elementi costitutivi della infrastruttura GWT-Observer/Proxy, in colore verde sono rappresentate le connessioni tra questi elementi costitutivi, in colore nero sono rappresentate le connessioni con elementi esterni all'infrastruttura GWT-Observer/Proxy.Al fine di implementate la modalità Proxy si dovranno quindi effettuare le seguenti operazioni:

• setup dell'application server e installazione del servizio GWT-Observer;• installazione e configurazione del server ICAP GreasySpoon;• installazione e configurazione del URL-rewriter (o redirector) Squirm;• installazione e configurazione del proxy HTTP Squid.

I paragrafi seguenti descriveranno i passi fondamentali relativi all'installazione dei servizi su un server Linux.

4.2.2 Setup dell'application server

L'installazione dell'applicativo ovvero il deployment sull' applicacation server non differisce da quanto già descritto nel paragrafo 4.1.2 .

4.2.3 Installazione del server ICAP

Il server ICAP potrà essere installato sia sullo stesso host dell'AS che su un host differente.Come server ICAP si è installato GreasySpoon23, tale software permette di programmare la modifica dei contenuti utilizzando degli script in linguaggio Java.

23 http://greasyspoon.sourceforge.net/ GreasySpoon è un applicativo opensource, i sorgenti sono disponibili con licenza GPL.

35

Illustrazione 4: console amministrativa del server ICAP GreasySpoon

Una volta effettuata l'installazione dell'applicativo e messo in esecuzione24 si potrà procedere alla sua configurazione accedendo con il browser ad una console di amministrazione in ascolto alla porta 9088 dell'host.Nel caso in cui si stia operando direttamente sull'host di GreasySpoon, si potrà inserire nel browser l'URL http://localhost:9088/ e apparirà una interfaccia web che funge da console di amministrazione e dalla quale si potranno gestire gran parte delle configurazioni (Illustrazione4).Nel nostro caso si è configurato il server ICAP in modo da porre i suoi servizi in ascolto sulla porta 8344.Si fa notare che in alternativa alla configurazione via interfaccia web vi è la possibilità di editare direttamente i file di configurazione.Si dovrà ora procedere all'inserimento degli script atti alla manipolazione delle richieste e delle risposte.La console di amministrazione di GreasySpoon fornisce un editor che permette la creazione degli script, di abilitarne l'accesso e di impostare il nome del servizio ad essi legato.Si dovrà inserire uno script per la manipolazione delle sole risposte (che consistono nelle pagine HTML richieste dai client), e si è configurato in modo da rispondere al nome di servizio injectobserver:

//-------------------------------------------------------------------

// ==ServerScript==

// @name injectobserver

// @status on

// @description adds Observer's call into the main BODY .

// @include .*

// @exclude

// @responsecode 200

// ==/ServerScript==

// --------------------------------------------------------------------

// Note: use httpMessage object methods to manipulate HTTP Message

// use debug(String s) method to trace items in service log (with log level >=FINE)

// ---------------

public void main(HttpMessage httpMessage){

try{

if (httpMessage.getResponseHeader("Content-Type").contains("text/html")) {

String body = httpMessage.getBody(

int posbod0 = body.indexOf("<body");

int posbod1 = body.indexOf("<BODY");

int posbod = (posbod0<posbod1) ? posbod0 : posbod1;

if (posbod<0) {

posbod = (posbod0>posbod1) ? posbod0 : posbod1;

}

if (posbod!=-1){

int pos1 = body.indexOf(">", posbod)+1;

body = body.substring(0,pos1)+

"<script language=\"javascript\" src=\"/GWT-

Observer/it.univ.trieste.observer/it.univ.trieste.observer.nocache.js\"></script>"+

24 Si consiglia la lettura delle istruzioni di installazione allegate all'applicativo.

36

body.substring(pos1);

httpMessage.setBody(body);

}

}

// httpMessage.toJson();

//httpMessage.minify();

}catch (Exception e){

debug(e.getMessage());

}

}

Si dovrà poi creare un secondo script utile all'elaborazione delle richieste effettuate dai client GWT-Observer, questo servizio ICAP sarà denominato addipheader:

//-------------------------------------------------------------------

// ==ServerScript==

// @name addipheader

// @status on

// @description Add X-observer-ip header containing the current browser IP.

// @include .*

// ==/ServerScript==

// --------------------------------------------------------------------

// Note: use httpMessage object methods to manipulate HTTP Message

// use debug(String s) method to trace items in service log (with log level >=FINE)

// ---------------

// ---------------

public void main(HttpMessage httpMessage){

//start your code from here

//System.err.println(httpMessage.getUsername());

//System.err.println(httpMessage.getUsergroup());

//System.err.println(httpMessage.getRequestHeaders());

//System.err.println(httpMessage.getBody());

debug(httpMessage.getRequestHeaders());

String userIP= httpMessage.getUsername();

httpMessage.addHeader("X-Observer-IP",userIP);

}

Si dovrà quindi abilitare questi servizi dal pannello di amministrazione e a quel punto il server ICAP risulterà pronto ad elaborare i contenuti per il server proxy Squid.

4.2.4 Installazione dell'URL-rewriter Squirm

L'URL-rewriter o redirector è un software che viene eseguito all'occorrenza dal proxy Squid e

37

per questo motivo dovrà essere installato sulla stessa macchina host su cui è stato installato il proxy.Si è scelto come URL-rewriter il software Squirm25 versione 1.2.6, un applicativo opensource i cui sorgenti sono disponibili sotto licenza GPL.Per l'installazione di Squirm si dovrà procedere allo scaricamento dei sorgenti e alla compilazione degli stessi26.Nella configurazione standard l'applicativo viene installato in /usr/local/squirm , i seguenti file di configurazione, squirm.conf e squirm.patterns dovranno essere inseriti nella cartella /usr/local/squirm/etc:

squirm.conf

begin

#network 10.0.0.0/8

network 127.0.0.0/24

network 192.168.0.0/24

network 0.0.0.0/0

log logs/match.log

#abort-log logs/abort.log

#pattern squirm.patterns get

pattern squirm.patterns all

end

squirm.patterns

regex ^.*/GWT-Observer/(.*) http://localhost:8080/GWT-Observer/\1 /GWT-Observer/

squirm.patterns definisce una serie di regole in cui una URL che corrisponde ad una espressione regolare viene convertita nella seconda espressione.Nell'esempio riportato qualsiasi richiesta al cui interno compaia la stringa “/GWT-Observer/” viene rediretta a localhost:8080/GWT-Observer/.Questa scelta fa riferimento al caso esemplificativo in cui il proxy e l'AS siano installati sullo stesso host, si riporta ora un esempio del file squirm.patterns per un AS installato su un altro host all'URL http://mio.server.net:8080 :

regex ^.*/GWT-Observer/(.*) http://mio.server.net:8080/GWT-Observer/\1 /GWT-Observer/

In alternativa si può utilizzare, la più specifica:

regex ^.*/GWT-Observer/it\.(.*) http://localhost:8080/GWT-Observer/it\.\1 /GWT-Observer/it

4.2.5 Installazione e configurazione del proxy HTTP Squid

L'installazione del proxy HTTP Squid può essere attuata attraverso il gestore di pacchetti

25 Homepage progetto, http://squirm.foote.com.au/26 si rimanda alla documentazione allegata ai sorgenti stessi

38

specifico della distribuzione Linux utilizzata, non si entrerà quindi nel dettaglio ma si rimanda alla documentazione del propria distribuzione o sistema operativo e alla documentazione presente sul sito del progetto Squid27.Si è fatto uso in questa trattazione del proxy Squid versione 3.0, si fa nota che le versioni precedenti mancano di alcune features necessarie mentre le versioni successive implementano le stesse funzionalità. Si invita comunque a verificare il manuale online di Squid siccome i file di configurazione sono talora soggetti a delle modifiche.Nel proseguo non si riporteranno per intero i file di configurazione ma solo le porzioni notevoli e modificate degli stessi.Modifiche attuate al file di configurazione squid.conf, sezione ACL,:

#Recommended minimum configuration:

acl manager proto cache_object

acl localhost src 127.0.0.1/32

acl to_localhost dst 127.0.0.0/8

#

# CUSTOM ACLs

# identifica le richieste e le risposte inviate ad una url contenente “GWT-Observer/it.univ”

acl to_observerservice urlpath_regex GWT-Observer/it\.univ

# identifica le risposte il cui mime-type corrisponde a text/html

acl htmlacl rep_mime_type -i text/html

# identifica le sole richieste gwt-rpc (il fine sarà inseguito di aggiungere una proprietà allo

# header contenente informazioni sull'IP del client

acl gwtreqacl req_mime_type -i text/x-gwt-rpc

# acl che ha lo scopo di identificare risorse corrispondenti a pubblicità, è approssimativa,

# ferma qualcosa, non è detto che serva le pubblicità potrebbero essere utili.

acl advertise dstdom_regex (/cgi-bin/nph-adclick\.exe|

doubleclick.net|/ads/media/images/|/smartbanner/|\.com/ads/banners/|/apfbanners/|/realmedia/ads/

|/event\.ng/|/pics/banner/|/viewcgi?

pool=|/clicktrack|/hittrack|/images\.go2net\.com/go2net/ads/|\.com/banners/|\.com/httpads/|\.com

/advertising/|/ads/adview\.php\?)

La successiva modifica indica a Squid di utilizzare l'URL-rewriter Squirm. Squid eseguirà all'occorrenza alcune istanze di Squirm in automatico ma si dovrà prestare attenzione ai permessi dell'utente Squid a cui dovrà essere permesso pieno accesso all'eseguibile Squirm e ai files di configurazione relativi.

File squid.conf, sezione URL-rewriter:

url_rewrite_program /usr/local/squirm/bin/squirm

url_rewrite_children 10

La seguente sezione configura l'utilizzo da parte di Squid del server ICAP, si fa notare che si è considerato il caso in cui i servizi ICAP e proxy risiedano sullo stesso host.

27 Homepage progetto, http://www.squid-cache.org/

39

File squid.conf, sezione ICAP options:

# ICAP OPTIONS

icap_enable on

icap_send_client_ip on

File squid.conf, sezione ICAP options, definizione dei servizi ICAP:

# associa al nome injectobserver il servizio icap://localhost:8344/injectobserver, configurato

in

# modo da modificare le pagine ->prima<- della memorizzazione cache

icap_service addipheader reqmod_precache 0 icap://localhost:8344/addipheader

icap_service injectobserver respmod_precache 0 icap://localhost:8344/injectobserver

#icap_service injectobserverhead respmod_precache 0 icap://localhost:8344/injectobserverhead

File squid.conf, sezione ICAP options, definizione delle classi associate ai servizi ICAP:

#<----->icap_class classname servicename

icap_class class_1 injectobserver

icap_class class_2 addipheader

#icap_class class_1 injectobserverhead

File squid.conf, sezione ICAP options, condizioni per l'invio ai servizi ICAP, basato sulle precedenti ACL:

# TAG: icap_access

#<----->Redirects a request through an ICAP service class, depending

#<----->on given acls

#

# Le richieste indirizzate ai servizi GWT-Observer devono essere modificate in modo da inserire

# nello header l'informazione relativa all'IP del client.

icap_access class_2 allow gwtreqacl

# definisce per quali utenti/condizioni il messaggio viene passato al servizio ICAP

# i messaggi che non risultano avere un Content-type text/html non devono essere modificati

icap_access class_1 deny !htmlacl

# tutti i messaggi che corrispondono a richieste ai servizi GWT-Observer non devono essere

# modificati

icap_access class_1 deny to_observerservice

# non si aggiunge GWT-Observer alle pagine (iframe) pubblicitari, opzionale può essere eliminata

# siccome in alcuni casi studiare l'interazione on le pubblicità potrebbe essere di interesse

#icap_access class_1 deny advertise

icap_access class_1 allow all

40

Negli esperimenti effettuati si è configurato il proxy Squid in modo da fornire il servizio sulla sua porta di default, la 3128.

4.2.6 Configurazione dei browser dell'utente

Al fine di attuare il monitoraggio della navigazione gli utenti dovranno configurare i loro browser in modo da connettersi ad internet attraverso il GWT-Observer/Proxy.Agli utenti si dovrà fornire l'IP (o nome di dominio) del server proxy e la porta scelta per il servizio28.

28 Essi dovranno fare riferimento al manuale del proprio browser. Nel caso del browser Firefox le opzioni relative sono disponibili attraverso il menu Modifica->Preferenze->Rete->Impostazioni.

41

5. Implementazione

5.1 Tecnologie utilizzate, approfondimenti

Nel capitolo 2 si sono elencate le principali tecnologie utilizzate per lo sviluppo dell'applicativo:

• Linguaggio di programmazione Java• Google Widget Toolk GWT• JavaScript e AJAX

5.1.1 GWT Google Widget Toolkit

In questa sede si vuole approfondire la descrizione delle GWT fornita nel paragrafo 2.2.1 mettendo in risalto gli aspetti che sono fondamentali per la comprensione della trattazione successiva.

5.1.1.1 Deferred binding e permutazioni

Nel processo di compilazione delle GWT vengono prodotte più versioni Javascript dell'applicativo, ognuna di queste versioni viene detta permutazione.Una delle caratteristiche di GWT è quella di supportare il maggior numero di browser possibili e a tal fine il compilatore GWT crea un pool di eseguibili ognuno compatibile con un dato browser.Vengono create permutazioni differenti anche in base alla localizzazione, ad esempio se volessimo supportare tre lingue e quattro browser (Firefox,IE,Safari,e Opera) verrebbero prodotti 3 x 4 = 12 eseguibili JavaScript distinti e ognuno contenente il codice specifico per supportare un particolare browser ed una particolare lingua.Il compilatore GWT produce un ulteriore JavaScript denominato nocache.js, il cui scopo è di rilevare browser (e localizzazione) e di caricare all'interno della pagina il codice della permutazione compatibile.Al fine di inserire l'applicativo nella pagina basterà quindi eseguire lo script nocache.js.

43

Questa tecnica di caricamento dell'applicativo è denominata deferred binding29 e le diverse versioni dell'applicativo prodotte dalla compilazione vengono denominate permutazioni.A titolo esemplificativo, utilizzando l'ambiente di sviluppo NetBeans, il plugin GWT4NB, e utilizzando il linker di default, il compilatore GWT produce i seguenti files che vengono inseriti nella directory “/web” dell'applicativo:

05A947BA2AE7F787078D66F670AEBAAD.cache.html AB3D11E1FD5504987D99280CE911FC3B.cache.html

0A9476898799A150D840F0B1C3672921.cache.png clear.cache.gif

16E641C7C79BD3C1168FA0461DB3C796.cache.html DF7764EEC1903CD03C9545B354D8D8E4.cache.png

1BDD0A86CAC8ECD70B8A5E6498399DA9.gwt.rpc E44767377485D18D6B6864F65BA8EF73.cache.png

2337F63FF5E81EEB755755DEDABB6C8E.cache.html EDC7827FEEA59EE44AD790B1C6430C45.cache.png

396F806CD63ABD414BFBB9D57429F05B.cache.png hosted.html

4762CFCA2D18D78E161CC57633A4F729.cache.html it.univ.trieste.observer.nocache.js

53F023A91C3330AE95E8D572DE43E85E.cache.html

Nei file HTML generati, i cui nomi sono costituiti da una sequenza alfanumerica, è contenuto il codice JavaScript delle diverse permutazioni.Il file it.univ.trieste.observer.nocache.js è in verità lo script nocache.js ovvero il loader dell'applicazione.

5.1.1.2 Linker di default e linker cross site

Il GWT fornisce diversi tipi di linker che modificano il modo in cui il loader nocache.js carica ed esegue il codice dell'applicativo nella pagina.Utilizzando il linker di default si va ad inserire il codice delle permutazioni all'interno di una serie di file HTML (par.5.1.1.1 ), uno per permutazione.Il caricamento dell'applicativo all'interno della pagina viene effettuato dallo script nocache.js creando all'interno del DOM un iframe invisibile nel quale viene caricata la risorsa HTML corrispondente alla permutazione (adatta al browser rilevato).L'uso dell'iframe garantisce un sandbox per l'applicativo GWT, isolandolo dal contesto della pagina, ma impedisce il caricamento di applicativi GWT da domini differenti da quello della pagina30 Il cross-site linker risolve il sopracitato problema legato ai domini e permette il caricamento dell'applicativo anche da domini diversi da quello della pagina.Nella modalità xs il codice non viene più eseguito all'interno di un iframe ma viene eseguito nello stesso contesto della pagina, inoltre le permutazioni non sono più inserite all'interno di file HTML ma il loro codice è inserito in file aventi estensione js.Sia con il linker di default che con il linker cross-site non cambiano le modalità di inserimento del codice all'interno della pagina, basterà eseguire lo script nocache.js il quale provvederà al caricamento e alla esecuzione della permutazione. Il linker cross-site è meno documentato e presenta alcune limitazioni di seguito enumerate:

• il debugging dell'applicativo in Developement Mode non è possibile;• il code splitting31 non è supportato.

29 http://code.google.com/intl/it-IT/webtoolkit/doc/latest/tutorial/compile.html30 L'iframe introduce delle misure di sicurezza atte a proteggere i contenuti della pagina genitore, tali misure di

isolamento agiscono quando l'URL del contenuto nell'iframe appartiene ad un dominio diverso da quello della pagina. In questo caso non è permesso agli script dell'iframe di accedere al documento del parent. Siccome gli applicativi GWT accedono puntualmente a queste risorse essi non possono funzionare.

31 http://code.google.com/webtoolkit/doc/latest/DevGuideCodeSplitting.html

44

La prima lacuna è aggirabile effettuando il debugging con il linker di default e utilizzando il cross-site linker solo per la versione di produzione.Il code splitting non è una feature utilizzata in GWT-Observer per cui la sua mancanza è ininfluente ai nostri scopi.Per questi motivi si è scelto di adottare il linker cross-site per GWT-Observer, in modo da assicurare la compatibilità con il maggior numero di pagine.

5.2 Analisi e progetto

5.2.1 Definizione del problema

Nel progetto dell'applicativo si è dapprima stesa una descrizione generale dello stesso, tale descrizione è riportata nel paragrafo 2.1 a cui si rimanda per i dettagli.In sintesi l'applicativo lato client deve effettuare le seguenti operazioni:

• rilevare le azioni dell'utente (mouse, tastiera e eventi particolari browser);• inviarne una descrizione al server.

L'applicativo lato server deve:

• ricevere le descrizioni delle azioni dal client;• salvarle su file.

Si è poi espansa questa prima descrizione dei ruoli introducendo maggiori dettagli:Il client deve:

• chiedere un identificatore unico dal server per l'interazione;• rilevare le azioni dell'utente;• registrare le azioni rilevate su un buffer locale;• spedire periodicamente le informazioni nel buffer al server;• nel caso di chiusura del browser o della pagina informare il server della fine

dell'interazione.

Il server deve:

• generare ed inviare un identificativo unico al client per l'interazione;• ricevere i dati inviati dal client e aggiungerli alla registrazione della interazione;• in caso di segnalazione della interruzione, salvare la registrazione su file con una serie di

dati identificativi.• essere in grado di gestire accessi concorrenti di più client.

Si sono definite ulteriori specifiche per l'applicativo lato client, infatti quest'ultimo è la componente più critica del progetto siccome deve svolgere le sue operazioni senza interferire con la navigazione dell'utente:

45

• il client JavaScript di GWT-Observer non deve alterare o rallentare in modo percettibile la navigazione dell'utente, a tal fine il carico dell'applicativo sulla CPU deve essere adeguato;

• la banda occupata dall'applicativo deve essere tale da consentire un uso remoto anche sulle normali linee ADSL senza interferire con altri eventuali servizi;

• possibilità di campionare gli eventi ad una frequenza massima prefissata (il default sarà di 40 Hz);

• la decimazione dei dati al fine del campionamento non si applicherà ai dati ritenuti di importanza vitale (pressione dei tasti, click del mouse, dettagli sugli elementi grafici).

5.2.2 Design dell'applicativo

La descrizione del par.5.2.1 ha portato alla stesura della flowchart (Illustrazione 5) relativa all'applicativo lato client.Per il progetto della componente server si è preferito attuare successivamente una stesura diretta del diagramma delle classi.Si è proseguito nell'analisi definendo le classi principali e i metodi relativi; si riportano di seguito le descrizioni generali delle classi principali, per le classi omesse si rimanda ai paragrafi successivi32 o alla documentazione JavaDoc.

5.2.2.1 ObserverEntryPoint

ObserverEntryPoint è l'entry point per l'applicativo GWT lato client.

5.2.2.2 Sniffer

Sniffer è la classe principale dell'applicativo lato client, una classe la cui istanza è responsabile di registrare gli handler per gli eventi di interesse e inizializzare i timer necessari per l'esecuzione periodica delle operazioni di trasmissione e controllo.All'interno della classe Sniffer si sono definiti i metodi che gestiscono le comunicazioni con il server e che fanno capo alle classi GWTTapeStream e GWTTapeStreamAsync (che implementano i metodi e le richieste GWT-RPC descritte nei paragrafo 2.4).

5.2.2.3 GWTTapeStream e GWTTapeStreamAsync

Queste classi implementano i metodi utili ad invocare il servizio GWT-RPC, si tratta quindi di una implementazione delle richieste getNewId, sendTape, sendFrameID e endOfInteraction descritte nel paragrafo 2.3 .

5.2.2.4 ActionShot

Per la registrazione dei dati si è deciso di creare delle classi le cui istanze sono atte a descrivere un evento rilevato (o campionato).ActionShot è una classe astratta preposta a questo scopo ed è la superclasse per tutti i possibili tipi di campione; da essa derivano:

• MouseAction per gli eventi legati al Mouse

32 Si fa nota che il codice è adeguatamente commentato.

46

• KeyAction per gli eventi legati alla tastiera• ScrollAction per gli eventi legati allo scrolll della finestra• ResizeAction per gli eventi legati al ridimensionamento della finestra.

Le informazioni e gli attributi previsti da queste classi sono identificabili dalla serializzazione XML degli stessi già descritta nel paragrafo 3.2.2 .

5.2.2.5 ActionShotManager

Questa classe non istanziabile è preposta alla creazione delle descrizione degli eventi, gli ActionShot, a partire dall'oggetto NativeEvent.Prevede la creazione di ActionShot anche a partire da un identificativo numerico legato al tipo di evento che si vuole rappresentare.

5.2.2.6 OnElement e OnElementDetailed

Queste classi definiscono degli oggetti atti a contenere una descrizione dell'elemento HTML che è stato bersaglio di un evento o che risulta interessante ai fini della interazione.OnElement contiene solo un identificativo numerico denominato HASH che la documentazione GWT garantisce essere unico per l'elemento HTML.OnElementDetailed contiene oltre all'HASH anche una serie attributi con dettagli.L'elenco degli attributi e i dati inclusi sono riconducibili alla rappresentazione XML data nel paragrafo 3.2.2 .

5.2.2.7 OnElementManager

Questa classe non istanziabile è preposta alla creazione degli oggetti OnElement e OnElementDetailed.Il metodo create crea l'oggetto OnElement a partire da un oggetto di tipo Element (che corrisponde ad un elemento HTML del DOM) e garantisce in modo automatico che la creazione della descrizione dettagliata OnElementDetailed venga effettuata una volta sola.Questo risultato è conseguito tenendo traccia in una lista degli hash degli elementi già incontrati.Si è ritenuto che possa risultare superfluo inviare innumerevoli volte le informazioni sugli elementi body e html o div, quindi OnElmentManager impedisce la creazione di OnElement e OnElmentDetailed, restituendo null, nel caso in cui l'elemento HTML risulti appartenere ad una lista di esclusione.La lista di esclusione è una lista di stringhe corrispondenti ai tag degli elementi da non registrare, la lista è hardcoded ed è denominata nel codice EXCLUSION_LIST.

5.2.2.8 Tape

La classe Tape definisce una collezione, estensione della classe Vector, atta a raccogliere gli oggetti derivati da ActionShot.Questa collezione è una lista ordinata temporalmente delle descrizioni degli eventi rilevati, per questo motivo i metodi, atti all'inserimento di nuovi elementi o la concatenazione di diversi Tape, effettuano dei controlli per sincerarsi che l'ordine temporale venga rispettato.Sempre nella classe Tape si sono implementati due diversi metodi per l'inserimento dei dati, addShot e addShotCompress, che garantiscono il rispetto del sample rate massimo fissato, ovvero realizzano un add capace di accettare o rifiutare un ActionShot.

47

Come si evince dal nome del metodo addShotCompress, esso prevede la creazione di un Tape in cui i dati subiscono una leggera modifica al fine di renderli più compatti; il metodo Tape.decompressThisTape permetterà di ricostruire i dati originari.Gli oggetti, istanza di questa classe, sono utilizzati per implementare sia i buffer lato client sia per la registrazione della interazione lato server.

5.2.2.9 GWTTapeStreamImpl

Implementa lato server il backend del servizio GWT-RPC, in essa sono stati raccolti i metodi atti a gestire le richieste dei client GWT-Observer.Questo servlet svolge la maggior parte delle operazioni lato server e interagisce costantemente con un oggetto (istanza della classe Record, presente nel contesto dell'applicazione) nel quale vengono memorizzate le registrazioni delle istanze in corso .

5.2.2.10 Record

Questa classe viene utilizzata lato server e definisce un oggetto, unico nel contesto dell'applicativo, che funge da archivio per tutte le istanze in corso di registrazione. Nel dettaglio, i Tape delle interazioni in corso di registrazione vengono memorizzate in una Map all'interno dell'istanza di Record.Nel caso di chiusura della interazione, la classe Record fornisce metodi per la chiusura della registrazione e il salvataggio del Tape relativo su disco (sia in forma XML che binaria).Si sono anche implementati dei timeout che forzano il salvataggio delle registrazioni su disco, e quindi la loro chiusura, nel caso di prolungato periodo di inattività.

48

49

Illustrazione 5: Flowchart, applicativo lato client

5.2.2.11 Diagramma delle classi

Nei seguenti diagrammi delle classi si è voluto rappresentare alcuni aspetti della struttura dell'applicativo.

50

Illustrazione 6: Diagramma delle classi lato client, l'istanza di Sniffer implementa ed esegue l'applicativo.

Illustrazione 7: Diagramma delle classi lato server.

51

Illustrazione 8: Diagramma delle classi adibite alla memorizzazione dei dati rilevati

5.3 Dettagli implementativi

5.3.1 Sniffer

Questa classe implementa le funzionalità dell'applicativo lato client, di essa viene istanziato un solo oggetto , sniffy,all'interno di ObserverEntryPoint.Conclusa la fase di inizializzazione e caricamento della pagina, ObserverEntryPoint esegue il metodo OnModuleLoad all'interno del quale viene invocato il metodo Sniffer.initialSnapshot che attua l'acquisizione dello snapshot iniziale e anche le inizializzazioni delle liste dei frame.

5.3.1.1 safeSend, trasmissione dei dati

Il metodo safeSend attua la trasmissione del buffer al backend senza causare interruzioni nelle registrazioni degli eventi, si riporta di seguito il codice del metodo:

1 private void safeSend(){

2 if (this.oldTape==null && tape!=null && (!tape.isEmpty()) && this.ID!=null){

3 this.oldTape = this.tape;

4 this.tape = new Tape(BUFFER_TAPE_TIME_MILLIS);

5 sentTapes++;

6 this.oldTape.setNumTape(sentTapes);

7 getService().sendTape(ID,this.oldTape, callbackSend);

8 }

9 }

La spedizione avviene solo se sono verificate le seguenti condizioni (riga 1):• oldTape == null, si è conclusa con successo la precedente spedizione• tape != null, vi è un buffer tape valido da spedire• !tape.isEmpty, tape non è vuoto• ID!=null, GWT-Observer è stato inizializzato correttamente

Al momento della spedizione il metodo safeSend() copia il riferimento dell'oggetto tape in oldtape (riga 3), sostituisce tape con un buffer vuoto (riga 4). La creazione di un nuovo buffer permette la continuazione della registrazione.Si esegue quindi la spedizione di oldtape utilizzando la richiesta sendtape (riga 7) del servizio GWT-RPC.La righe 5 e 6 assegnano un identificativo numerico (ordine nella sequenza) al Tape prima della spedizione.La callback di safeSend verifica la corretta spedizione e nel caso di successo assegna ad oldtape il valore null, in assenza di questa operazione la condizione di riga 2 impedisce nuovi invii.safeSend viene eseguito periodicamente da un timer (default è 2 secondi) ma la soluzione proposta impedisce la sovrapposizione di spedizioni o il sovvertimento dell'ordine di invio.

5.3.1.2 endOfInteraction

L'unico momento critico è la gestione della fine interazione in cui viene invocato il metodo endOfInteraction, il quale procede all'invio immediato del tape (non vi è la necessità di fare

52

controlli su oldTape).In questo caso l'esatto ordine di arrivo non è garantito, la logica implementata lato server utilizza l'attributo Tape.numtape (utilizzato come ordine nella sequenza) per ricostruirne l'ordine.Lato server si è implementato nella classe GWTTapeStreamImpl il metodo addAllSyncro responsabile di inserire i buffer Tape ricevuti nel giusto ordine in coda alla registrazione complessiva (per la concatenazione si è implementato il metodo Tape.addAll).

5.3.1.3 Gestione degli iframe

L'istanza di Sniffer provvede anche ad identificare eventuali istanze di GWT-Observer presenti all'iterno di iframe della pagina.A tal fine vengono svolte le seguenti operazioni:

• durante la inizializzazione viene creata nel contesto della pagina la proprietà observerId78933 avente come valore l'ID ricevuto dal server;

• viene creata una lista degli elementi HTML corrispondesti ad iframe;• periodicamente vengono ispezionati gli iframe per accertare se vi è all'interno del loro

contesto la proprietà observerId789 ricavando l'ID della interazione contenuta nell'iframe;

• vengono comunicati al server gli ID delle nuove interazioni rilevate.

Non è sempre possibile accedere al contesto di un iframe34 in questi casi viene generata una eccezione (che viene opportunamente gestita).Dal punto di vista implementativo si fa notare che si è stati costretti a scrivere due metodi JSNI, _getIFrameID e _setIFrameID al fine di accedere direttamente alle proprietà dell'oggetto window.

5.3.2 Classe Tape

La classe Tape estende la collection Vector<ActionShot> e contiene....

5.3.2.1 Rate limiter

L'obiettivo è quello di limitare la frequenza di campionamento degli eventi rilevati, questa necessità è imposta al fine di limitare la quantità di informazioni da inviare al server e rispettare le condizioni sulla banda imposte.Questa decimazione non è però applicabile a tutti i campioni, alcuni di essi non possono essere scartati per l'importanza della informazione ad essi associata: la pressione dei tasti, il click del mouse e le descrizioni dettagliate degli elementi HTML.Vista anche la bassa frequenza di questi eventi e la rarità con cui si accompagnano con i movimenti del mouse questa scelta non porta ad un superamento della frequenza massima imposta.

I limiti imposti sono fissati dalle costanti MAX_SAMPLE_RATE e MIN_DELTA_T della classe Tape e definiscono la massima frequenza di campionamento consentita in Hz e il minimo intervallo di tempo tra i campioni in millisecondi.

33 Il nome della variabile è stato scelto a caso nella speranza di non creare collisioni.34 Perché vi possa essere comunicazione tra pagina nell'iframe e pagina genitore, le due pagine devono avere delle

URL appartenenti allo stesso dominio.

53

Si è implementato il rate limiter nel metodo add(ActionShot e, boolean activeCompression), i metodi addShot e addShotCompress si appoggiano al meotdo add() per le loro funzioni. L'algoritmo utilizzato è riassumibile nei seguenti punti:

1. Si divide il tempo in un insieme di intervalli di durata MIN_DELTA_T;2. un solo campione viene accettato all'interno di un intervallo temporale;3. altri campioni all'interno dello stesso intervallo vengono scartati (Illustrazione 9).

Il codice reale che effettua la decimazione si trova nel metodo add(ActionShot e, boolean activeCompression ed è il seguente:

1 if (((e instanceof MouseAction &&!((MouseAction)e).isMouseClick())

2 ||(e instanceof ScrollAction)

3 ) &&!e.hasElementDetails()

4 ) {

5 // I =[startRateInterval,endRateInterval] time interval

6 if (currentShotTime>=startRateInterval){

7 if (currentShotTime<endRateInterval){

8 // The e ActionShot/sample time belongs to I, e has been accepted.

9 // I (the accept range) has to be moved up.

10 startRateInterval = endRateInterval;

11 } else {

12 // the I 's start time is moved to the current time.

13 startRateInterval = currentShotTime;

14 }

15 } else {

16 return false;

17 }

18 } else {

19 // when the sample is not rate-limited, the I interval is moved up

20 startRateInterval = currentShotTime+MIN_DELTA_T;

21 }

22 }

54

Illustrazione 9: Algoritmo di decimazione, registrazione o rifiuto di un ActionShot

23 // Interval's lenght is always the same..

24 endRateInterval = startRateInterval+MIN_DELTA_T;

Si assume che startRateInterval ed endRateInterval siano già inizializzati (corrispondono agli estremi del primo intervallo di tempo).Nella riga 1 viene effettuato un controllo per verificare se l'ActionShot appartiene ad una classe derivata e contiene informazioni soggette a decimazione.Nel caso di decimazione, alla riga 7, si verifica se il tempo è all'interno o dopo l'intervallo di tempo corrente. Se questa condizione non è verificata il campione non viene memorizzato e il metodo restituisce false.Nel caso in cui l'istante di tempo appartenga all'intervallo [startRateInterval,endRateInterval], gli estremi dell'intervallo vengono spostati in avanti di MIN_DELTA_T (riga 11) altrimenti l'estremo inferiore viene spostato all'istante di tempo dell'ActionShot corrente (riga 16). Nel caso di eventi esclusi dalla decimazione l'algoritmo proposto reagisce spostando in avanti gli estremi dell'intervallo (riga 24).Si fa notare startRateInterval e endRateInterval sono dichiarati nel tape con il modificatore transient e ciò impedisce la serializzazione degli stessi.

5.3.2.2 Compressione dei dati

Il Tape può essere riempito di campioni compressi usando il metodo addShotCompress.Non si devono utilizzare entrambi i metodi addShot e addShotCompress su uno stesso oggetto Tape o non sarà possibile la decompressione dei dati .La compressione viene al momento effettuata solo sull'attributo relativo all'istante di tempo, registrando l'incremento invece che il calore assoluto.35

La compressione dell'ActionShot viene implementata dal seguente metodo Tape.compress:

1 private void compress(ActionShot e) {

2 // the first compression is based on the time attribute

3 currentShotTime = e.getTime();

4 e.setTime(currentShotTime-lastShotTime);

5 lastShotTime = currentShotTime;

6 }

currentShotTime e lastShotTime sono inizializzati a 0.Alla prima esecuzione di compress l'istante di tempo viene registrato per esteso, nelle esecuzioni successive il tempo viene sostituito con il solo incremento.La riga 3 rileva l'istante di tempo del campione, la riga 4 sostituisce tale valore con l'incremento rispetto al precedente, la riga 5 aggiorna il valore precedente al corrente.Le variabili currentShotTime e lastShotTime sono dichiarate con un modificatore transient, ciò impedisce la serializzazione degli stessi.Il comando decompressThisTape ricostruisce i tempi originari a partire da un Tape contenente dati ActionShot compressi; applicare tale comando su un Tape non compresso comporta la corruzione dei dati memorizzati.

35 Test effettuati applicando una simile compressione anche ai movimenti del mouse hanno sortito una riduzione della dimensione dei dati, ma il numero di operazioni necessarie e il carico non sembrano giustificare la scelta. In alternativa si propone l'uso della compressione gzip sui dati trasmeesi. (inserimento di un filtro sul lato server)

55

5.3.2.3 Classe OnElementManager

L'OnElement manager fornisce il metodo create al fine di generare una descrizione dell'elemento HTML nativo; create segue le seguenti regole:

• se l'elemento è di un tipo appartenente ad una lista di esclusione restituisce null;• Se per l'elemento è già stato creato un oggetto OnElementDetailed allora creare un

OnElment, altrimenti creare un OnElmentDetailed.

L'implementazione di base, molto semplice, è stata poi elaborata al fine di introdurre delle ottimizzazioni, saranno quindi necessarie alcune precisazioni sul codice.Le seguenti strutture dati sono utilizzate:

static private ArrayList<Integer> alreadySentElementsHashes = new ArrayList<Integer>();

static private ArrayList<Element> alreadySentElements = new ArrayList<Element>();

static private ArrayList<Integer> bannedElementsHashes = new ArrayList<Integer>();

public static final List<String> EXCLUSION_LIST = Arrays.asList(

"HTML","BODY","SPAN","B","DIV","P","STRONG");

• alreadySentElementsHashes, lista contenente gli HASH degli elementi HTML di cui si è già creato un OnElementDetailed.

• alreadySentElementsHashes, lista dei riferimenti agli elementi HTML di cui si è già creato un OnElementDetailed (nello stesso ordine di alreadySentElementsHashes).

• BannedElementsHashes, lista degli HASH degli elementi il cui tipo è risultato appartenere alla lista esclusione.

• EXCLUSION_LIST, lista dei tipi di elementi HTML per cui non devono essere generate le descrizioni, vengono identificati dal loro tag HTML.

Si riporta il codice del metodo create:

1 static public OnElement create(Element element) {

2 Integer hashElement = element.hashCode();

3 //Check for the previous element

4 //Sometimes the previous element and the next equals.

5 if (hashElement==lastHash) {

6 if (lastBanned){

7 return null;

8 } else {

9 return new OnElement(hashElement);

10 }

11 }

12 lastHash = hashElement;

13 // Check bannedElementHashes, this check is optimal in case

14 // of number of banned > number of accepted

15 if (bannedElementsHashes.indexOf(hashElement)!=-1){

16 lastBanned = true;

17 return null;

18 }

19 //It's ok to check if this is an already known element

56

20 if (alreadySentElementsHashes.indexOf(hashElement)==-1) {

21 // new element, more details needed

22 // is this element's tag type into the exclusion list?

23 if (EXCLUSION_LIST.contains(element.getNodeName())){

24 //This element has to be excluded

25 bannedElementsHashes.add(hashElement);

26 lastBanned = true;

27 return null;

28 } else {

29 // add element to alreadySentList and returns OnElementDetailed

30 alreadySentElementsHashes.add(hashElement);

31 alreadySentElements.add(element);

32 lastBanned = false;

33 return createDetailed(hashElement, element);

34 }

35 } else {

36 // already sent element, no details needed

37 lastBanned = false;

38 return new OnElement(hashElement);

39 }

40 }

Memorizzando l'HASH dell'elemento precedente in lastHash e l'esito del controllo sulla lista esclusioni in lastBanned, si tenta di evitare ricerche all'interno di liste e confronti tra stringhe.Le righe 5-11 attuano un controllo per verificare se l'elemento corrente e il precedente sono lo stesso, in tal caso si può applicare la seguente regola:

Se l'elemento è stato precedentemente “bannato”, restituire null, altrimenti restituire un oggetto di tipo OnElement.

Siccome in questo caso l'elemento è stato già visionato, l'oggetto OnElementDetailed è sicuramente stato generato in precedenza.Il codice (15-18) verifica la presenza dell'elemento nella lista esclusioni verificando se l'HASH dell'elemento appartiene alla lista bannedElementsHashes.Se l'HASH appartiene ad un elemento noto (indi OnElementDetailed già creato) allora viene creato un OnElement altrimenti viene verificato se il tag dell'elemento appartiene alla lista esclusioni (riga 67); se l'elemento non appartiene alla lista esclusioni viene creato un oggetto OnElmentDetailed.

57

5.4 Progetto della modalità Proxy

Nella illustrazione 1 del capitolo 2 si è rappresentato in modo approssimativo la topologia della rete realizzata, i client cono collegati ad un server proxy Squid e questo permettere la navigazione ma nel contempo permette al servizio GWT-Observer di monitorarla.Il Proxy HTTP deve quindi attuare le seguenti operazioni aggiuntive:

1. Inserire nelle pagine richieste dagli utenti (ovvero nelle risposte i tipo html/txt) la chiamata al codice JavaScript di GWT-Observer

2. Redirigere in modo trasparente tutte le richieste dei client per risorse aventi una URL del tipo http://dominio_sito.net/GWT-Observer/* verso http://mio_was.org/GWT-Observer/*

Per realizzare la manipolazione dei contenuti descritta nel punto 1 si è scelto di utilizzare un server ICAP36.I proxy HTTP che supportano lo standard ICAP possono delegare ai servizi ICAP la modifica dei contenuti delle risposte e delle richieste, per una descrizione generale del protocollo ICAP si rimanda al paragrafo 5.4.1 .Per realizzare la ridirezione descritta al punto 2 si è scelto di adottare un URL-rewriter37 (o redirector) di Squid.

5.4.1 Il protocollo ICAP

ICAP, Internet Content Adaptation Protocol (RFC 35079) è un protocollo testuale, simile all'HTML , il cui formato delle richieste e delle risposte segue lo standard per i messaggi descritto nell'RFC 2822.Come per l'HTTP le richieste effettuate dai proxy al server ICAP iniziano con una linea di richiesta:

RESPMOD icap://icap.example.net/translate?mode=french ICAP/1.0

La richiesta ICAP include l'URI di un servizio ICAP (nome del server, nome del servizio) e i parametri.Dopo gli headers della richiesta ICAP vengono incapsulate parti di messaggi da elaborare, possono esserci più header o body relativi (ad esempio) a contenuti HTML di cui si richiede la modifica.Il seguente header ICAP indica la presenza di più contenuti incapsulati all'interno di una richiesta: due header e un body HTML:

Encapsulated: req-hdr=0, res-hdr=45, res-body=100

36 Il protocollo ICAP, Internet Content Adaptation Protocol, è definito nell'RFC 3507, una descrizione generale è riportata nel par.5.4.1 , l'RFC 3507 è consultabile su http://www.ietf.org/rfc/rfc3507.txt

37 Il Proxy Squid può essere configurato in modo da inviare tutti gli URL delle richieste dei client ad un programma esterno chiamato URL-rewriter, esso riceve nello stdin l'URL originariamente richiesta e restituisce l'URL modificata allo Squid attraverso lo stdout.

58

La porta di default per il servizio ICAP è 1344.

5.4.2 Descrizione della modalità Proxy

In questo paragrafo si descriverà il funzionamento della modalità Proxy in un teatro esemplificativo e si esaminerà l'esecuzione di una richiesta da parte del browser dell'utente e le fasi successive.Nella Illustrazione 10 si sono rappresentate in tre fasi la richiesta di una pagina HTML da parte del browser dell'utente e il percorso logico della risposta del server.Descrizione delle fasi:

1. Il browser richiede la pagina http://www.gino.com, la richiesta viene girata dal proxy all'host del sito www.gino.com;

2. La risposta contenente la risorsa richiesta viene inviata al proxy, esso riconosce il contenuto di tipo txt/html e invece di inviare il contenuto al browser richiedente lo invia al server ICAP affinché venga inserito il codice JavaScript del client GWT-Observer;

3. La risposta con il contenuto modificato (l'occhio rappresenta l'inoculazione di GWT-Observer nel contenuto HTML) viene inviato al browser richiedente.

Conclusa la richiesta della pagina ed eseguito il codice di GWT-Observer, il browser comincerà a comunicare attraverso delle richieste le informazioni sull'interazione dell'utente.Tali richieste saranno, nella configurazione di default, inviate a delle risorse aventi come URL esemplificativa http://www.gino.com/GWT-Observer/nomeservizio.Questa soluzione permette di aggirare la SOP ma le richieste risultano indirizzate a risorse che

59

Illustrazione 10: Richiesta di una risorsa HTML/pagina da parte del browser dell'utente.

non esistono sul server www.gino.com.Il proxy riconoscerà le richieste verso il servizio backend GWT-Observer e le ridirigerà verso l'host e l'application server corretti.Nella Illustrazione 11 è rappresentata in tre fasi l'elaborazione delle richieste al servizio GWT-Observer da parte del proxy.Descrizione delle fasi:

1. Il browser, come client GWT-Observer, effettua una richiesta a www.gino.com/GWT-Observer/nomeservizio;

2. Il proxy invia l'URL della richiesta al URL-rewriter Squirm, Squirm identifica nel path una chiamata ai servizi backend e modifica l'URL di destinazione della richiesta in www.observer.com/GWT-Observer/nomeservizio;

3. Squirm restituisce l'URL modificata al punto 2 a Squid che provvede ad inviare la richiesta in modo trasparente alla nuova URL www.observer.com/GWT-Observer/nomeservizio .

La risposta alla richiesta viene girata al browser dell'utente che non si accorge dell'avvenuto cambio di destinatario.

5.4.3 Configurazione dei servizi

Al fine di implementate la modalità proxy si sono configurati i seguenti servizi:

60

Illustrazione 11: Richiesta del client GWT-Observer diretta al servizio backend, ma volutamente effettuata verso www.gino.com/GWT-Observer/nomeservizio

• Application server• Server ICAP;• Redirector Squirm;• Proxy HTTP Squid

L'installazione è trattata nel capitolo 4, nei seguenti paragrafi si fornirà una spiegazione dettagliata del codice e dei file di configurazione..

5.4.3.1 Configurazione del server ICAP

Come server ICAP si è installato GreasySpoon38; questa scelta è stata effettuata dato che tale software permette di programmare le modifiche dei contenuti con degli script in linguaggio Java.Per configurare il server ICAP, si potrà accedere alla console di amministrazione, per dettagli riguardo l'accesso della console consultare paragrafo 4.2.3 (Illustrazione 12).

Si è proceduto alla scrittura e all'inserimento degli script atti alla manipolazione delle richieste e delle risposte.La console di amministrazione di GreasySpoon fornisce un editor che permette la creazione degli script, di abilitarne l'accesso e di impostare il nome del servizio ad essi legato.Si è creato uno script per la manipolazione delle sole risposte (che consistono nelle pagine HTML richieste dai client), e si è configurato in modo da rispondere al nome di servizio "injectobserver".Segue il codice dello script injectobserver che inserisce il codice JavaScript di GWT-Observer39 come primo elemento all'interno del body della pagina txt/html:

38 http://greasyspoon.sourceforge.net/39 "<script language="javascript"

src="/GWT-Observer/it.univ.trieste.observer/it.univ.trieste.observer.nocache.js"></script>"

61

Illustrazione 12: console amministrativa del server ICAP GreasySpoon

1 //-------------------------------------------------------------------

2 // ==ServerScript==

3 // @name injectobserver

4 // @status on

5 // @description adds Observer's call into the main BODY .

6 // @include .*

7 // @exclude

8 // @responsecode 200

9 // ==/ServerScript==

10 // --------------------------------------------------------------------

11 // Note: use httpMessage object methods to manipulate HTTP Message

12 // use debug(String s) method to trace items in service log (with log level >=FINE)

13 // ---------------

14

15 public void main(HttpMessage httpMessage){

16 try{

17 if (httpMessage.getResponseHeader("Content-Type").contains("text/html")) {

18 String body = httpMessage.getBody(

19 int posbod0 = body.indexOf("<body");

20 int posbod1 = body.indexOf("<BODY");

21 int posbod = (posbod0<posbod1) ? posbod0 : posbod1;

22 if (posbod<0) {

23 posbod = (posbod0>posbod1) ? posbod0 : posbod1;

24 }

25 if (posbod!=-1){

26 int pos1 = body.indexOf(">", posbod)+1;

27 body = body.substring(0,pos1)+

28 "<script language=\"javascript\" src=\"/GWT-

Observer/it.univ.trieste.observer/it.univ.trieste.observer.nocache.js\"></script>"+

29 body.substring(pos1);

30 httpMessage.setBody(body);

31 }

32

33 }

34 // httpMessage.toJson();

35 //httpMessage.minify();

36

37 }catch (Exception e){

38 debug(e.getMessage());

39 }

40 }

Le righe 25-31 attuano l'inserimento dello script GWT-Observer nel codice della pagina, tale inserimento è però condizionato alla presenza del body nel documento html.Si è poi creato un secondo script utile all'elaborazione delle richieste effettuate dai client GWT-Observer, il servizio ICAP sarà denominato addipheader:

62

1 //-------------------------------------------------------------------

2 // ==ServerScript==

3 // @name addipheader

4 // @status on

5 // @description Add X-observer-ip header containing the current browser IP.

6 // @include .*

7 // ==/ServerScript==

8 // --------------------------------------------------------------------

9 // Note: use httpMessage object methods to manipulate HTTP Message

10 // use debug(String s) method to trace items in service log (with log level >=FINE)

11 // ---------------

12

13 // ---------------

14 public void main(HttpMessage httpMessage){

15 //start your code from here

16 //System.err.println(httpMessage.getUsername());

17 //System.err.println(httpMessage.getUsergroup());

18 //System.err.println(httpMessage.getRequestHeaders());

19 //System.err.println(httpMessage.getBody());

20 debug(httpMessage.getRequestHeaders());

21 String userIP= httpMessage.getUsername();

22 httpMessage.addHeader("X-Observer-IP",userIP);

23 }

Questo script aggiunge una proprietà allo header della richiesta XHR (riga 22), il backend utilizzerà il nuovo header al fine di determinare i veri IP dei client collegati al server proxy.Affinché questo sia possibile il server Squid deve essere configurato in modo da inviare al server ICAP le informazioni relative all'IP dei client per ogni richiesta.

5.4.3.2 Configurazione dell'URL-rewriter Squirm

L'URL-rewriter o redirector è un software che viene eseguito all'occorrenza dal proxy Squid e per questo motivo dovrà essere installato sulla stessa macchina host su cui è stato installato il proxy.Si è scelto come URL-rewriter il software Squirm40 versione 1.2.6, un applicativo opensource i cui sorgenti sono disponibili sotto licenza GPL.Anche se l'ultimo aggiornamento del progetto risale al 2005, Squirm risulta ancora molto usato e fornisce tutte le features necessarie.Si sono modificati i file di configurazione, squirm.conf e squirm.patterns al fine di implementare le ridirezioni descritte nel paragrafo 5.4.2 -

5.4.3.3 squirm.conf

1 begin

40 http://squirm.foote.com.au/

63

2 #network 10.0.0.0/8

3 network 127.0.0.0/24

4 network 192.168.0.0/24

5 network 0.0.0.0/0

6 log logs/match.log

7 #abort-log logs/abort.log

8 #pattern squirm.patterns get

9 pattern squirm.patterns all

10 end

Con questo file si è aggiunta la ridirezione per tutte le richieste provenienti da network locali.La penultima riga indica che tutte le URL devono essere elaborate secondo le espressioni regolari descritte nel file squirm.patterns.

5.4.3.4 squirm.patterns

regex ^.*/GWT-Observer/(.*) http://localhost:8080/GWT-Observer/\1 /GWT-Observer/

squirm.patterns definisce una serie di regole in cui una URL che corrisponde ad una espressione regolare viene convertita nella seconda espressione.Il comando regex inserito nel file squirm.patterns agisce su ogni URL contenente la stringa “/GWT-Observer/”, estrae dalla URL la stringa corrispondente al match “(.*)” e la reinserisce al posto di “\1” al secondo membro.Il terzo membro dell'espressione è chiamato accellerator non è utile alla comprensione e viene suggerito in automatico dallo Squirm al fine di accelerare il matching dell'URL.Nell'esempio riportato qualsiasi richiesta al cui interno compaia la stringa “/GWT-Observer/” viene rediretta a “localhost:8080/GWT-Observer/”.Si potrebbe obiettare che con questa soluzione vi sia il rischio di un match indesiderato, una possibile soluzione è la sostituzione del contesto scelto per GWT-Observer con un identificativo alfanumerico.In alternativa mantenendo le configurazioni e le convenzioni precedenti la seguente regola riduce lievemente la possibilità di collisioni indesiderate, ulteriori miglioramenti sono possibili includendo una parte più ampia del path dei servizi:

regex ^.*/GWT-Observer/it\.(.*) http://localhost:8080/GWT-Observer/it\.\1 /GWT-Observer/it

5.4.3.5 Configurazione del proxy HTTP Squid

Si è fatto uso in questa trattazione del proxy Squid versione 3.0, si fa nota che le versioni precedenti mancano di alcune features necessarie mentre le versioni successive implementano le stesse funzionalità. Si invita comunque a verificare il manuale online di Squid siccome i file di configurazione sono talora soggetti a delle modifiche.Nel proseguo non si riporteranno per intero i file di configurazione ma solo le porzioni notevoli e modificate degli stessi.

Modifiche attuate al file di configurazione squid.conf, sezione ACL:

64

#Recommended minimum configuration:

acl manager proto cache_object

acl localhost src 127.0.0.1/32

acl to_localhost dst 127.0.0.0/8

#

# CUSTOM ACLs

# identifica le richieste e le risposte inviate ad una url contenente “GWT-Observer/it.univ”

acl to_observerservice urlpath_regex GWT-Observer/it\.univ

# identifica le risposte il cui mime-type corrisponde a text/html

acl htmlacl rep_mime_type -i text/html

# identifica le sole richieste gwt-rpc (il fine sarà inseguito di aggiungere una proprietà allo

# header contenente informazioni sull'IP del client

acl gwtreqacl req_mime_type -i text/x-gwt-rpc

# acl che ha los copo di idenrificare risorse corrispondenti a pubblicità, è approssimativa,

ferma

# qualcosa, non è detto che serva le pubblicità potrebbero essere utili.

acl advertise dstdom_regex (/cgi-bin/nph-adclick\.exe|

doubleclick.net|/ads/media/images/|/smartbanner/|\.com/ads/banners/|/apfbanners/|/realmedia/ads/

|/event\.ng/|/pics/banner/|/viewcgi?

pool=|/clicktrack|/hittrack|/images\.go2net\.com/go2net/ads/|\.com/banners/|\.com/httpads/|\.com

/advertising/|/ads/adview\.php\?)

La sezione ACL permette di creare delle condizioni applicabili alle richieste e alle risposte in transito; queste condizioni vengono utilizzate al fine di classificare i contenuti.La seguente sezione invece indica a Squid di utilizzare l'URL-rewriter Squirm. Squid eseguirà all'occorrenza alcune istanze di Squirm in automatico ma si dovrà prestare attenzione ai permessi dell'utente Squid a cui dovrà essere permesso pieno accesso all'eseguibile Squirm e ai files di configurazione relativi.

File squid.conf, sezione URL-rewriter:

url_rewrite_program /usr/local/squirm/bin/squirm

url_rewrite_children 10

La seguente sezione configura l'utilizzo da parte di Squid del server ICAP, si fa notare che di nuovo si è considerato il caso in cui i servizi ICAP e proxy risiedano sullo stesso host.

File squid.conf, sezione ICAP options:

# ICAP OPTIONS

icap_enable on

icap_send_client_ip on

65

File squid.conf, sezione ICAP options, definizione dei servizi ICAP:

# associa al nome injectobserver il servizio icap://localhost:8344/injectobserver, configurato

in

# modo da modificare le pagine ->prima<- della memorizzazione cache

icap_service addipheader reqmod_precache 0 icap://localhost:8344/addipheader

icap_service injectobserver respmod_precache 0 icap://localhost:8344/injectobserver

#icap_service injectobserverhead respmod_precache 0 icap://localhost:8344/injectobserverhead

File squid.conf, sezione ICAP options, definizione delle classi associate ai servizi ICAP:#<----->icap_class classname servicename

icap_class class_1 injectobserver

icap_class class_2 addipheader

#icap_class class_1 injectobserverhead

File squid.conf, sezione ICAP options, condizioni per l'invio ai servizi ICAP, basato sulle ACL precedentemente definite:

# TAG: icap_access

#<----->Redirects a request through an ICAP service class, depending

#<----->on given acls

#

# Le richieste indirizzate ai servizi GWT-Observer devono essere modificate in modo da inserire

# nello header l'informazione relativa all'IP del client.

icap_access class_2 allow gwtreqacl

# definisce per quali utenti/condizioni il messaggio viene passato al servizio ICAP

# i messaggi che non risultano avere un Content-type text/html non devono essere modificati

icap_access class_1 deny !htmlacl

# tutti i messaggi che corrispondono a richieste ai servizi GWT-Observer non devono essere

# modificati

icap_access class_1 deny to_observerservice

# non si aggiunge GWT-Observer alle pagine (iframe) pubblicitari, opzionale può essere eliminata

# siccome in alcuni casi studiare l'interazione on le pubblicità potrebbe essere di interesse

#icap_access class_1 deny advertise

icap_access class_1 allow all

L'esecuzione delle regole di accesso per una richiesta/risposta avviene nell'ordine specificato nel file, qualora una condizione (ovvero l'ACL) fosse verificata e risultasse in un deny or in un allow le regole successive non verrebbero valutate.L'inserimento della regola “icap_access class_1 deny !htmlacl” alleggerisce lo Squid e il server ICAP siccome permette l'invio al server ICAP del solo contenuto txt/html e impedisce la valutazione delle condizioni sucessive per contenuti che non sono di interesse.La regola “icap_access class_1 deny to_observerservice”, è stata introdotta per impedire l'inserimento del JavaScipt GWT-Observer anche alle pagine HTML eventualmente incluse in risposte provenienti dall'AS41 e dal contesto dell'applicazione GWT-Observer.

41 Nel momento in cui il browser esegue nocache.js, esso richiede lo scaricamento della permutazione di GWT-Observer dall'AS, essendo la permutazione una richiesta di un file HTML, in assenza di precauzioni, alla risposta

66

6. Prestazioni e dimensioni dell'applicativo

Si esporranno di seguito i risultati delle prove effettuate al fine di verificare il rispetto delle specifiche descritte nel paragrafo 5.2.1 .Tutti gli esperimenti descritti in questo capitolo sono stati effettuati sulla seguente configurazione:

• browser Firefox 3.5.7• sistema operativo Linux Opensuse 11.2• PC, 4GB Ram, CPU Intel Core Duo T6600@1200MHz42.

6.1 Dimensione dell'applicativo

Si è valutata la dimensione del framework lato client, ovvero la dimensione dell'applicativo JavaScript GWT-Observer;questo dato riveste particolare importanza siccome una ridotta dimensione dell'applicativo implica uno scaricamento rapido dello stesso.Nella tabella 1 viene riportata la dimensione dell'applicativo per ognuna delle 6 permutazioni e la media delle stesse, in tre diverse condizioni:

• OBF, codice offuscato( flag OBF), il compilatore GWT è configurato in modo da generare codice offuscato. Tale configurazione genera un codice JavaScript molto compatto ed è quindi usato in produzione.

• OBF–gzip, Codice offuscato compresso con gzip, utile per simulare la dimensione dell'applicativo nel caso in cui browser e server supportino la compressione gzip.

• Pretty, Codice non offuscato(flag PRETTY), il compilatore GWT è configurato in modo da generare codice JavaScript leggibile, utile al fine del profiling o della ispezione del codice.

verrebbe aggiunta nuovamente la chiamata al nocache.js. Questo avrebbe portato ad una imprevista ricorsione senza fine in cui GWT-Observer viene istanziato decine di volte fino al verificarsi di un errore. Tale problema non sussiste nel caso dell'utilizzo del linker cross-site (xs) siccome le permutazioni divengono in quel caso delle semplici risorse .js .

42 La frequenza nominale del processore T6600 è 2200Mhz ma si è scelto di operare ad una frequenza inferiore al fine di simulare una macchina obsoleta.

67

Si è inoltre inserita nella tabella 1 la colonna gzip/OBF che riporta il rapporti tra la dimensione della permutazione compressa (OBF-gzip) e non compressa (OBF).

Oltre alla permutazione la pagina dovrà anche scaricare il codice di nocache.js la cui dimensione ammonta a 5.075 Bytes.Dalla tabella si evince che mediamente la singola permutazione di GWT-Observer comporta lo scaricamento di 72.252 Bytes che scendono a 23.231 Bytes se il browser e il server supportano la compressione sulla connessione.

6.2 Tempi di caricamento

Si sono effettuate delle misure sui tempi di caricamento di alcune pagine sia nella modalità Direct che nella modalità Proxy per valutare l'eventuale ritardo causato da GWT-Observer.Per effettuare le misure si è utilizzato l'add-on del Firefox Lori, Life of request info, questi consente di rilevare il tempo intercorso tra l'inizio del caricamento pagina, l'arrivo del primo byte e l'istante di completamento del rendering della pagina.In tutte le prove effettuate non si è mai fatto uso della cache del Firefox in modo da simulare un primo caricamento della pagina e quindi la condizione peggiore.

6.2.1 Modalità direct

Si è approntato un AS all'interno della rete locale allo scopo di servire due pagine di prova e i servizi di GWT-Observer.Le pagine di prova utilizzate sono riproduzioni della pagina di registrazione di Bing e della pagina di registrazione di Ebay43.Per evidenziare la maggior latenza causata dal caricamento e dalla inizializzazione di GWT-Observer si è scelto di misurare i tempi di caricamento delle pagine con l'inserimento di GWT-Observer e senza l'inserimento di GWT-Observer.Al fine di ottenere dei risultati significativi si sono ripetute le misure 8 volte e si sono riportate nella tabella 2 le medie dei risultati ottenuti per i tempi rilevati:

• Primo Byte [sec], tempo in secondi intercorso dall'inizio del caricamento della pagina all'arrivo del primo Byte.

• Completamento rendering [sec], tempo in secondi intercorso dall'inizio del caricamento della pagina al completamento del rendering (o disegno) della stessa.

43 Le pagine sono analoghe a quelle utilizzate nei test descritti nel cap.7.

68

Tabella 1: Dimensione dell'applicativo lato client

Permutazione

0 74.184 23.231 192.330 31,32

1 74.094 23.231 192.090 31,35

2 72.550 22.838 190.566 31,48

3 71.098 22.414 186.799 31,53

4 71.416 22.531 187.539 31,55

5 70.170 22.131 185.231 31,54

Media 72.252 23.231 189.093 31,46

OBF [Bytes] OBF – gzip [Bytes] Pretty [Bytes] gzip/OBF (%)

• Tempo effettivo di caricamento [sec], tempo in secondi intercorso tra l'arrivo del primo Byte e il completmento del rendering.

Calcolando tempo effettivo di caricamento [sec] si vuole evidenziare il maggior ritardo nel caricamento della pagina imputabile alla inizializzazione dello script GWT-Observer.

La tabella 2 evidenzia l'aumento del tempo44 di caricamento della pagina addebitabile alla presenza e quindi alla esecuzione del client GWT-Observer nel browser dell'utente.Per entrambe le pagine di prova l'aumento del tempo di caricamento è dell'ordine del centinaio di millisecondi.

6.2.2 Modalità Proxy

Si è realizzato nella rete locale un servizio GWT-Observer/Proxy e si sono installati su uno stesso server, il server proxy Squid, il server ICAP e un AS opportunamente configurati45.Per minimizzare le fluttuazioni delle misure dovute a congestioni della rete o dei webserver remoti, il GWT-Observer/Proxy a sua volta accede alla rete attraverso un secondo proxy cache HTTP trasparente configurato sul gateway della rete locale.Con la configurazione proposta si spera di mettere in maggiore evidenza il ritardo nel caricamento della pagina introdotto dalla filiera Squid-ICAP-Squirm.Nell'esperimento si sono rilevati i tempi di caricamento relativi alla pagina Trenitalia.it effettuando le medie di 8 misure in 3 condizioni differenti:

• Proxy nocache, navigazione effettuata attraverso il GWT-Observer/Proxy ma partendo da una situazione con cache dello Squid svuotata, questo impone il passaggio dei contenuti attraverso il server ICAP;

• Proxy, navigazione effettuata attraverso il GWT-Observer/Proxy ma con la pagina già presente nella cache dello Squid, i contenuti già elaborati dal server ICAP non vengono rimandati allo stesso eliminando il ritardo addebitabile alla modifica dei contenuti;

• Normale, navigazione diretta senza passare per il GWT-Observer/Proxy e quindi una navigazione non monitorata (in questo caso si transiterà comunque attraverso il secondo proxy trasparente).

I risultati delle misure sono riportati nella tabella 3, dove si sono evidenziati i tempi della colonna completamento rendering.In questo esperimento il tempo di completamento rendering assume maggiore importanza

44 Differenza delle righe nella colonna “Tempo di caricamento”. Il “tempo di caricamento” è a sua volta ricavato come differenza tra le colonne “Primo Byte” e “Completamento rendering”.

45 Consultare al riguardo il cap.4, manuale d'uso

69

Tabella 2: Tempi di caricamento delle pagine monitorate e non, modalità Direct.

Sito

0,022 0,157 0,135

0,024 0,284 0,261

0,126

0,021 0,324 0,303

0,021 0,441 0,420

0,118

Primo Byte [sec]Completamento rendering [sec]

Tempo effettivo caricamento [sec]

Registrazione Bing

Bing + GWT-Observer

Aumento tempo di caricamento dovuto a GWT-Observer

Registrazione Ebay

Registrazione Bing + GWT-Observer

Aumento tempo di caricamento dovuto a GWT-Observer

siccome tale dato include sia il ritardo dovuto all'azione del GWT-Observer/Proxy sia il ritardo dovuto all'esecuzione del client GWT-Observer sul browser.

Il ritardo di caricamento della pagina tra un collegamento diretto (normale) e uno attraverso il GWT-Observer/Proxy è pari a 0,701 secondi nel caso di prima visita della pagina e di 0,395 secondi nel caso di visite successive che beneficiano della cache del GWT-Observer/Proxy.Nelle misure effettuate non si è fatto uso della cache del browser.

6.3 Carico sulla CPU del client

Si sono effettuate delle misure qualitative relative al carico sulla CPU del processo browser nel caso di navigazione su siti monitorati con GWT-Observer.La scelta della modalità GWT-Observer/Proxy per queste misure garantisce la valutazione del carico del client GWT-Observer nel caso di utilizzo con pagine reali, complesse e composte da più frame ed elementi dinamici.Si è quindi utilizzata la modalità GWT-Observer/Proxy già configurata per gli esperimenti del paragrafo 6.2.2 e si è effettuata la navigazione su due siti Repubblica.it e Trenitalia.it.Per la misura sulla occupazione di CPU sul processo browser si è utilizzato il comando htop del sistema operativo Linux e si è misurato il carico nelle seguenti condizioni:

1. navigazione su pagine monitorate utilizzando il GWT-Observer/Proxy, il client GWT-Observer sottoposto alla massima attività ottenuta muovendo il mouse con intensità e per tempi prolungati;

2. navigazione su pagine non monitorate, la navigazione è attuata senza l'utilizzo di GWT-Observer/Proxy e il mouse è in movimento per tempi prolungati come per il punto 1;

3. navigazione su pagine monitorate utilizzando il GWT-Observer/Proxy, l'utente effettua una navigazione naturale sulla pagina.

Esaminando il carico in queste condizioni si è potuto stimare per differenza il maggior carico addebitabile all'applicativo client GWT-Observer nelle condizioni peggiori.Nella tabella 4 si riportano i risultati ottenuti dalla media di 50 rilevazioni per pagina, nelle condizioni 1 e 2; il significato dei dati raccolti è il seguente:

• Navigazione con GWT-Observer/Proxy, percentuale della CPU utilizzata dal processo browser durante la navigazione monitorata con GWT-Observer/Proxy, condizione di picco (movimento intenso del mouse.

• Navigazione diretta GWT-Observer/Proxy, percentuale della CPU utilizzata dal processo browser durante la navigazione con un collegamento diretto ad internet e quindi senza GWT-Observer. Si è comunque valutato il carico del browser nella condizione di picco (movimento intenso del mouse).

70

Tabella 3: Tempi di caricamento della pagina Trenitalia.it, con e senza GWT-Observer/Proxy

0,735 1,793 1,059

0,566 1,487 0,921Normale 0,323 1,092 0,769

modalità di accesso a internet

Primo Byte [sec]Completamento rendering [sec]

Tempo effettivo caricamento [sec]

Proxy nocache

Proxy

• Carico aggiuntivo client GWT-Observer, percentuale della CPU utilizzata dal processo browser addebitabile a GWT-Observer nel caso di navigazione monitorata da GWT-Observer/Proxy, tale dato è ottenuto per differenza dai precedenti.

I risultati esposti nella tabella 4 evidenziano che l'uso di GWT-Observer comporta, nel caso di massima intensità nella interazione, un aumento del carico del browser pari al 12% della CPU.Nel caso di mouse fermo e nessuna interazione da parte dell'utente si è verificato che l'occupazione del processore è pari allo 0%, non vi è quindi un carico fisso percepile addebitabile all'applicativo client.Si è quindi rilevata l'occupazione di processore da parte del browser nel caso di una interazione di un utente finalizzata alla mera fruizione dei contenuti della stessa.L'utente è lasciato libero di interagire con la pagina nel modo che ritiene più soddisfacente; le medie delle 50 rilevazioni sono riportate nella tabella 5.

Nell'interpretazione dei risultati riportati si ricorda che il 100% corrisponde all'impiego di un processore al massimo delle sue capacità, in un sistema dual core il massimo valore possibile risulterà essere il 200%.

6.4 Occupazione di banda

Si sono effettuate misure qualitative sulla banda massima (o di picco) occupata dall'applicativo sia in upload che in download.A tal fine si sono utilizzati i seguenti strumenti software:

• Iptraf, comando che permette di visualizzare su macchine Linux l'occupazione di banda in upload e download.

• Firebug, estensione del browser Firefox che permette di ispezionare il contenuto di ogni richiesta e risposta ricevuti dal browser durante la navigazione.

Utilizzando iptraf si è misurata l'occupazione di banda del client GWT-Observer mentre il mouse viene tenuto in continuo movimento sulla pagina.In questa condizione si costringe l'applicativo a gestire il maggior numero di eventi, a produrre il maggior numero di ActionShot, e quindi a generare il maggior traffico nell'inviarli al server. Le misure relative al traffico massimo generato sono riportate in tabella 6.

71

Tabella 4: Carico % del processo browser sulla CPU in condizioni di picco.

30,00% 18,00% 12,00%26,00% 14,00% 12,00%

Sito Navigazione con

GWT-Observer/ProxyNavigazione diretta, senza GWT-Observer

Carico aggiuntivoclient GWT-Observer

Trenitalia.it Repubblica.it

Tabella 5: Occupazione media % della CPU da parte del browser durante l'interazione dell'utente.

10,00%11,00%

Sito Navigazione con

GWT-Observer/Proxy Trenitalia.it Repubblica.it

Sempre nella condizione di mouse in movimento si sono rilevate con Firebug le seguenti misure:

• 1 connessione HTTP ogni 2 secondi;• dimensione massima del payload della richiesta con movimento mouse: 3551 Bytes;• dimensione tipica dello header della richiesta: 967 Bytes.

Il numero di connessioni effettuate coincide con il valore imposto (hardcoded) nel codice e quindi modificabile dallo sviluppatore attraverso la modifica di una costante.La dimensione del payload e dello header sono coerenti con le precedenti misure approssimative della banda portando ad ipotizzare un upload massimo di 2267 Bytes/sec46. Questo risultato è compatibile con le misure qualitative attuate con iptraf.Vi è inoltre la possibilità di configurare l'AS attraverso l'aggiunta di un filtro affinché le richieste vengano compresse con gzip, si è voluto stimare il risparmio di banda senza però implementare tale soluzione.Per effettuare la stima si sono inseriti in un file il contenuto di una richiesta del client GWT-Observer e si è effettuata una compressione gzip delo stesso; i risultati sono riportati in tabella 7.

L'utilizzo della compressione ridurrebbe la banda massima occupata in upload a 750 Bytes/sec.

6.5 Impressioni soggettive sulla navigazione

Durante gli esperimenti di navigazione con le pagine monitorate attraverso GWT-Observer/Proxy non si sono percepiti rallentamenti o rilevati malfunzionamenti dei siti stessi.Il carico del client GWT-Observer sul browser e le latenze introdotte dal server dell'applicativo non sono quindi tali da causare disagio all'utente.

6.6 Analisi dei risultati ottenuti

Nei risultati del paragrafo 6.1 si è evidenziato che la singola permutazione consta mediamente di 72.252 Bytes che si riducono a 23.231 Bytes nel caso di compressione gzip. Si può confrontare questo risultato con le dimensioni tipiche di alcuni elementi tratti dalla homepage di Libero:

• una immagine Jpg di bassa qualità 380x170 ha una dimensione di 18.5 Kbytes;• Il codice HTML della homepage di libero occupano 27,3 Kbytes;

46 Empiricamente: Banda in upload = (dimensione payload + dimensione header) / periodo di invio= (3551+967)/2 = 2267 Bytes/sec

72

Tabella 6: Banda di picco occupata da GWT-Observer

Client Upload 20 Kbit/sec 2,5 KBytes/sec

Client Download 2 Kbit/sec 0,25 Kbytes/sec

Tabella 7: Dimensione di una richiesta di GWT-Observer.

Tipo di richiestaNormale 3511 4534

933 1470

Payload [Bytes] Payload+Header [Bytes]

Compressa (gzip)

• gli elementi grafici legati alla homepage Libero sono molti e ben più ingombranti (complessivamente le sole immagini hanno un ingombro maggiore di 100 Kbytes).

Questi dati fanno concludere che la dimensione dello script GWT-Observer lo rendono compatibile con utilizzo all'interno delle comuni pagine.I risultati ottenuti nel paragrafo 6.2 evidenziano come i tempi di caricamento della pagina risentono della presenza e della esecuzione di GWT-Observer in modo trascurabile. Anche nella navigazione monitorata attraverso GWT-Observer/Proxy i ritardi sui caricamenti della pagina si mantengono a livelli accettabili e comparabili con le normali fluttuazioni nei tempi di caricamento comunemente sperimentati durante una navigazione.Nel paragrafo 6.4 si è misurata una occupazione di banda in upload massima pari a 2,5 Kbyte/sec, che risulta essere una frazione delle capacità delle linee ADSL odierne. L'adozione della compressione gzip renderebbe ancora minore l'occupazione della banda ma comporterebbe un maggior carico sul processore lato server, particolare che dovrà in qual caso essere attentamente valutato.In tutti gli aspetti valutati l'applicativo ha rispettato le specifiche imposte nel paragrafo 5.2.1 .

73

7. Test dell'applicativo

Si descriveranno gli esperimenti svolti al fine di verificare sul campo la funzionalità dell'applicativo sia nella modalità Direct che Proxy.Per entrambe le modalità di utilizzo sono state verificate:

• la correttezza dei dati registrati• la capacità di gestire più utenti contemporanei• l'usabilità del sito monitorato

Si fa notare che nei seguenti esperimenti non si è installato alcun software aggiuntivo sulle macchine di test o plugin sui browser.

7.1 Test nella modalità Direct

La modalità Direct è utilizzata da un amministratore al fine di monitorare e registrare l'interazione dell'utente su alcune pagine del proprio sito.Le motivazioni che possono spingere un amministratore ad attuare queste registrazioni potranno essere di diverso tipo, tra queste la creazione di un CAPTCHA o l'identificazione di un particolare utente.Si è voluto quindi, nel test della modalità Direct, ricreare delle condizioni simili a quelle del teatro finale di utilizzo.

7.1.1 TestPages, realizzazione delle pagine di prova

Si è proceduto alla creazione di un applicativo web adibito alla presentazione di una successione di pagine di test, tale applicativo, denominato TestPages, permette agli utenti di svolgere sulle pagine di test delle comuni operazioni, quali la compilazione di un form di registrazione o l'effettuazione di un login.TestPages, oltre ad incorporare nelle pagine il codice JavaScript di GWT-Observer, implementa la logica atta a raccogliere i dati inseriti dagli utenti nei form.Si è ritenuto che le informazioni raccolte nei form potrebbero rivelarsi importanti nelle successive ricerche sui CAPTCHA, o al fine di identificare il legame tra i dati raccolti e l'input

75

rilevato dalla tastiera.

7.1.1.1 Descrizione dell'applicativo TestPages

Per la realizzazione dell'applicativo TestPages si è utilizzato il linguaggio Java.Le funzioni dell'applicativo sono implementate all'interno di alcuni servlet che hanno lo scopo di gestire le varie operazioni:

• pagina di login del test• presentazione del test• descrizione o presentazione delle pagine di prova• visualizzazione delle pagine di prova• raccolta dei dati inseriti nei form delle pagine di prova e salvataggio degli stessi su file• conclusione del test

Per la partecipazione all'esperimento si impone l'inserimento di una password nella schermata di login (Illustrazione 13).

Al login segue una pagina di presentazione dell'esperimento (Illustrazione 14).

Alla pressione del tasto “Inizia test”, TestPages fornisce all'utente una presentazione della pagina successiva con una descrizione della azione richiesta (Illustrazione 15).

76

Illustrazione 13: Pagina di login di TestPages

Illustrazione 14: Presentazione esperimento

La pressione del tasto “Prosegui” porta l'utente ad una pagina di prova, le illustrazioni 16 e 18 riportano alcuni esempi delle pagine di prova realizzate. L'uscita dalle pagine è causata dal completamento della azione richiesta nella presentazione, ad esempio una azione di submit o login da parte dell'utente.Alla conclusione del test viene visualizzata una pagina che permette all'utente di rifare il test (Illustrazione 17).

77

Illustrazione 15: Presentazione pagina di prova successiva

Illustrazione 17: Pagina conclusione test

Illustrazione 16: Pagina di prova, registrazione Ebay Calssico

7.1.1.2 Convenzioni adottate per il salvataggio dei file

I dati raccolti nei form vengono associati all'ID della interazione relativa e salvati su file in formato XML.I file vengono salvati nella directory WEB-INF dell'applicativo TestPages e il loro nome segue la convenzione ID_interazione.xml.Si riporta di seguito come esempio il contenuto del file 12687360108690004.xml relativo ai dati inseriti nei form durante l'interazione con la pagina Bing.

<testservice.utils.UserInteraction>

<pageURL>bing.htm</pageURL>

<ParameterMap class="org.apache.catalina.util.ParameterMap" serialization="custom">


<map>

<default>

<loadFactor>0.75</loadFactor>

<threshold>12</threshold>

</default>

<int>16</int>

<int>4</int>

<string>login</string>

<string-array>

<string>Giano</string>

</string-array>

<string>passwd</string>

78

Illustrazione 18: Pagina di prova, registrazione Bing

<string-array>

<string>parolamia</string>

</string-array>

<string>remMe</string>

<string-array>

<string>1</string>

</string-array>

<string>SI</string>

<string-array>

<string> Accedi </string>

</string-array>

</map>

<linked-hash-map>

<default>

<accessOrder>false</accessOrder>

</default>

</linked-hash-map>

<org.apache.catalina.util.ParameterMap>

<default>

<locked>true</locked>

</default>

</org.apache.catalina.util.ParameterMap>

</ParameterMap>

<interactionID>12687360108690004</interactionID>

</testservice.utils.UserInteraction>

I dati relativi alle interazioni e rilevati dal client GWT-Observer sono stati salvati dal backend GWT-Observer seguendo le convenzioni indicate nel capitolo 3.

7.1.1.3 Scelta delle pagine di prova

Si sono create sono delle riproduzioni delle pagine di login e registrazione di siti famosi, si riporta la lista delle pagine create:

• registrazione nuovo utente Google;• registrazione nuovo utente Amazon;• login sul sito Bing;• registrazione nuovo utente Bing;• registrazione nuovo utente Ebay;• login sul sito Facebook;• registrazione nuovo utente sul forum Html.it;• login sul sito Skype.

7.1.2 Esperimenti effettuati

L'applicativo TestPages e i servizi GWT-Observer47 sono stati installati sull' AS GlassFish 3.0 del server “Voyager” in dotazione al Laboratorio di Reti di Calcolatori.

47 La procedura di installazione è stata descritta nel capitolo 4.

79

La pagina principale per l'accesso ai test è stata resa disponibile all'interno della rete locale e raggiungibile all'indirizzo: http://voyager.inginf.units.it:7979/TestPages/Al test hanno partecipato 7 persone e si sono quindi raccolte le registrazioni di 56 interazioni.

7.1.3 Risultati ottenuti

Nessuna delle registrazioni è risultata danneggiata anche se in 4 occasioni i browser non hanno fatto in tempo a generare la richiesta l'endOfInteraction.La mancanza dell'endOfInteraction non ha causato perdita di dati siccome l'ultimo click del mouse effettuato dall'utente è risultato trovarsi nelle registrazioni lato server, l'unico effetto è stato quindi un posticipo del salvataggio delle interazioni su file da parte del server.Per dare una dimensione dei dati registrati, la serializzazione binaria delle interazioni di un utente relative al test, durato complessivamente 6 minuti, occupano 400 KBytes , mentre la serializzazione XML delle stesse interazioni occupano 2,5 MBytes.Legando la quantità di dati al tempo impiegato sono stati raccolti 1 Kbytes/secondo di dati binari e 7 Kbytes/sec di dati in fromato XML48.

7.2 Test nella modalità Proxy

Per il test della modalità proxy si sono installati l'AS Glassfish, il server Squid e ICAP su un unico host all'interno della rete locale49.Si è invitato gruppo di utenti ad attuare una navigazione monitorata attraverso il GWT-Observer/Proxy.Gli utenti hanno utilizzato i seguenti brower:

• Firefox 3.6;• Firefox 3.5.7;• Internet Explorer 7.

7.2.1 Esperimenti effettuati

E' stato chiesto agli utenti di effettuare le seguenti operazioni:

• una navigazione su alcuni siti appartenenti ad una lista;• una navigazione libera sui siti di loro preferenza;• annotare le impressioni soggettive sull'uso o gli eventuali problemi riscontrati.

7.2.2 Risultati ottenuti

La lista di siti, fornita agli utenti, su cui si è richiesto di effettuare la navigazione è la seguente:

• Virgilio.it• Ebay + Ebay classico• Corriere della Sera

48 la serializzazione XML attuata con XStream è più prolissa della serializzazione GWT-RPC adottata nella trasmissione.

49 Per il setup dell'infrastruttura vale quanto riportato nel cap.4; per una descrizione dettagliata della modalità GWT-Observer/Proxy si rimanda ai dettagli implementativi del cap.5

80

• Repubblica• Facebook• Forum Amule• Google Reader• Google Maps

Nessun utente ha riportato malfunzionamenti o disagio nella navigazione sui siti appartenenti alla lista e la registrazione delle interazioni è avvenuta con successo.Anche la successiva navigazione libera ha avuto lo stesso esito positivo, nessun malfunzionamento o disagio è stato rilevato e le registrazioni sono avvenute con successo.Si sono incontrati soltanto alcuni limiti tecnici alla registrazione, già noti dalla fase di implementazione:

1. la navigazione su pagine https non è osservabile con GWT-Observer in modalità proxy;2. i Flash non permettono a GWT-Observer di rilevare gli eventi mouse o tastiera che

avvengono su di essi.

Esclusi i due casi problematici sopracitati, la registrazione è avvenuta correttamente per tutte le interazioni effettuate dagli utenti.

81

8. Conclusioni

L'obiettivo prefissato è stato conseguito con successo; si è quindi riusciti ad implementare un applicativo JavaScript e una infrastruttura che permettono la registrazione remota delle azioni intraprese dall'utente durante l'interazione con una pagina web.Lo strumento realizzato fornisce entrambe le modalità operative preventivate in sede di analisi, permettendo sia la registrazione dell'attività degli utenti connessi ad un sito specifico, sia la registrazione della navigazione degli utenti connessi ad un proxy http.

Il client JavaScript dell'applicativo è stato sottoposto alla verifica delle specifiche prestazionali imposte in sede di analisi, ottenendo i seguenti risultati:

• L'applicativo JavaScript sviluppato presenta una dimensione di poche decine di Kbytes e la sua presenza comporta un aumento dei tempi di download di una pagina di fatto trascurabile.

• Le operazioni attuate dall'applicativo durante la sua inizializzazione causano un ulteriore ritardo nella visualizzazione della pagina quantificabile in 100 ms, ritardo impercettibile all'utente.

• In condizioni di massima attività l'applicativo client ha causato un aumento nel carico del processore pari al 12% del valore massimo, valore moderato e quindi rispondente alle specifiche.

• La banda di picco occupata dall'applicativo in upload non supera i 2,5 Kbytes/sec nel caso di connessione standard e si stima valga 0,75 Kbytes/sec in caso di connessione compressa con gzip; entrambi i valori sono compatibili con le capacità delle connessioni odierne.

Oltre alle precedenti verifiche prestazionali, l'infrastruttura ha superato una serie di test che ha coinvolto un gruppo di utenti invitati ad interagire con i siti web monitorati o a navigare attraverso il proxy.Durante gli esperimenti le registrazioni delle interazioni sono avvenute con successo e nessuno degli utenti ha lamentato malfunzionamenti o rallentamenti apprezzabili; inoltre si è verificata la correttezza delle registrazioni sia nel caso di pagine composte da numerosi elementi dinamici sia nel caso di complesse applicazioni AJAX.Sempre durante la sperimentazione si sono evidenziati alcuni casi particolari nei quali l'applicativo non ha potuto effettuare la registrazione degli eventi, ma tali limitazioni o erano

83

state già previste in fase di progetto o sono aggirabili con lievi modifiche al codice delle pagine monitorate.

L'adozione del Google Widget Toolkit ha permesso di scrivere sia il codice dell'applicativo client che server in linguaggio Java; in questo modo si è potuto scrivere del codice comune per le due componenti e operare ad un livello di astrazione maggiore.Il GWT ha altresì permesso di produrre un applicativo JavaScript in grado di operare indifferentemente su tutti i maggiori browser, sollevando l'autore dal pesante onere di gestire le problematiche relative alla compatibilità cross-browser. Oltre alla scrittura del codice, si è dovuta porre particolare attenzione alla realizzazione della infrastruttura proxy; la soluzione adottata consiste nella integrazione di diversi servizi e software che hanno richiesto lo studio di tutti gli standard e delle convenzioni ad essi relativi.Per quanto all'inizio risultasse problematica, l'integrazione dei diversi servizi ha dato esito positivo, risultando in una soluzione funzionale.

Concludendo, l'applicativo realizzato fornisce tutte le funzionalità necessarie alla raccolta dei dati negli ambiti di impiego previsti e costituisce uno strumento concreto, utilizzabile nelle successive ricerche sull'interazione uomo-interfaccia web.

84

9. Ringraziamenti

Il primo e più grande ringraziamento va ai miei genitori per l'amore, la cura e il cibo.

Il secondo ringraziamento va ad Angela, la mia musa, per aver ispirato questa e altre imprese.

Un ringraziamento va a tutti i miei amici ma soprattutto Vlad, Luca, Federico e a tutti i componenti della “Tana”; come compagni di un Vault mi avete accompagnato in queste Wastelands, voi siete la vera Brotherhood Of Steel!

Ringrazio il Professor Alberto Bartoli per l'opportunità accordatami e per il puntuale supporto.

Ringrazio tutte le IA del laboratorio di Reti di Calcolatori, Eric, Giorgio, Enrico, Marco, Andrea, Luca, Gabriele, Voyager, Odissey per i preziosi consigli e per l'amicizia; sacrificherò al Quelo un vitello affinché Egli vi rimeriti con informatica prosperità.

Ringrazio marzialmente Claudio, Maria e gli amici del KarateTeam per gli anni di entusiasmante Kumite, grazie a voi ho conosciuto il vero dolore (ma che ringrazio a fare !?)

Ringrazio tutti, ma proprio tutti coloro che hanno aspettato con ansia questo momento.

Ringrazio i produttori di videogiochi per gli anni di felicità.

Ringrazio i giapponesi per i loro cartoni animati e per aver così segnato la mia infanzia e adolescenza; senza la vostra piacevole contaminazione, sicuramente, mi sarei iscritto al liceo artistico ed adesso sarei un annoiato regista circondato da fotomodelle, grazie! L'ho scampata bella.

Grazie

85

10. Bibliografia

[1] Guo, Qi, e Eugene Agichtein. 2009. Beyond session segmentation: predicting changes in search intent with client-side user interactions. In Proceedings of the 32nd international ACM SIGIR conference on Research and development in information retrieval, 636-637. Boston, MA, USA

[2] Guo, Qi, e Eugene Agichtein. 2008. Exploring mouse movements for inferring query intent. In Proceedings of the 31st annual international ACM SIGIR conference on Research and development in information retrieval, 707-708. Singapore, Singapore

[3] Atterer, Richard, Monika Wnuk, e Albrecht Schmidt. 2006. Knowing the user's every move: user activity tracking for website usability evaluation and implicit interaction. In Proceedings of the 15th international conference on World Wide Web, 203-212. Edinburgh, Scotland

[4] Atterer, Richard, e Albrecht Schmidt. 2007. Tracking the interaction of users with AJAX applications for usability testing. In Proceedings of the SIGCHI conference on Human factors in computing systems, 1347-1350. San Jose, California, USA

[5] Cooper, Robert. Understanding the GWT compiler, Javalobby. http://java.dzone.com/news/understanding-gwt-compiler

[6] J. Elson, A. Cerpa, 2003, Request for Comments(RFC) 3507, Internet Content Adaptation Protocol (ICAP), http://www.ietf.org/rfc/rfc3507.txt

[7] ClickTale Wiki, http://wiki.clicktale.com/Article/Main_Page

[8] glassfish: GlassFish - Open Source Application Server, https://glassfish.dev.java.net/

[9] Sun GlassFish Enterprise Server 2.1 Quick Start Guide, Deploying a Sample Web Application, http://docs.sun.com/app/docs/doc/820-4334/geyvr

[10] Wikipedia, Same Origin Policy, http://en.wikipedia.org/wiki/Same_origin_policy

[11] Google Web Toolkit -Google Code, documentazione, http://code.google.com/intl/it-IT/webtoolkit/doc/latest/DevGuide.html

[12] Apache Tomcat 6.0 - Proxy Support HOW-TO, http://tomcat.apache.org/tomcat-6.0-doc/proxy-howto.html.

[13] Squid homepage, documentazione, http://www.squid-cache.org/

[14] Squirm homepage, documentazione, http://squirm.foote.com.au/

87

Progetto e realizzazione di una infrastruttura per la registrazione degli eventi su interfacce web...

Documents

Transcript of Progetto e realizzazione di una infrastruttura per la registrazione degli eventi su interfacce web...