analisi ed ottimizzazione base dati di un server web per ... analisi ed ottimizzazione base dati di...

UNIVERSITA' DEGLI STUDI DI MILANOFacoltà di Scienze Matematiche, Fisiche e Naturali

Corso di Laurea in Informatica triennale

ANALISI ED OTTIMIZZAZIONE BASE DATI DI UN SERVER WEB PER LA DISTRIBUZIONE

SOFTWARE IN AMBITO SCIENTIFICO

Relatore: Prof.ssa S. CASTANOCorrelatore: Dott. G. BATTISTIONI

Tesi di laurea diChristian QUADRI

matricola 689544

Anno Accademico 2007/2008

Indice

1 Il sistema preesistente.................................................................................................................7

1.1 Funzionalità del sistema esistente......................................................................................7

1.2 Gestione dati....................................................................................................................10

1.2.1 L'archivio dei dati.....................................................................................................10

1.2.2 Il sistema di distribuzione del software.....................................................................12

1.3 Nuovi requisiti .................................................................................................................16

2 Progettazione dell'applicazione e della base di dati.................................................................17

2.1 Analisi delle criticità.........................................................................................................17

2.1.1 La base di dati ..........................................................................................................17

2.1.2 L'applicazione...........................................................................................................18

2.2 Progettazione della base di dati........................................................................................19

2.2.1 Schema Entità Relazione..........................................................................................19

2.2.2 Progettazione Logica.................................................................................................23

2.3 Progettazione dell'applicazione web.................................................................................24

3 Sviluppo dell'applicazione web e della base di dati.................................................................27

3.1 Tecnologie utilizzate.........................................................................................................27

3.2 Implementazione base di dati...........................................................................................28

3.2.1 Progettazione fisica...................................................................................................28

3.2.2 Sicurezza...................................................................................................................33

3.3 Architettura software........................................................................................................34

3.3.1 Interazione base di dati.............................................................................................36

3.3.2 Procedura di autenticazione......................................................................................38

3.3.3 Modulo download pacchetti software.......................................................................40

3.3.4 Modulo di ricerca avanzata.......................................................................................42

4 Esempi d’uso............................................................................................................................45

Conclusioni e sviluppi futuri.......................................................................................................49

Introduzione 4

Introduzione

Il progetto di tesi è stato realizzato presso la sezione INFN (Istituto Nazionale di Fisica

Nucleare) di Milano con sede al dipartimento di Fisica dell'Università degli Studi di Milano.

Durante l'attività di tirocinio, svolto presso lo stesso ente, sono stato assegnato all'analisi del

funzionamento del sito web “www.fluka.org” al fine di collaborare con il web master al

miglioramento delle funzionalità.

Il sito web ha come obiettivi principali la distribuzione e il supporto tecnico del software di

simulazione delle particelle elementari FLUKA per applicazioni nella fisica delle alte energie,

schermature, dosimetria in fisica medica e radiobiologia. FLUKA possiede una licenza che ne

vieta l'uso per scopi commerciali e militari. Il gruppo di ricercatori che sviluppa tale software

ha la necessità di controllarne la distribuzione e a tale scopo ogni utente del sito che intende

scaricare il simulatore deve registrarsi, fornendo i propri dati che vengono memorizzati in

una specifica base di dati in formato testo.

Il lavoro di tesi è iniziato con un'attività di analisi dell'archivio dei dati e dell'applicazione

web, in funzione di nuovi requisiti del gruppo di ricercatori, i quali hanno richiesto la

possibilità di ottenere dati statistici e un migliore controllo sulla diffusione del software,

avendo un controllo costante di quali utenti avessero effettivamente effettuato con successo lo

scaricamento del software in quanto il sistema esistente non era in grado di fornire questi dati.

In seguito a questa analisi è risultato opportuno sostituire l'archivio dei dati in formato testo

con un Data Base Management System (DBMS) relazionale, per una migliore gestione dei

dati e garantirne una scalabilità maggiore, sfruttando le potenzialità di generazione di

http://www.fluka.org/

Introduzione 5

interrogazioni, anche complesse, del linguaggio SQL.

La progettazione della base di dati è iniziata con l'analisi dei requisiti e la creazione dello

schema EntitàRelazione che è stato poi presentato al gruppo di ricerca, modificandolo dove

necessario. Lo schema è stato tradotto nel suo modello relazionale e implementato utilizzando

MySQL come DBMS.

Una volta definita e testata la struttura della base di dati è iniziata la fase di analisi e

progettazione delle nuove funzionalità realizzabili all'interno dell'applicazione web, in

funzione dei nuovi requisiti e della nuova tipologia di base di dati identificandone le parti da

modificare e i nuovi moduli da realizzare.

Il risultato della progettazione è il seguente:

– Apportare modifiche alle procedure di interazione con la base di dati, creando un modulo

di interfaccia tra sito web e base di dati sostituendo quelle precedenti.

– Riprogettazione della procedura di autenticazione per gli utenti registrati rendendola

obbligatoria per accedere alla procedura di scaricamento pacchetti, diversamente da

quanto avveniva in precedenza in cui l'accesso al download era regolato tramite

autorizzazione diretta del web server.

– Progettazione di una nuova procedura di download dei pacchetti in grado di monitorare il

completamento con successo dello scaricamento.

– Progettazione di un modulo di ricerca avanzata utilizzabile dall'amministratore del sito

per effettuare ricerche specifiche e personalizzabili all'interno della lista degli utenti

registrati.

L'implementazione delle nuove parti dell'applicazione web è stata fatta utilizzando le

tecnologie a disposizione sul web server. Sviluppando tali moduli si è cercando di riutilizzare

Introduzione 6

il più' possibile il codice già presente e si sono integrati i nuovi blocchi mantenendo

un'architettura coerente con quella preesistente.

Nel Capitolo 1 è presentato lo stato del sistema durante la fase di analisi, descrivendo

dettagliatamente la struttura dell'archivio dei dati e le sue interazioni con l'applicazione web.

Nel Capitolo 2 è descritta la fase di progettazione della nuova base di dati e dei moduli

applicativi, presentando un'analisi delle criticità del sistema preesistente

Il Capitolo 3 è interamente dedicato alla fase implementativa descrivendo il funzionamento

delle procedure realizzate, presentando i problemi riscontrati e la loro soluzione.

Nel Capitolo 4 sono presentate alcune schermate del sito web relative alle funzionalità

implementate.

Nell'ultimo capitolo sono riportate le conclusioni del lavoro di tesi e alcuni sviluppi futuri

realizzabili sulle basi di ciò che è stato realizzato.

Capitolo 1 7

Capitolo 1

Il sistema preesistente

In questo capitolo verranno descritte:

– le funzionalità del sistema nel Sottocapitolo 1.1.

– il sistema di gestione dei dati e di distribuzione del software nel Sottocapitolo 1.2;

– nel Sottocapitolo 1.3 i requisiti che sono alla base della ristrutturazione del sistema

oggetto dell'elaborato finale.

1.1 Funzionalità del sistema esistente

La struttura generale del sistema esistente è rappresentata nella figura 1.1

Figura 1.1: struttura generale del sistema esistente

Il sistema preesistente 8

Il principale obiettivo del sistema si occupa del distribuzione controllata del software di

simulazione delle particelle elementari FLUKA[1][2] per applicazioni nella fisica delle alte

energie, schermature, dosimetria in fisica medica e radiobiologia. Il gruppo di ricercatori ha

la necessità di controllare la distribuzione di questo software, in quanto la sua licenza ne vieta

l'utilizzo per scopi commerciali e militari. Un'ulteriore scopo del sistema è quello di fornire

supporto tecnico, informazione e documentazione del software agli utilizzatori distribuiti in

tutto il mondo prevalentemente presso enti di ricerca in abito fisico.

Ogni utente che intende scaricare il simulatore deve effettuare una registrazione via web

immettendo i seguenti dati: nome, cognome, indirizzo di posta elettronica, l'organizzazione o

l'ente presso cui lavora o effettua ricerche, gli interessi nell'ambito dei settori della fisica delle

particelle, l'esperienza nell'uso del software, l'ambito di utilizzo (ricerca/didattica o

occasionale) e l'iscrizione alla mailing list generica di discussione (FLUKAdiscuss).

L'iscrizione alla lista degli utenti utilizzatori (FLUKAuser) è attivata in modo automatico al

momento della registrazione.

Oltre a questi dati viene richiesta una password che verrà utilizzata nella procedura di

autenticazione.

Non viene richiesto l'inserimento di uno username in quanto viene automaticamente generato

dal sistema e fornito all'utente tramite l'invio di una email, all'indirizzo di posta elettronica

specificato durante la registrazione.

Il sistema controlla che l'indirizzo di posta elettronica sia unico all'interno dell'archivio dei

dati, in quando è l'unico dato, tra quelli descritti sopra, in grado di verificare se un utente è

già registrato.

Il software viene distribuito in due modalità: pacchetto sorgente e pacchetto compilato. Per


entrambi i tipi sono associati permessi, che vengono concessi sulla base del dominio

dell'indirizzo di posta elettronica, in funzione dell'appartenenza alle liste dei domini consentiti

o proibiti1.

Possono verificarsi tre casi:

– Accesso consentito, se il dominio appartiene alla lista dei domini consentiti.

– Accesso negato, se il dominio appartiene alla lista dei domini proibiti.

– Accesso in stato decisionale, se il dominio non appartiene a nessuna delle due liste. In

questo caso la concessione dei permessi è demandata dell'amministratore del sito. In

questo stato l'utente non ha accesso al sistema.

Nel caso di accesso negato l'utente non verrà inserito nell'archivio dei dati e verrà informato

tramite un messaggio.

L'amministratore del sito può, in qualsiasi momento, cambiare i permessi, bloccando o

abilitando gli utenti registrati.

Il sistema deve memorizzare automaticamente data e ora della registrazione e l'indirizzo IP da

cui è stata effettuata, per un migliore controllo della distribuzione geografica2 degli utenti a

scopo statistico.

Ogni utente che intende modificare o cancellare il proprio profilo deve richiederlo

espressamente all'amministratore del sito il quale eseguirà manualmente la cancellazione o la

modifica richiesta.

1 Per ottenere i permessi di scaricare i pacchetti sorgenti sono necessari requisiti aggiuntivi che possono essere ottenuti contattando direttamente l'amministratore, il quale approverà o respingerà la richiesta.

2 Per distribuzione geografica degli indirizzi si intende solo la nazione, ricavata attraverso l'utilizzo del sistema DNS e dei database RIPE[3]


1.2 Gestione dati

In questo sottocapitolo verrà presentato in maniera dettagliata il sistema di acquisizione,

gestione e mantenimento dei dati preesistente sul server web. Nella Sezione 1.2.1 verrà

presentata l'archivio dei dati in formato testo, mentre nella Sezione 1.2.2 verra descritto il

funzionamento delle funzionalità offerte dal sistema.

1.2.1 L'archivio dei dati

L'archivio dei dati è in formato testo semplice e suddivisa in diversi file, uno per ogni utente

nominato in base allo username. Al suo interno sono contenuti i dati relativi ad uno specifico

account nel seguente formato: nome_campo separatore3 valore, i nomi dei

campi e il loro significato sono descritti nella Tabella 1.1.

Tabella 1.1: descrizione dei campi dell'archivio dei dati

Nome campo Descrizione Valori assuntifuid Username dell'utente Qualsiasi

pwd Password cifrata Qualsiasi

fname Nome Qualsiasi

lname Cognome Qualsiasi

email Indirizzo di posta elettronica Qualsiasi indirizzo di posta elettronica valido

affiliation Ente, laboratorio o azienda presso cui lavora l'utente Qualsiasi

interests Interessi nell'ambito dei settori della fisica della Qualsiasi

3 Nel caso specifico il separatore è rappresentato dal carattere '='.


Nome campo Descrizione Valori assuntiparticelle

DMLsubscribe Iscrizione alla mailing list delle generica di discussione (FLUKA discuss)

Y/N (si/no)

UMLsubscribe Iscrizione alla mailing list degli utenti utilizzatori del software

Y/N (si/no)

flukaUse Ambito di utilizzo del software E(didattica/ricerca) O(occasionale)

sourcePrv Permesso di scaricare i pacchetti sorgente GOOD / BAD / DECISION

packagePrv Permesso di scaricare i pacchetti compilati GOOD / BAD / DECISION

experience Esperienza nell'uso del software Vari livelli di esperienza

IP Indirizzo IP da cui si è effettuata la registrazione Qualsiasi indirizzo Ipv4 valido

error Errori occorsi durante la procedura di registrazione qualsiasi

dateReg Data e ora in cui è stata effettuata la registrazione Data e ora nel formato: AAAAMMGG_HHMMSS

dateUpd Data e ora in cui è stato effettuato l'aggiornamento del profilo

Data e ora nel formato: AAAAMMGG_HHMMSS

delete_me Campo opzionale che viene inserito aggiunto quando l'utente richiede la cancellazione del proprio profilo

Y/N (sì / no )

update_me Campo opzionale che viene inserito aggiunto quando l'utente richiede l'aggiornamento del proprio profilo

Y/N (sì / no )

Verranno ora approfonditi alcuni campi per chiarirne meglio il significato.

Il valore del campo fuid viene generato dal sistema nel formato fuidx dove x

rappresenta il primo intero libero tra i nomi utente già inseriti.

Il valore del campo pwd contiene la cifratura della password può essere di due tipi dovuto

all'utilizzo di due differenti algoritmi di cifratura, dovuto al fatto che l'archivio dei dati


contiene anche utenti registrati attraverso l'interfaccia di una versione precedente del sito

web.

Entrambi gli algoritmi sono usati dal web server Apache per criptare le password utilizzate

per il processo di autenticazione ad aree protette del file system del server, attraverso

l'utilizzo di htaccess4

I valori contenuti nei campi sourcePrv e packagePrv rispecchiano i tre tipi di permessi

descritti nei requisiti. GOOD significa che l'utente ha il permesso di scaricare il tipo di

pacchetto, BAD l'utente non possiede il permesso5, DECISION, l'indirizzo mail dell'utente

non appartiene né ai domini consentiti né a quelli proibiti.

Il campo interests può avere due formati a causa una diversa procedura di registrazione

nelle precedenti versioni del sito internet che lasciava totale libertà all'utente di inserire i

propri interessi nell'abito della fisica. Al fine di compiere un'indagine statistica sugli ambiti di

interesse di ciascun utente registrato, è stata limitata la scelta a un numero finito di settori

della fisica. Nel secondo caso ad ogni interesse è associata una stringa univoca, più interessi

sono separati da caratteri separatori (nel caso specifico “ | ”).

1.2.2 Il sistema di distribuzione del software

L'accesso al sistema di distribuzione del software avviene collegandosi al sito web dal quale

4 Il web server Apache (nello specifico la versione 2.0) permette di creare delle sottodirectory protette il cui accesso è riservato solo agli utente correttamente autenticati e autorizzati. Questo sistema è descritto dettagliatamente alla pagina internet “http://httpd.apache.org/docs/2.0/howto/htaccess.html”. Nei file htaccess specificano tra le sue direttive il nome del file delle password utilizzate per l'autenticazione.

5 Il valore BAD è predefinito per il campo sourcePrv, mentre può essere assunto dal campo packagePrv solo se l'amministratore volesse bloccare un particolare utente.

http://httpd.apache.org/docs/2.0/howto/htaccess.html


l'utente utilizzatore può eseguire le seguenti procedure:

– registrazione di un nuovo utente

– autenticazione e autorizzazione degli accessi all'area personale

– visualizzazione del profilo personale

– distribuzione del software

– gestione della lista utenti da parte dell'amministratore

Procedura di registrazione

Dopo che l'utente ha confermato l'inserimento dei dati tramite internet browser, il server

elabora i dati richiesti ed esegue le seguenti operazioni:

– analisi della correttezza dei dati inseriti

– ricerca nell'archivio dei dati per verificare che l'indirizzo di posta elettronica non sia già

presente, e nel caso lo fosse, l'utente verrà informato attraverso un messaggio

– verifica dell'esistenza del dominio dell'indirizzo di posta elettronica tramite analisi dei

record DNS

– verifica dei permessi, basandosi sull'indirizzo di posta elettronica. Se risulta all'interno

della lista proibita allora verrà notificato all'utente tramite un messaggio

– ricerca nell'archivio dei dati per la generazione del nome utente (si veda la descrizione del

campo fuid nella sezione precedente )

– inserimento dei dati se nessun errore è occorso durante le precedenti verifiche e

salvataggio di tutti i dati contenuti

– aggiornamento del file delle password delle aree protette nelle quali sono presenti i

pacchetti scaricabili se l'utente ha ottenuto i permessi


– gestione della lista utenti da parte dell'amministratore

Al termine della registrazione l'utente viene informato del risultato della procedura. Se tutte le

operazioni sono state eseguite con successo l'account è stato inserito nell'archivio dei dati. Il

permesso di scaricare i pacchetti software viene concesso, come già detto in precedenza, solo

se il dominio dell'indirizzo di posta elettronica appartiene alla lista dei domini consentiti,

altrimenti la decisione di abilitare o disabilitare l'accesso all'area download viene demandata

all'amministratore.

Il permesso di scaricare i pacchetti sorgente viene negato a tutti i nuovi utenti registrati.

Coloro i quali dovessero essere interessati ai sorgenti dovranno inviare una richiesta via mail

all'amministratore, chiedendone l'abilitazione.

Procedura di autenticazione e autorizzazione

La procedura ricerca i dati all'interno dell'archivio dei dati ottenendo la password cifrata e

viene confrontata con la cifratura della password inserita, se le due password sono identiche

allora l'accesso viene autorizzato altrimenti viene visualizzato un messaggio di errore

opportuno.

Questa procedura è riservata esclusivamente agli utenti registrati attraverso la nuova

interfaccia di registrazione.

Procedura di visualizzazione del profilo personale

Ogni utente può visualizzare i dati del proprio profilo previo accesso all'area personale

tramite la procedura di autenticazione e autorizzazione descritta sopra. Da quest'area è

possibile richiede la modifica dei dati oppure la cancellazione dell'account personale.


Procedura di distribuzione del software

I pacchetti software si trovano in specifiche cartelle sul file system del server, protette

dall'accesso di utenti non autorizzati. Da web browser si accede alla pagina di download dei

pacchetti, cliccando sul nome del file, si effettua una richiesta HTTP6 al server all'area

protetta dove è mantenuto il file.

In risposta il server richiede l'autenticazione per l'accesso e automaticamente il browser apre

all'utente un finestra popup nella quale viene richiesto l'inserimento di username e password.

Si invia così una seconda richiesta HTTP al server il quale autorizza o nega l'accesso7 a tale

area e di conseguenza l'utente potrà iniziare il download del file richiesto.

Gestione della lista utenti da parte dell'amministratore

L'amministratore ha la possibilità di visualizzare la lista degli utenti registrati accedendo alla

perte amministrativa del sito web. Da tale selezione è possibile visualizzare tutti gli utenti

contenuti nell'archivio dei dati oppure effetture ricerche scegliendo tra un ristretto numero di

possibilità, non personalizzabili dell'amministratore, esempio: tutti gli utenti registrati nelle

ultime ventiquattro ore oppure tutti gli utenti in stato decisionale.

Dopo aver visualizzato la lista è possibile accedere al profilo del singolo utente

modificandolo o eliminandolo, secondo quanto richiesto dall'utente stesso oppure secondo le

esigenze dell'amministratore.

6 Alla prima richiesta HTTP il web server risponde con il codice 401 che significa “richiesta di autorizzazione” all'area protetta [4]

7 Alla seconda richiesta HTTP viene aggiunta l'opzione Authorization con i valori username e password codificati in base64. Il server risponde con codice 200 se è autorizzato altrimenti risponde ancora con codice 401.


1.3 Nuovi requisiti

Il gruppo di ricerca ha espresso la necessità di acquisire nuovi dati, con l'obiettivo di

aumentare il controllo sull'operato degli utenti e sulla distribuzione del software.

Il gruppo di ricerca ha evidenziato un forte interesse all'analisi statistica dei dati.

Il sistema dovrà tenere traccia dei download effettuati con successo da un particolare utente,

memorizzando data e ora del completamento, l'indirizzo IP da cui è stato effettuato, che file è

stato richiesto e data ora di creazione del file sul server, per distinguere le varie versioni del

singolo pacchetto a parità di nome.

Sono state richieste maggiori informazioni utilizzando l'indirizzo IP, ricavandone il nome

dell'host nella rete, a quale ente, organizzazione o azienda appartiene e in quale nazione si

trova sfruttando i database RIPE e il servizio DNS.

Per aumentare la sicurezza e il controllo dell'accesso all'area download, il sistema dovrà

tenere traccia dell'ultimo accesso effettuato con successo da parte dell'utente,

memorizzandone data e ora.

Capitolo 2 17

Capitolo 2

Progettazione dell'applicazione e della base di dati

In questo capitolo verranno analizzate le criticità del sistema presentato nel capitolo

precedente e verranno proposte soluzioni alternative riprogettando o integrando i moduli già

presenti.

L'analisi delle criticità è presentata nel Sottocapitolo 2.1.

Nei Sottocapitoli successivi verrà descritta in dettaglio la progettazione dell'applicazione e

della base di dati a supporto.

2.1 Analisi delle criticità

Nella Sezione 2.3.1 verranno esposte le criticità relative alla base di dati, mentre nella

Sezione 2.3.2 quelle relative al sistema nel suo complesso.

2.1.1 La base di dati

Una base di dati realizzata come descritto nella Sezione 1.2.1, se da un lato, permette un

facile ampliamento del numero di campi contenuto all'interno nel singolo file data la struttura

Progettazione dell'applicazione e della base di dati 18

molto semplice, dall'altro risulta molto onerosa la progettazione di procedure che la

interroghino, soprattutto in funzione delle nuove esigenze del gruppo di ricercatori (vedi

Sottocapitolo 1.1). La difficoltà nella creazione di codice che elabori i dati, sta nel fatto che

ogni campo deve essere interpretato dal suo valore in stringa al suo significato semantico, per

poter effettuare così confronti oppure analisi statistiche. Si creerebbero così delle procedure

ad hoc per ogni richiesta differente, minimizzando la riusabilità del codice e con prestazioni

medie inferiori rispetto all'utilizzo di una base di dati relazionale.

2.1.2 L'applicazione

La procedura di distribuzione dei pacchetti software, presentata nel precedente sottocapitolo,

risulta incapace di soddisfare la richiesta del gruppo di ricercatori di avere un controllo

dettagliato sugli scaricamenti. Non esiste, nell'implementazione attuale, una procedura in

grado di verificare se un download è stato completato con successo e da quale host nella rete

internet è stato effettuato. Queste informazioni risiedono esclusivamente nei file di log del

server web Apache8, la cui lettura e analisi9 risulta molto onerosa.

Nell'attuale sistema solo agli utenti registrati attraverso il nuovo sito è consentito l'accesso

all'area di visualizzazione del profilo personale. La procedura di autorizzazione è in grado di

verificare le credenziali degli utenti che utilizzano la password cifrata con il nuovo algoritmo.

L'amministratore del sito può effettuare solo un numero limitato di ricerche all'interno della

8 Per la struttura dettagliata e personalizzabile dei file di log del server web Apache sito internet “http://httpd.apache.org/docs/2.0/logs.html”

9 Per verificare se un utente ha effettuato il download con successo è necessario osservare i seguenti campi del file di log: nome dell'utente remoto, richiesta GET HTTP, numero di byte inviati nella risposta, codice della risposta. Il numero di byte deve essere uguale alla dimensione del file e il codice di di risposta deve essere 200.

http://httpd.apache.org/docs/2.0/logs.html


base di dati degli utenti, predefinite e senza possibilità, a meno di modifiche del codice, di

personalizzazione in funzione dei dati che si vogliono ottenere.

2.2 Progettazione della base di dati

In questo sottocapitolo verrà descritta la progettazione del database relazionale e la sua

realizzazione pratica. Nella Sezione 2.2.1 verrà presentato il modello concettuale dei

dati(diagramma entità relazione) e la sua traduzione nel modello logico relazionale verrà

descritta nella Sezione 2.2.2.

2.2.1 Schema Entità Relazione

La progettazione concettuale dei dati, in accordo coi requisiti raccolti e descritti nel

Sottocapitolo 1.1, è rappresentata nel diagramma Entità Relazione riportato nella Figura 4.1.

Figura 2.1: schema entità relazione


L'entità USER rappresenta un utente del sistema, ed è descritta nella tabella 2.1

Attributo Descrizionefuid Identificatore dell'entitàpwd Password cifrata

mail_address Contiene l'indirizzo mail specificato al momento della

registrazionefname Nome dell'utentelname Cognome dell'utente

experience Esperienza nell'uso del softwareaffiliation Organizzazione presso cui l'utente è ospitatofluka_use Tipo di utilizzo del software

dml_subscribe Iscrizione alla mailing list delle generica di discussione (FLUKA

discuss) uml_subscribe Iscrizione alla mailing list degli utenti utilizzatori di FLUKAsource_prv Privilegi di scaricare pacchetti in formato sorgentepackage_prv Privilegi di scaricare pacchetti in formato compilato

status Stato dell'utentedate_registration Data e ora di registrazione dell'utente

date_update Data e ora di modifica del profilo utentelast_access Data e ora dell'ultimo accesso autenticato al sistema ( si vedano le

specifiche capitolo xxx)

Tabella 2.1: descrizione entità USER

Il campo status è stato introdotto per condensare il significato dei campi update_me e

delete_me della Tabella 1.1, e della stato dell'utente, DECISION o GOOD, dopo la

registrazione. Tale scelta è basata sul fatto che l'assunzione di uno dei valori escluda


automaticamente gli altri.

La conseguenza di questo cambiamento comporta che i campi source_prv e

package_prv assumono solo valori booleani.

L'entità INTEREST completa il quadro dell'utente e rappresenta i suoi interessi nell'ambito

di settori della fisica. Viene descritta nella tabella 2.2

Attributo DescrizioneName_interst Identificatore debole dell'entità e rappresenta un interesse in ambito fisico

dell'utente

Tabella 2.2: descrizione dell'entità INTEREST

L'entità HOST,che specifica un particolare host nella rete internet, è descritta nella tabella 2.3

Attributo DescrizioneIP Identificatore dell'entità rappresentante indirizzo IP

Name_Host Nome dell'host tramite risoluzione DNSAffiliation Nome dell'organizzazione presso cui l'host risiedeCountry Paese di appartenenza

Tabella 2.3: descrizione dell'entità HOST

L'entità DOWNLOAD,descrive un download avvenuto con successo da parte di uno specifico

utente da un particolare host in un preciso istante temporale con granularità di un secondo.

Tale entità è descritta nella tabella 2.4.


Attributo DescrizioneID Identificatore dell'entità

Date_Time Data e ora in cui è stato effettuato il downloadFile Nome del file scaricato

Date_Creation_Fil

e

Data e ora di creazione del file sul server che identifica la versione specifica del

software(si vedano le specifiche capitolo xxx )

Tabella 2.4: descrizione dell'entità DOWNLOAD

Mail_address è unico all'interno del sistema,rispettando la specifica di univocità degli

indirizzi mail (si vedano le specifiche al Sottocapitolo 1.1 ).

La scelta di creare l'entità INTEREST è dettata dal fatto che un attributo che descrive gli

interessi dell'utente all'interno di USER sarebbe multi valore. Si tratta di un'entità debole

infatti viene identificata solo parzialmente da Name_Interest lasciando il riconoscimento

univoco attraverso l'associazione Interessato_A che lega INTEREST a USER.

Nell'entità HOST, gli attributi Name_Host, Affiliation e Country derivano dalla

risoluzione DNS e dall'uso dei database RIPE[3], qualora esistano, dell'indirizzo ip.

USER è collegata con HOST tramite l'associazione Registrato_Da che rispetta la richiesta

di conoscenza dell'host da cui un utente si è registrato (si veda Sottocapitolo 1.1).

Nell'entità DOWNLOAD la scelta del campo Id come identificatore, in contrapposizione a

rendere DOWNLOAD un'entità debole identificata debolmente con Date_Time, è dettata dal

fatto che si è voluto prevenire il problema di gestione in caso di contemporaneità di

download. Per contemporaneità si intende che lo stesso utente da host diversi effettui il

download allo stesso tempo, con una granularità di un secondo.

DOWNLOAD è collegata con USER tramite Effettua che associa un utente ai propri

download effettuati, mentre è collegata con HOST attraverso Effettuato_Da specificando


che il download è stato effettuato da un particolare host.

2.2.2 Progettazione Logica

La progettazione logica traduce lo schema entità relazione descritto nel paragrafo precedente

nel corrispondente modello relazione. Verrà usata la seguente notazione: “attributo ” indica

uno o più attributi chiave, “attributo>rel[c]” attributo che si riferisce al campo “c” nella

relazione “rel”, “attributo*” attributo opzionale.

Lo schema logico del diagramma in Figura 2.1 è il seguente:

DOWNLOAD (Id,Date_Time,File,Date_Creation_File, Fuid-> USER[Fuid],Ip->HOST[ip] )

HOST (Ip, Name_Host*, Affiliation*, Country*)

INTEREST ([Fuid]->USER[Fuid], Name_Interest )

USER(Fuid,FName,LName,Mail_address,Experience,Affiliation ,Dml_subscribe*,Uml_subscribe*,SourcePrv,PackagePrv, Status,Date_Registration,Date_Update*,Last_Access*,Register_Host->HOST[ip] )

Tutte le associazioni dello schema ER sono di cardinalità uno a molti, da cui segue che gli

attributi chiave nelle entità con cardinalità maggiore, nell'associazione considerata, vengano

aggiunti all'insieme di attributi dell'entità con cardinalità minore e venga creato un vincolo di

integrità referenziale tra i campi delle due tabelle relazionali, ad esempio l'attributo

Register_Host della tabella USER si riferisce alla chiave della tabella HOST.


2.3 Progettazione dell'applicazione web

In questo sottocapitolo verrà presentata la progettazione dell'applicazione web mostrandone

le funzionalità, descrivendo le modifiche progettuali apportate al vecchio sistema,

specificando quali funzionalità sono state ridisegnate e quali solo modificate, in funzione dei

nuovi requisiti descritti nel Sottocapitolo 1.1.

Le funzionalità del sistema sono descritte dal diagramma degli Use Case UML in Figura 2.2

per l'utente utilizzatore e in Figura 2.3 per l'amministratore.

L'autenticazione è stata completamente riprogettata per rendere possibile l'accesso anche ai

vecchi utenti e soddisfare il requisito di conoscenza dell'ultimo accesso autenticato

dell'utente. Con l'obiettivo di uniformare l'accesso alle aree protette del sito web,

l'autenticazione è necessaria per accedere alla sezione di download dei file oltre che

all'accesso al profilo personale, come già avveniva nel precedente sistema (vedi Sezione

1.2.2).

Figura 2.2: Use Case utente


La visualizzazione del profilo personale e registrazione da parte dell'utente sono state

modificate nella parte relativa all'interazione con la base di dati. Il cambiamento di tipologia

di base di dati ha comportato una rivisitazione della struttura cambiando il modulo di

interfaccia, passando dall'archivio di dati in formato testo alla base di dati utilizzando un

sistema DBMS.

Lo scaricamento pacchetti è stato riprogettato al fine di verificare il completamento del

download da parte di uno specifico utente. Per soddisfare questo requisito il modulo si occupa

direttamente della distribuzione del pacchetto, potendo così monitorare l'avvenuto successo

dello scaricamento. In fase di progettazione di questa funzionalità sono state considerate

diverse ipotesi senza dover ricorrere alla già esistente lettura integrale di file di log. Una della

prime idee è stata considerare lo scaricamento di un pacchetto da parte di un utente prima di

inviarlo, inserendo i dati prima dell'effettiva operazione di download dal server. Tale

soluzione è però inefficace ai fini dei requisiti, in quando un download non completato non

viene distinto da uno avvenuto con successo. La soluzione adottata è risultata efficace

riuscendo a distinguere nettamente i download completati da quelli falliti ( si veda il Capitolo

Figura 2.3: Use Case amministratore


3 per l'implementazione di questa funzionalità).

Il nuovo sistema, soprattutto per la parte riguardante l'utente utilizzatore del software, è stato

progettato in modo tale da non stravolgere l'utilizzo dell'applicazione web alla quale l'utente

era già abituato. In caso di sostanziale cambiamento sono stati previsti appositi messaggi atti

a guidare l'utente all'utilizzo della nuova funzionalità.

Nella parte amministrativa dell'applicazione sono state introdotte due nuove funzionalità:

ricerca avanzata e sincronizzazione con il vecchio archivio dei dati.

La ricerca avanzata è stata introdotta per soddisfare le richieste di analisi statistiche sui dati

degli utenti registrati. La sua progettazione è tale da risultare dinamica e flessibile ad aggiunte

future di nuovi dati di interesse e presuppone l'esistenza di una base di dati relazionale. Il

modulo prevede una componente in grado di generare automaticamente query da sottoporre

alla base di dati in funzione degli specifici dati richiesti dall'amministratore, selezionati

attraverso un'intuitiva schermata di ricerca.

La funzionalità di sincronizzazione della base di dati è stata progettata per permettere la

conversione dei valori dei campi della vecchia base di dati nel nuovo formato. Durante la fase

di progettazione di questa funzionalità si è assunto che il vecchio archivio dei dati fosse

coerente e non contenesse errori nel formato dei campi. Qualora in fase di analisi dei dati

siano state incontrate incongruenze sono state immediatamente risolte contattando

direttamente l'amministratore del sistema.

Capitolo 3 27

Capitolo 3

Sviluppo dell'applicazione web e della base di dati

In questo capitolo verrà descritto in maniera dettagliata lo sviluppo dell'applicazione relativo

alle parti modificate o completamente reimplementate dell'applicazione preesistente,

rispecchiando le decisioni progettuali descritte nel capitolo precedente.

Nel Sottocapitolo 3.1 verranno presentate brevemente le tecnologie utilizzate motivandone il

loro impiego. Nel Sottocapitolo 3.2 verra descritta l'implementazione fisica della base di dati

presentata nel capitolo precedente. Nel Sottocapitolo 3.3 verranno descritti dettagliatamente i

moduli software realizzati focalizzando l'attenzione sulle scelte implementative effettuate.

3.1 Tecnologie utilizzate

La scelta delle tecnologie è stata fatta in accordo con i software già installati e configurati sul

sistema del web server di FLUKA. Il sistema operativo è una distribuzione Linux, nello

specifico Red Hat Enterprise[5] sulla quale è installato Apache 2.0[6] come server web. Il

sito internet è sviluppato in PHP 5[7] e JavaScript[8] (nella sola parte riguardante il modulo

di ricerca avanzata).

Il sito web sfrutta entrambi i protocolli HTTP[4] e HTTPS[9] utilizzando il secondo nelle

aree personali, nell'area dell'amministratore e per l'invio delle credenziali durante la fase di

autenticazione.

Sviluppo dell'applicazione web e della base di dati 28

I nuovi moduli dell'applicazione, dovendo fondersi con i preesistenti, sono stati realizzati con

lo stesso linguaggio, utilizzando le funzioni di libreria standard.

Inoltre sono state installate le seguenti librerie:

– PECL[10] per l'estensione delle funzionalità di gestione del protocollo HTTP

– MCrypt[11] per utilizzare la libreria Mcrypt in PHP10

Per la base di dati è stato utilizzato MySQL 5.0[12] come software DBMS.

L'utilizzo di questi software è in accordo con la filosofia open source11 dell'ente di ricerca

presso cui è stata realizzata l'applicazione.

3.2 Implementazione base di dati

3.2.1 Progettazione fisica

Verranno descritte le tabelle realizzate descrivendo le particolari scelte dei tipi di dato, gli

indici in aggiunta a quelli sulle chiavi primarie e le viste realizzate in funzione delle attività

statistiche e amministrative che verranno svolte.

Tutte le tabelle sono state implementate usando InnoDb[13] come metodo di memorizzazione

su disco di MySQL per consentire di creare e mantenere i vincoli di integrità referenziale dei

dati e quindi la consistenza interna nella base di dati.

Tabella Host

10 La libreria Mcrypt di PHP necessita che sia installato il pacchetto di sistema libmcrypt. 11 Per la definizione di “open source” si rimanda al seguente sito: “http://it.wikipedia.org/wiki/Open_source”.


Codice SQLCREATE TABLE Host ( ip varchar(50) PRIMARY KEY,

name_host varchar(60), affiliation varchar(1000), country varchar(60)) ENGINE = InnoDb;

Tabella 3.1: codice della definizione della tabella Host

L'attributo ip è stato dimensionato per tenere conto della rappresentazione IPv6 degli

indirizzi, allo stato attuale il web server utilizza IPv4, ma in un futuro potrebbe registrare gli

indirizzi nella nuova versione del protocollo ip, come già fanno alcune utility di rete presenti

del server.

Tabella User

Codice SQLCREATE TABLE User ( fuid varchar(20) PRIMARY KEY,

pwd varchar(100) NOT NULL, f_name varchar(30) NOT NULL, l_name varchar(30) NOT NULL, mail_address varchar(100) UNIQUE NOT NULL, experience varchar(30) NOT NULL, affiliation varchar(100) NOT NULL, fluka_use varchar(60) NOT NULL, dml_subscribe char(1), uml_subscribe char(1), source_prv varchar(20) NOT NULL, package_prv varchar(20) NOT NULL, status varchar(20) NOT NULL, date_registration datetime NOT NULL, date_update datetime, last_access datetime, ip varchar(50),

FOREIGN KEY(ip) REFERENCES Host(ip)) ENGINE = InnoDb;

Tabella 3.2: codice della definizione della tabella User

In questa tabella sull'attributo mail_address è stato definito un vincolo di UNIQUE in

accordo con le specifiche di univocità dell'indirizzo mail (si veda Sottocapitolo 2.1 ).

Sull'attributo date_registration è stato creato un indice, in quanto le ricerche di utenti in

funzione della data sono molto frequenti, sia per la gestione amministrativa, sia per la


generazione di statistiche.

Tabella Interest

Codice SQLCREATE TABLE Interest( fuid varchar(20),

name_interest varchar(20), FOREIGN KEY(fuid) REFERENCES User(fuid), PRIMARY KEY (fuid,name_interest))ENGINE = InnoDb;

Tabella 3.3: codice della definizione della tabella Interest

Tabella Download

Codice SQLCREATE TABLE Download (id serial PRIMARY KEY,

date_time datetime NOT NULL, file varchar(40) NOT NULL, date_creation_file datetime NOT NULL, fuid varchar(20) NOT NULL,ip varchar(50) NOT NULL,FOREIGN KEY(fuid) REFERENCES User(fuid),

FOREIGN KEY(ip) REFERENCES Host(ip)) ENGINE = InnoDb;

Tabella 3.4: codice della definizione della tabella Download

Per ottimizzare la ricerca dei download effettuati in base alla data è stato aggiunto un indice

sull'attributo date_time, in quanto viene frequentemente utilizzato in acquisizione di

statistiche.

Vista view_all_download

Codice SQLCREATE VIEW view_all_download ASSELECT User.fuid,mail_address,date_time,file,date_creation_file,

Host.ip,name_host,Host.affiliation,countryFROM User INNER JOIN Download inner join HostORDER BY date_time ASC ;

Tabella 3.5: codice della definizione della vista view_all_dowload

La vista rappresenta tutti i download specificando quale utente lo ha effettuato, in quale data e

da quale particolare host è avvenuto. La creazione di questa vista è motivata dall'importanza


statistica e amministrativa di questi dati.

Vista view_state_decision

Codice SQLCREATE VIEW view_state_decision ASSELECT fuid,mail_address,f_name,l_name,User.affiliation AS

user_affiliation, date_registration,Host.ip,name_host, Host.affiliation,country

FROM User INNER JOIN HostWHERE status='DECISION';

Tabella 3.6: codice della definizione della vista view_state_decision

La vista rappresenta tutti gli utenti cui lo stato di registrazione è uguale a DECISION, per il

significato di tale stato si vedano specifiche Sottocapitolo 1.1 , riportando gli attributi che lo

identificano e l'informazione completa riguardo all'host da cui ha effettuato la richiesta di

registrazione. L'importanza di questa informazione è rilevante per l'amministratore del sito.

Vista view_download_stat

Codice SQLCREATE VIEW view_download_stat ASSELECT YEAR(date_time) AS year, MONTH(date_time) AS month, COUNT(*) AS total, COUNT(DISTINCT fuid) AS

user_unique_download FROM DownloadGROUP BY YEAR(date_time),MONTH(date_time);ORDER BY YEAR(date_time) ASC,MONTH(date_time) ASC

Tabella 3.7: codice della definizione della vista view_download_stat

In questa vista vengono rappresentate le quantità, divise per anno e per mese, dei download

effettuati.

Si considerano due quantità: tutti i download effettuati in uno specifico mese di uno specifico

anno e nello stesso periodo si contano quanti utenti hanno scaricato, descritta in SQL da

COUNT(DISTINCT fuid).


Vista view_registration_stat

Codice SQLCREATE VIEW view_registration_stat AS

SELECT YEAR(date_registration) AS year,MONTH(date_registration) AS month, COUNT(*)as total

FROM UserWHERE status<>'DECISION'GROUP BY YEAR(date_registration),MONTH(date_registration)ORDER BY YEAR(date_registration) ASC,MONTH(date_registration)

ASC;

Tabella 3.8: codice della definizione della vista view_registration_stat

La vista rappresenta la quantità di registrazioni avvenute divise per anno e per mese. Gli

utenti devono essere in uno stato diverso da DECISION perchè come da specifiche l'utente

non è considerato registrato se è in questo stato.

Funzione read_interest

Il codice della funzione read_interest è descritto nella tabella 3.9

CREATE DEFINER = 'site_admin'@'localhost' FUNCTION read_interest(user VARCHAR(20)) RETURNS VARCHAR(2000) BEGIN

DECLARE num INT DEFAULT 0; DECLARE end_rows INT DEFAULT 0; DECLARE user_int VARCHAR(2000) DEFAULT ''; DECLARE temp_int VARCHAR(100); DECLARE cur CURSOR FOR SELECT name_interest

FROM Interest where fuid = user;

DECLARE CONTINUE HANDLER FOR NOT FOUND SET end_rows = 1; scansiono gli interessi OPEN cur ; REPEAT

SET temp_int=''; FETCH cur INTO temp_int; aggiungo il carattere separatore solo se non è il primo elemento IF num > 0 THEN

SET user_int = CONCAT(user_int,'|'); END IF; concatenazione col nuovo interesse trovato SET user_int= CONCAT(user_int,temp_int); SET num = num+1;


UNTIL end_rows END REPEAT; CLOSE cur; RETURN user_int;

END;

Tabella 3.9: codice della funzione read_interest()

Questa funzione viene utilizzata dall'applicazione web per la visualizzazione del profilo

utente. Preleva tutti gli interessi dell'utente specificato in argomento e restituisce una stringa

contenente tutti gli interessi divisi da un separatore (” | ” nel codice).

3.2.2 Sicurezza

L'accesso alla base di dati è consentito solo a due tipi di utenti: amministratore della base di

dati e amministratore del sito web, che sono a tutti gli effetti utenti del DBMS.

L'amministratore della base di dati

Questo tipo di utente ha il completo controllo sulla base di dati. L'utilizzo di questo utente

deve essere limitato solo in casi in cui è necessario alterare la struttura del database, è

fortemente sconsigliato l'utilizzo di questo tipo di utente per interagire12 col sito internet, per

evitare che errori di programmazione all'interno del codice del sito web comportino

alterazioni strutturali nella base di dati.

L'amministratore del sito web

Possiede permessi limitati alla gestione dei dati (inserimento, modifica, aggiornamento e

12 L'interazione tra sito web realizzato in PHP e il database avviene attraverso una connessione TCP dal web server Apache al server MySQL. Nei parametri della connessione devono essere specificati l'utente e la password con i quali si vole connettersi al server.


cancellazione). Inoltre possiede i permessi di esecuzione della funzione read_interest.

Questo tipo di utente può essere utilizzato per l'interazione con il sito web.

L'utente registrato nel sistema non possiede invece alcun utente a livello DBMS, in quanto si

è preferito evitare la creazione di un account per ogni utente con un maggiori restrizioni e

controlli di sicurezza.

L'autenticazione e autorizzazione degli utenti è lasciata alla parte web che verrà descritta nel

successivo sottocapitolo. La sicurezza nel controllo degli accessi è stata spostata a livello

dell'implementazione in PHP del sito web.

3.3 Architettura software

In questo sottocapitolo verranno presentati tutti i moduli realizzati suddivisi in sezioni. Per

ogni modulo verranno descritti funzionalità, interazione tra i moduli e dettagli implementativi

rilevanti.

Le componenti realizzate sono le seguenti:

– modulo di interazione con la base di dati

– modulo di autenticazione (login)

– modulo download pacchetti

– modulo di ricerca avanzata degli utenti

La struttura generale del nuovo sistema e l'interazione tra i moduli sono rappresentate nella

Figura 3.1, che mette in risalto i cambiamenti rispetto al vecchio sistema rappresentato in

Figura 1.1


Durante l'implementazione si è cercato di riutilizzare il più possibile il codice delle funzioni

già presenti nell'applicazione, al fine di massimizzare la compatibilità e mantenere

un'architettura coerente con la struttura dei moduli presenti.

Nelle funzionalità modificate solo nella parte riguardante l'interfaccia con la base di dati,

sono state sostituite le chiamate di funzione all'interfaccia con la vecchia base di dati con la

creazione di query SQL specifiche e con chiamate alle funzioni contenute nel modulo di

interazione con la base di dati descritto in seguito.

Le modifiche apportate non hanno intaccato la struttura base dell'applicazione web.

Figura 3.1: struttura generale del sistema


3.3.1 Interazione base di dati

Questo modulo costituisce l'interfaccia tra la base di dati e l'applicazione web. Tutte le

funzioni implementate in questo modulo vengono richiamate ogni qual volta sia necessario

l'accesso ai dati contenuti all'interno della base di dati.

Le funzionalità implementate sono:

– apertura della connessione con la base di dati

– chiusura della connessione con la base di dati

– esecuzione di query

– esecuzione di una transazione

– sincronizzazione dei dati con la vecchia base di dati

Per lo sviluppo è stato utilizzato il modulo di interfaccia tra PHP e MySQL che è un

componente delle librerie di PHP13.

L'apertura e la chiusura della connessione sono semplici wrapper creati al fine di gestire

potenziali errori che potrebbero occorrere durante l'esecuzione delle funzioni di libreria.

La funzione di esecuzione delle query è in grado di gestire i quattro principali tipi di query di

manipolazione dati: insert, delete, upadate e select. Il flusso di esecuzione è differente a

seconda che sia un'interrogazione alla base di dati oppure inserimento, cancellazione e

modifica dei dati.

La funzione che gestiste l'esecuzione di una transazione14 è stata creata in quanto MySQL

rifiutava una stringa unica contenente tutte le operazioni, che sono infatti inserite all'interno

13 La libreria per la gestione dei database MySQL non è direttamente installata nel core di PHP, ma necessita l'installazione di un pacchetto aggiuntivo vedi pagina internet: “http://it.php.net/manual/en/book.mysql.php”.

14 Una transazione è un programma in esecuzione che forma un'unità logica di elaborazione sulla base di dati. [14]Paragrafo 15.1.2.


di un vettore PHP. Tale vettore viene processato sottoponendo al DBMS l'operazione, se

l'esecuzione avviene con successo si continua l'iterazione sul vettore altrimenti viene eseguita

un'operazione di rollback. Se nessun errore è occorso allora viene eseguita un'operazione di

commit. Rollback e commit vengono esplicitamente sottoposte al DBMS tramite codice

PHP.

Il funzionamento della funzione di sincronizzazione con la vecchia base di dati è descritto

nella Figura 3.2.

La criticità in termini prestazionali sta nell'invio di due richieste DNS (al passo 2.3) per ogni

nuovo indirizzo IP trovato che richiedono un tempo molto variabile da una richiesta e l'altra,

dipendente dalla presenza nelle cache degli apparati di rete dei record DNS richiesti.

Al passo 2.1 avviene il controllo dell'esistenza dell'indirizzo mail, rispettando quanto detto

nei requisisti, in cui viene specificato che non possono esistere due utenti con lo stesso

indirizzo di posta elettronica (vedi Capitolo 1).

L'elaborazione dei risultati della transazione permette all'amministratore di conoscere il

successo o il fallimento dell'operazione, il tempo impiegato per eseguire la sincronizzazione,

il numero di nuovi utenti trovati e quanti effettivamente inseriti per via dei possibili duplicati

di mail.

L'implementazione suppone che la base di dati da cui vengono estratti i dati sia coerente e che

i formati dei campi siano quelli documentati alla Sezione 1.2.1. L'ordine con cui vengono

inserite le query all'interno del vettore della transazione è fondamentale per garantire

l'integrità referenziale tra le tabelle della base di dati (si veda Sezione 2.2.2).

3.3.2 Procedura di autenticazione


La procedura consente ad un utente di autenticarsi al sistema fornendo le proprie credenziali

tramite form web. L'autenticazione viene gestita attraverso una pagina non accessibile

all'utente per motivi di sicurezza. Tale pagina richiama l'effettiva procedura di autenticazione

che è descritta nella Figura 3.3. Se l'autenticazione è avvenuta con successo si procede con

l'aggiornamento dei dati dell'ultimo accesso e il settaggio delle variabili di sessione15. Al

passo 4 la procedura verifica il tipo di password attivando 2 differenti metodi di controllo

della password. Se si tratta del nuovo tipo semplicemente controlla la password con quella

presente nella base di dati, se invece il tipo è vecchio il sistema effettua una richiesta HTTP

ad una zona protetta usando i file htaccess di Apache16( passo 5 ). Se l'accesso viene

autorizzato la password viene cifrata col nuovo algoritmo e vengono modificati i dati

dell'utente ( passo 6 ).

Questa implementazione permette di avere un gestione trasparente dell'accesso di vecchi e

nuovi utenti, durante la realizzazione del sistema il passo 5 non era eseguito dal sistema, ma

era semplicemente gestito tramite una redirezione alla zona protetta. All'utente compariva una

finestra popup nella quale veniva richiesto il reinserimento di username e password. Una

volta inserite le credenziali queste venivano memorizzate nella cache del browser fino alla

sua chiusura. In caso di accesso dallo stesso browser di utenti differenti ( sempre di vecchio

tipo ) le credenziali che venivano passate erano quelle presenti nella cache, senza la

visualizzazione della finestra popup, questo comportava che ai passi 2 l'utente si presentava

con le credenziali inserite nel form web, invece al passo 5 si presentava con le credenziali del

15 Le variabili di sessione impostate sono: validUser ( a valori boolean indica utente valido autenticato) e userName(username dell'utente autenticato).

16 Vedi nota 7 per l'utilizzo di HTTP e nota 4 per le zone protette del web server Apache.


precedente utente presenti nella cache. Per evitare questo problema di sicurezza il passo 5 è

stato modificato con una gestione automatica da parte del sistema.

Figura 3.3: diagramma funzionamento della procedura di autenticazione

Figura 3.2: diagramma funzionamento procedura di sincronizzazione con la vecchia base di dati


3.3.3 Modulo download pacchetti software

L'implementazione di questa funzionalità ha due obiettivi: soddisfare i requisiti dei ricercatori

di tenere traccia dei download effettuati con successo e permettere all'utente di continuare la

navigazione all'interno del sito web durante lo scaricamento dei pacchetti.

Nell'applicazione web la persistenza tra le richieste HTTP è gestita tramite le sessioni

PHP[15], permettendo l'identificazione dell'utente che intende effettuare il download tramite

una variabile definita all'interno del vettore di sessione. Una prima implementazione

realizzata riusciva a raggiungere solo il primo dei due obiettivi preposti, infatti l'utente non

riusciva a continuare la navigazione all'interno del sito sino al termine della procedura di

download. Tale problema era dovuto al fatto che qualunque richiesta successiva fatta

dall'utente al web server, veniva riconosciuta come appartenente alla stessa sessione nella

quale era già in esecuzione un'altra richiesta, cioè lo scaricamento del pacchetto e veniva

quindi accodata. Per ovviare a questo problema durante la procedura di download la sessione

PHP è disabilitata, rendendo cosi' ogni richiesta di download indipendente dal contenuto della

variabile di sessione. Questa implementazione permette di raggiungere entrambi gli obiettivi,

ma comporta l'introduzione di alcuni accorgimenti di sicurezza che verranno descritti in

seguito.

Il diagramma di funzionamento della procedura è descritto nella Figura 3.4.


Al passo 1 vengono controllati i permessi dell'utente utilizzando come chiave il valore

contenuto nella variabile di sessione. I problemi di sicurezza sorgono nel momento in cui le

funzionalità della sessione PHP vengono disabilitate, in quanto ogni richiesta è anonima (nel

senso che non appartiene a nessun utente che ha effettuato la procedura di autenticazione) e

quindi chiunque potrebbe richiedere il download del file, costruendo una richiesta HTTP ad

hoc, vanificando cosi' la sicurezza introdotta dalla procedura di login e dal controllo dei

permessi al passo 1. Per ovviare a questo problema è stato introdotto un campo aggiuntivo al

form, i cui dati sono inviati tramite il metodo POST, della pagina di download (trattasi della

nuova finestra visualizzata dopo il passo 3), che specifica quale utente abbia intenzione di

scaricare il pacchetto. Tali contromisure non bastano in quando il nome utente è visualizzato

in chiaro nel codice della pagina web, quindi i valori dei campi vengono cifrati utilizzando

una cifratura tramite l'uso dell'algoritmo a chiave simmetrica Blowfish[16] utilizzato nella

Figura 3.4: diagramma di funzionamento della procedura di download


modalità CFB17. Questa cifratura unita all'utilizzo del protocollo HTTPS[9] consente di

risolvere i problemi di sicurezza esposti sino ad ora. Come ulteriore misura al passo 6

vengono nuovamente controllati i permessi dell'utente, ma differentemente da quanto

avveniva al passo 1, viene usato come chiave il valore contenuto nel parametro di POST.

Al passo 7 avviene il download vero e proprio utilizzando la funzione della libreria

http_send_file della libreria PECL. Se la funzione termina con successo vengono inseriti i dati

all'interno della tabella Download.

3.3.4 Modulo di ricerca avanzata

Questo modulo consente all'amministratore del sistema di effettuare ricerche avanzate sulla

lista degli utenti registrati. Per questa funzionalità è stata realizzata un'interfaccia grafica, con

controllo della correttezza e consistenza degli input lato client realizzato in JavaScript.

Attraverso quest'interfaccia l'amministratore seleziona i campi di interesse rendendo dinamica

e personalizzabile la ricerca di particolari categorie di utenti.

La generazione della lista degli utenti è gestita totalmente dalla procedura descritta nella

Figura 3.5.

Il passo 1 riceve in input l'argomento POST della richiesta HTTP il quale è strutturato in

modo tale da consentire alla procedura di riconoscere quali tabelle e quali campi sono

coinvolti nella ricerca. Tale meccanismo è stato realizzato nominando in modo opportuno i

campi del form HTML di ricerca secondo il seguente formato:

17 CF B acronimo di Cipher Feedback è una delle modalità di cifratura a blocchi per algoritmi a chiave simmetrica.


tipo_nomeTabella_nomeCampo, rispettivamente il tipo di box all'interno del form18,

una delle tabelle contenute nella base di dati e nome del campo relativo alla specifica tabella.

In questa fase di implementazione si preferito mantenere indipendenti i nomi presenti nel

form HTML dai nomi presenti nella base di dati. A tale proposito è stato creato un vettore che

funziona da wrapper tra l'applicazione e la base di dati. Il passo 1 al termine dell'esecuzione

restituisce una vettore nel quale sono contenute le tabelle interessate, i campi e i loro valori.

Al passo 2 avviene la generazione effettiva della query SQL secondo i parametri della

ricerca. Riceve in input il risultato del passo 1 e immediatamente verifica le condizioni di join

tra le tabelle interessate, processa i valori dei campi convertendoli nel formato adatto alla

base di dati (essenziale per i campi contenenti valori di data e ora).

Al passo 2.3 si verifica la presenza di casi eccezionali che comportano il cambiamento delle

condizioni di join precedentemente inserite. Durante la fase di testing di questa procedura si è

rivelato necessario gestire un solo caso particolare, cioè il caso in cui l'amministratore scelga

di trovare gli utenti che non hanno effettuato lo scaricamento dei pacchetti, in questo caso la

condizione di where conteneva la seguente stringa “WHERE User.fuid NOT IN

(SELECT fuid FROM Download)” eliminando la condizione di join tra la tabella

User e Download.

Il passo 3 è semplicemente l'esecuzione della query generata al passo precedente utilizzando

le funzioni descritte sopra nella Sezione 3.2.1. Il passo 4 genera il codice HTML della lista

ottenuta processando il risultato dell'esecuzione della query.

18 Di tutti i box esistenti sono stati usati solo checkBox e selectBox guidando quindi l'utente nella selezione dei valori dei campi, facilitando da un lato il controllo di consistenza e dall'altro evitando l'inserimento da parte dell'utente di stringhe arbitrarie.


Figura 3.5: diagramma di funzionamento della procedura di ricerca e generazione della lista utenti

Capitolo 4 45

Capitolo 4

Esempi d’uso

In questo capitolo verranno presentati alcuni esempi d'uso dell'applicazione web attraverso

schermate realizzate durante la fase di testing. Le schermate sono state scelte selezionando le

funzionalità che hanno comportato un cambiamento nell'interfaccia web.

4.1 Funzionalità di ricerca avanzata

Nella figura 4.1 è rappresentata la funzionalità di ricerca avanzata effettuata

dall'amministratore realizzata in JavaScript.

Figura 4.1: schermata della ricerca avanzata

Esempi d’uso 46

L'interfaccia risulta semplice, intuitiva e da la possibilità all'amministratore di effetture

ricerche anche articolate utili per monitorare gli utenti.

Il risultato della ricerca effettuata è rappresentato nella Figura 4.2

4.2 Funzionalità di download dei pacchetti software

Nella figura 4.3 rappresenta una schermata dell'area di download pacchetti, l'utente ha già

Figura 4.2: risultato della ricerca

Figura 4.3: pagina di download pacchetti

Esempi d’uso 47

selezionato il pacchetto software e gli è apparsa una finestra dalla quale iniziare lo

scaricamento.

Il messaggio della finestra conferma che l'utente ha i permessi per scaricare questo tipo di

file, in caso contrario l'unica azione possibile sarà la chiusura di tale finestra.

Nella Figura 4.4 è riportato il codice della pagina relativa alla finestra popup nella quale i

campi nascosti del form HTML sono cifrati.

4.3 Funzionalità di sincronizzazione con il vecchio archivio dei dati

Nella Figura 4.5 è rappresentato il risultato della funzione di sincronizzazione tra la vecchia e

la nuova base di dati. Viene riportato nella schermata di output il risultato di successo o

fallimento, quanti nuovi utenti sono stati trovati, quanti inseriti e quanti indirizzi mail

duplicati sono state travati. Per la parte riguardante la tempistica di esecuzione si noti l'elevata

differenza tra la generazione della transazione rispetto alla sua esecuzione, dovuta alle

richieste DNS effettuate duranti la sua creazione.

Figura 4.4: codice HTML della pagina

Esempi d’uso 48

Figura 4.5: risultato della procedura di sincronizzazione

49

Conclusioni e sviluppi futuri

La realizzazione del modulo di ricerca avanzata ha soddisfatto le esigenze di ottenimento di

maggiori dati statistici ai fini della comprensione della diffusione del software di simulazione

FLUKA, per ottimizzarne i contenuti.

Con il sistema realizzato è ora possibile controllare la distribuzione dei pacchetti risalendo

all'utente che ha effettuato il download, da quale indirizzo IP e che pacchetto ha richiesto,

attraverso la gestione dei dati dello scaricamento da parte del sistema.

Attraverso la nuova procedura di autenticazione tutti gli utenti, anche quelli con il vecchio

tipo di password, possono accedere alle stesse funzionalità rendendo cosi' omogenea 'utilizzo

del sito. Inoltre la gestione delle differenze di password avviene in maniera trasparente

all'utente, evitando possibili difficoltà di comprensione nell'utilizzo dell'applicazione.

Il lavoro svolto è ora autosufficiente e rappresenta una nuova release del sistema che è

utilizzabile da subito. I ricercatori stanno valutandolo in fase di test per una introduzione in

produzione a breve.

Tra i miglioramenti futuri, si potrebbero realizzare strumenti atti ad automatizzare la

generazione di statistiche, attraverso la creazione di moduli che gestiscano la creazione

automatica di grafici sfruttando i dati contenuti nella base di dati. La progettazione di tali

moduli dovrà essere preceduta da una accurata analisi di quali statistiche sono rilevanti per il

Conclusioni e sviluppi futuri 50

gruppo di ricercatori.

Un altro sviluppo futuro proposto consiste nell'eseguire un'analisi del carico di rete del web

server in modo tale da dimensionare la banda utilizzata durante lo scaricamento dei pacchetti

software.lo steering dei progetti in corso, ovvero modifiche al piano di lavoro inizialmente

concordato anche sulla base delle metriche raccolte.

Bibliografia

[1]: G. Battistoni, S. Muraro, P.R. Sala, F. Cerutti, A. Ferrari,S. Roesler, A. Fasso`, J. Ranft,

The FLUKA code: Description and benchmarking, 2007

[2]: A. Fasso`, A. Ferrari, J. Ranft, and P.R. Sala, FLUKA: a multiparticle transport code,

2005

[3]: Database Ripe, http://www.ripe.net/db/index.html

[4]: T. BernersLee, R. Fielding , H. Frystyk, RFC 1945 Hypertext Transfer Protocol

HTTP/1.0

[5]: Red Hat Enterprise, http://www.redhat.com/rhel/server/

[6]: Apache 2.0, http://httpd.apache.org/docs/2.0/

[7]: PHP home page, www.php.net

[8]: JavaScript, http://it.wikipedia.org/wiki/JavaScript

[9]: HTTPS, http://www.ietf.org/rfc/rfc2818.txt

[10]: PECL HTTP, http://it.php.net/manual/en/book.http.php

[11]: MCrypt, http://mcrypt.sourceforge.net/

[12]: MySQL 5.0, http://dev.mysql.com/doc/refman/5.0/en/

[13]: MySQL, InnoDB storage engine, http://dev.mysql.com/doc/refman/5.0/en/innodb.html

[14]: Ramez A. Elmasri, Shamkant B. Navathe, Sistemi di basi di dati Fondamenti, 2007

[15]: PHP, PHP session,http://www.php.net/manual/en/book.session.php

[16]: Bruce Schneier, Blowfish, http://www.schneier.com/blowfish.html

analisi ed ottimizzazione base dati di un server web per ... analisi ed ottimizzazione base dati di...

Documents