__
Università degli studi di Ferrara
Indice
1.
Introduzione .................................................................................................... 3
2.
Il progetto dell’applicazione “Fatture On-Line”................................................ 6
2.1.
La vecchia applicazione del Comune per la gestione delle fatture ..........6
2.2.
Specifiche e requisiti del progetto ............................................................9
2.3.
Architettura Generale del sistema..........................................................10
2.4.
Sistema di autenticazione ......................................................................11
2.5.
Livelli di autorizzazione ..........................................................................13
2.6.
Architettura Base di dati .........................................................................14
2.7.
Architettura filesystem............................................................................15
2.8.
Interfaccia Web ......................................................................................17
2.9.
Struttura pagine Web .............................................................................18
3.
Accessibilità .................................................................................................. 21
4.
Tecnologie utilizzate ..................................................................................... 25
5.
4.1.
SQL e Microsoft SQL Server..................................................................25
4.2.
Server Web Apache ...............................................................................26
4.3.
HTML e CSS ..........................................................................................29
4.4.
PHP........................................................................................................31
4.5.
JavaScript ..............................................................................................33
Realizzazione della nuova applicazione....................................................... 37
5.1.
Architettura della rete del Comune.........................................................37
5.2.
Tabelle database....................................................................................38
5.3.
Sistema di autenticazione ......................................................................42
5.4.
Interfaccia web .......................................................................................49
5.5.
Struttura script........................................................................................50
5.6.
Ricerca e visualizzazione.......................................................................51
5.7.
Accessibilità e stampa............................................................................55
5.8.
Amministrazione utenti e fornitori...........................................................57
5.9.
Statistiche...............................................................................................59
5.10.
Altre Funzionalità ................................................................................61
5.11.
Test del servizio ..................................................................................65
1
__
Università degli studi di Ferrara
6.
Conclusioni ................................................................................................... 66
7.
Riferimenti..................................................................................................... 67
8.
Indice delle figure.......................................................................................... 68
2
__
Università degli studi di Ferrara
1. Introduzione
Le Pubbliche Amministrazioni (PA), sono responsabili della gestione dei
dati dei cittadini e offrono servizi per la loro consultazione. I cittadini ne possono
usufruire di persona tramite gli sportelli comunali, o a distanza utilizzando i
servizi telefonici o accedendo al Web.
Negli ultimi anni le P.A. hanno colto l’importanza dei moderni mezzi di
comunicazione intraprendendo sempre più progetti riguardanti il mondo di
Internet, data la sua utilità come strumento di comunicazione che permette di
raggiungere in modo più efficiente i cittadini.
Affinché i servizi Web siano facilmente utilizzabili dai cittadini, si devono
tenere in considerazione le caratteristiche di usabilità e accessibilità per
permettere al maggior numero di utenti di poter usufruire dei servizi. Inoltre si
devono tenere in considerazione le persone disabili che necessitano, per non
essere penalizzate nell’utilizzo, di interfacce adeguate così da riuscire a servirsi
a pieno dei sevizi messi a loro disposizione. Il problema dell’accessibilità è stato
valutato a livello nazionale, ed è stata introdotta nel 2004 la legge Stanca, la
quale pone i requisiti che i servizi web delle P.A. devono offrire per poter essere
considerati sufficientemente accessibili. Essa specifica inoltre le caratteristiche
che devono presentare i servizi, in base alle tecnologie impiegate, alla tipologia,
allo scopo e agli strumenti utilizzati per accedervi, inoltre definisce le linee guida
per la presentazione dei contenuti come testo, colori, suoni, video e animazioni.
Il Comune di Cento è uno dei comuni più informatizzati d’Italia, offre un
portale per i cittadini, con comunicazioni, eventi e molto altro ed è presente nel
Web ormai da molto tempo, prima ancora dell’introduzione della legge Stanca.
Questo ha determinato, negli ultimi anni, lavori di ristrutturazione del portale del
comune e dei suoi servizi in modo da rendere i contenuti più funzionali e
accessibili.
Questa tesi descrive la progettazione e realizzazione del rinnovo e
ampliamento del servizio “Fatture On-Line” precedentemente offerto dal comune,
risultato ormai inadeguato avendo limiti di funzionalità, come la creazione della
base di dati utilizzata e alcune funzionalità scarse o mancanti, ma soprattutto di
3
__
Università degli studi di Ferrara
accessibilità. Il risultato è una nuova versione, più completa, più funzionale e
provvista di una interfaccia rispettante i requisiti di usabilità e le normative di
accessibilità.
Il servizio “Fatture On-line” ha come scopo principale quello di offrire ai
fornitori e ai dipendenti del Comune la possibilità di consultare le fatture.
L’accesso è suddiviso in due sezioni: una per i fornitori che permette la
consultazione, la ricerca delle proprie fatture e la visualizzazione dei dettagli; e
una per i dipendenti del comune, che permette la consultazione, la ricerca di
tutte le fatture e la visualizzazione delle informazioni sui fornitori. E’ presente
un’ulteriore sezione di amministrazione a cui possono accedere solo un gruppo
ristretto di utenti, nella quale è possibile gestire gli utenti interni e l’accesso per i
fornitori.
Il progetto, che ha preceduto la realizzazione dell’applicazione, è partito
con l’ampliamento della struttura del database già utilizzato: oltre ai dati delle
fatture e dei fornitori sono stati considerati anche quelli degli utenti, in questo
modo è possibile consentire, limitare o negare l’accesso, identificando gruppi di
utenti e i relativi privilegi. Sono stati individuati due gruppi principali: Utenti di
Dominio,
suddivisi
in
tre
livelli,
con
privilegi
crescenti
per
separare
l’amministrazione dalla sola consultazione, e Utenti Fornitori con accesso limitato
alla consultazione delle fatture di un singolo fornitore. Un ulteriore passo del
progetto è stato quello della sicurezza, progettando il filesystem in maniera tale
da separare la parte accessibile ai fornitori da quella dedicata ai dipendenti del
comune, e la realizzazione di un sistema di accesso sicuro. Nel corso del
progetto si è prestata particolare attenzione all’accessibilità e usabilità
dell’applicazione (uno dei motivi principali di questo progetto) progettando
un’interfaccia semplice ma nello stesso tempo funzionale e, per quanto possibile,
esente da limitazioni per utenti disabili, ad esempio utilizzando colori con
contrasti adeguati, access key per la facile fruizione del servizio con l’ausilio
della sola tastiera. Infine è stata progettata un’architettura di base degli script per
la facile realizzazione e manutenzione dell’applicazione.
A questo punto si è passati alla fase di realizzazione, mettendo in pratica
le idee, gli schemi e le procedure ideate in fase di progettazione. Sono state
4
__
Università degli studi di Ferrara
create le tabelle necessarie, è stato sviluppato il sistema di autenticazione e
sono state implementate nuove funzionalità di ricerca, amministrazione e
statistica.
Questa tesi è il frutto di un tirocinio svolto presso il Servizio Sistemi
Informativi (SSI) del Comune di Cento che si occupa della gestione e
amministrazione hardware e software della rete civica, l’amministrazione della
intranet comunale, del portale del Comune, la gestione e realizzazione di servizi
on-line e siti Web strettamente collegati al Comune.
5
__
Università degli studi di Ferrara
2. Il progetto dell’applicazione “Fatture On-Line”
Il progetto prevede lo sviluppo di un sistema per la consultazione dei
fornitori e delle fatture via web, chiamato “Fatture On-Line”, comprendente
un’interfaccia web a uso degli utenti interni e dei fornitori dell’ente per il
monitoraggio delle fatture di fornitura, dalla loro registrazione al pagamento.
Viene creata un’ulteriore interfaccia di amministrazione per la gestione degli
utenti. Tutte le interfacce vengono create nel rispetto delle norme di accessibilità
ed usabilità previste per la P.A..
L’applicazione è suddivisa in due sezioni, una per l’accesso degli utenti
esterni (fornitori), e una per l’accesso degli utenti di dominio (dipendenti del
comune). La prima modalità di accesso permette ai fornitori del comune di Cento
di poter cercare e visualizzare le proprie fatture, mostrandone i dettagli e lo stato
in cui si trovano. La seconda modalità permette ai dipendenti del comune di
poter cercare e visualizzare tutte le fatture e relativi dettagli con la possibilità di
gestire l’accesso dei fornitori al servizio.
2.1.
La vecchia applicazione del Comune per la gestione delle fatture
Il Comune di Cento, sensibile al discorso Web, ha creato un portale per
offrire ai cittadini, con un nuovo approccio, i propri servizi. Tra questi servizi è
presente un applicativo Web per la gestione delle fatture on-line in cui sono
molto evidenti le limitazioni di utilizzo e di gestione del servizio, che non erano
state previste o risolte nella progettazione precedente:
-
l’applicazione permetteva di visualizzare le fatture dell’anno in corso e dei
due anni precedenti, il numero degli anni in cui considerare le fatture era
impostato a mano con cadenza annuale, in una fase di batch che genera
la base di dati finale;
-
non esisteva un accesso specifico per gli utenti interni alla sede del
comune e mancava una sezione di amministrazione adeguata;
-
non c’era una gestione dei fornitori ( ad esempio non si poteva cambiare la
password di un fornitore );
6
__
-
Università degli studi di Ferrara
la procedura di conversione e preparazione della base di dati utilizzata dal
servizio web ( fase di batch ) era molto lunga:
o estrapolazione dei dati dal database del gestionale su macchina
unix in un file di testo;
o una macchina Windows si prendeva carico di importare il file di testo
e caricarlo in un database Access;
o ulteriore normalizzazione e associazione dei dati come fatture e
dettagli;
o conversione database Access in un database PostgreSQL.
-
interfaccia web non rispettante le normative sull’accessibilità e usabilità
per la P.A;
-
interfaccia web non rispettante le caratteristiche di usabilità.
Dalle immagini di figura 1,2 e 3, si può notare come l’applicazione presenta
colorazioni non idonee, e non dispone di un interfaccia abbastanza intuitiva.
Questi particolari sono stati dei motivi più che sufficienti per decidere di
riorganizzare e aggiornare il servizio, da questo nasce anche l’esigenza di creare
una nuova interfaccia più efficiente e funzionale.
Figura 1: Pagina principale di accesso al servizio
7
__
Università degli studi di Ferrara
Figura 2: Pagina di ricerca
Figura 3: Risultati ricerca
8
__
2.2.
Università degli studi di Ferrara
Specifiche e requisiti del progetto
Le specifiche del progetto sono diverse per gli utenti di dominio e per i fornitori:
La parte di accesso per gli utenti di dominio prevede:
-
4 livelli di autenticazione ( Dominio, Utente, Amministratore e Super
Amministratore );
-
visualizzazione di tutte le fatture;
-
ricerca per fattura;
-
ricerca per fornitore;
-
sezione
di
BackOffice
per
l’amministrazione
del
servizio
che
comprende:
o amministrazione accesso fornitori;
o amministrazione permessi utenti di dominio;
o statistiche accessi.
La parte riguardante i fornitori prevede:
-
accesso solo previa abilitazione del servizio;
-
cambio Password al primo utilizzo;
-
cambio password allo scadere di 60 giorni dall’ultimo accesso;
-
visualizzazione delle proprie fatture;
-
ricerca delle proprie fatture;
-
possibilità di invio modulo di richiesta informazioni su una specifica
fattura.
L’intera applicazione rispetta le specifiche di accessibilità e usabilità,
permettendo la consultazione del servizio anche a utenti disabili senza particolari
disagi, utilizzando programmi specifici come lettori audio di testo per non
vedenti, o altre tipologie di programmi, e periferiche di visualizzazione che
supportano risoluzioni diverse.
9
__
2.3.
Università degli studi di Ferrara
Architettura Generale del sistema
L’applicazione prevede un’architettura generale su cui basarsi, e da cui
partire per la progettazione delle singole parti. Ogni singola parte offre
un’interfaccia per poter comunicare con le atre, in modo tale da ottenere un
approccio modulare che consenta di sostituire o modificare un singolo elemento,
senza dover eseguire correzioni in altri componenti.
In figura 4 è rappresentato lo schema generale del servizio, in cui
possiamo trovare i vari blocchi che compongono il sistema. L’interfaccia Web,
accessibile con l’ausilio di un comune browser, rappresenta il tramite che
consente all’utente di dialogare con l’applicazione; da qui è possibile scegliere se
accedere alla sezione dedicata agli utenti di dominio tramite l’autenticazione di
dominio, oppure accedere alla sezione pubblica tramite il sistema di
autenticazione e codifica. Solamente dalla sezione di dominio è possibile
accedere alla sezione di amministrazione. Nella figura è presente un blocco
chiamato “APPLICAZIONE Fatture On-Line” che rappresenta il cuore del
servizio, questo contiene le implementazioni delle funzionalità e ne permette la
fruizione grazie alla comunicazione con il server Web e con un database che
contiene i dati per l’utilizzo del servizio.
Figura 4: Schema generale del servizio
10
__
2.4.
Università degli studi di Ferrara
Sistema di autenticazione
Il sistema di autenticazione è una parte molto importante che permette di
proteggere l’accesso alla visualizzazione di informazioni riservate. E’ suddiviso in
due sezioni: una sezione di accesso per gli utenti di dominio, e una per l’accesso
pubblico. L’autenticazione della sezione riguardante gli utenti di dominio è
demandata ad Active Directory [Microsoft Active Directory], che si occupa di
proteggere le macchine all’interno della rete del comune e la protezione di aree
riservate ai soli utenti di dominio.
Riguardo all’autenticazione della sezione di accesso pubblico, è stata adottata
una doppia protezione: una basata su Apache e l’altra basata su script PHP e
database. La protezione di Apache permette l’accesso al sistema di
autenticazione vero e proprio, si è scelto di utilizzare un'unica coppia di nome
utente e password, perché questa protezione ha come unico scopo quello di
arginare i tentativi di forzatura del sistema da parte di persone che non hanno
fatto richiesta di accesso al servizio. La protezione basata su PHP e database
permette di autenticare l’accesso dei fornitori al servizio.
Sono stati presi in considerazione metodi diversi per la protezione delle
informazioni inserite dagli utenti. Tra questi si predilige l’utilizzo di SSL ( Secure
Socket Layer ) [Protocollo SSL] che permette, tramite una codifica a chiavi
pubblica e privata, di creare un canale di comunicazione sicuro tra client e
server, rendendo le intercettazioni della trasmissione non comprensibili e
difficilmente decodificabili. Purtroppo per problemi sui server del comune
(durante il corso del tirocinio) non è stato ancora possibile attivare la protezione.
Per arginare questo problema, sono stati presi in considerazione i metodi di
autenticazione “http” come “Basic” e “Digest”. L’autenticazione Basic codifica le
informazioni in ingresso, come nome utente e password, in Base64 e le invia al
server che provvederà a decodificarle e successivamente ad elaborarle.
L’autenticazione Digest è simile alla Basic a differenza del fatto che le
informazioni non vengono inviate direttamente, ma a lato client ne viene creato
un hash che successivamente verrà inviato al server per una comparazione con i
dati presenti nel database. Questi due metodi però permettono una limitata
11
__
Università degli studi di Ferrara
modifica della maschera di inserimento dati. Vista la necessità di un sistema che
ha bisogno di una personalizzazione della maschera di inserimento e che non
permetta la facile intercettazione e comprensione delle informazioni inviate, si è
provveduto a creare un metodo personalizzato.
E’ stato ideato un sistema che permette di salvaguardare le informazioni di
accesso ed evitare nei limiti del possibile l’intercettazione della comunicazione, e
l’utilizzo di queste informazioni al di fuori della sessione corrente. In ogni
sessione viene generata una chiave alfanumerica che ha la caratteristica di
essere univoca, e identifica la sessione corrente. Considerando che ogni volta la
chiave di sessione cambia, si è pensato di utilizzarla in fase di accesso al
servizio, dopo di che viene effettuato l’hash delle informazioni concatenate con la
chiave e inviate al server, che provvede a verificare l’autenticazione con le
informazioni reperite dal database. Il tutto è schematizzato in figura 5.
Oltre a questo, per aumentare la sicurezza, è stato aggiunto un sistema di
codifica per le informazioni sensibili non a conoscenza del server, come ad
esempio avviene nel cambio di una password. Il sistema precedentemente
descritto, non lo si può applicare a questa situazione, perché funziona solo se il
server è già a conoscenza dell’informazione che deve transitare. In questo caso,
la nuova password scelta dall’utente è sconosciuta al server e non la si può
criptare vista l’impossibilità di ricondursi ad essa, quindi, si è deciso di effettuare
una codifica lato client delle informazioni sensibili, tramite l’utilizzo di una chiave
random. Il tutto poi viene inviato dal client, successivamente decodificato ed
elaborato dal server. Il tutto è schematizzato in figura 6.
Figura 5: Schema di cifratura
Figura 6: Schema di codifica
12
__
2.5.
Università degli studi di Ferrara
Livelli di autorizzazione
Sono stati definiti 4 livelli di autorizzazione per la parte relativa all’accesso di
dominio, aventi le seguenti caratteristiche:
-
Dominio:
o Utente precedentemente autentificato nel dominio, che all’interno
del servizio è considerato come un utente senza autorizzazione (per
ora questo livello viene considerato come il livello “Utente” così che
tutti i dipendenti del comune possono accedere al servizio, è stata
prevista l’inabilitazione dell’autorizzazione “Dominio” nell’eventualità
che possano sorgere problematiche interne).
-
Utente:
o Utente con permessi di visualizzazione delle fatture di tutti i fornitori,
e con la possibilità di effettuare ricerche sia per fattura che per
fornitore.
-
Amministratore:
o Utente con accesso alla sezione di amministrazione e con i
permessi di gestione fornitori, e gestione limitata dei permessi degli
utenti di dominio.
o Permessi per la gestione delle scansioni delle fatture.
-
Super Amministratore:
o Utente con accesso completo a tutte le funzionalità del servizio.
( gestione fornitori, gestione completa permessi utenti di dominio,
visualizzazione statistiche, modifica impostazioni generali, gestione
scansioni fatture ).
Per quanto riguarda l’accesso da parte dei fornitori, è disponibile un unico livello
di autorizzazione che permette la visualizzazione delle proprie fatture e dei
dettagli a esse connesse.
13
__
2.6.
Università degli studi di Ferrara
Architettura Base di dati
La procedura batch che permetteva di estrapolare i dati dal database del
gestionale in un nuovo database, così da poter essere manipolati senza rischio,
è stata rinnovata e ridotta a due fasi:
-
Estrapolazione dei dati dal database del gestionale su macchina unix in un
file di testo
Le
Conversione da file di testo a database SQL Server
ottimizzazioni
e
le
normalizzazioni
vengono
ora
fatte
all’interno
dell’applicazione web.
Il database è costituito da 3 tabelle principali dove risiedono i dati dei
fornitori, delle fatture e dei dettagli delle fatture. Come possiamo notare dallo
schema di figura 7, con cadenza giornaliera, i dati provenienti dal database del
gestionale vengono salvati in un file di testo e, successivamente, utilizzati per
popolare le tabelle che verranno utilizzate dal servizio. Oltre a queste sono state
aggiunte, in questo progetto, altre 4 tabelle (vedere in figura 8) per la gestione
del servizio che permettono:
-
la gestione delle scansioni associate alle fatture;
-
la gestione dei permessi di dominio e accesso fornitori;
-
la registrazione degli accessi;
-
il settaggio di impostazioni globali per la configurazione del servizio.
Figura 7: Schema procedura Batch
14
__
Università degli studi di Ferrara
Le tabelle di gestione del servizio non sono collegate direttamente alle tabelle
principali con delle chiavi importate, questo per evitare cancellazioni o modifiche,
essendo le tre tabelle svuotate e ripopolate giornalmente.
Figura 8: Nuove tabelle per il sistema
2.7.
Architettura filesystem
Il filesystem è un altro aspetto che è stato curato per fornire un livello
maggiore di sicurezza. In prima analisi sono state create due cartelle separate
visibili in figura 9, una per l’accesso al servizio da parte degli utenti di dominio, e
l’altra per l’accesso dei fornitori. E’ stato fatto questo per poter sfruttare il
meccanismo di autenticazione di dominio, dando l’accesso alla prima cartella
solo a chi si è autentificato come utente di dominio, non potendo usare questo
metodo per la seconda cartella, si è optato per una doppia autenticazione
Apache / PHP-Database. La prima autenticazione è gestita dal server web
Apache, con una unica autorizzazione che viene comunicata solo ai fornitori che
richiedono il servizio, e serve principalmente per scongiurare eventuali tentativi
di ingresso con credenziali scelte a caso. La seconda autorizzazione è gestita
nella parte protetta dal dominio tramite una interfaccia web di amministrazione.
In seconda analisi si è passati alla struttura delle cartelle che conterranno il
servizio. Si è deciso di creare sia la cartella di dominio che quella per i fornitori
con la stessa struttura mostrata in figura 10.
Sono presenti 2 cartelle primarie, una con le classi base, che verranno
utilizzate per contenere i dati prelevati da database, e una con le librerie o parti
15
__
Università degli studi di Ferrara
che verranno incluse nelle pagine. Nelle
inclusioni troviamo le funzioni di
accesso al database, funzioni generiche, file di protezione, menu, ecc…
Solamente all’interno della parte di dominio troviamo una cartella dedicata
all’amministrazione, che al suo interno ha la stessa struttura precedentemente
descritta.
Figura 9: Schema struttura del filesystem principale
Figura 10: Schema struttura dettagliata del filesystem
16
__
2.8.
Università degli studi di Ferrara
Interfaccia Web
L’interfaccia web è un altro punto importante su cui soffermarsi, perché è il
tramite che permette all’utilizzatore di usufruire del servizio, quindi rendere
l’interfaccia intuitiva e di facile uso permette di ottimizzarne l’impiego. E’ stata
fatta una ricerca sulle specifiche relative all’accessibilità, da applicare
all’interfaccia per poter rispettare le normative, riuscendo a offrire un servizio
accessibile anche a utenti disabili. Inoltre si è cercato di mantenere, per quanto
possibile, l’interfaccia simile agli altri servizi, facilitando l’utilizzo omogeneo del
portale del comune (un esempio è visibile in figura 11 e figura 12).
Figura 11: Esempio di interfaccia del portale del comune
Figura 12: Esempio di interfaccia del servizio
17
__
2.9.
Università degli studi di Ferrara
Struttura pagine Web
Creare una struttura di base per le pagine web è importante, perchè
permette di facilitarne la creazione e la modifica. Tipicamente in una pagina se
ne includono altre, che possono contenere librerie di funzioni, classi o variabili,
oppure contenuti dinamici o statici. Questo permette di agevolare la modifica
dell’applicazione da parte di più persone, che possono agire su parti diverse
contemporaneamente, mantenendo un’interfaccia comune. Spesso si nota la
presenza di molte parti di un’applicazione che sono identiche o presentano
caratteristiche molto simili, con le inclusioni si può semplificare questa situazione
inserendo, in tutte le pagine che presentano caratteristiche simili, un file che
racchiude porzioni di codice dinamico, che, ad ogni chiamata, genera dei
contenuti che possono essere uguali, oppure offrire contenuti con sostanziali
differenze. Volendo fare un esempio, possiamo prendere in considerazione un
menù presente in tutte le pagine e, che in certe sezioni, le voci siano diverse
oppure che vengano visualizzate in base alle autorizzazioni dell’utente che
richiede la pagina. Per fare questo basta creare una porzione di codice che
genera un menù dinamico, il quale in base al tipo di richiesta mostri voci diverse
o tenga conto delle autorizzazioni, e includere questo file in ogni pagina, dove
queste ultime provvederanno a chiamare il menù passando i parametri adeguati.
In questo progetto si è scelto l’utilizzo dei template che permettono, una
volta creatone uno, di generare nuove pagine con una struttura di base da cui
partire. Se si modifica un template tutte le pagine create con esso possono
essere aggiornate automaticamente.
La figura 15 mostra com’è stato creato il layout delle pagine del servizio, questo
è costituito da quattro parti principali:
18
-
Header
-
Menu
-
Contenuto
-
Footer
__
Università degli studi di Ferrara
La sezione Header rappresenta la parte superiore della pagina in cui sono
contenuti:
-
Il Logo (vedi figura 13), presente in tutte le pagine:
Figura 13: Logo comune di Cento
-
L’intestazione dinamica (vedi figura 14):
Nell’intestazione troviamo il nome del servizio, in questo caso “Fatture On
Line”, il nome dell’utente collegato al servizio, il profilo dell’utente
(permessi) e la data dell’ultimo accesso.
Figura 14: Intestazione servizio, accesso di dominio
Figura 15: Layout pagine servizio
19
__
Università degli studi di Ferrara
La sezione Menù rappresenta il blocco in cui trovare i collegamenti alle varie
funzioni del servizio ed eventualmente può ospitare altre informazioni come una
legenda. La sezione Contenuto rappresenta il blocco in cui verranno visualizzati
tutti i contenuti del servizio. La sezione Footer rappresenta la parte inferiore della
pagina in cui sono contenute scritte descrittive e include la sezione “Access Key”
(esempio in figura 16). Nella sezione Access Key troviamo una parte importante
per l’acessibilità, cioè la legenda delle Access Key presenti nella pagina.
Figura 16: Footer con Access Key
20
__
Università degli studi di Ferrara
3. Accessibilità
L'accessibilità di un sito si ottiene tecnicamente rispettando le regole
dettate dal progetto Web Accessibility Initative (WAI) [WAI]: una iniziativa del
W3C [W3C], il consorzio mondiale che si occupa di standardizzare la
progettazione dei siti web. Le linee guida contenute nel progetto WAI,
consentono di realizzare un sito i cui contenuti e servizi siano fruibili da parte di
tutti gli utenti, anche coloro che hanno necessità particolari ed accedono al web
mediante dispositivi diversi dal monitor, tastiera o mouse. Rendere un sito
accessibile significa, dunque, permettere a chiunque di accedere pienamente ai
contenuti, alle informazioni ed ai servizi resi a disposizione dal sito,
indipendentemente dal sistema operativo, dagli strumenti di navigazione, dalle
impostazioni del browser, e a prescindere dalla velocità di connessione di cui si
dispone. Significa inoltre perseguire un percorso di ricerca e di aggiornamento
continuo, che parte dalla conoscenza dei problemi e delle reali necessità degli
utenti, delle tecnologie per supportarli, dai test derivati dall'applicazione di queste
tecnologie, dal monitoraggio dei risultati e dall'implementazione delle soluzioni
più soddisfacenti per gli utenti.
Il 17 dicembre 2003 il Parlamento approva all'unanimità la "Legge Stanca",
che consente ai disabili l'accessibilità alle nuove tecnologie digitali e informatiche
precisando che un "sito web accessibile", è un sito Internet il cui contenuto
informativo multimediale e le procedure di interazione e navigazione siano fruibili
da utenti dotati di browser con diverse configurazioni, che consentano di
disabilitare le funzioni di caricamento di immagini, animazione, suono, colore,
temporizzazione e omettere l'uso di visualizzatori addizionali. Si considera
accessibile un sito che non ostacoli l'orientamento, la navigazione, la lettura di
pagine e documenti, lo scaricamento di file e l'interazione con form o quant'altro
richieda introduzione di dati e gestione di comandi, quando tali operazioni siano
eseguite da una persona sufficientemente addestrata nell'uso di una postazione
di lavoro.
21
__
Università degli studi di Ferrara
Ai fini dell'accessibilità, i criteri fondamentali ai quali le amministrazioni sono
invitate ad attenersi nello sviluppo di applicazioni informatiche sono i seguenti:
-
Accessibilità dalla tastiera:
o tutte le funzioni dell'applicazione devono essere gestibili da tastiera.
Tutte le azioni previste con l'uso di dispositivi di puntamento e
manipolazione di oggetti devono essere rese possibili anche con
equivalenti comandi di tastiera e devono essere chiaramente descritte
nella documentazione dell'applicazione;
o i comandi impartiti con combinazione di tasti di scelta rapida devono
rispettare, per le operazioni più comuni, le scelte abituali del sistema
operativo e devono essere ridefinibili dall'utente, per risolvere eventuali
problemi di conflitto con quelli della tecnologia assistiva. Vanno inoltre
preferite combinazioni semplici di tasti che risultino di facile
memorizzazione e richiedano una modesta abilità manuale per
l'esecuzione;
o l'applicazione deve prevedere una successione logica delle operazioni
di interazione. La successione deve essere chiaramente individuabile
dalla tecnologia assistiva, per seguirne il percorso e consentire
l'interpretazione alternativa delle operazioni;
o l'applicazione non deve interferire con le funzioni di accessibilità
eventualmente disponibili nel sistema operativo;
o i comandi che prevedono una risposta a tempo devono essere evitati,
oppure deve essere prevista la possibilità, per l'utilizzatore, di regolare
il tempo di risposta;
-
Icone:
o tutte le icone devono avere una chiara etichetta testuale o
un'alternativa testuale selezionabile dall'utilizzatore;
o ad ogni icona deve essere associata una combinazione di tasti di scelta
rapida. Per le barre di icone deve essere disponibile anche un menù a
tendina con comandi equivalenti;
22
__
-
Università degli studi di Ferrara
Oggetti:
o l'applicazione deve usare le routine di sistema per la presentazione del
testo, in modo da permetterne l'interpretazione alla tecnologia assistiva.
L'informazione minima da fornire per tale interpretazione è costituita dal
contenuto testuale dello schermo, dagli attributi del testo e dalla
posizione del cursore;
o l'applicazione deve rendere disponibili sufficienti informazioni sugli
oggetti usati dall'interfaccia utente, affinché la tecnologia assistiva
possa identificarli e interpretarne la funzione;
-
Multimedia:
o l'applicazione deve prevedere opzioni alternative di segnalazione visiva
di avvertimento e rinforzo delle segnalazioni sonore di allarme del
programma;
o l'applicazione deve prevedere opzioni di presentazione sincronizzata in
formato testuale di tutte le informazioni audio, per mezzo di didascalie,
sotto-titolazioni o altro, se questo non sia palesemente in contrasto con
le funzioni del programma o oggettivamente impossibile da realizzare o
non sufficiente per un utilizzatore non udente;
o l'applicazione deve prevedere opzioni di descrizione vocale o
presentazione sincronizzata in formato testuale di tutte le informazioni
di tipo video se questo non è palesemente in contrasto con le funzioni
del programma o oggettivamente impossibile da realizzare o non
sufficiente per un utilizzatore non vedente (ad esempio programmi CAD
o di montaggio fotografico);
-
Presentazione a video:
o l'applicazione non deve usare il colore come mezzo per fornire
informazione o indicare una azione selezionabile in un menu oppure
deve prevedere un metodo alternativo utilizzabile anche da chi non
percepisce i colori;
23
__
Università degli studi di Ferrara
o l'applicazione deve permettere all'utilizzatore di scegliere i colori e
regolare il loro contrasto, sia nell'interfaccia utente sia nelle aree di
lavoro e presentazione dei dati;
o l'applicazione non deve contenere immagini di sfondo in presenza di un
testo o un grafico importante, oppure deve essere fornita di una
opzione per eliminare tale sfondo;
o l'applicazione deve permettere all'utilizzatore di cambiare dimensioni e
tipo di caratteri, per mezzo del sistema operativo, per la presentazione
a video e per la stampa;
o l'applicazione deve permettere all'utilizzatore di regolare o bloccare gli
effetti di lampeggio, rotazione o movimento delle presentazioni a video,
se questo non interferisce con lo scopo dell'applicazione;
o l'applicazione deve permettere all'utente di selezionare la definizione di
schermo preferita;
o l'applicazione deve rispettare le scelte dell'utente relative ai puntatori di
sistema del mouse;
o per gli elementi selezionabili, si deve prevedere una distanza minima di
almeno il 4% della larghezza o altezza dello schermo, oppure deve
essere prevista un'opzione di ridimensionamento;
-
Etichette dei campi:
o le etichette relative ai campi dei dati devono trovarsi immediatamente
vicine ai campi stessi, preferibilmente a sinistra, in modo da facilitare la
loro lettura, e l'associazione al campo relativo, da parte degli screen
reader per i ciechi;
-
Documentazione:
o tutta la documentazione deve essere fornita anche in formato
elettronico accessibile e deve includere anche descrizioni testuali di
figure e grafici;
o qualunque uscita prodotta dall'applicazione deve essere disponibile in
formato accessibile.
24
__
Università degli studi di Ferrara
4. Tecnologie utilizzate
Il progetto, oggetto del tirocinio, è basato su un servizio che si trova su un
server web Apache attivo su una macchia virtuale Windows 2003 Server.
L’utilizzo di una macchina virtuale permette la migliore configurazione,
manutenzione e affidabilità del server. Come Database Management System
(DBMS) è stato utilizzato Microsoft SQL Server, e come linguaggio per la
creazione dell’applicazione web, è stato scelto PHP, per la facilità di
programmazione e la caratteristica di essere Open Source, il che significa che i
codici sorgenti del PHP sono disponibili a chiunque, con la possibilità di essere
modificati e utilizzati in modo gratuito. Per quanto riguarda l’accessibilità e
l’usabilità si è fatto un uso principale dei fogli di stile CSS per la parte grafica.
Come tecnologia lato client è stato utilizzato il JavaScript.
4.1.
SQL e Microsoft SQL Server
La storia di SQL [Linguaggio SQL] inizia nel 1974 con la definizione da
parte di Donald Chamberlin, e di altre persone che lavoravano presso i laboratori
di ricerca dell'IBM, di un linguaggio per la specificazione delle caratteristiche dei
database che adottavano il modello relazionale. Questo linguaggio si chiamava
SEQUEL (Structured English Query Language) e venne implementato in un
prototipo chiamato SEQUEL-XRM fra il 1974 e il 1975. Le sperimentazioni con
tale prototipo portarono fra il 1976 ed il 1977 ad una revisione del linguaggio
(SEQUEL/2), che in seguito cambiò nome per motivi legali, diventando SQL. Il
prototipo (System R), basato su questo linguaggio, venne adottato ed utilizzato
internamente da IBM e da alcuni suoi client. Grazie al successo di questo
sistema, che non era ancora commercializzato, anche altre compagnie iniziarono
a sviluppare i loro prodotti relazionali basati su SQL. A partire dal 1981 IBM
cominciò a rilasciare i suoi prodotti. Nel corso degli anni ottanta numerose
compagnie
(ad
esempio
Oracle
e
Sybase,
solo
per
citarne
alcune)
commercializzarono prodotti basati su SQL, che divenne lo standard industriale
di fatto per quanto riguarda i database relazionali. Il fatto di avere uno standard
definito di un linguaggio per database relazionali, apre potenzialmente la strada
25
__
Università degli studi di Ferrara
alla intercomunicabilità fra tutti i prodotti che si basano su di esso. Dal punto di
vista pratico, purtroppo, le cose sono andate in modo differente. Infatti, in
generale, ogni produttore adotta ed implementa nel proprio database solo il
cuore del linguaggio SQL (il cosiddetto Entry level o al massimo l'Intermediate
level), estendendolo in maniera proprietaria a seconda della propria visione del
mondo dei database.
L'ingresso di Microsoft nel mondo dei database di fascia "enterprise" risale
intorno al 1989, quando cominciò la competizione con Oracle, IBM e Sybase che
erano i dominatori del mercato. La prima versione fu SQL Server per OS/2 ed
era quasi identica a Sybase SQL Server 4.0 su Unix. Fino al 1994 Microsoft SQL
Server riportava tre copyright della Sybase come indicazione della sua origine; in
seguito Sybase cambiò il nome del suo prodotto in "Adaptive Server Enterprise"
per evitare confusione con "Microsoft SQL Server" [Microsoft SQL Server]. SQL
Server 7.0 è stato il primo database server basato su un'interfaccia grafica.
Microsoft SQL Server è un database relazionale prodotto da Microsoft, che nelle
prime versioni era utilizzato per basi dati medio-piccole, ma negli ultimi anni (a
partire dalla versione 2000) è stato utilizzato anche per la gestione di basi dati di
grandi dimensioni. Questo DBMS della Microsoft usa una variante del linguaggio
SQL standard (lo standard ISO certificato nel 1992) chiamata T-SQL (TransactSQL).
4.2.
Server Web Apache
Apache [Server Web Apache] è il principale server web, con una quota di
mercato vicino al 70% (vedi figura 17). Svariate società commerciali hanno
adottato soluzioni basate su Apache per i loro prodotti, incluse Oracle, Red Hat e
IBM. Lo scopo del progetto del Server HTTP è di sviluppare e mantenere un
server HTTP Open Source per i moderni sistemi operativi, come Unix e
Windows. Il fine di questo progetto è quello di fornire un server sicuro, efficiente
ed estensibile che garantisca servizi HTTP in aderenza con gli standard HTTP
correnti. Il server Apache iniziò la sua vita come modifica del server Web NCSA,
26
__
Università degli studi di Ferrara
uno dei primi server http, poi cresciuto oltre la semplice implementazione di un
server web, occupandosi dello sviluppo di altre tecnologie critiche dal lato server.
Apache è un server web basato su processi. Al suo avvio, genera (fork) svariati
processi figli; con il fork un processo primario genera copie identiche di se
stesso, chiamate figli. Ognuno dei quali può servire una richiesta indipendente
dalle altre, con il vantaggio di migliorare la stabilità: se uno dei figli ha un
comportamento anomalo (va fuori controllo o si blocca) può essere interrotto
senza alcun effetto sugli altri.
Figura 17: Dati sulla diffusione dei principali server web
La stabilità è ottenuta a spese delle prestazioni. Nella maggior parte dei sistemi
Unix, la creazione di processi e il cambiamento del contesto (assegnazione di
tempo del processore a ogni processo), sono operazioni costose in termini di
risorse di sistema, dal momento che i processi sono isolati gli uni dagli altri e non
possono quindi facilmente condividere codice e dati. Caratteristiche:
-
Modularità:
Possiede un'architettura modulare, che permette di abilitare o disabilitare
moduli per aggiungere o rimuovere funzionalità al server Web. È possibile
personalizzare Apache per migliorarne le prestazioni e la sicurezza. In
aggiunta ai moduli di base, esiste un gran numero di moduli di terze parti,
con i quali è possibile ampliare ulteriormente le funzionalità del server.
27
__
-
Università degli studi di Ferrara
Moduli multiprocesso:
Astrae l'architettura di elaborazione delle richieste tramite moduli speciali,
chiamati Multi Processing modules (MPMs), ossia moduli Multi Processo,
grazie ai quali Apache può essere configurato come un server basato su
processi, come un server puramente basato su thread o come un misto di
tali modelli. I thread sono inglobati all'interno dei processi e sono eseguiti
simultaneamente; a differenza dei processi, possono condividere sia dati
che codice, risultando così più "leggeri", tanto che in molti casi i server di
tipo "threaded" hanno una migliore scalabilità rispetto ai server basati su
processi. Il server risulta, in controparte, meno affidabile, perché se un
thread ha un comportamento anomalo può causare la corruzione di codice
o di dati appartenenti ad altri thread.
-
Moduli multi protocollo:
La gestione dei protocolli in Apache è stata incapsulata in un suo proprio
livello, rendendo possibile la scrittura di moduli per protocolli diversi da
HTTP, quali POP3 per la posta o FTP per il trasferimento di file. Questi
moduli di protocollo possono trarre vantaggio dalla solida ossatura del
server e dalla funzionalità dei moduli, come l'autenticazione e la
generazione di contenuti dinamici. Questo significa che, per esempio, è
possibile autenticare i propri utenti POP3, tramite lo stesso database di
utenti che Apache usa per le richieste web e che il contenuto FTP può
essere generato dinamicamente grazie a CGI,PHP,JSP o qualunque altra
delle tecnologie di creazione di contenuti dinamiche lato server.
Le applicazioni web sono scritte in linguaggi di alto livello come Java, Perl, C# e
così via e Apache dispone di svariati moduli che ne permettono l'integrazione
con il server. In molti casi i moduli espongono le API di Apache, così che tutti i
moduli Apache possano essere scritti in questi linguaggi.
28
__
4.3.
Università degli studi di Ferrara
HTML e CSS
L’HTML (Hypertest Markup Language) [HTML 4.01] è un linguaggio usato
per descrivere i documenti ipertestuali disponibili nel Web. Non è un linguaggio
di programmazione, ma un linguaggio di markup, ossia descrive il contenuto,
testuale e non, di una pagina web. L'estensione comune dei documenti HTML
sono “.html” o “.htm”. È stato sviluppato alla fine degli anni '80 da Tim BernersLee al CERN di Ginevra. Verso il 1994 ha avuto una forte diffusione, in seguito ai
primi utilizzi commerciali del web. HTML è un linguaggio di pubblico dominio la
cui sintassi è stabilita dal World Wide Web Consortium (W3C), ed è basato su un
altro linguaggio avente scopi più generici, l'SGML. Il cuore principale della
sintassi di questo linguaggio è l'elemento. Gli elementi sono le strutture del
linguaggio a cui è delegata la funzione di formattare i dati o indicare al Web
browser delle informazioni. Ogni elemento è racchiuso all'interno di tag, uno di
apertura ed uno di chiusura. Quest'ultimo, per certi elementi, è opzionale. I tag
sono dei segnalini (markup) costituiti da una sequenza di caratteri racchiusa da
due parentesi angolari, cioè i segni minore e maggiore.
Un documento HTML comincia con l'indicazione della DTD (Document
Type Definition), la quale dice al browser l'URL (Uniform Resource Locator) delle
specifiche HTML che stiamo utilizzando per il nostro documento (indicando
quindi, implicitamente, quali elementi, attributi ed entità possiamo utilizzare).
Tutte le informazioni contenute nel documento devono essere indicate tra i tag
<HTML> e </HTML>. All'interno di questi due tag la sintassi HTML permette due
sezioni: una racchiusa tra i tag <HEAD> e </HEAD>, ed una racchiusa tra i tag
<BODY> e </BODY>. All'interno della prima sezione sono indicate delle
informazioni generali riguardanti l'intero documento e che non vengono
visualizzate dal browser. All'interno della sezione BODY sono indicate tutte le
informazioni effettivamente presenti nel documento. Il tag principale più utilizzato
dell'HTML è il tag <A>, che descrive un collegamento (o link) ad un altro
documento ipertestuale. Sui browser grafici è possibile chiedere al computer di
passare alla risorsa indicata dal link semplicemente facendo un clic con il
mouse.
29
__
Università degli studi di Ferrara
Lo scopo dell’HTML è definire il ruolo strutturale che gli elementi contenuti
nella pagina hanno all’interno del documento, ad esempio paragrafi, titoli, link,
tabelle, liste, ecc… e non per decidere come questi elementi dovrebbero essere
visualizzati sullo schermo, anche se nel tempo sono stati usati stratagemmi sui
tag per controllare la presentazione delle pagine web.
I fogli di stile sono nati per superare questa situazione, separando le
istruzioni di visualizzazione dai tag strutturali dell’HTML conservando i vantaggi
di portabilità, di condivisione dei documenti e visualizzazione corretta su browser
differenti, anche quelli che non sono in grado di interpretare correttamente i CSS
[CSS 2.1]. I fogli di stile (CSS, cascading style sheet) sono una tecnologia che si
sta lentamente imponendo all'attenzione di coloro che realizzano siti. Si tratta di
un linguaggio per il visual design, ovvero per controllare l'aspetto visivo degli
elementi che costituiscono la pagina HTML. I CSS sono una specifica diversa da
HTML. Quest’ultimo può contenere al suo interno delle istruzioni CSS associate
ai tag HTML, oppure può fare riferimento, con un'apposita dichiarazione, ad un
foglio di stile separato tramite un proprio URI.
Sono caratterizzati da regole strutturate nel seguente modo:
selettore {
proprietà1 : valore1;
proprietà2 : valore2, valore3;
}
E ne possiamo trovare di vario tipo:
-
Selettori di tipo:
p{
……
}
I selettori di tipo applicano la regola a tutti gli elementi di uno specifico tipo.
-
Classi:
.nomeClasse {
……
}
Le classi applicano la regola a tutti gli elementi in cui è presente la
proprietà class=”nomeClasse”.
30
__
-
Università degli studi di Ferrara
Identificatori:
#nomeIdentificatore {
……
}
Gli identificatori applicano la regola a tutti gli elementi in cui è presente la
proprietà id=”nomeIdentificatore”.
-
Pseudoclassi:
a:link {
……
}
Le pseudoclassi individuano gli elementi in base alle loro proprietà. Ad
esempio link si applica ai collegamenti e identifica i collegamenti non
visitati.
-
Pseudoelementi:
p:first-line {
……
}
Gli pseudoelementi individuano solo una parte di un elemento. Ad
esempio first-line individua solo la prima linea di un paragrafo.
-
Selettore di discendenza, figlio e fratello:
Identificano solamente gli elementi che si trovano in una
particolare
condizione di discendenza.
-
Selettore di attributi
a[title=esempio] {
……
}
Il selettore di attributi permette di identificare gli elementi in base ai loro
attributi.
4.4.
PHP
31
__
Università degli studi di Ferrara
PHP [Linguaggio PHP] è un linguaggio di scripting interpretato, con licenza
Open Source, originariamente concepito per la realizzazione di pagine web
dinamiche. Attualmente è utilizzato principalmente per sviluppare applicazioni
web lato server, ma può essere usato anche per scrivere script a linea di
comando o applicazioni stand-alone con interfaccia grafica. Il nome PHP è
l’acronimo per Professional Home Pages. Lo scopo del linguaggio è quello di
consentire agli sviluppatori web di realizzare in modo veloce pagine dinamiche.
Per pagine dinamiche, in questo contesto, si intendono pagine il cui contenuto
viene, almeno in parte, generato nel momento in cui le stesse vengono richieste
al web server. Un esempio classico di pagina dinamica è fornito dai motori di
ricerca: i risultati che ci vengono restituiti a seguito di una interrogazione non
sono pagine web statiche, bensì documenti generati "su misura", sulla base della
nostra richiesta. La definizione "ufficiale" permette di chiarire le caratteristiche di
questo linguaggio:
-
Il PHP è un linguaggio di scripting. I programmi scritti in linguaggio PHP,
denominati brevemente script, vengono eseguiti tramite un apposito
software, l'interprete PHP. Quest'ultimo si occupa di leggere il codice PHP
e, interpretandone le istruzioni, esegue le operazioni corrispondenti (ad
esempio la lettura di un file o un calcolo aritmetico). Dunque, il PHP è
quello che tecnicamente si definisce un linguaggio interpretato, ed in
questo esso si differenzia da altri linguaggi di programmazione, come ad
esempio C++ e Java, il cui codice sorgente, per poter essere eseguito,
deve prima essere compilato.
-
Il PHP è "HTML-embedded". Questa caratteristica si riferisce al fatto che il
codice PHP è immerso nell'HTML; gli script sono inseriti all’interno di tag
appositi ( <?php ?> oppure solamente <? ?> ), nelle pagine HTML in cui
devono produrre i loro effetti. Il web server riconosce le pagine PHP,
distinguendole da quelle "statiche", sulla base dell'estensione, htm o html
per le pagine statiche e php3, php o phtml per le pagine php; quando il
32
__
Università degli studi di Ferrara
server riconosce una estensione associata a PHP passa il testimone
all'interprete, lasciando che sia quest'ultimo ad occuparsene.
-
Il PHP Opera server-side. cioè opera lato server. Significa che tutta
l'elaborazione di uno script avviene sul server, prima che questi spedisca
la pagina al browser (il "client"). Di conseguenza, chi accede ad una
pagina PHP non ha la possibilità di leggere le istruzioni in essa contenute,
essendo state processate lato server, il client vedrà soltanto il risultato
dell'elaborazione.
La sintassi del linguaggio ricalca in gran parte quella di altri popolari linguaggi di
programmazione come C/C++, Java e Perl quindi permette una facile
comprensione a chi si appresta per la prima volta all’utilizzo del PHP; offre inoltre
una libreria di funzioni molto completa per ogni tipologia di utilizzo, dalla
comunicazione con i database di vario tipo a funzioni matematiche, ecc…
Attualmente il PHP è molto diffuso grazie al fatto che è Open Source, ed
esistono una infinità di script di ogni genere, già pronti da usare per poter creare
applicazioni di ogni tipologia in pochissimo tempo, come carrelli elettronici o
portali di informazione.
4.5.
JavaScript
JavaScript [Linguaggio JavaScript] è un linguaggio di scripting orientato
agli oggetti comunemente usato nei siti web. Fu originariamente sviluppato da
Brendan Eich della Netscape Communications con il nome di Mocha e
successivamente di LiveScript, ma in seguito è stato rinominato "JavaScript" ed
è stato formalizzato con una sintassi più vicina a quella del linguaggio Java di
Sun Microsystems. Netscape vuole arricchire Mosaic corredandolo di nuove
funzionalità, anche per questo motivo viene coinvolto Eich a cui viene affidato il
compito di realizzare un linguaggio da integrare nel browser Netscape, che
potesse rendere le pagine web più interattive e al contempo che fosse semplice
da usare. Inoltre Netscape, prima azienda ad ottenere una licenza per l'impiego
di Java, aveva bisogno di questo nuovo linguaggio di scripting anche per
raggiungere una maggiore interazione con le applet (piccole applicazioni Java).
33
__
Università degli studi di Ferrara
Mocha in realtà era solo il nome in codice del progetto a cui Brendan Eich iniziò
a lavorare. Ad esso venne riconosciuto il nome ufficiale di LiveScript (Live stava
proprio ad enfatizzare il suo obiettivo, quello di rendere più vive le pagine web, in
Netscape questo termine viene utilizzato come prefisso per tecnologie diverse).
Il linguaggio venne integrato nel browser (in altri termini, il browser sarebbe stato
corredato di un componente dedicato all'interpretazione ed esecuzione delle
istruzioni contenute nelle pagine web) a partire dalla versione beta di Navigator
2.0. Anche il nome LiveScript ebbe vita breve perchè, proprio per mettere in
evidenza la capacità del linguaggio di integrarsi con Java e anche per godere di
una parte di quel successo che già circondava quest'ultimo, LiveScript cambia di
nuovo nome. In un comunicato congiunto del 4 dicembre 1995, Netscape e Sun
Microsystem viene annunciata la nascita di JavaScript.
Prima dell'avvento di JavaScript, affinché una pagina web rispondesse ad
una interazione con l'utente (un clic su di un bottone di un form ad esempio)
necessitava di una comunicazione con il server (il computer remoto al quale
sarebbero stati inviati i dati per la loro elaborazione). Un classico esempio é
quello del controllo dei dati inseriti dall'utente in un form. Se non si impiega
JavaScript, ecco cosa accade: l'utente compila il form, probabilmente dimentica
di inserire alcuni dati ritenuti obbligatori oppure li inserisce in modo errato (ad
esempio, una data, un indirizzo email, il codice fiscale ecc…). Nel momento in
cui l'utente inoltra il form cliccando sull'apposito pulsante di invio, i dati vengono
spediti al server e qui sottoposti ad un processo di controllo, se questo controllo
non va a buon fine, l'utente si vede recapitare una pagina web contenente il form
appena compilato, insieme ad una serie di messaggi di errore, relativi a quelle
informazioni non fornite o fornite in modo errato. Tutto ciò comporta dei tempi di
attesa legati alla comunicazione tra il client, la macchina dell'utente, e il server.
Questi tempi possono essere ridotti se anche la pagina web potesse eseguire
quei controlli di correttezza sui dati. Questo è un classico esempio di impiego di
JavaScript per migliorare il grado di interazione dell'utente con una pagina web.
Il successo di JavaScript é sin da subito evidente e costringe anche
Microsoft ad adeguarsi. Vengono integrati due interpreti all'interno di Microsoft
Internet Explorer: uno per il linguaggio VBScript e uno per una declinazione
34
__
Università degli studi di Ferrara
Microsoft del linguaggio JavaScript, cui viene attribuito il nome Jscript. Anche se
il nome é diverso, il linguaggio é talmente simile a JavaScript che é sufficiente
adottare alcuni accorgimenti perché, lo stesso codice sia utilizzabile senza
modifiche da entrambi gli interpreti (quello della Microsoft e quello della
Netscape). Netscape sottopone JavaScript ad ECMA [Ente ECMA]: un ente
preposto alla definizione di standard nel settore dell'informatica e delle
telecomunicazioni. Al termine di questo processo viene redatto un documento
contenente le specifiche del linguaggio di scripting, al quale viene attribuito un
nuovo
nome
(probabilmente
per
non
avvantaggiare
alcuna
azienda
commerciale): ECMAScript.
Oggi JavaScript é ritornato ad essere una delle tecnologie più in voga sul
web grazie ad AJAX, acronimo di Asynchronous JavaScript And Xml. Si tratta di
un modo nuovo di impiegare JavaScript per raggiungere quello stesso scopo che
si era dato Brendan Eich quando creò il linguaggio: rendere ancora più reattive
le pagine web a seguito dell'interazione con l'utente. Tanto per fare un esempio
pratico, il servizio di posta elettronica di Google sfrutta questa tecnologia per
assicurare una più rapida risposta in base alle azioni dell'utente.
JavaScript è un linguaggio di programmazione orientato a oggetti con una
sintassi vagamente basata sul C. Come il C, JavaScript ha il concetto di parole
chiave riservate, che rendono quasi impossibile espandere il linguaggio
(essendo eseguito direttamente dal sorgente). Come nel C, il linguaggio non ha
propri costrutti di input o output; mentre il C si affida alle librerie I/O standard, un
interprete JavaScript si basa su un programma ospite in cui è integrato. Ci sono
molti programmi ospiti di questo tipo, di cui quelli relativi al Web sono gli esempi
più noti. Questi verranno illustrati per primi.
JavaScript, se integrato in un browser Web, si collega alle applicazioni
tramite interfacce chiamate DOM (Document Object Model) (vedi figura 18), a
lato server (web server) e al lato client (browser). Molti siti web usano la
tecnologia JavaScript lato client per creare potenti applicazioni web dinamiche.
Un uso principale del Javascript basato su web è la scrittura di piccole funzioni
integrate nelle pagine HTML, che interagiscono con il DOM del browser per
compiere determinate azioni non possibili con il solo HTML statico, come aprire
35
__
Università degli studi di Ferrara
una nuova finestra, controllare i valori nei campi di ingresso, cambiare le
immagini al passaggio del mouse, ecc. Sfortunatamente, i DOM dei vari browser
non sono standardizzati, browser diversi espongono diversi oggetti o metodi allo
script, ed è quindi spesso necessario scrivere differenti versioni di una funzione
JavaScript per ciascuno dei browser.
Al di fuori del Web, interpreti JavaScript sono integrati in diverse
applicazioni. Adobe Acrobat e Adobe Reader supportano JavaScript nei file
PDF. La piattaforma Mozilla, che è alla base di molti diffusi browser Web, usa
JavaScript per implementare l'intefaccia utente e la logica di transazione dei suoi
vari prodotti. Gli interpreti JavaScript sono integrati anche nelle applicazioni
proprietarie prive di interfacce programmabili via script.
Il principale tag del linguaggio Javascript è il tag “script”. Questo tag è
un'estensione dell'HTML, in quanto permette la gestione di codice esterno che
non è nativo HTML. Un documento può presentare in più parti la definizione del
tag SCRIPT. Tramite questo tag si può rappresentare la versione utilizzata ed, a
seconda del browser, si avrà l'interpretazione appropriata.
Figura 18: JavaScript Document Object Model (DOM)
36
__
Università degli studi di Ferrara
5. Realizzazione della nuova applicazione
Nella realizzazione del progetto si mette in pratica tutto quello che è stato
ideato in fase di progettazione utilizzando le tecnologie prescelte, creando le
implementazioni necessarie alla realizzazione degli schemi, delle interfacce e
delle funzionalità viste nei capitoli precedenti.
5.1.
Architettura della rete del Comune
L’architettura di base va analizzata prima di procedere alla realizzazione,
facendo emergere le caratteristiche più importanti, le tecnologie hardware e
software in uso, e i possibili limiti di utilizzo; comprendere questo permette di
implementare metodi e procedure adeguati che possano sfruttare al meglio
l’architettura sottostante.
L’architettura della rete intranet del Comune di Cento, visibile in figura 19,
è separata da Internet grazie all’ausilio di un Firewall, che protegge la rete
interna. Questo, inoltre, delimita anche la DMZ (DeMilitarized Zone) che significa
letteralmente zona demilitarizzata e, nel modello dei firewall, indica un’area della
rete che non è situata né all’interno, né all’esterno del dominio protetto.
Tipicamente, ai sistemi e ai dispositivi che si trovano all’interno della DMZ, viene
fornito un certo livello di protezione che però non è considerato pienamente
affidabile dal dominio protetto. La DMZ viene normalmente utilizzata per
permettere ai server, in essa posizionati, di fornire servizi all'esterno, senza
compromettere la sicurezza della rete aziendale interna nel caso una delle
macchine sia sottoposta ad un attacco informatico.
Nella rete trovano posto sia server Linux che server Windows, e offrono
una serie di servizi che permettono alla rete di funzionare correttamente, ad
esempio server di posta, server DNS, server proxy, server in cui risiedono i
gestionali in uso presso l’ente, server DB, file server e altri ancora.
Nel nostro caso, l’applicazione “Fatture On-Line” non ha bisogno di
prestazioni elevate, perchè non è previsto un uso intensivo del servizio, o un uso
contemporaneo da parte di molti utenti, tale da ottenere un carico consistente,
inoltre non utilizza tecnologie particolarmente vincolanti. Questo ha permesso di
37
__
Università degli studi di Ferrara
sfruttare nel migliore dei modi le tecnologie presenti nella rete del comune,
utilizzando i servizi già offerti come server web Apache con estensione PHP, nel
quale risiederà il servizio e MS SQL Server, che gestirà i dati in uso.
Figura 19: Schema della rete del Comune di Cento
5.2.
Tabelle database
Precedentemente abbiamo visto le tabelle già presenti nel sistema e
quelle di nuova creazione. In figura 20, 21 e 22 è visibile la struttura delle tabelle
pre-esistenti nel database che verranno utilizzate solamente in lettura.
Figura 20: Tabella Fornitori
38
__
Università degli studi di Ferrara
Figura 21: Tabella Fatture
Figura 22: Tabella Dettaglio
Come si può notare, i nomi delle colonne sono un po’ criptici, questo deriva dal
gestionale in uso, da cui vengono prelevati i dati. All’interno dell’applicazione è
stata fatta un’associazione di queste colonne con nomi di più facile
comprensione. Tutti i dati delle tabelle passano attraverso delle classi base, che
hanno il compito di presentare i dati con nomi più chiari e facilmente gestibili.
Le tabelle aggiuntive non hanno chiavi importate, proprio perché quelle già
presenti nel sistema vengono svuotate e ripopolate ogni giorno con la
conseguente perdita dei dati. L’inserimento, modifica e cancellazione dei dati
delle tabelle aggiuntive viene effettuato tramite interfaccia web.
Ora vediamo la struttura di quelle che sono state aggiunte:
Tabella “PERMESSI”:
La tabella “PERMESSI”, visibile in figura 23, contiene i dati per l’accesso al
servizio e per la sua fruizione. Come si può notare dalla figura sono presenti i
campi “USERNAME” e “PASSWORD” che rappresentano lo username
dell’utente e la relativa password.
39
__
Università degli studi di Ferrara
Figura 23: Tabella Permessi
Nel campo PASSWORD non troviamo la password in chiaro ma la troviamo
cifrata con l’algoritmo MD5. In questa tabella sono presenti i permessi, sia per gli
utenti di dominio che per i fornitori, essendo gli utenti di dominio autentificati da
un sistema esterno al servizio, nel campo PASSWORD troveremo una password
fittizia. Nella colonna LAST_ACCESS viene registrato il timestamp dell’ultimo
accesso effettuato dall’utente. Nella colonna PERMESSI troviamo l’identificativo
numerico, che rappresenta il grado di autorizzazione associato all’utente (da 1 a
100 per gli utenti di dominio, maggiore di 100 per i fornitori), si è scelto di
utilizzare un range così elevato di autorizzazioni, nel caso in cui ci sia bisogno di
creare nuove tipologie di autorizzazioni. Nella colonna STATO viene salvato lo
stato dell’utente, che può essere “ATTIVO” o “SOSPESO”, se l’utente non è
stato precedentemente attivato, non è presente nella tabella, quindi non ha
permessi.
Tabella “FATTURE_S”:
La tabella “FATTURE_S”, visibile in figura 24, registra le associazioni tra una
fattura e la relativa scansione, caricata tramite un’interfaccia web. Nella colonna
RIFERIMENTO, viene salvato il riferimento della fattura e nella colonna PATH
viene salvato il nome del file.
Figura 24: Tabella Fatture_s
40
__
Università degli studi di Ferrara
Tabella “LOG_FATTURE”:
La tabella “LOG_FATTURE”, visibile in figura 25, registra gli accessi al servizio
sia della parte di dominio che della parte di accesso dei fornitori. Qui è presente
un campo ID auto incrementale, che rappresenta l’indice della tabella. Nella
colonna USERNAME viene registrato lo username, nella colonna DATA viene
registrato il timestamp e nella colonna IP viene registrato l’indirizzo IP di chi ha
avuto accesso al servizio. Non ci si è posti il problema di dividere il log di
accesso al sito per le due sezioni, perchè facilmente identificabili dallo
username, essendo formattati in due modi totalmente differenti.
Figura 25: Tabella Log_Fatture
Tabella “IMPOSTAZIONI”:
La tabella “IMPOSTAZIONI”, visibile in figura 26, consente di registrare le
impostazioni globali del servizio, per poterle rendere dinamiche. Attualmente,
all’interno del sito, vengono utilizzate impostazioni come il numero di record per
pagina, l’e-mail a cui inviare le richieste di informazioni, la posizione effettiva
dove salvare le scansioni caricate, ecc…. In questa tabella è presente un campo
ID auto incrementale, che rappresenta l’indice della tabella. La colonna
IMPOSTAZIONE rappresenta il codice da utilizzare all’interno degli script, come
parametro di una funzione, creata appositamente per recuperarne il valore. La
colonna
VALORE
DESCRIZIONE
contiene
contiene
una
il
valore
descrizione
dell’impostazione.
dell’impostazione,
La
colonna
questo
per
agevolare la comprensione delle funzionalità e dei valori da poter utilizzare. Le
impostazioni vengono caricate e registrate come variabili di sessione al login
dell’utente e utilizzate durante la fruizione del servizio.
41
__
Università degli studi di Ferrara
Figura 26: Tabella Impostazioni
5.3.
Sistema di autenticazione
Nella progettazione sono stati definiti i sistemi di autenticazione e in figura
27 è possibile distinguere le due modalità di accesso: Accesso con
autorizzazione di Dominio e Accesso con username e password per i Fornitori.
L’autenticazione della sezione di dominio utilizza il sistema di protezione di
Active Directory, che viene gestito esternamente al servizio. Provando ad
accedere alla sezione di dominio appare una maschera, visibile in figura 28, che
richiede le informazioni di autenticazione. Se le informazioni sono corrette, si ha
acceso alle pagine richieste, altrimenti appare una pagina contenente un
messaggio che descrive la non validità delle credenziali inserite.
Figura 27: Pagina di acceso al servizio
42
__
Università degli studi di Ferrara
La protezione è totalmente trasparente all’applicazione ma, attraverso il server
web, vengono rese disponibili delle variabili che possono essere utilizzate
all’interno degli script. Una di queste si chiama “REMOTE_USER” e contiene, in
seguito all’autenticazione di un utente, il dominio di appartenenza e il nome
utente.
L’autenticazione della sezione di accesso ai fornitori utilizza la doppia
protezione Apache/PHP-database. La protezione Apache è gestita esternamente
al servizio. Provando ad accedere alla sezione pubblica appare anche qui una
schermata, visibile in figura 29, simile a quella di dominio e con la stessa
funzionalità, cioè di verificare la validità delle informazioni inserite, ma con l’unica
differenza che, invece di essere validate dal controller di dominio, vengono
validate dal server web Apache.
Figura 28: Maschera di protezione Dominio
Figura 29: Maschera di protezione Apache
43
__
Università degli studi di Ferrara
La protezione basata su PHP e database è gestita completamente dal
servizio. Superando l’autenticazione Apache viene mostrata una pagina, visibile
in figura 30, contenente una maschera per l’inserimento delle credenziali di
accesso e altre informazioni. A partire da questa pagina è stato implementato il
sistema di autenticazione ideato precedentemente. Riepilogando brevemente, il
sistema prevede la generazione di un hash delle informazioni concatenate con la
chiave di sessione. L’hash verrà poi inviato al server per una comparazione con i
dati presenti nel database, e fornirà un risultato. Lo schema del sistema è visibile
in figura 31. L’hash delle informazioni viene effettuato tramite l’utilizzo
dell’algoritmo MD5. Lato client vengono effettuate le seguenti operazioni:
-
Creazione hash dello username concatenato con la chiave di sessione
-
Creazione hash della password
-
Creazione hash dell’hash della password concatenato con la chiave di
sessione.
In seguito le informazioni vengono inviate al server, dove uno script in php
provvede a generare le query necessarie, a reperire le informazioni dal database
e a verificare l’autenticazione, in seguito genera una pagina di risposta per il
client.
Figura 30: Pagina di accesso al servizio per i fornitori abilitati
44
__
Università degli studi di Ferrara
Figura 31: Schema di criptazione
La verifica dell’autorizzazione avviene nel modo seguente (Chiamiamo “H1”
l’hash contenente lo username e “H2” l’hash contenente la password):
-
Ricerca all’interno della tabella dei permessi di corrispondenze di H1 e H2
tramite una query di ricerca creata da uno script
-
Controllo del risultato della query. Se il risultato contiene un record la
validazione da esito positivo e si da l’accesso al servizio. Se il risultato non
contiene record la validazione da esito negativo, l’utente viene avvertito che
le credenziali sono errate e viene negato l’accesso al servizio.
Durante l’implementazione di queste operazioni, ci si è accorti che realizzando la
comparazione e validazione all’interno degli script, si ottiene un sistema molto
lento, che genera un elevato numero di query al database. Per velocizzare le
operazioni di ricerca, è stato implementato a livello di DBMS una funzione che
genera l’MD5 di una stringa, così da poter eseguire tutto il metodo con un’unica
query al database (vedi figura 32). L’implementazione è stata obbligatoria, vista
la mancanza di una funzione adeguata in Microsoft SQL Server. La semplice
query di ricerca creata restituisce il numero di occorrenze della coppia di
informazioni inviata dal client, effettuando chiamate alla funzione “fn_md5()” ed
eseguendo le comparazioni con il suo risultato. Ovviamente il risultato della
45
__
Università degli studi di Ferrara
query sarà uguale a ‘0’, se le credenziali dell’utente non sono presenti, oppure
sarà uguale a ‘1’ se l’utente è stato autentificato.
SELECT COUNT(*) AS num
FROM PERMESSI
WHERE (dbo.fn_md5(USERNAME + ‘CHIAVE SESSIONE') = 'H1')
AND (dbo.fn_md5(PASSWORD + ‘CHIAVE SESSIONE’) = 'H2')
Figura 32: Query per l’autenticazione
La realizzazione della funzione che genera l’MD5 di una stringa, è stata
fatta aggiungendo una procedura estesa, vedi figura 33, che si collega ad una
dll, contenente l’implementazione dell’algoritmo MD5. In seguito è stata
aggiunta, nel database di interesse, una user defined function, vedi figura 34,
che pensa a richiamare la funzione di libreria e a restituirne il risultato.
Gli script in PHP, per accedere al database, utilizzano le credenziali di un utente
creato appositamente per l’accesso al database delle fatture on-line. A questo
utente, sono stati dati i permessi per poter eseguire la suddetta funzione in una
query (vedi figura 35), e per l’utilizzo della libreria impostata in precedenza (vedi
figura 36).
Figura 33: Extended Store Procedure xp_md5
46
__
Università degli studi di Ferrara
Figura 34: User defined function fn_md5
Figura 35: Finestra permessi utente fatture per la funzione fn_md5
47
__
Università degli studi di Ferrara
Figura 36: Finestra permessi utente fatture per la libreria xp_md5
Durante la progettazione, è stato creato anche un sistema di codifica/decofica
delle informazioni sensibili non a conoscenza del server. Il sistema prevede la
generazione di una chiave random alfanumerica, che il client utilizzerà per la
codifica delle informazioni. Le informazioni codificate verranno poi inviate al
server, in cui verranno decodificare e poi elaborate. Lo schema del sistema è
visibile in figura 37. Prendendo come riferimento l’esempio del cambio password,
si è deciso di effettuare una codifica eseguita nel modo seguente:
-
Il server genera una chiave random di lunghezza casuale, la scrive in un
cookie e la invia al client, nel frattempo viene salvata momentaneamente
come variabile di sessione;
-
Il client codifica la nuova password in Base64, tramite la chiave prelevata dal
cookie, in seguito elimina il cookie per non lasciare più tracce della chiave sul
client, e invia il tutto al server;
-
Il server provvede a decodificare la password con la chiave salvata, elimina la
chiave dalla sessione e poi procede con la criptazione in MD5 della password
e la salva sul database.
48
__
Università degli studi di Ferrara
Per effettuare queste operazioni, lato server, sono stati creati due script in PHP:
il primo genera una chiave alfanumerica random di lunghezza variabile, il
secondo effettua la decodifica delle informazioni ricevute. Lato client, è stato
creato uno script in JavaScript che preleva le informazioni inserite, le codifica
con la chiave ricevuta, e cancella il cookie.
Figura 37: Schema di codifica
5.4.
Interfaccia web
Nella
realizzazione
dell’interfaccia
sono
stati
utilizzati
programmi,
appositamente creati, per il controllo del grado di leggibilità delle pagine web, da
parte di utenti con problemi alla vista. Tramite questi è stato possibile accertare
l’idoneità dei colori utilizzati e l’adeguatezza del contrasto. Sono inoltre stati
inseriti gli Access Key in ogni pagina con una comoda legenda che li riassume.
Gli Access Key danno la possibilità di consultare il servizio con più facilità,
tramite l’utilizzo della sola tastiera, attraverso la quale si usano combinazioni di
tasti per l’accesso rapido a collegamenti, pulsanti e campi da compilare.
Nella compilazione delle pagine si è cercato di mantenere il codice pulito,
evitando di inserire, direttamente nella pagina, proprietà di stile come colori e
formattazioni, e delegando il compito ai fogli di stile ( CSS ) che conterranno tutte
le formattazioni grafiche necessarie. Essendo tutte le proprietà di stile in un file
esterno, otteniamo che, alla disabilitazione dei CSS ( ad esempio nel caso di
visualizzazione in dispositivi con risoluzione molto bassa ), la pagina rimane
comprensibile e comunque consultabile. L’utilizzo dei CSS permette di poter
cambiare lo stile di tutte le pagine in una volta sola, modificando un singolo file.
Questo utilizzo è alquanto utile soprattutto nel caso in cui si necessita di
stampare la pagina, poiché durante le fasi che precedono la stampa, il browser
49
__
Università degli studi di Ferrara
carica ( se dichiarato ) un foglio di stile, creato appositamente per formattare i
contenuti, nascondendo tutto ciò che è superfluo, e modificando le eventuali
colorazioni e decorazioni.
Al completamento, le pagine sono state verificate tramite il servizio web
del W3C raggiungibile al seguente indirizzo: http://validator.w3.org/, grazie al
quale è stata confermata la qualità e la correttezza delle pagine html generate
dagli script PHP.
5.5.
Struttura script
Per il corretto funzionamento e sviluppo di un’applicazione web, si rivela di
grande utilità creare file che si prendano carico di gestire uno o più servizi
principali utilizzati da tutta l’applicazione. Ne è un esempio un file “database.php”
che, al suo interno, contiene tutte le funzioni necessarie per effettuare le
operazioni principali con il database, come l’apertura o la chiusura di una
connessione, l’esecuzione di una query o la restituzione di un singolo record di
un resultset. In questo progetto sono stati previsti alcuni di questi file come
quello precedentemente descritto. Segue la descrizione di altri file ideati
nell’applicazione:
-
Il file “function.php” contiene tutte le funzioni per la consultazione avanzata
del database, ed eventualmente qualche funzione di utilità come codifica o
decofica. Esempio di queste funzioni sono la restituzione di una classe o
un’array di classi contenente il risultato di una query avanzata di ricerca,
oppure funzioni per il controllo delle autorizzazioni di un determinato
utente.
-
Il file “varSessione.php” pensa alla registrazione, cancellazione e
aggiornamento delle variabili di sessione.
-
Il file “debug.php” da la possibilità, previa abilitazione tramite la sezione di
amministrazione, di visualizzare tutte le variabili utilizzate per agevolare le
operazioni di sviluppo e correzione errori.
-
Il file “menusx.php” visualizza il menù laterale dinamico tenendo conto
delle autorizzazioni dell’utente connesso.
50
__
Università degli studi di Ferrara
-
Il file “top.php” visualizza tutte le informazioni presenti nell’intestazione.
-
Il file “acccesskey.php” si preoccupa di visualizzare correttamente la
legenda delle access key.
-
Il file “classes.php” si preoccupa al suo interno di caricare le classi.
-
Il file “protect.php”, che è il più importante, permette di proteggere tutte le
pagine e di mantenere lo stato di connessione dell’utente.
Questi file sono inclusi in quasi tutte le restanti pagine del servizio, inoltre ogni
sezione (Dominio, Amministrazione, Fornitori) ha una versione propria per
differenziare le funzionalità, pur mantenendo la stessa struttura. Ad esempio
nella sezione di Amministrazione vi sono funzioni che non sono presenti nelle
altre sezioni, come la modifica dei permessi.
5.6.
Ricerca e visualizzazione
Nella vecchia applicazione, le funzionalità di ricerca e visualizzazione dei
dati non erano sufficienti. Ci si è posti subito il problema di migliorare e ampliare
le modalità di ricerca. Precedentemente era possibile cercare le fatture
singolarmente per anno, per numero documento o per tipo di documento. Ora la
ricerca è stata ampliata, ed è possibile ricercare per anno, codice fornitore,
numero documento, riferimento fattura e stato fattura contemporaneamente, per
ottenere una ricerca raffinata, vedi figura 38. Dopo aver effettuato una ricerca è
anche possibile, tramite un collegamento visibile sopra i risultati, modificarla
subito dopo averla effettuata, vedi figura 39.
E’ stata aggiunta una nuova funzionalità: un modulo per la ricerca dei fornitori,
così da poterne visualizzare le fatture, vedi figura 40. Anche in questo è possibile
ricercare per ragione sociale, codice fiscale e partita iva contemporaneamente.
Per la visualizzazione delle fatture, sono stati mantenuti quasi tutti i
contenuti presenti anche nel vecchio servizio e altri sono stati combinati, vedi
figura 41. E’ stata eliminata la colonna TIPO e accorpate le colonne LIQUIDATA
e PAGATA in una unica, che, insieme alla legenda sulla sinistra, permettono una
più facile identificazione dello stato delle fatture.
51
__
Università degli studi di Ferrara
Figura 38: Modulo di ricerca fatture
Figura 39: Opzioni di ricerca
Figura 40: Modulo di ricerca fornitore
52
__
Università degli studi di Ferrara
In precedenza, la visualizzazione dei fornitori era possibile solo in sede di
amministrazione, ora si possono visualizzare dettagli minimi dei fornitori anche
nella normale sezione di ricerca facilitando la ricerca delle fatture, vedi figura 42.
Una visualizzazione quasi identica, vedi figura 43, è presente in amministrazione
con
la
differenza
che
è
visibile
lo
stato
del
fornitore.
Da
questa,
successivamente, è possibile visualizzare i dettagli completi dei fornitori con le
operazioni di amministrazione annesse, vedi figura 44.
In tutte le interfacce che visualizzano un elenco di dati, c’è la possibilità di
ordinare i risultati rispetto ad una qualsiasi delle colonne, e di poter scorrere le
pagine comodamente, tramite una apposita sezione sottostante l’elenco dei dati,
visibile in figura 45.
Un ulteriore facilitazione è stata creata nelle tabelle,
offrendo la possibilità di interazione, agendo su un punto qualsiasi della riga,
senza dover agire limitatamente solo sui link.
Figura 41: Risultati ricerca fatture
53
__
Università degli studi di Ferrara
Figura 42: Risultati ricerca fornitori
Figura 43: Risultati ricerca fornitori in amministrazione
54
__
Università degli studi di Ferrara
Figura 44: Dettagli fornitore non attivo
Figura 45: Link per la visualizzazione delle pagine
5.7.
Accessibilità e stampa
Come già detto, l’accessibilità è stata ottenuta con un corretto utilizzo dei
fogli di stile (CSS). Nell’applicazione sono stati creati e inseriti all’interno delle
pagine due fogli di stile, il primo per la normale visualizzazione, e il secondo per
la stampa. Di seguito è riportata la sintassi utilizzata per l’inserimento dei CSS:
<link href="../folStyle.css" rel="stylesheet" type="text/css" media="screen" />
<link href="../folStylePrint.css" rel="stylesheet" type="text/css" media="print" />
L’attributo “media” permette di specificare al browser quale foglio di stile caricare
per la tipologia di visualizzazione scelta. Nel nostro caso sono stati utilizzati due
55
__
Università degli studi di Ferrara
valori: “screen” e “print”. Il valore “screen” indica la modalità di visualizzazione
classica, invece il valore “print” indica la modalità di visualizzazione di stampa.
Attivando la stampa, o più semplicemente l’anteprima di stampa (vedi
figura 46), verrà creata una visualizzazione della pagina con il foglio di stile
“folStylePrint.css”, che ha il compito di formattare i contenuti in un formato
stampabile, nascondendo le parti inutili alla stampa (come menù, sottolineature
dei collegamenti, colori superflui, zone utili solamente alla navigazione, ecc…) e
modificando, se necessario, la formattazione dei contenuti rimanenti.
Figura 46: Anteprima di stampa fatture
56
__
5.8.
Università degli studi di Ferrara
Amministrazione utenti e fornitori
La sezione di amministrazione è stata migliorata e ampliata con nuove
funzionalità. Tra queste è presente una gestione completa degli utenti di dominio
e dei fornitori. In figura 47 è possibile vedere l’interfaccia di amministrazione
degli utenti di dominio. Qui è possibile aggiungere un nuovo utente abbinandogli
i permessi più appropriati. Il nome utente inserito, deve essere uguale ad un
utente di dominio, in caso contrario non avrebbe nessun effetto. Di seguito al
form per l’inserimento, è presente una tabella contenente tutti gli utenti già
presenti, le relative autorizzazioni, e la data di ultimo accesso. In questa tabella è
possibile, tramite il link Aggiorna, di aggiornare i permessi di uno specifico
utente, e tramite il link Elimina, di eliminare un utente dalla lista. Si ricorda inoltre
che chi ha un livello di autorizzazione inferiore al livello massimo, che in questo
caso è quello di “SUPER_AMMINISTRATORE”, può modificare i permessi fino al
proprio
livello
e
non
oltre.
Ad
esempio,
un
utente
con
livello
“AMMINISTRATORE” può dare ad un qualsiasi utente (modificandone o
creandone uno) al massimo i permessi di “AMMINISTRATORE” e non di
“SUPER_AMMINISTRATORE”.
Figura 47: Amministrazione utenti di dominio
57
__
Università degli studi di Ferrara
La sezione di amministrazione permette, inoltre, di amministrare l’accesso
dei fornitori. Per fare ciò si può utilizzare il modulo di ricerca per cercare un
fornitore, poi visualizzare i dettagli del fornitore scelto, e infine scegliere, tra le
opzioni disponibili, l’azione da effettuare. Le operazioni possibili sono:
“Attivazione”, “Sospensione”, “Riattivazione”, “Generazione nuova password” e
“Disattivazione”. L’operazione di “Attivazione” permette di abilitare l’accesso, e
genera una password alfanumerica di 8 caratteri mostrata a video, che verrà in
seguito comunicata al fornitore per il primo accesso. La “Sospensione” sospende
l’accesso fino alla riattivazione. La “Riattivazione” riattiva un fornitore
precedentemente sospeso. L’opzione “Generazione nuova password”, permette
di generare una nuova password, che verrà obbligatoriamente cambiata al
successivo accesso, nel caso in cui un fornitore se la sia dimenticata. La
“Disattivazione” elimina tutte le informazioni di accesso di un fornitore, utile nel
caso in cui il comune non abbia più rapporti con un determinato fornitore. Un
esempio è visibile in figura 48. Sotto le informazioni del fornitore, sono disponibili
le azioni possibili. Nella figura è possibile sospendere, disattivare e generare una
nuova password.
Figura 48: Dettagli fornitore attivo
58
__
5.9.
Università degli studi di Ferrara
Statistiche
La capacità di registrare gli accessi è considerata necessaria e spesso
obbligatoria per legge. E’ stata creata una sezione per le statistiche del servizio,
che permette di tenere sotto controllo gli accessi e altre informazioni aggiuntive.
In figura 49 è possibile vedere una schermata delle statistiche generali. Qui
sono visibili alcuni dettagli: un resoconto numerico degli accessi totali e degli
accessi per singola categoria, il numero dei fornitori attivi, il numero di quelli
sospesi, il numero totale delle scansioni caricate. Un’altra funzionalità è quella di
poter visualizzare il numero degli accessi effettuati per ogni utente (vedi figura
50).
Figura 49: Statistiche generali
Figura 50: Statistiche accessi per utente
59
__
Università degli studi di Ferrara
Infine, è presente la possibilità di visualizzare l’elenco di tutti gli accessi registrati
(vedi figura 51). Qui sono visibili lo username dell’utente che ha avuto accesso, il
suo indirizzo IP e il timestamp.
In questo servizio non c’è stato bisogno di generare statistiche sofisticate,
avendo un’importanza minore rispetto ad altri servizi. Cosa ben differente se si
parla di servizi come l’anagrafe che ha un impatto superiore in ambito di privacy,
nel quale potrebbe esserci il bisogno di una statistica più completa che, ad
esempio, possa mantenere la traccia degli spostamenti o delle azioni effettuate
da un utente. Nell’eventualità che qualche malintenzionato riesca a visualizzare
dati riservati o addirittura a comprometterli, risultano utili, statistiche più complete
che possano fornire informazioni sulla possibile provenienza di questa persona,
sui dati che sono stati osservati o modificati, e su come è stato possibile
l’accesso a sezioni non autorizzate.
Figura 51: Elenco di tutti gli accessi
60
__
Università degli studi di Ferrara
5.10. Altre Funzionalità
Richiesta informazioni fattura:
Mentre un fornitore controlla le proprie fatture, può notare qualcosa che non và
nei dati, oppure qualcosa di poco chiaro. E’ quindi necessario fornire uno
strumento che permetta di contattare il Comune per informazioni o chiarimenti.
Sotto i dettagli di ogni fattura (vedi figura 52) è presente un collegamento che
porta alla schermata visibile in figura 53, la quale permette di inoltrare una
richiesta di informazioni. Nella richiesta vengono automaticamente incluse le
informazioni della fattura e lo username di chi è collegato al servizio, inoltre dà la
possibilità di inserire altre informazioni come nome, cognome, indirizzo, e-mail
(campo obbligatorio), la tipologia di richiesta, se si desidera una risposta, e il
testo della richiesta. Il tutto viene inviato ad un indirizzo e-mail impostato in
amministrazione.
Figura 52: Collegamento richiesta informazioni in dettaglio fattura
Figura 53: Modulo richiesta informazioni fattura
61
__
Università degli studi di Ferrara
Aggiunta e visualizzazione scansioni:
Volendo offrire un servizio completo, è stata offerta ai fornitori la possibilità di
fare il download delle scansioni originali delle fatture. Sotto i dettagli di ogni
fattura, se è stata caricata una scansione, è presente un collegamento che
permette di scaricare la scansione sul proprio computer, o di aprirla direttamente
con programmi come Acrobat Reader (se la scansione è in formato PDF) oppure
con un visualizzatore di immagini (se la scansione è una semplice immagine). La
gestione delle scansioni è stata ideata accettando qualsiasi tipologia di file,
lasciando al client
il compito di aprirli. L’amministrazione delle scansioni è
possibile, nella sezione di dominio, solo a chi ha permessi superiori o pari al
livello AMMINISTRATORE. Nella zona sottostante i dettagli delle fatture, sono
presenti, se si è autorizzati, le opzioni relative alle scansioni. Sono visibili le
opzioni “Visualizza scansione” ed “Elimina scansione”, se è già stata caricata
una scansione, altrimenti verrà visualizzato un campo in cui è possibile
selezionare sul proprio PC il file da caricare, e un link che permette di eseguire il
caricamento. In figura 54 è visibile un esempio in cui non è presente nessuna
scansione.
Figura 54: Opzione di aggiunta scansione fattura
62
__
Università degli studi di Ferrara
Impostazioni generali del servizio:
Nella sezione di amministrazione, è presente un pannello di gestione delle
impostazioni generali del servizio, il quale è accessibile solamente a chi ha un
livello pari a SUPER_AMMINISTRATORE. Questo pannello visualizza le
informazioni delle impostazioni registrate, e ne consente la modifica dei valori.
Le informazioni visualizzate sono: il codice dell’impostazione, il valore e una
descrizione (utilità e utilizzo). In figura 55 è visibile una schermata contenente
alcune impostazioni inserite in fase di programmazione:
-
L’impostazione ACCESSO_DOMINIO, permette di attivare o disattivare
l’accesso a chiunque sia autentificato dal dominio. Se l’opzione è disattivata,
possono accedere solo gli utenti che hanno un livello di autorizzazione
diverso da DOMINIO, cioè registrato nei permessi utente;
-
L’impostazione DEBUG_VARIABILI_DOMINIO, permette di abilitare o
disabilitare, nella sezione di dominio, la visualizzazione di tutte le variabili
utilizzate, questo permette di facilitare la risoluzione dei problemi di
programmazione della sezione di dominio;
Figura 55: Schermata impostazioni generali del servizio
63
__
-
Università degli studi di Ferrara
L’impostazione DEBUG_VARIABILI_FORNITORI, permette di abilitare o
disabilitare, nella sezione fornitori, la visualizzazione di tutte le variabili
utilizzate, questo permette di facilitare la risoluzione dei problemi di
programmazione della sezione fornitori;
-
L’impostazione EMAIL_SUPPORTO, permette di settare l’indirizzo e-mail a
cui verranno recapitate le richieste di informazioni;
-
L’impostazione NUM_REC_PER_PAGINA, permette di settare, nelle pagine
con molti dati, quanti record visualizzare per pagina;
-
L’impostazione PATH_SCANSIONI, permette di impostare il percorso
assoluto in cui verranno salvate le scansioni delle fatture.
E’ possibile, se nascono richieste, aggiungere nuove impostazioni manualmente
sul database e in seguito richiamarle all’interno degli script, tramite un’apposita
funzione. In figura 56 è possibile vedere una porzione di codice che, tramite la
funzione getImpostazione(), carica il valore delle impostazioni e le registra nella
sessione.
session_register("num_record_per_pagina");
session_register("email_supporto");
session_register("path_scansioni");
session_register("accesso_dominio");
session_register("debug_variabili_dominio");
$_SESSION["num_record_per_pagina"] =
getImpostazione($connessione,"NUM_RECORD_PER_PAGINA");
$_SESSION["email_supporto"] =
getImpostazione($connessione,"EMAIL_SUPPORTO");
$_SESSION["path_scansioni"] =
getImpostazione($connessione,"PATH_SCANSIONI");
$_SESSION["accesso_dominio"] =
getImpostazione($connessione,"ACCESSO_DOMINIO");
$_SESSION["debug_variabili_dominio"] =
getImpostazione($connessione,"DEBUG_VARIABILI_DOMINIO");
Figura 56: Codice per il caricamento delle impostazioni
64
__
Università degli studi di Ferrara
5.11. Test del servizio
L’anticipata conclusione del progetto ha portato ad una fase di analisi e
test più completa, permettendo di apportare modifiche e aggiungere parti che
avevano un’importanza minore. Inizialmente, era stato richiesto un servizio con
un sistema di protezione minimo e con solamente due livelli di autorizzazione:
“Dominio” e “Amministratore”. Analizzando il progetto, sia da parte dei dipendenti
del comune che da parte mia, sono state trovate modifiche da apportare ad
alcuni particolari e trovate nuove funzionalità da aggiungere. A seguito di questa
analisi sono state aggiunte o modificate le seguenti funzionalità:
-
Aggiunto un modulo di ricerca dei fornitori nella parte di dominio, finalizzata
alla visualizzazione delle fatture del fornitore ricercato;
-
Creato un sistema di protezione più complesso (nuovo sistema di
autenticazione e codifica);
-
Creati nuovi livelli di permessi. Sono stati aggiunti nuovi livelli (UTENTE,
SUPER_AMMINISTRATORE)
e
modificati
i
permessi
per
il
livello
AMMINISTRATORE;
-
Ampliata e aggiornata la gestione degli utenti di dominio. Ora è possibile
gestire i nuovi livelli di autorizzazione;
-
Aggiunto un pannello di amministrazione per le impostazioni generali del
servizio;
-
Aggiunta la capacità di abilitare o disabilitare l’accesso a tutti i dipendenti del
comune che hanno permessi uguali a DOMINIO;
-
Modificate e aggiunte scritte nell’intestazione per rendere più chiare le
informazioni di accesso;
-
Aggiunta la possibilità di ricercare le fatture in base allo stato;
-
Aggiunto un pannello completo per la visualizzazione delle statistiche.
Un’ulteriore fase di test è stata superata con successo, e non sono stati rilevati
errori o malfunzionamenti del servizio.
65
__
Università degli studi di Ferrara
6. Conclusioni
Questa tesi è il frutto di un progetto svolto nella cornice di un tirocinio
effettuato presso il Comune di Cento, in cui è stata creata un’applicazione Web,
chiamata “Fatture On-Line”, per la consultazione delle fatture e dei fornitori. Si
tratta di un semplice servizio che permette ai fornitori, previa abilitazione, di
consultare le proprie fatture, e ai dipendenti del comune di visualizzare i dettagli
delle fatture e dei fornitori.
La nuova applicazione descritta in questa tesi sostituisce il vecchio
servizio “Fatture On-Line” che soffriva di limitazioni e non rispettava le normative
vigenti di accessibilità. Durante le varie fasi in cui è stata creata la nuova
applicazione, sono emerse problematiche di diverso tipo che sono state tutte
risolte; di questo è interessante osservare come una buona progettazione possa
rendere le cose più semplici rispetto a problemi imprevisti, e dare la possibilità di
affrontare casi difficili con meno difficoltà e perdita di tempo. Ne è stato un
esempio la creazione del sistema di autenticazione, nato in principio in un modo
e poi stravolto. L’architettura di base del codice ha permesso di sostituire il
vecchio blocco di autenticazione con il nuovo in modo facile e veloce.
Un domani, se ce ne fosse l’esigenza, si potrebbe migliorare l’uso dei
permessi, ad esempio dando la possibilità di eliminare un utente solo al
SUPER_AMMINISTRATORE,
attualmente
ogni
utente,
con
accesso
all’amministrazione, può eliminare tutti gli utenti con privilegi pari o inferiori al
proprio. Potrebbe essere utile offrire una statistica più completa che registri tutti i
movimenti e le azioni di un utente, o addirittura un sistema che invii una e-mail di
segnalazione, se vengono avvertite delle intrusioni o delle forzature del sistema.
Questo progetto ha permesso di affrontare una moltitudine di aspetti non
affrontati o affrontati in parte in ambito universitario, come la programmazione in
php, descritta in parte e con nozioni molto basilari, come l’approfondimento della
struttura e configurazione di Microsoft SQL Server. Ciò nonostante, l’istruzione e
la cultura offerta dall’Università ha permesso di apprendere e approfondire
velocemente i sistemi, le piattaforme di sviluppo e tutto quello che non era
conosciuto in precedenza.
66
__
Università degli studi di Ferrara
Il tirocinio mi ha fornito un’esperienza molto ricca riguardante sia aspetti
formativi che collaborativi. Ho avuto modo di approfondire conoscenze e di
apprenderne di nuove, che mi hanno arricchito, in particolar modo ho dato
particolare importanza ad argomenti come l’accessibilità e la sicurezza.
Approfondire l’accessibilità mi ha permesso di comprendere maggiormente la
costruzione di interfacce, ma soprattutto capire come l’utilizzo di queste possa
essere difficoltoso da parte di utenti disabili. Studiare a fondo la sicurezza mi ha
consentito di acquisire conoscenze ulteriori, studiare metodi implementativi e
dare maggiore importanza alla protezione, a partire dalle basi di un’applicazione.
Ho inoltre avuto modo di poter collaborare con un gruppo di persone competenti,
che mi hanno accolto e inserito in un ambiente di lavoro maturo, e mi hanno
offerto pieno supporto e disponibilità, con le quali ho potuto lavorare con serenità
e sintonia.
7. Riferimenti
[CSS 2.1]
http://www.w3.org/TR/CSS21/
[Ente ECMA]
http://www.ecma-international.org/
[HTML 4.01]
http://www.w3.org/TR/html401/
[Linguaggio JavaScript]
http://developer.mozilla.org/en/docs/JavaScript
[Linguaggio PHP]
www.php.net
[Linguaggio SQL]
http://www.wiscorp.com/SQLStandards.html
[Microsoft Active Directory]
http://www.microsoft.com/windowsserver2003/
technologies/directory/activedirectory/
[Microsoft SQL Server]
http://www.microsoft.com/italy/sql/
[Server Web Apache]
www.apache.org
[Protocollo SSL]
http://wp.netscape.com/eng/ssl3/
[WAI]
www.w3c.org/WAI/
[W3C]
www.w3c.org
67
__
Università degli studi di Ferrara
8. Indice delle figure
Figura 1: Pagina principale di accesso al servizio.................................................7
Figura 2: Pagina di ricerca ....................................................................................8
Figura 3: Risultati ricerca.......................................................................................8
Figura 4: Schema generale del servizio ..............................................................10
Figura 5: Schema di cifratura ..............................................................................12
Figura 6: Schema di codifica ...............................................................................12
Figura 7: Schema procedura Batch.....................................................................14
Figura 8: Nuove tabelle per il sistema .................................................................15
Figura 9: Schema struttura del filesystem principale...........................................16
Figura 10: Schema struttura dettagliata del filesystem .......................................16
Figura 11: Esempio di interfaccia del portale del comune...................................17
Figura 12: Esempio di interfaccia del servizio .....................................................17
Figura 14: Intestazione servizio, accesso di dominio ..........................................19
Figura 15: Layout pagine servizio .......................................................................19
Figura 16: Footer con Access Key ......................................................................20
Figura 17: Dati sulla diffusione dei principali server web ....................................27
Figura 18: JavaScript Document Object Model (DOM) .......................................36
Figura 19: Schema della rete del Comune di Cento ...........................................38
Figura 20: Tabella Fornitori .................................................................................38
Figura 21: Tabella Fatture ...................................................................................39
Figura 22: Tabella Dettaglio ................................................................................39
Figura 23: Tabella Permessi ...............................................................................40
Figura 24: Tabella Fatture_s ...............................................................................40
Figura 25: Tabella Log_Fatture ...........................................................................41
Figura 26: Tabella Impostazioni ..........................................................................42
Figura 27: Pagina di acceso al servizio...............................................................42
Figura 28: Maschera di protezione Dominio........................................................43
Figura 29: Maschera di protezione Apache.........................................................43
Figura 30: Pagina di accesso al servizio per i fornitori abilitati............................44
68
__
Università degli studi di Ferrara
Figura 31: Schema di criptazione........................................................................45
Figura 32: Query per l’autenticazione .................................................................46
Figura 33: Extended Store Procedure xp_md5 ...................................................46
Figura 34: User defined function fn_md5 ............................................................47
Figura 35: Finestra permessi utente fatture per la funzione fn_md5...................47
Figura 36: Finestra permessi utente fatture per la libreria xp_md5.....................48
Figura 37: Schema di codifica .............................................................................49
Figura 38: Modulo di ricerca fatture.....................................................................52
Figura 39: Opzioni di ricerca ...............................................................................52
Figura 40: Modulo di ricerca fornitore..................................................................52
Figura 41: Risultati ricerca fatture .......................................................................53
Figura 42: Risultati ricerca fornitori......................................................................54
Figura 43: Risultati ricerca fornitori in amministrazione.......................................54
Figura 44: Dettagli fornitore non attivo ................................................................55
Figura 45: Link per la visualizzazione delle pagine .............................................55
Figura 46: Anteprima di stampa fatture ...............................................................56
Figura 47: Amministrazione utenti di dominio .....................................................57
Figura 48: Dettagli fornitore attivo .......................................................................58
Figura 49: Statistiche generali.............................................................................59
Figura 50: Statistiche accessi per utente ............................................................59
Figura 51: Elenco di tutti gli accessi ....................................................................60
Figura 52: Collegamento richiesta informazioni in dettaglio fattura ....................61
Figura 53: Modulo richiesta informazioni fattura .................................................61
Figura 54: Opzione di aggiunta scansione fattura...............................................62
Figura 55: Schermata impostazioni generali del servizio ....................................63
Figura 56: Codice per il caricamento delle impostazioni .....................................64
69
