Introduzione
1.1 Web statico e Web interattivo
In principio il Web era una semplice collezione di pagine HTML statiche collegate tra di loro
tramite link ipertestuali. Lo scopo principale era quello di rendere disponibile su Internet documenti
correlati come in un enorme ipertesto. La necessità di una maggiore interattività tra l’utente e il
server Web, nata soprattutto nel momento in cui grandi aziende hanno visto nella rete delle reti, un
nuovo veicolo commerciale, ha indirizzato gli sforzi nello sviluppo di strumenti per rendere il Web
sempre più "dinamico". Un classico esempio è dato dai motori di ricerca: l’utente inserisce in una
form una parola chiave e invia al server la richiesta restando in attesa di una risposta in tempo reale.
Dalla parte del server viene a questo punto attivata una procedura in grado di interrogare un
database e di generare una pagina HTML con la lista dei link richiesti. Per fare questo, l’HTML non
è sufficiente e quindi è stato introdotto da subito uno standard che consentisse di far comunicare le
richieste HTTP con una applicazione residente sul server, lo standard CGI (Common Gateway
Interface).
Sinteticamente, l’interazione tra browser e applicazione CGI segue i questa procedura:
il browser invia al server Web una richiesta facendo riferimento al nome dell’applicazione
seguita da una serie di parametri;
il server Web riconosce che la richiesta deve essere indirizzata all’applicazione specificata e
ne attiva un’istanza passandole opportunamente i parametri
l’applicazione effettua l’elaborazione in base ai parametri acquisiti e crea sullo standard
output un flusso di dati che costituisce la pagina di risposta per il browser.
il server Web cattura il flusso di dati generato dall’applicazione CGI e la trasforma in una
risposta HTTP
L’applicazione CGI può essere uno script di shell del sistema operativo o di un linguaggio
interpretato (ad esempio Perl) oppure una applicazione vera e propria sviluppata con un qualsiasi
linguaggio di programmazione e che segue alcune regole per interfacciarsi con il Web.
1.2 Client-side scripting
L’interfaccia CGI tuttavia presenta dei limiti: ad esempio anche per semplici elaborazioni vengono
richieste molte risorse al server, e in certi casi ciò può portare a ritardi sulla risposta o ad un
eccessivo carico sul server stesso. Si pensi al caso di invio di dati in qualche modo errati (ad
esempio, una data non valida) che attivano un’istanza di applicazione CGI con l’unico effetto di
notificare l’erroneo inserimento di dati e con la conseguenza di consumare risorse del server e della
banda di trasmissione.
Per superare questo genere di problemi, Netscape prima e Microsoft dopo, hanno pensato di
permettere ai loro browser, di interpretare particolari linguaggi, detti linguaggi di scripting
(JavaScript, Jscript e VBscript), che permettono al client di effettuare alcune semplici elaborazioni,
permettendo sicuramente al server di alleggerire il carico e dando una spinta decisiva verso le
attuali capacità interattive del Web.
1.3 Introduzione ad ASP
Il successo ottenuto dal client-side scripting ha portato in breve tempo allo sviluppo di linguaggi di
scripting anche per il lato server, iniziando prima con ambienti specializzati, come ad esempio
Borland IntraBuilder dove è Javascript il linguaggio sever-side utilizzato e poi orientandosi verso
linguaggi di scripting integrati nel server Web, come ad esempio in Netscape Enterprise Server.
Cavalcando questa tendenza, la Microsoft, rilasciando la versione 3.0 di Internet Information Server
(IIS), ha introdotto sul mercato degli scripting server-side, la tecnologia Active Server Pages (ASP),
con l’idea di sfruttare non solo le potenzialità degli strumenti server dedicati alla connettività, ma
anche attraverso la tecnologia COM (Common Object Model), sfruttare tutte le risorse che il server
Microsoft ha a disposizione e coinvolgendo anche i linguaggi di scripting come Jscript e Vbscript.
1.4 A cosa serve e come funziona
Le pagine ASP sono completamente integrate con i file HTML, sono facili da creare e non
necessitano di compilazione, sono orientate agli oggetti e usano componenti server ActiveX.
Possiamo affermare che ASP, è lo strumento che riesce a far convogliare tutte le risorse disponibile
sul server, per realizzare un sito Web (che nell’ottica ASP coincide con una applicazione) che possa
sfruttare diverse tecnologie in modo trasparente.
Le pagine di un sito non sono più una semplice collezione di documenti HTML ma un insieme di
pagine contenenti codice script interpretabile dal server Web, il quale effettua le elaborazioni
specificate prima di inviare la pagina HTML risultante al browser che l’ha richiesta.
E’ da sottolineare che il risultato della elaborazione del motore ASP, è una pagina HTML standard
che offre di conseguenza il vantaggio, di essere indipendente dal tipo di browser utilizzato. La
figura 1 sintetizza lo schema di funzionamento di un’applicazione ASP:
Figura 1
Il browser richiede una pagina ASP;
il Web server preleva la pagina ASP ed attiva l’interprete ASP per la pre-elaborazione della
pagina, coinvolgendo eventualmente altri componenti presenti sul server
il risultato dell’elaborazione eventualmente altri componenti presenti sul server
il risultato dell’elaborazione viene inviato al browser tramite il protocollo HTTP
1.5 ASP e client/server
Tra i vantaggi di ASP, è stato messo in risalto, la generazione di pagine Web in HTML standard,
ottenendo in tal modo una completa indipendenza dell’applicazione Web dal particolare browser
utilizzato. Questo aspetto comporta tuttavia un lavoro notevole per il server che deve generare
pagine statiche. In un certo senso questa soluzione è in contrasto con il modello client/server
secondo il quale il carico di lavoro di elaborazione viene suddiviso tra le due entità. L’introduzione
stessa dei linguaggi di scripting client side aveva questo scopo. Con ASP si dovrebbe quindi
dedurre un ritorno al modello centrato esclusivamente sul server. Invece ASP mette a disposizione
del progettista, la possibilità di decidere quale parte del codice far eseguire dal client e quale dal
server, magari decidendolo sulla base del browser utilizzato.
1.6 ASP e i suoi utilizzi
Definire i contesti di applicazione di ASP, equivale a definire i contesti in cui è opportuno utilizzare
elaborazioni sul server. Tuttavia è possibile delineare alcuni tipi di applicazione per le quali ASP
può essere una soluzione indicata.
L’utilizzo per cui era stata progettata la tecnologia ASP, era originariamente quello di interfacciare
il browser con un database, ma basandosi sul modello COM (Component Object Model), ASP è in
grado di interagire con le applicazioni che seguono questo standard e riportare i risultati di questa
interazione sotto forma di pagine Web. Ad esempio la richiesta di un utente di visualizzare una
tabella si traduce in una richiesta da parte di ASP verso il database di accedere alla tabella in
questione, rappresentarla internamente tramite un oggetto ADO e tradurre il contenuto della tabella
in una serie di tag HTML. La possibilità di interagire con database ODBC compatibili, pone ASP
come uno dei mezzi più efficaci per la realizzazione di applicazioni distribuite indipendentemente
dal database utilizzato.
Inoltre il principio di interazione con applicazioni COM consente alle pagine ASP, di colloquiare
con sistemi di posta elettronica (ad esempio Exchange o SMTP server) oppure interagire con
applicazioni Microsoft come MTS (Microsoft Transaction Manager e Message Queue Server).
Infine, attraverso la tecnologia ActiveX , è possibile estendere le funzionalità di ASP, progettando
ex-novo, altri oggetti.
Portabilità e Integrazione
2.1 Portabilità di ASP
Abbiamo detto che ASP è stato introdotto da Microsoft nel 1997. E' quindi uno standard
relativamente giovane e legato alla tecnologia della azienda di Redmond. Infatti, affinché il codice
ASP possa essere interpretato, c'è bisogno che il Web server utilizzato, sia un server Active X come
ad esempio IIS o Personal Web Server (anche se per quest’ultimo ci sono alcune limitazioni di
utilizzo). Ultimamente (in particolare dalla Chili Soft con Chili!ASP) sono state realizzate anche
versioni per Netscape Enterprise, Lotus Domino, Solaris. Altre aziende stanno invece producendo
moduli aggiuntivi, scritti in Java, per server Unix (Linux, Novell, Sun, Macintosh, HPUX, SGI,
SCO,Dec Alpha, IBM OS/2, RS/6000, AS/400, S/390, Apache, FastTrack/Enterprise servers, Sun
WebServer, Java WebServer,IIS, WebSphere and Lotus Domino). In particolare Chili Software ha
annunciato lo sviluppo di una nuova tecnologia, Denominata Chili!Beans, che consentirà di
interfacciare applicazioni ASP e componenti JavaBean: ciò renderebbe ASP totalmente esportabile
e in grado di imporsi come standard. Altro fatto che fa pensare ad ASP come una soluzione di
successo, è l’indirizzo architetturale dato ad alcuni ambienti applicativi. Essi infatti, si ispirano
direttamente a questa tecnologia, come nel caso dell’estensione Cold Fusion Markup Language, che
definisce un linguaggio di markup proprietario destinato all’interpretazione da parte di alcuni Web
server.
Ma l’esempio più clamoroso è costituito dalla Sun che ha scelto di emulare ASP utilizzando la
tecnologia Java direttamente all’interno di pagine HTML, con JSP (Java Server Pages).
2.2 Integrazione
Il fatto che ASP, sia una tecnologia Microsoft, non preclude che questa tecnologia non possa essere
utilizzata con prodotti non proprietari della stessa casa software.
2.2.1 ASP e COM
ASP è perfettamente integrato nell’Active Server Model di Microsoft: esso rappresenta un ponte che
mette in comunicazione il Web server e i componenti COM presenti sul server. Un’applicazione
ASP complessa può essere costituita da una serie di componenti messi in relazione tra di loro e con
il Web server mediante un linguaggio di scripting. Questo comporta l’uso di tecniche note per la
realizzazione di componenti o il riuso di componenti pre-esistenti, purché questi non facciano uso di
elementi visuali, come finestre, toolbar, ecc.
L’utilizzo di componenti esterni al Web server consente di estendere le funzionalità dell’ambiente
ASP e di costruire applicazioni complesse o interfacciare applicazioni esistenti con il Web. Un
ruolo fondamentale per l’aggancio dei componenti esterni viene affidato all’oggetto predefinito
Server, che tramite il metodo CreateObject() crea una connessione ad un’istanza di un oggetto
ActiveX. La sintassi di CreateObject() è la seguente:
Server.CreateObject(progID)
dove progID è l’identificativo della classe o il tipo di oggetto da istanziare nel formato
AppName.ObjectType, con AppName il nome del componente e ObjectType la classe. Una volta
istanziato l’oggetto, è possibile utilizzarne tutti i metodi e le proprietà pubbliche.
Ad esempio, supponendo di avere a disposizione un componente per la gestione di magazzino
(Magazzino) che fornisce un oggetto per la gestione degli articoli (Articolo), è possibile creare una
sua istanza da un’applicazione ASP tramite l’esecuzione della seguente istruzione JScript:
ArtMag = Server.CreateObject("Magazzino.Articolo")
Da questo momento in poi è possibile invocare qualsiasi metodo dell’oggetto facendo uso della
classica dot notation, cioè la sintassi Oggetto.Metodo.
2.2.2 ASP e BackOffice
L’integrazione di ASP nel modello COM si evidenzia particolarmente nell’interfacciamento con i
prodotti Microsoft della famiglia BackOffice. Infatti, con la versione di ASP fornita con IIS 4.0 è
disponibile un oggetto predefinito (ObjectContext) per l’interazione con MS Transaction Server,
una serie di componenti per l’interazione con MS Exchange Server e SMTP Server (Collaboration
Data Objects for NT Server) e un insieme di componenti per dialogare con MS Message Queue
Server.
L’insieme di questi componenti consentono di realizzare applicazioni robuste ed efficienti con poco
sforzo. Per fare un esempio, è possibile effettuare dei trasferimenti di articoli da un magazzino ad
un altro, affidando la gestione della transazione a MS Transaction Server. Con i Collaboration Data
Objects for NT Server (CDONTS), è possibile realizzare sistemi di gestione di messaggi e posta
elettronica su Web veramente sofisticati, sfruttando le potenzialità di MS Exchange Server e SMTP
Server e ottimizzando l’invio di informazioni asincrone tramite i componenti di MS Queue Server.
2.2.3 ASP e database
Un ruolo senza dubbio rilevante di ASP è quello di mediatore tra Web server e un sistema di
gestione di database. Questo è infatti l’uso più comune di questa tecnologia, un uso che ne ha
senz’altro favorito il successo. Grazie ad ActiveX Data Object (ADO) è possibile accedere a
qualsiasi database ODBC o OLEDB compatibile, usufruendo dei vantaggi che questa tecnologia
offre, tra i quali la semplicità di accesso ai dati e l’indipendenza dell’applicazione dal tipo di
database.
Tramite ADO, la gestione di un database non presenta particolari difficoltà. ASP supporta
un’efficiente gestione delle connessioni ad un database sfruttando la funzione di connection pooling
di ODBC 3.5. Questa funzione consente la condivisione di una connessione tra richieste provenienti
da utenti diversi, evitando di creare nuove connessioni, operazione che riduce le prestazioni del
database, e riducendo il numero di connessioni inattive.
2.2.4 Supporto dei linguaggi di scripting
Un linguaggio di scripting non è un vero e proprio linguaggio di programmazione: con un
linguaggio di scripting è possibile effettuare elaborazioni e gestire le risorse messe a disposizione da
un ambiente ospite, ma non è possibile realizzare applicazioni complete ed autonome. ASP
consente di utilizzare un linguaggio di scripting all’interno del Web server. In realtà, è possibile
utilizzare più linguaggi di scripting all’interno di un’applicazione ASP e addirittura all’interno di un
file ASP.
ASP supporta in modo nativo due linguaggi di scripting, VBScript e JScript. Se non diversamente
specificato, ASP interpreta il codice script che trova all’interno dei marcatori <% e %> come codice
VBScript, il linguaggio predefinito. E’ possibile comunque modificare il linguaggio predefinito sia
a livello di Web server, cioè per tutte le applicazioni ASP gestite da IIS, che a livello di singola
applicazione, cioè per tutte le pagine che compongono un’applicazione. E’ comunque da tener
presente che impostare un linguaggio predefinito può portare problemi di compatibilità con altri
Web server non adeguatamente configurati: infatti, portando un’applicazione ASP da un Web
server con JScript come linguaggio predefinito su un Web server con VBScript predefinito è
evidente che la sua esecuzione causa problemi di interpretazione sul server di destinazione.
Tramite la direttiva @ LANGUAGE è possibile specificare il linguaggio da utilizzare all’interno di
una determinata pagina ASP. Così, ad esempio, se una pagina ASP contiene come prima linea la
direttiva
<% @ LANGUAGE = "JScript" %>
il motore ASP interpreterà il codice contenuto all’interno di quella pagina come codice JScript.
Inoltre, all’interno di una pagina possono essere utilizzati linguaggi di scripting diversi, potendo
sfruttare al massimo le caratteristiche proprie di ciascuno di essi. Utilizzando una versione arricchita
del tag <SCRIPT> è possibile specificare che un blocco di codice deve essere interpretato secondo
un determinato linguaggio:
<SCRIPT LANGUAGE="VBScript" RUNAT="Server" >
Codice script
</SCRIPT>
L’attributo RUNAT specifica a che livello deve essere interpretato lo script; se non viene impostato,
lo script è destinato all’interpretazione da parte del browser.
Oltre a VBScript e JScript, è possibile utilizzare un qualsiasi linguaggio di scripting il cui scripting
engine sia stato installato sul Web server. Uno scripting engine è un interprete di un determinato
linguaggio realizzato come oggetto COM secondo lo standard ActiveX Scripting
(www.microsoft.com/management/wsh.htm). Gli scripting engine di VBScript e JScript sono
installati insieme a IIS; tuttavia è possibile installare uno scripting engine anche per altri linguaggi,
come REXX, Perl, Python. Un esempio di scripting engine Perl è PerlScript di Activeware. In
genere l’installazione di uno scripting engine non è un’operazione complessa; occorre tuttavia
effettuare alcune modifiche manuali al registro di sistema quando si installano scripting engine di
linguaggi che non supportano la dot notation per l’accesso ai metodi di un oggetto.
La sintassi
3.1 Cenni preliminari
Dopo aver visto gli aspetti principali di ASP, cominciamo a studiarne la sintassi e i mezzi che
abbiamo a disposizione per le nostre applicazioni. Esaminandone più da vicino "l’anatomia",
possiamo dividere una pagina ASP in tre parti:
1) Testo
2) Marcatori HTML
3) Comandi script
In un documento con estensione .asp è consentito utilizzare variabili, cicli e istruzioni di controllo,
grazie alla possibilità di richiamare la sintassi di un linguaggio di scripting, come ad esempio il
VBscript e il Jscript, ma anche perl e rexx e altri. La scelta del linguaggio dipende in primo luogo
dalle necessità del programmatore e dal tipo di esecuzione che si vuole avere: se si vogliono
eseguire gli script dal lato server è preferibile utilizzare il VBscript, mentre se ci si vuole affidare
alla potenza degli "scripting engine" (motore che interpreta i comandi dei linguaggi di scripting e li
esegue) dei singoli navigatori è sicuramente meglio utilizzare il Jscript, semplice ed efficace.
Il codice ASP è sempre delimitato da i due marcatori <% e %>. Ad esempio la seguente riga:
<% x="ciao" %>
assegna alla variabile x la stringa "ciao". Una pagina può essere costituita solamente da codice ASP,
oppure avere ASP immerso nel codice HTML: in entrambi i casi l’estensione deve essere .asp.
Come accennato, all’interno della pagina è possibile sempre inserire un codice in un linguaggio
diverso da ASP: in questo caso deve però essere dichiarato dove tale codice va eseguito.
Supponendo allora di voler usare uno script in Jscript, la giusta sintassi è la seguente:
<SCRIPT LANGUAGE = Jscript RUNAT= [server oppure client]>
Il valore di default per il parametro RUNAT è "server". Una volta definita una funzione in un
qualsiasi linguaggio di script, per richiamarla basta usare l’istruzione call, come nell’esempio che
segue:
Esempio con "Call"
Commenti
<% Call PrintDate %>
<SCRIPT LANGUAGE=Jscript RUNAT=Server> //Questa è l'istruzione di
function PrintDate()
cui si parlava
{
var x
x = new Date()
Response.Write(x.+ getDate())
}
</SCRIPT>
//Il metodo write
dell’oggetto Response,
scrive in output il valore
di x
Per l’esempio precedente abbiamo definito una funzione in Jscript, che poi abbiamo richiamato
all’interno del codice ASP. Ciò si rende necessario ogni qualvolta si ha bisogno di funzioni o
procedure, dato che ASP, non è in grado di definirle. Esso però mette a disposizione oltre a Call,
anche un’altra istruzione, include, che permette di inserire in un file asp, il contenuto di un file
esterno che può essere di testo, html, asp, grafica o qualsiasi altro file presente sul server. La
sintassi è la seguente:
<!--INCLUDE FILE="nomefile.est" -->
e va usata sempre al di fuori dei tag <%,%>, che delimitano gli script ASP.
3.2 Istruzioni fondamentali
Cominciamo con il vedere come sia possibile in ASP, compiere operazioni cicliche utilizzando le
istruzioni di iterazione messe a disposizione. Esse sono di tre tipi: DO ….. UNTIL (o WHILE)
LOOP, WHILE….WEND e FOR….NEXT. Vediamo un esempio per ognuna:
Esempio con "Do while"
<title>Esempio 2</title>
<body bgcolor="#FFFFFF"></head>
<p>Do Loop con while<br>
<%
counter = 1
thismonth = month(now())
Do while counter < thismonth + 1
response.write "month number " & counter & " "
response.write "__________" & "<br><br>"
If counter >13 then
exit do
end if
counter = counter+1
Loop
%>
<hr>
Commenti
//month(now())
restituisce il numero del
mese corrente
//La if ... then...end if
invece ha la stessa
sintassi che in VB
//L'istruzione exit forza
l'uscita da un ciclo
</body>
</html>
//Da notare che se si
vuole inserire una
stringa, occorre farla
precedere
e seguire da & come
nell'esempio
In questo esempio è stata introdotto anche l’istruzione if…then…Else…EndIF di cui vedremo nei
successivi esempi, la sintassi completa ed altre applicazioni. E’ invece utile mostrare un esempio
dell’istruzione Select Case, che permette di sveltire la scrittura del codice, nel caso in cui ci siano
diverse istruzioni if da svolgere:
Esempio con "Select case"
Commenti
<TITLE>Esempio 3</TITLE>
<body bgcolor="#FFFFFF">
Inserisci un numero da 0 a 4
<form>
Inserisci il tuo grado di stipendio (0-4):
<input type="text" name="grado"><br>
<input type="submit" name="Invia">
</form>
<%
dim GradoSalario
GradoSalario=request.querystring("grado")
Select Case GradoSalario
case 0,1
response.write("Poveraccio...")
case 2,3
response.write("Buongiorno Signore !")
case 4
response.write("Eccellenza come va ?")
End Select
%>
</BODY>
</html>
Continuiamo, presentando ora un esempio sull’istruzione, for…next, diviso in più parti e in cui
troviamo tutti i possibili utilizzi dell’istruzione:
Esempio con "For…Next" 1
<HTML>
<HEAD>
<TITLE>Esempio 4</TITLE>
<BODY bgcolor="#FFFFFF"></HEAD>
Commenti
<%
for counter = 1 to 5
response.write "now we are looping" & "<br>"
next
%>
</BODY></HMTL>
//In questa prima parte,
l’uso di for next, è quello
tradizionale
Esempio con "For…Next" 2
Commenti
<HTML>
<HEAD>
<TITLE>Esempio 5</TITLE>
<BODY bgcolor="#FFFFFF"> </HEAD>
<%
for counter = 1 to 5
response.write "now we are on loop number " &
counter & "<br>"
next
%>
</BODY></HTML>
Esempio con "For…Next" 3
<HTML>
Commenti
<HEAD>
<TITLE>Esempio 6</TITLE>
<BODY bgcolor="#FFFFFF"> </HEAD>
<%
for counter = 0 to 25 step 5
response.write "now we are on loop number " &
counter & "<br>"
next
//In questo caso invece
l’incremento avviene
specificando il passo
attraverso l’istruzione
step
%>
</BODY></HTML>
Esempio con "For…Next" 4
Commenti
<HTML>
<HEAD>
<TITLE>Esempio 7</TITLE></HEAD>
<BODY>
<%
for counter = 50 to 25 step –5
response.write "now we are on loop number " &
counter & "<br>"
next
//L’istruzione step può
essere usata anche per un
"conto alla rovescia"
%>
</BODY></HTML>
Concludiamo questa prima carrellata di esempi, con quello che riguarda il ciclo WHILE…WEND e
l’esempio di come sia possibile effettuare un "ciclo infinito" con l’istruzione DO…LOOP:
Esempio con "While….Wend"
Commenti
<TITLE>Esempio 5</TITLE>
<body bgcolor="#FFFFFF">
<HTML>
cont=0;
<%
WHILE cont=5 DO
Response.write Ciao a tutti!
Cont=cont+1
WEND
%>
</BODY>
</HTML>
Esempio con "Do…Loop"
Commenti
<TITLE>Esempio 6</TITLE>
//In questo esempio non
c’è nessun modo per
uscire dal ciclo se non
cambiare la pagina!
(Attenzione: il processo
rimane attivo sul server a
me no che
l’amministratore non lo
<body bgcolor="#FFFFFF">
<HTML>
<%DO%>
‘ not ready yet!
uccida!)
<%LOOP%>
</BODY>
</HTML>
E’ interessante anche notare come in questo caso, sia usato ASP, in piena fusione con l’HTML.
Infatti le istruzioni in ASP sono tutte racchiuse all’interno dei tag <% %>: in questo modo è
possibile usare i tag e le istruzioni HTML.
Diamo infine, un’occhiata a come in ASP, sia possibile gestire gli array. ASP mette a disposizione
la possibilità di gestire collezioni di dati, statiche o provenienti da form. La sintassi per dichiarare
un array è la seguente:
ReDim Array(dim1,dim2)
In questo caso abbiamo definito un array bidimensionale di dimensioni dim1 e dim2. Per accedere
ai suoi elementi basta inserire i vaolri degli indici, ricordando che essi partono dallo zero fino a
(dim1)-1.
3.3 Gli oggetti predefiniti
La grande diffusione di ASP e le sue enormi potenzialità, sono per buona parte dovute agli oggetti
che il linguaggio mette a disposizione per la gestione dell’output, dell’input e delle operazioni che il
client vuole o deve compiere sul server. Come già abbiamo accennato poi, è possibile, attraverso le
specifiche ActiveX, progettare oggetti ad hoc per determinate applicazioni. In questo lavoro, ci
occuperemo però solamente degli oggetti Built – In. L’oggetto viene caricato in memoria, solo nel
caso in cui venga richiesto il suo utilizzo. Vediamone dunque un elenco:
Response Object
Si usa per mandare testo, dati e gestire cookies verso il browers
Request Object
Gestisce i dati dei form, i cookies e le variabili sul server
Server Object
Permette di accedere ai metodi e alle proprietà del server. Il metodo più utilizzato è
Server.CreateObject, che permette la definizione di oggetti ActiveX
Session Object
Permette di spedire dati ed interagire con un particolare utente che naviga nel sito, senza che tali
dati siano visibili a tutti
ADO Object
Gestisce le collezioni della tecnologia ADO. Nel seguito lo useremo per le operazioni con i
database
Application Object
Permette di manipolare i dati all'interno di uno script che saranno resi visibili a tutti quelli che
stanno navigando sul sito o utilizzando lo script in quel momento
BrowserCap Object
Permette di riconoscere il browser e le impostazioni (ad esempio la risoluzione,il numero di colori
etc) che il visitatore sta utilizzando, adattando il sito al software dell'utente
FileSystem Object
Permette di manipolare files e directories
Ognuno degli oggetti presentati, ha una collezione di metodi, proprietà ed eventi, di cui
elencheremo ora le proprietà soffermandoci con degli esempi sulle caratteristiche più interessanti di
ognuno.
3.3.1 Response Object
La sintassi per l'oggetto Response è:
Response.collection/property/metodo
I collection dell'oggetto Response sono:
Cookies: Si usano per determinare il valore dei cookies
Le property per l'oggetto Response sono:
Buffer: serve per il controllo dell'input quando si reindirizza una pagina con il metodo Redirect
CacheControl: determina se il proxy riesce a mantenere in cache il contenuto delle pagine ASP
CharSet: Specifica il set di caratteri utilizzato
ContentType: Specifica il protocollo HTTP utilizzato
Expires: Specifica il tempo che deve trascorrere prima che una pagina presente nella cache del
browser
ExpiresAbsolute: Specifica la data e l'ora quando la pagina deve essere cancellata dalla cache del
browser
IsClientConnected: indica se il client è ancora connesso al server
I metodi dell'oggetto Response sono:
Write: scrive una stringa in output
Redirect: permette il collegamento a un'altra pagina
AddHeader: pone il valore tra i tag <Header> ad un valore value
AppendToLog: Aggiunge una stringa al log del webser per una interrogazione
BinaryWrite: scrive le informazioni inviate senza nessuna conversione in caratteri
Clear: cancella qualsiasi codice HTML nel buffer di trasmissione
End: ferma l'esecuzione della pagina ASP e restituisce il risultato corrente
Flush: Invia immediatamente il contenuto del buffer di trasmissione
3.3.2 L'oggetto Request
La sintassi per l'oggetto Request è la seguente:
Request.collection/property/method (variabile)
I collection dell'oggetto Response sono:
ClientCertificate: I valori dei campi memorizzati nei certificati del client, che vengono mandati
durante una richiesta via HTTP
Cookies: I valori dei cookie spediti via HTTP
Form: I valori dei form che vengono utilizzati durante una richiesta via HTTP
QueryString: I valori delle variabili in una interrogazione via HTTP
ServerVariables: i valori delle variabili del server
Le property per l'oggetto Response sono:
TotalBytes Read-only: Restituisce il numero di byte spediti da un client durante una richiesta al
server
I metodi dell'oggetto Response sono:
BinaryRead: Restituisce i dati spediti al server da un client come parte di un POST
Il parametro variabile è una stringa che specifica il valore da utilizzare in una colection o che deve
essere usata come input per un metodo o una property. Se la variabile non è presente quando si usa
una delle 5 collection viste, l'oggetto Request restituisce il valore EMPTY. Tutte le variabili,
possono essere visualizzate direttamente usando l'istruzione:
Request(variabile)
senza quindi il nome della collection. In questo caso, il sever cerca il valore della variabile,
analizzando le collection nell'ordine che segue: n QueryString, Form, Cookies, ClientCertificate,
ServerVariables.
Se una variabile con lo stesso nome esiste in più di una collection, l'oggetto Request restituisce la
prima istanza incontrata. Per questo è sicuramente meglio, specificare anche il nome della
collection, quando si vuole utilizzare una variabile. Ad esempio, invece di
Request.(AUTH_USER), è sicuramente meglio usare
Request.ServerVariables(AUTH_USER).
3.3.3 Server Object
La sintassi per l'oggetto Server è:
Server.property/metodo
Le property per l'oggetto Response sono:
ScriptTimeout: il tempo massimo che uno script può funzionare, prima che venga "disattivato" dal
server
I metodi dell'oggetto Server sono:
CreateObject: crea un istanza di un componente del server
HTMLEncoding: applica il codice HTML ad una generica stringa
MapPath: Sostituisce ad un percorso assoluto, una path virtuale sul server oppure il path relativo
alla pagina corrente in un path fisico
URLEncode: Applica le regole di encoding, inclusi i caratteri di escape, ad una stringa
3.3.4 Session Object
L'oggetto Session, viene usato per memorizzare particolari informazioni sulla sessione iniziata da
un utente. Le variabili i cui valori vengono modificati, si mantengono per tutta la durata della
sessione. Il web server attiva un'istanza dell'oggetto Session, ogni volta che un utente accede ad una
pagina. Il server poi, distruggerà l'istanza una volta che l'utente si sia disconnesso o dopo un certo
tempo di timeout. Attraverso l'uso di Session è possibile memorizzare le preferenze di ciascun
utente collegato: ad esempio, se "X" preferisce che non vengano visualizzate immagini ma solo
testo, è possibile memorizzare questa informazione in un istanza dell'oggetto che verrà richiamata,
nel momento in cui "X" si collega. La sintassi per l'oggetto Session è:
Session.collection/property/metod
Le collection per l'oggetto Session sono:
Contents: Contiene gli ITEMS che sono stati aggiunti alla sessione con i comandi di script
StaticObjects: Contiene gli oggetti creati con il tag <OBJECT>
Le property per l'oggetto Session sono:
CodePage: Il codice della pagina che sarà usato per il mapping simbolico del sito
LCID: L’identificatore locale per la sessione
SessionID: Restituisce un ID per l’utente connesso nella sessione avviata
Timeout: Indica il periodo di Timeout per la sessione in corso. Viene espressa in minuti
I metodi dell'oggetto Session sono:
Abandon: Questo metodo, distrugge un oggetto Session e rilascia tutte le risorse ritenute
dall’oggetto fino a quel
momento.
Session possiede anche la gestione di eventi. Essi sono gestibili nel file global.asa attraverso i
seguenti script:
Session_OnEnd
Session_OnStart
Nel seguito ci occuperemo meglio di questo oggetto nell’ottica della gestione della sicurezza.
ASP e database
In questa sezione ci occuperemo dell’utilizzo per cui è nato ASP e che quindi risulta essere il più
interessante aspetto di questo linguaggio di scripting: l’interfacciamento con i database ODBC
compatibili.
Innanzitutto ci occuperemo di approfondire alcuni aspetti della tecnologie ODBC e ADO, in seguito
faremo riferimento con un semplice esempio, ai metodi che ASP offre, per accedere on-line ad un
database.
In questo capitolo, si danno per scontate, la conoscenza di SQL e la sintassi di ASP, quest’ultima
per altro descritta nel capitolo precedente.
4.1 ODBC, IDC e ASP
Nell’ambito di una standardizzazione, che le permettesse di vendere i suoi prodotti anche a chi
proveniva da altri strumenti, per quel che riguarda i database, la Microsoft introdusse nel 1991,
l’interfaccia ODBC per poter fare interagire DBMS, sistemi operativi e protocolli di rete anche
diversi tra loro.
ODBC rende quindi possibile, l’utilizzo di qualunque DBMS a patto che esso fornisca i driver per
l’interfaccia. Lo sviluppo di Internet, come più volte affermato, ha poi deviato gli sforzi dei
programmatori, affinché gli utenti potessero interagire con i DBMS tramite un browser, ovvero
permettere la consultazione on-line di basi di dati. A tale scopo Microsoft ha associato ai suoi Web
Server, oltre alla possibilità di utilizzare l’interfaccia ODBC, la tecnologia IDC (Internet Database
Connector) ed infine, per rendere più semplice la programmazione e proporre una alternativa ai
programmi CGI, ha introdotto ASP.
Partiamo occupandoci di IDC. Internet Database Connector è uno strumento che può essere
utilizzato per spedire queries ad un database e formattare i dati che ritornano, in una pagina HTML.
In figura è illustrato come IIS e Personal Web Server consentono l'accesso a un database:
I Web browser inviano richieste ai server Internet usando il protocollo HTTP; i server Web
rispondono alle interrogazioni con documenti HTML grazie proprio a IDC.
IDC usa due tipi di file per controllare l'accesso al database e la generazione del documento HTML
di risposta:
file .idc Internet Database Connector
file .htx HTML extension
I file .idc contengono le informazioni necessarie per connettersi all'appropriato ODBC data source e
consentire l'esecuzione di istruzioni SQL. Inoltre questi file contengono informazioni sul nome e la
locazione del file HTML.
I file .htx contengono i template per il documento HTML che viene restituito al Web browser dopo
che i dati spediti hanno interagito con il database attraverso IDC.
Per usare IDC lo strumento è ASP, il quale nasconde sia all’utente che al programmatore la struttura
e la costruzione dei file .idc e .htx.
4.2 ASP e ADO
Abbiamo visto come ODBC sia uno standard, che agisce ad un livello molto alto tra database e
applicazione. Per utilizzare i driver ODBC, e quindi poter leggere un database, ASP si serve della
tecnologia ADO (ActiveX Data Objects) sviluppata da Microsoft pe il suo linguaggio ActiveX.
Tramite ADO è comunque possibile connettere una applicazione anche a database non ODBC
compatibile quali ad esempio OLE DB.
Per identificare il database su cui lavorare, gli script ADO hanno bisogno che sia specificato un
DSN (data source name) che univocamente specifichi il nome e il "luogo fisico" dove il database si
trova. A sua volta il DSN contiene le informazioni che riguardano la configurazione del database, le
specifiche sulla sicurezza, dove e come sono allocati i dati e può registrare le modifiche del file di
log.
ODBC mette a disposizione tre tipi di DSN: User, System o File. Eccone una breve descrizione:
Il System DSN, permette agli utenti di avere un login ad un server per l'accesso ad un database
Lo User DSN controlla l'accesso di determinati utenti secondo le specifiche di sicurezza del server.
Il File DSN, che mantiene il form del text file, permette l'accesso a diversi utenti e facilita il
passaggio di dati da un server ad un altro semplicemente copiando il File DSN.
I primi due sono mantenuti all'interno del registro di sistema del S.O. Nel corso del nostro studio
faremo riferimento al File DSN ed in particolare a quello che identifica i database Access.
Per utilizzare ADO, occorre disporre della dll msado15.dll invocata dal programID, ADODB. Il
modello ADO può essere riassunto con il seguente schema:
Gli oggetti di ADO, sono sette, ma tutti sono in qualche modo collegati con l’oggetto Connection,
quello che permette di connettere l’applicazione ASP con un database ODBC compatibile. Quindi
una volta dichiarato un oggetto Connection, è possibile gestire gli errori di connessione attraverso
l’oggetto Error. Oppure possiamo compiere operazioni sul database usando l’oggetto Command,
grazie al quale è possibile specificare stringhe che possono essere query o comandi per interagire
con la base di dati. A sua volta command, permette di definire parametri all’interno delle stringhe di
comando utilizzando l’oggetto Parameter. In alternativa all’uso di Command, ADO da la
possibilità di accedere ai record di un database utilizzando l’oggetto Recordset che a sua volta
sfrutta i metodi dell’oggetto Field attraverso il quale è facile spostarsi tra i campi di una tabella di
un database.
Per ognuno di questi oggetti, esistono diversi metodi e il loro approfondimento va forse oltre lo
scopo di questo lavoro. Ci limiteremo allora a presentare le caratteristiche dei metodi che verranno
usati nell’esempio che presentiamo, dove lo scopo sarà quello di implementare le operazioni basilari
che si devono poter compiere su un database.
4.3 Un piccolo esempio
Il modo migliore per capire come sia possibile interagire con una base di dati utilizzando ASP, è
quello di studiare un semplice esempio e su di esso compiere le operazioni elementari come
inserzione, cancellazione, ricerca e visualizzazione dei dati. Considereremo un semplice database
Access costituito da una sola tabella, che rappresenta i dati associabili ad un libro e discuteremo
ognuna delle operazioni sopra citate.
4.3.1 Connessione
Prima di procedere nell’esempio, vediamo in che modo si stabilisce la connessione tra il file ASP e
il database. I metodi sono diversi e nel seguito gli utilizzeremo indifferentemente, tutti . In questo
esempio, per quel che riguarda la visualizzazione, la connessione avviene usando l’oggetto
ADODB.RecordSet:
Set rst =
Server.CreateObject("ADODB.records
et")
rst.Open strQuery, strProvider
Con il metodo rst.open apriamo materialmente la comunicazione con il database che si trova sul
server, nel percorso individuato attraverso la stringa strProvider e definiamo anche
l’interrogazione (in questo caso statica) che si vuole effettuare sul database e che viene letta
attraverso la stringa strQuery.
strProvider="DRIVER=Microsoft Access Driver (*.mdb); DBQ=" & Server.MapPath("/")
& "\asp\applic\motore\libri.mdb;"
strQuery="SELECT * FROM tablibri WHERE titolo='"&titolo&"' OR
autore='"&autore&"' OR categoria='"&cat&"' OR
editrice='"&ed&"'"
Su strQuery non c’è molto altro da dire, mentre è interessante porre l’attenzione su strProvider.
Notiamo infatti che per definire il path dove si trova il file Access, utilizziamo il metodo
dell’oggetto Server, MapPath: in questo modo rendiamo il percorso "relativo" e non assoluto. Ciò
però potrebbe comportare problemi di carico sul server. Se allora il programma viene sviluppato
solo per una macchina e non si prevede di dover in futuro, esportare le pagine realizzate su altri
server, è preferibile usare la seguente modalità per definire il path:
strProvider="DRIVER=Microsoft Access Driver (*.mdb); DBQ="&
"c:\inetpu
b\wwwro
ot\asp\ap
plic\moto
re\libri.m
db;"
Infatti in questo caso specifichiamo il path assoluto sulla macchina che stiamo utilizzando.
Il secondo metodo, che utilizzeremo per l’inserimento e la cancellazione di un record, sfrutta la
seguente sintassi:
Set cn = Server.CreateObject("ADODB.Connection")
cn.Open strProvider
In questo caso ci limitiamo a connettere il database con la nostra pagina. Quindi non abbiamo
ancora definito nessuno strumento per lavorare sui record. Per farlo dobbiamo definire il seguente
oggetto:
Set cm= Server.CreateObject("ADODB.Command")
Set cm.ActiveConnection = cn
Ora cm, ci permetterà di svolgere update, delete e insert, sulla base di dati.
Il terzo metodo per la connessione sfrutta invece le proprietà del driver odbc ed è un metodo
relativamente semplice e legato al file global.asa, di cui tratteremo in dettaglio nella seconda parte.
Per ora analizziamo il metodo con cui avviene tale connessione. In questo caso occorrerà interagire
con il sistema operativo (nel nostro caso Windows 98). All’interno del pannello di controllo occorre
selezionare la voce Origine Dati ODBC:
e selezionare poi il foglio DSN System:
Dopo aver premuto il tasto aggiungi occorre selezionare il driver per il database che si sta
utilizzando (nel nostro caso il database è un file Access) e premere fine. A questo punto appare
l’ultima schermata, quella che ci chiederà il DSN da associare e il percorso dove si trova il database
da leggere. Ultimate queste operazioni, la nostra base di dati sarà localizzata da ADO, con il nome
che gli abbiamo assegnato. Quest’ultimo metodo sarà quello che utilizzeremo per il nostro esempio
di sito commerciale.
4.3.2 Visualizzazione
Passiamo ora ad analizzare il nostro semplice esempio, partendo dalla più banale delle operazioni,
la visualizzazione dei campi di un semplice database, costituito solo da una tabella. Questa
limitazione non pregiudica la generalità del metodo che presenteremo: infatti le procedure che
utilizziamo ora, saranno poi usate anche nell’esempio finale di gestione di un sito e-commerce.
Lo script per visualizzare i dati nella tabella è la seguente:
Scrittura dei record di un database
<%
ON ERROR RESUME NEXT
IF rst.EOF THEN
Response.Write "Non ci sono record nel database"
ELSE
FOR i = 1 to rst.Fields.Count –4
Response.Write "<td width=200> "& rst(i).Name &"</td>"
NEXT
WHILE NOT rst.EOF
FOR i = 1 to rst.fields.count – 4
Response.Write "<td align=left valign=top
bgcolor='#ffffff'>"
& rst(i) &"</td>"
NEXT
Response.Write "<td width=250 bgcolor='#fad336'>
<a href='libri.asp?ID="&rst(0)&"'> '"&rst(2)&"' </a></td>"
rst.MoveNext
WEND
END IF
%>
Come già detto in precedenza, utilizziamo un oggetto ADO di tipo recordset: ciò ci permette di
definire in pratica un cursore che si muove sulle tuple della tabella. Per accedere quindi ad un
campo della tabella, la sintassi è la seguente:
rst(i) oppure rst("nome_campo")
per muoversi invece su un’altra tupla si usa il metodo:
rst.MoveNext
Più avanti vedremo altre caratteristiche dell’oggetto RecordSet relative alle operazioni che si
possono compiere su un database.
4.3.3 Cancellazione e ordinamento
Per cancellare e ordinare i dati di una tabella, sfrutteremo in parte lo script per la visualizzazione,
aggiungendo dei controlli che ci permetteranno di definire dei bottoni per l’ordinamento secondo i
diversi campi e per la cancellazione. Le righe di codice da aggiungere sono le seguenti:
Controlli per l’ordinamento rispetto ad un campo
<%
'Questa if serve per definire il pulsante per ogni
campo
'Che ci permette di ordinare la tabella per ogni campo
if request.form("sort")<> "" THEN
StrSort=request.form("sort")
ELSE
'decido rispetto a quale campo ordinare la tabella
come default
StrSort="AUTORE ASC"
END IF
%>
Definizione del campo per la Cancellazione
<%
'In questa IF identifico qual è il record che voglio
cancellare
tramite la chiave primaria della tabella ovvero ID1
IF Request("ID") <> "" THEN
strIDNum=Request("ID")
'Da notare che in questo caso apro la connessione
con il database
'Utilizzando ADODB.Connection. Questo perché
sui record del database non devo compiere
operazioni
set objConn =
server.createobject("ADODB.Connection")
objConn.Open strProvider
'In questo caso definisco l'oggetto cm utilizzando
ADODB.command set cm =
Server.CreateObject("ADODB.Command")
cm.ActiveConnection = objConn
cm.CommandText = "DELETE FROM Tablibri
WHERE ID1 = " &strIDNum
cm.Execute
END IF
%>
4.3.4 Inserimento
Ecco infine lo script per l’inserimento di un record nel nostro database:
Inserimento di record in una tabella
<%
titolo=request.form("titolo")
autore=request.form("autore")
cat=request.form("cat")
ed=request.form("editrice")
anno=request.form("anno")
prezzo=request.form("prezzo")
testo=request.form("testo")
imm=request.form("imm")
collana=request.form("collana")
Set cm= Server.CreateObject("ADODB.Command")
Set cm.ActiveConnection = cn
'Definiamo l'azione di inserimento su tutti i campi
cm.CommandText = "INSERT INTO tablibri (autore, titolo, categoria, editrice, anno, prezzo, testo, imm,
collana) VALUES
('"&autore&"','"&titolo&"','"&cat&"','"&ed&"','"&anno&"','"&prezzo&"','"&testo&"','"&imm&"','"&collana&"')
'Definiamo i parametri della query
cm.Parameters.Append cm.CreateParameter("type",200, ,255)
cm("type") = Request("SeedType")
cm.Execute
%>
4.3.5 L’oggetto RecordSet
Abbiamo visto in precedenza alcune proprietà dell’oggetto RecordSet ma vale la pena
approfondirne alcuni aspetti, dato che questo oggetto risulta essere un mezzo versatile e potente, per
la gestione dei dati in un database creando un set di record e le operazioni per operare su di esso.
Cominciamo ad esempio, con le operazioni di insert, delete e update. Abbiamo visto nei paragrafi
precedenti come sia possibile utilizzare l’SQL standard per svolgere queste azioni. Un altro via, è
utilizzare i metodi che RecordSet mette a disposizione. Supponiamo allora di voler inserire un
record in una tabella della nostra base di dati. Dopo essersi connessi utilizzando
Server.CreateObject("ADODB.recordset") e rst.Open strProvider, per inserire un nuovo record
basterà scrivere:
rs. AddNew
rs("Nome_campo1")=valore1
rs("Nome_campo2")=valore2
….
Rs.update
Analogamente utilizzando il metodo:
rs.delete
elimineremo il record che si sta puntando (anche se è possibile specificare quale record cancellare).
Un altro importante metodo è rs.close i che chiude la connessione stabilita con il database su cui si
sta operando.
Un’altra importante caratteristica di RecordSet è la possibilità di definire dei parametri sulla
connessione che si effettua con un database. I più importanti sono CursorType e LockType e si
definiscono nel seguente modo:
Rs.Open Connessione,CursorType,LockType
Il CursorType definisce il tipo di cursore cioè la rappresentazione dei records e definisce anche il
tipo di viste possibili su di essi. I tipi di cursore sono quattro:
1. Cursore di default (valore 0): Definisce un cursore statico ad eccezione del fatto che
permette spostamenti solo in avanti e non indietro dato che questo cursore non deve tenere
traccia dei record aggiunti, modificati o cancellati da altri utenti
2. Cursore Keyset (valore 1): possono "vedere" delle modifiche apportate da altri utenti,
nonché spostarsi tra i record in avanti ed indietro. Non si possono invece vedere i record
aggiunti o eliminati da altri utenti
3. Cursori Dinamici (valore 2): Questo tipo di cursore è in grado di vedere qualsiasi cosa:
modifiche, aggiunte e cancellazioni fatte anche da altri utenti e consentono qualsiasi
spostamento
4. Cursori Statici (valore 3): in questo caso è possibile spostarsi avanti e indietro ma non è
possibile rilevare le modifiche ai dati apportate da altri utenti
Il valore di LockType determina che tipo di blocco il database deve usare quando viene aperto un
RecordSet; questo ai fini del controllo di concorrenza sugli accessi ai dati da parte di più utenti
contemporaneamente. I tipi di lock sono:
1. AdLockReadOnly (valore 1): i dati possono essere solo letti
2. AdLockPessimistic (valore 2): i dati vengono bloccati (cioè non sono modificabili da altri
utenti) appena qualcuno comincia ad effettuare operazioni di modifica, così da garantire
un’assoluta integrità degli stessi ma a costo di spiacevoli rallentamenti del sistema; infatti
finche l’utente non termina le proprie modifiche quei dati rimangono bloccati
3. AdLockOptimistic (valore 3): questo tipo di blocco, crea un buffer temporaneo in cui
vengono conservati gli aggiornamenti e le modifiche, mentre i dati originali sono ancora
accessibili agli altri utenti. I dati vengono protetti dalle modifiche degli altri utenti solo nel
momento in cui viene lanciato un comando di aggiornamento (update)
Un esempio di utilizzo di queste caratteristiche di RecordSet, è nell’esempio di sito e-commerce,
nella sezione che riguarda la registrazione di nuovi utenti.
Gestire le Sessioni ( Sessions )
Una delle sfide nello sviluppare una applicazione Web funzionante è mantenere le informazioni
dello user lungo tutto il corso della sua visita ( session ) al sito Web.
Come sappiamo HTTP è un protocollo senza memoria; il server cioè non mantiene informazioni
sulle precedenti richieste dell'utente.
Questa caratteristica del protocollo HTTP quindi non consente di scrivere applicazioni Web come
cataloghi online, dove il sito Web deve mantenere in memoria le scelte fatte dal cliente.
ASP risolve il problema della gestione delle informazioni di sessione, mettendo a disposizione
l'oggetto Session. ASP gestisce le informazioni di stato a due livelli:
a livello di applicazione: consentendo di memorizzare ed accedere ad informazioni globali
all'applicazione e visibili quindi da tutti gli utenti.
a livello di sessione: permettendo la memorizzazione e l'accesso ad informazioni relative all'utente
di una determinata sessione.
Usando quindi l'oggetto Session è possibile creare applicazioni intelligenti che identificano ogni
visitatore e collezionano informazioni che consentono di tenere traccia delle scelte fatte dall'utente.
5.1 Che cosa è una sessione?
Le sessioni rappresentano uno dei più utili strumenti offerti da ASP. Quando un utente visita una
pagina ASP sul nostro sito, ASP considera questo una "sessione" e immediatamente differenzia
quell’utente da tutti gli altri collegati al sito. Ogni cosa che viene memorizzata nella sessione di
quell’utente può essere recuperata da quella pagina e manipolata dalle pagine successive per
rendere i dati mostrati sensibili al particolare utente collegato.
E’ importante sapere che le Sessioni vengono memorizzate sul server è non in cookies. Nessun
utente può quindi esaminare un cookie scoprendo in tal modo il contenuto di una qualsiasi variabile
di sessione.
5.2 Application values e Sessions values
Esistono due tipi di dati che la nostra applicazione può manipolare per poter "ricordare"
informazioni sull’utente:
SessionData
Questo tipo di dati sono generalmente riferiti ad un utente. La prima pagina e tutte le altre che
l’utente visita definiscono la sessione. Ogni dato memorizzato durante la sessione è un oggetto
privato. Il codice che segue mostra come memorizzare dati in una variabile di sessione:
<%
session("cognome")="Rossi"
session("nome")="Carlo"
%>
Application Data
I dati di applicazione sono visibili ad ogni utente. A differenza dei dati di sessione ogni pagina Web
può modificare questo tipo di informazioni rendendo però possibili problemi relativi alla
concorrenza degli accessi. Questo problema può essere comunque facilmente risolto usando i
metodi lock e unlock offerti dall’oggetto application; infatti dopo aver invocato un lock su di una
applicazione, nessun altro update può essere fatto finché l’unlock non viene invocato.
<%
application.lock
application("valore")=application("valore")+1
application.unlock
%>
5.3 Organizzazione di un’applicazione distribuita in ASP
Tecnicamente possiamo dire che il modulo che si occupa di verificare se una pagina contenga o
meno del codice ASP, il quale va eseguito prima che la pagina stessa venga inviata al client, non è
altro che un filtro ISAPI che viene eseguito all’interno di Internet Information Server. Per esso
un’applicazione ASP non è altro che una directory interna alla home page ( in genere chiamata
wwwroot ) e per la quale è attivo il permesso di esecuzione.
L’applicazione ASP è quindi rappresentata da tutti i file con estensione .ASP e da tutti gli altri che
si trovano all’interno di questa directory. Un’applicazione viene avviata quando un client richiede
una pagina ASP all’interno della directory che costituisce l’applicazione. E’ inoltre possibile
sfruttare il file GLOBAL.ASA per depositarvi al suo interno script riguardanti l’avvio e la chiusura
dell’applicazione.
Il file Global.asa è diviso in quattro eventi, o segmenti:
<script language=vbscript runat=server>
SUB Application_OnStart
END SUB
SUB Application_OnEnd
END SUB
SUB Session_OnStart
END SUB
SUB Session_OnEnd
END SUB
</script>
Supponiamo che un browser richieda una pagina ASP. Per prima cosa il server verificherà se già
esiste una istanza dell’oggetto APPLICATION. Se l’istanza non esiste ne verrà creata una. Il
server verificherà poi se esiste la procedura APPLICATION_OnStart dentro il file
GLOBAL.ASA per eseguire le inizializzazioni decise dal progettista del sito ( come ad esempio le
connessioni ai database ).
Successivamente il server istanzierà un oggetto SESSION generando un ID univoco che viene
trasmesso attraverso un cookie al browser che lo memorizza. Tale ID è conservato sul server in una
proprietà dell’oggetto SESSION detto SessionID che servirà al server per capire se un determinato
client che manda un cookie contenente un ID abbia o meno una sessione aperta nell’applicazione.
Fatto questo il server controlla ancora il file GLOBAL.ASA per eseguire una eventuale procedura
SESSION_OnStart la quale contiene informazioni per l’inizializzazione della sessione corrente.
Anche questa procedura è realizzata dal progettista del sito. Esistono inoltre gli eventi
APPLICATION_OnEnd e SESSION_OnEnd.
E’ data la possibilità al progettista di non scrivere nessun script per ognuno di questi eventi. Quindi
non è neanche necessaria la presenza del file GLOBAL.ASA stesso.
Una sessione termina quando viene invocato il metodo ABANDON dell’oggetto SESSION, o
quando scade un TIMEOUT associato alla sessione.
Quando non esistono più sessioni aperte viene invocata dal server la chiusura dell’applicazione.
5.4 Inizio e Fine di una Sessione
Una sessione può iniziare in tre modi differenti:
un nuovo utente richiede un URL che identifica un file .asp in un'applicazione, e il file Global.asa
per quella applicazione include una procedura Session_OnStart , oppure un utente immagazzina un
valore nell'oggetto Session o anche se un utente richiede un file .asp in un'applicazione, e il file
Global.asa dell'applicazione usa il tag <Object> per istanziare un oggetto sessione.
Una sessione automaticamente termina se
l'utente non richiede od aggiorna una pagina dell'applicazione per un determinato periodo di tempo.
In genere 20 minuti ne rappresenta il valore di default.
E' possibile modificare il tempo di timeout configurando la proprietà Session Timeout sulle opzioni
contenute su Internet Service Manager.
Il seguente esempio imposta il valore del Timeout a 5 minuti.
<% Session.Timeout = 5 %>
E' inoltre possibile forzare la terminazione della sessione con il seguente comando:
<% Session.Abandon %>
5.5 SessionID e Cookies
La prima volta che un utente richiede un file .asp all'interno di una data applicazione , ASP genera
un SessionID . Il SessionID è un numero prodotto con un complesso algoritmo che identifica in
modo univoco il singolo utente.
All'inizio di una nuova sessione, il server immagazzina il SessionID sul browser dell'utente sotto la
forma di un cookie.
Il sessionID cookie è simile ad una chiave di un lucchetto; quando l'utente interagisce con
un'applicazione durante una sessione, ASP può immagazzinare le informazioni per l'utente in un
lucchetto sul server.
Il SessionID cookie , trasmesso al server ( tramite HTTP ), abilita l'accesso a queste informazioni
nel senso che la chiave del lucchetto consente l'accesso al contenuto del lucchetto. Ogni volta che
ASP riceve una richiesta per una pagina, controlla se è presente un SessionID cookie.
Dopo aver immagazzinato un SessionID cookie sul browser dell'utente, ASP riutilizza lo stesso
cookie per guidare la sessione,
anche se l'utente richiede un altro file .asp
o richiede un altro file .asp in un'altra applicazione.
anche se l'utente abbandona la sessione ( oppure è scattato il Timeout ) , ASP continua ad
utilizzare lo stesso cookie.
Soltanto quando l'amministratore del server riavvia il server, ASP rigenera nuovi SessionID cookie.
ASP non invia i cookie di sessione sotto le seguenti condizioni:
se disabilitiamo le sessioni
oppure nelle pagine ASP è contenuto <%@ EnableSessionState=False %>
5.6 Immagazzinare dati nell'oggetto Session
L'oggetto Session mette a disposizione una array associativo dinamico che può immagazzinare
informazioni.
L'esempio seguente mostra come salvare due nuove variabili.
<%
Session("FirstName") = "Jeff"
Session("LastName") = "Smith"
%>
Per recuperare informazioni da un oggetto Session, basta usare il nome della variabile interessata.
Ad esempio:
Welcome <%= Session("FirstName") %>
Possiamo sfruttare l'oggetto Session anche per memorizzare ad esempio le scelte fatte dall'utente.
Ad esempio:
Potremmo memorizzare se l'utente preferisce navigare su una pagina solo testuale o anche con le
immagini.
<%
If Session("ScreenResolution") = "Low" Then
%>
This is the text version of the page.
<%
Else
%>
This is the multimedia version of the page.
<%
End If
%>
5.7 Vediamo come utilizzare i cookie
Lo script seguente mostra come sia possibile memorizzare dentro dei cookie dati inseriti dentro un
form e successivamente come cancellarli.<%
response.buffer=true
%>
<html><head>
<TITLE>cookiesform.asp</TITLE>&
<body bgcolor="#FFFFFF">
<%
ln=Request.Cookies("thatperson")("lastname")
fn=Request.Cookies("thatperson")("firstname")
st=Request.Cookies("thatperson")("state")
%>
<Form action = "cookiesformrespond.asp">
Form with Cookies<p>
Please enter your First Name<p>
<Input NAME="NameFirst" size ="40" value=<%=fn%>>
<p>
Please enter your Last Name<p>
<Input NAME="NameLast" size ="40" value=<%=ln%>>
<p>
Please enter your State abbreviation<p>
<Input NAME="State" MaxLength="2" value=<%=st%>>
<Input type=submit></form>
</body></html>
Lo script che segue mostra come memorizzare il cookie passato dal form precedente:
<%response.buffer=true%>
<html><head>
<TITLE>cookiesformrespond.asp</TITLE>&
<body bgcolor="#FFFFFF">
<%
l=request.querystring("namelast")
f=request.querystring("namefirst")
st=request.querystring("state")
cookypath="/learn/test"
cookydomain=".www.activeserverpages.com"
cookydie=date+365
Response.Cookies("thatperson")("lastname") = l
Response.Cookies("thatperson")("firstname") = f
Response.Cookies("thatperson")("state") = st
Response.Cookies("thatperson").Expires = cookydie
Response.Cookies("thatperson").Domain = cookydomain
Response.Cookies("thatperson").Path = cookypath
response.write Request.Cookies("thatperson")("lastname") & "<p>"
response.write Request.Cookies("thatperson")("firstname") & "<p>"
response.write Request.Cookies("thatperson")("state") & "<p>"
%>
</body></html>
Il seguente script mostra come cancellare il cookie:
<%response.buffer=true%>
<html><head>
<TITLE>cookiesformforget.asp</TITLE>&
<body bgcolor="#FFFFFF">
<%
cookiepath="/learn/test"
cookiedomain=".www.activeserverpages.com"
cookiesdie=date-365
Response.Cookies("thatperson").Expires = cookiesdie
Response.Cookies("thatperson").Domain = cookiesdomain
Response.Cookies("thatperson").Path = cookiespath
response.write "I will not remember you"
%>
</body></html>
5.8 Salvare lo Stato senza i Cookies
Non tutti i browser supportano i cookies. Spesso i browser che supportano i cookies vengono
impostati a non usarli. Se comunque l'applicazione necessita di memorizzare lo stato della
navigazione possiamo operare in altri modi; ovvero dobbiamo scrivere un meccanismo nostro per
passare dati tra pagine ASP.
Esistono due modi differenti per fare questo:
Aggiungere i parametri necessari sull'URL
Aggiungere dei valori nascosti in un FORM
Esempio:
Il seguente form HTML contiene un controllo nascosto, che invia anche l'identificatore dell'utente.
<FORM METHOD="POST" ACTION="/scripts/inform.asp">
<INPUT TYPE="text" NAME="city" VALUE="">
<INPUT TYPE="text" NAME="country" VALUE ="">
<INPUT TYPE="hidden" NAME="userid" VALUE= <%=UserIDNum(i) %>
<INPUT TYPE="submit" VALUE="Enter">
Il file Global.asa
Un'applicazione ASP è costituita dall'insieme dei file contenuti in una directory virtuale del Web
server e nelle sue subdirectory. Può essere una semplice home page o può consistere in un
complesso insieme di pagine e componenti correlati.
Come abbiamo visto a differenza di un sito Web tradizionale , un'applicazione ASP è in grado di
mantenere informazioni di stato, cioè informazioni condivise tra le pagine, superando l'assenza di
stato tipica del protocollo HTTP.
La gestione delle informazioni di stato viene effettuata tramite gli oggetti Application e Session.
Questi oggetti consentono, oltre alla condivisione di informazioni globali all'applicazione e locali
alla singola sessione utente , di gestire determinati eventi.
Infatti, a differenza di quanto avviene con l'approccio CGI o con altre tecniche di server-side
scripting, con ASP l'insieme delle pagine di una applicazione è visto come un insieme unico e come
tale ha un avvio e una terminazione.
L'avvio avviene alla prima richiesta ricevuta dal Web server relativa ad una pagina appartenente
all'applicazione; la terminazione avviene con la fine dell'esecuzione del Web server. Inoltre
ciascuna sessione utente ha anch'essa un inizio e una terminazione: l'inizio corrisponde alla prima
richiesta di una pagina da parte dell'utente, mentre la terminazione si verifica in corrispondenza
della scadenza di un intervallo di timeout predefinito.
L'esecuzione di script in corrispondenza dell'avvio e della terminazione di un'applicazione e/o di
una sessione richiede la presenza di un file, denominato Global.asa , contenente gli script
opportuni.
Il file la cui estensione .asa sta per Active Server Application, viene letto dal motore ASP all'avvio
dell'applicazione e all'inizio di cisacuna sessione utente. I file Global.asa possono contenere soltanto
i seguenti oggetti:
1.
2.
3.
4.
Eventi Application
Eventi Session
Dichiarazioni <Object>
Dichiarazioni TypeLibrary
6.1 Eventi Application
Un'applicazione ASP è composta di tutti i file nella root e in ogni sua sottodirectory.
Un'applicazione inizia appena l'utente apre una delle pagine Web dell'applicazione e termina in
corrispondenza dello shuts down del server.
L'applicazione ha due eventi:
l'evento Application_OnStart
l'evento Application_OnEnd
Possiamo realizzare script per questi eventi nel file Global.asa. Quando l'applicazione parte il server
controlla nel Global.asa e processa gli script contenuti in Application_OnStart . Quando invece
termina , vengono processati gli script di Application_OnEnd .
Application_OnStart
Questo evento occorre prima che la nuova sessione venga creata.
Sintassi:
<SCRIPT LANGUAGE=ScriptLanguage RUNAT=Server>
Sub Application_OnStart
...
End Sub
</SCRIPT>
Parametri
ScriptLanguage
Specifica lo script language usato per definire l'evento. Può essere VBScript oppure JScript.
Application_OnEnd
Questo evento occorre alla terminazione della applicazione.
Sintassi
<SCRIPT LANGUAGE=ScriptLanguage RUNAT=Server>
Sub Application_OnEnd
...
End Sub
</SCRIPT>
Parametri
ScriptLanguage
Specifica lo script language usato per definire l'evento. Può essere VBScript oppure JScript.
Attenzione:
Non si può chiamare il metodo MapPath nello script di Application_OnEnd .
6.2 Evento Session
Il Web server crea automaticamente una nuova sessione quando un utente ( non in possesso di una
sessione ) , apre una pagina Web dell'applicazione. Il server distrugge l'applicazione quando scade
un timeout associato alla sessione dell'utente, oppure quando invoca il metodo Abandon.
Una sessione ha due eventi associati:
1. L'evento Session_OnStart
2. L'evento Session_OnEnd
Come per l'evento Application è possibile associare a questi due eventi degli script.
Session_OnStart
L'evento Session_OnStart occorre quando il server crea una nuove sessione. Questo evento
rappresenta il momento giusto per definire tutte le variabili di sessione che verranno utilizzate
durante l'applicazione. Tutti gli oggetti predefiniti Application , ObjectContext , Request ,
Response , Server , Session sono disponibili all'interno di questo evento.
Sintassi
<SCRIPT LANGUAGE=ScriptLanguage RUNAT=Server>
Sub Session_OnStart
...
End Sub
</SCRIPT>
Parametri
ScriptLanguage
Specifica il linguaggio script utilizzato. Può essere VBScript o JScript.
Session_OnEnd
Questo evento occorre quando una sessione viene terminata o scade il relativo timeout. Sono
disponibili soltanto gli oggetti predefiniti Application , Server , Session.
Sintassi
<SCRIPT LANGUAGE=ScriptLanguage RUNAT=Server>
Sub Session_OnEnd
...
End Sub
</SCRIPT>
Parametri
ScriptLanguage
JScript o VBScript.
Attenzione
Non è possibile utilizzare il metodo MapPath all'interno di questo evento.
6.3 Dichiarazione degli <OBJECT>
E' possibile creare oggetti con uno scope di sessione o applicazione nei file Global.asa usando i tag
<OBJECT>. Gli oggetti creati nei file Global.asa vengono creati soltanto quando il server processa
lo script che contiene quell'oggetto, in questo modo è possibile risparmiare risorse di sistema.
Sintassi
<OBJECT RUNAT=Server SCOPE=Scope ID=Identifier
{PROGID="progID"|CLASSID="ClassID"}>
...
</OBJECT>
Parametri
Scope
Specifica la visibilità ( scope ) dell'oggetto. Nei file Global.asa, Scope può essere posto sia
al valore Session che al valore Application.
Identifier
Specifica il nome per l'istanza dell'oggetto.
ProgID
E' un identificatore che deve avere il seguente formato: [Vendor.]Component[.Version]
ClassID
Specifica un identificatore unico per un oggetto della classe COM.
Esempi
Il primo esempio crea un oggetto di sessione chiamato MyConnection usando il parametro ProgID.
Il secondo esempio invece crea l’oggetto usando il parametro ClassID.
<OBJECT RUNAT=Server SCOPE=Session ID=MyConnection
PROGID="ADODB.Connection">
REM Object Script
</OBJECT>
<OBJECT RUNAT=Server SCOPE=Session ID=MyConnection
CLASSID="Clsid:8AD3067A-B3FC-11CF-A560-00A0C9081C21">
REM Object Script
</OBJECT>
Attenzione
Gli oggetti creati nel file Global.asa possono essere utilizzati da ogni script nell'applicazione.
Per Esempio:
l’oggetto che qui viene creato nel file Global.asa può essere usato da qualunque script del progetto.
---GLOBAL.ASA--<OBJECT RUNAT=Server SCOPE=Session ID=MyAd PROGID="MSWC.AdRotator">
</OBJECT>
Possiamo far riferimento all'oggetto MyAd in ogni pagina della applicazione.
---SOME.ASP--<%= MyAd.GetAdvertisement("/ads/adrot.txt") %>
6.4 Esempi di Global.asa
Ricordiamo che un’applicazione può avere soltanto un file Global.asa.
Esempio 1
Questo esempio illustra il modo in cui costruire uno script che obblighi gli utenti a visitare una
determinata pagina , come prima pagina visitata. Se la pagina corrente ( all'interno dell'evento
Session_OnStart ) è la pagina definita come pagina iniziale, non fa nulla altrimenti usa il metodo
Response.Redirect per ridirezionare l'utente sulla home page desiderata.
<SCRIPT RUNAT=Server Language=VBScript>
Sub Session_OnStart
' Verifica che la prima pagina visitata dall'utente
' sia la home page da noi definita
' Sostituire startPage con il path
' della nostra Home Page
startPage = "/MyApp/StartHere.asp"
currentPage = Request.ServerVariables("SCRIPT_NAME")
if strcomp(currentPage,startPage,1) then
Response.Redirect(startPage)
end if
End Sub
</SCRIPT>
Attenzione:
Il precedente script funziona soltanto se il browser dell'utente supporta i cookies. E' necessario
quindi informare l'utente nella HOME PAGE che il sito Web necessita dell'abilitazione dei cookies.
Tutti gli eventi che seguono il metodo Redirect nell'evento Session_OnStart non vengono eseguiti.
<SCRIPT LANGUAGE=VBScript RUNAT=Server>
Sub Session_OnStart
' Session initialization script
Response.Redirect "http:/server/app/StartHere.asp"
End sub
</SCRIPT>
ESEMPIO 2
All'avvio dell'applicazione viene letto un file di testo contenente il valore con
cui inizializzare la variabile globale Application("accessi") per il conteggio
degli accessi al sito Web; all'inizio di ciascuna sessione utente il valore degli
accessi viene incrementato, mentre alla terminazione dell'applicazione il
valore aggiornato degli accessi verrà memorizzato nel file.
<SCRIPT LANGUAGE=VBScript RUNAT=Server>
Sub Application_OnStart
'Inizializza la variabile per il conteggio del numero di accessi
'leggendo il valore memorizzato in un file di testo
Set FileObject = Server.CreateObject("Scripting.FileSystemObject")
Set NAccessiFile =FileObject.OpenTextFile("accessi.txt", 1 , FALSE ,
FALSE )
Application("accessi") = NAccessiFile.ReadLine
End Sub
</SCRIPT>
<SCRIPT LANGUAGE=VBScript RUNAT=Server>
Sub Application_OnEnd
'Sovrascrive il file "accessi.txt" con un file aggio rnato
Set FileObject = Server.CreateObject("Scripting.FileSystemObject")
Set NAccessiFile =FileObject.CreateTextFile("accessi.txt", 1 , TRUE ,
FALSE )
NAccessiFile.WriteLine( Application("accessi"))
End Sub
</SCRIPT>
<SCRIPT LANGUAGE=VBScript RUNAT=Server>
Sub Session_OnStart
'Incrementa il numero di accessi
Application.lock
Application("accessi") = Application("accessi") + 1
Application.unlock
End Sub
</SCRIPT>
<OBJECT RUNAT=Server SCOPE=Scope ID=Identifier
{PROGID="progID"|CLASSID="ClassID"}>
</OBJECT>
Esempio 3
Con questo global.asa possiamo visualizzare il numero degli utenti collegati al nostro sito Web
senza dover utilizzare nessun file testo. In Application_OnStart inizilizziamo il timeout di sessione
e la variabile WhosOn che conta il numero di utenti online. In Sessione_OnStart incrementiamo
WhosOn mentre quando l’utente termina la sua sessione ( Session_OnEnd ) la decrementiamo.
<SCRIPT LANGUAGE="VBScript" RUNAT="Server">
Sub Application_OnStart
Session.Timeout = 3
Application.Lock
Application("WhosOn") = 0
Application.UnLock
End Sub
Sub Session_OnStart
Application.Lock
Application("WhosOn") = Application("WhosOn") + 1
Application.UnLock
End Sub
Sub Session_OnEnd
Application.Lock
Application("WhosOn") = Application("WhosOn") - 1
Application.UnLock
End Sub
</SCRIPT>
Per visualizzare la variabile WhosOn possiamo inserire il seguente script nella pagina iniziale della
nostra applicazione.
<%
response.write "Are Now " & Application("WhosOn") & " users at this page."
%>
Protezione di un’applicazione ASP
Supponiamo di voler restringere l’accesso a determinate porzioni di un sito Web. Ad esempio
perché il sito contiene informazioni riservate o dati personali. In questi casi vorremmo consentire
l’accesso al sito a visitatori esterni soltanto dopo averne verificato lo username e la password.
Siamo inoltre interessati a creare un sistema che consenta l’accesso libero al sito soltanto al prezzo
di una semplice email. Vogliamo infine realizzare un sistema che ci consenta di tenere traccia dei
movimenti del cliente nel sito.
Il Web server offre allo sviluppatore di siti Web una varietà di metodi per proteggere una
applicazione ASP dagli accessi di utenti non autorizzati.
7.1 Quali sono le possibili scelte?
Usando IIS si hanno diverse possibilità:
Secure NT File System
Una buona scelta se si è su una rete Windows, ed è possibile richiedere l'uso di Internet
Explorer e se non esistono proxy-server tra il browser ed il server.
Scrivere da soli il proprio filtro
Flessibile, ma può risultare complicato da realizzare.
Autenticazione basata sui cookie e pagine ASP
Usato se è necessario proteggere soltanto le pagine ASP. Può essere lento in quanto richiede
anche l’uso dei cookie. Questo sistema può essere ingannato.
7.2 I permessi NTFS ( Secure NT File System )
Possiamo rendere sicure le nostre applicazioni ASP applicando le primitive di accesso NTFS ai
singoli file o directory.
I permessi NTFS, rappresentanti le fondamenta del sistema di sicurezza del server Web, consentono
di definire i vari livelli di accesso a file o directory consentiti a gruppi di persone o a singoli utenti.
Quando un utente con un account valido cerca di accedere ad un file protetto, il computer del server
verifica il file chiamato Access Control List ( ACL ), il quale definisce i permessi per accedere ai
vari file protetti. Se l'account dello user ha sufficienti permessi per aprire i file, il computer fornisce
l'accesso. Questo accesso, a secondo dei casi, può consentire all'utente di modificare i dati, oppure
permettere soltanto di leggerli.
Perché usare NTFS :
Una buona scelta se si è su una rete Windows, ed è possibile richiedere l'uso di Internet Explorer e
se non esistono proxy-server tra il browser ed il server.
Se si lavora su una intranet NTFS può essere la soluzione ideale se
se ci sono pochi utenti
possiamo richiedere di utilizzare un browser compatibile con NTFS ( come Internet
Explorer ).
Perché non usare NTFS:
Vogliamo la compatibilità della nostra applicazione con browser che non siano
necessariamente IE.
Dobbiamo gestire un grande numero di utenti.
Per rendere sicura una applicazione ASP per un utente od un gruppo di utenti, bisogna assicurarsi di
impostare nel modo corretto i permessi NTFS sul file Global.asa.
Se il file Global.asa include comandi che restituiscono informazioni al browser e noi non abbiamo
protetto Global.asa, le informazioni verranno restituite al browser, anche se gli altri file del progetto
sono stati protetti.
E' possibile configurare i permessi del server Web, per definire come gli utenti potranno vedere,
eseguire, manipolare le pagine ASP.
Comunque anche se i permessi NTFS consentono una granularità nella definizione degli accessi da
parte degli utenti, i permessi vengono applicati a tutti gli utenti senza discriminare tra i diversi tipi
di account.
E' possibile seguire le seguenti regole quando si definiscono i permessi sugli accessi alle pagine
ASP:
Abilitare i permessi di lettura o di script sulle directory contenenti i file .asp
Abilitare i permessi di lettura e di script sulle directory contenenti sia i file .asp che altri
file come i .html.
Abilitare i permessi per la lettura e l'esecuzione su directory contenenti sia file .asp che
altri file eseguibili come i .exe e i .dll i quali richiedono dei permessi di esecuzione per
essere eseguiti.
7.3 Cookie Security
Possiamo usare i cookies di sessione per memorizzare lo username e la password da un form,
validarli entrambi e quindi inizializzare una variabile di sessione per indicare che lo user ha
superato correttamente il login. Il Web server può quindi utilizzare questi cookie per configurare le
applicazioni ASP, e consentire una sessione personalizzata per l'utente.
E’ importante far notare che è conveniente usare i cookies con le pagine ASP se non abbiamo
problemi a creare in VBScript ( o Jscript ) una nostra soluzione oppure se non abbiamo
problemi nell’escludere gli user che non usano i cookies. Infine è conveniente usare questo
livello di sicurezza se nella nostra applicazione abbiamo soltanto file con estensione .ASP.
Non conviene invece usare i cookies con le pagine ASP se vogliamo proteggere tutto il sito e non
semplicemente i file ASP, oppure se siamo preoccupati riguardo le prestazioni della nostra
applicazione. Un altro punto a sfavore di questo sistema di sicurezza è rappresentato dal fatto che
un sistema basato sui cookie può essere ingannato.
Nell’ esempio che segue vengono illustrati due script che mostrano come costruire un semplice
sistema di autenticazione. Il primo ( Login.asp ), non necessariamente un file ASP, contiene un
form che richiede all’utente di inserire il proprio username e la sua password. Il secondo (
LoginNow.asp ), che deve essere un’applicazione ASP, riceve i dati dal form e verifica che questi
coincidano con due valori predefiniti.
Creiamo una pagina di login:
Login.asp
<form action="loginNow.asp" method="POST">
Username: <input type="text" name="username" size="22"> <br>
Password: <input type="password" name="password" size="22"><br>
<input type="submit" value="Login Now">
</form>
Creiamo poi una pagina ASP che riceve e processa i risultati di Login.asp
LoginNow.asp
<%
username = Request.Form("username")
password = Request.Form("password")
if ("Alessandro" <> username) Then
response.Write("Spiacente, username e password incorretti (1)")
response.End
End if
if ("passwdBianchi" <> password) Then
response.Write("Spiacente, username e password scorrette (2)")
response.End
End if
Session("username")=username
%>
Salve Alessandro Bianchi!.
<a href=protected.asp>Ora può andare sulla tua pagina protetta</a>
In ogni pagina ASP ( se è una pagina HTML la trasformeremo in ASP ) inseriremo uno script che
verificherà lo username e la password. Se il progetto è composto di molte pagine possiamo inserire
in testa alla pagina ASP un include al file ASP qui sotto illustrato:
protected.asp
<%
username = Session("username")
if ("" = username) Then
response.Write("Spiacente, Accesso non consentito.")
response.End
End if
%>
Benvenuto.
7.4 Scrivere un sistema di autenticazione personalizzato
Se abbiamo le capacità, le risorse e il tempo necessari possiamo scrivere un sistema di
autenticazione noi stessi. Gli script che seguono mostrano come implementare un sistema di
sicurezza personalizzato utilizzando un database Microsoft Access chiamato customSecurity.mdb
contenente gli user e le password scelte dagli utenti.
Per prima cosa abbiamo bisogno di una pagina ( anche semplicemente una pagina HTML ) che
visualizzi un form per l’autenticazione dell’utente. La pagina securitylogin.asp che segue chiede
allo user di inserire il proprio username e la propria password. Questo è lo script securitylogin.asp
:
<html><head>
<title>securitylogin.asp</title>
</head><body bgcolor="#FFFFFF">
<form action="securityloginrespond.asp" method="POST">
Autenticazione:<p>
Name -&gt; <input NAME="userName" size="20"><br>
Password -&gt; <input NAME="userPassword" size="20"><br>
<input type="submit"><input type="reset">
</form></body></html>
I dati inseriti nel form vengono poi passati alla pagina ASP securityloginrespond.asp che li
elabora e li confronta con i dati contenuti nel database customsecurity.mdb. Per far funzionare lo
script è necessario modificare il path
/learn/test/secret/customsecurity.mdb
con quello in cui teniamo il nostro archivio delle password.
Lo script securityloginrespond.asp conterrà inizialmente le seguenti righe riguardanti
l’inizializzazione del database e la query che cercherà nel db lo user e la password inserite:
<%
dbname="/learn/test/secret/customsecurity.mdb"
myname=request.form("username")
mypassword=request.form("userpassword")
set conntemp=server.createobject("adodb.connection")
cnpath="DBQ=" & server.mappath(dbname)
conntemp.Open "DRIVER={Microsoft Access Driver (*.mdb)}; " & cnpath
sqltemp="select * from users where user='"
sqltemp=sqltemp & myname & "'"
set rstemp=conntemp.execute(SQLTemp)
Dopo aver eseguito la query se ne controlla il risultato verificando se il puntatore al database punta
alla fine dell’archivio. In questo caso è necessario rimandare l’utente alla pagina iniziale poiché il
cliente ha inserito dati errati.
If rstemp.eof then%>
user name errato <%=Myname%> on file!<br>
Try <A href='securitylogin.asp'>Logging in</a> again
<%response.end
end if
Infine se l’utente ha inserito username e password corretti vengono istanziate alcune variabili di
sessione e l’applicazione può continuare.
If rstemp("Password")=mypassword then
session("name")=rstemp("user")
session("securitylevel")=rstemp("securitylevel")
response.write "Security Level=" & session("securitylevel")
else%>
7.5 Evitare di memorizzare le pagine ASP nella cache
Ogni versione di un browser ha le sue regole per memorizzare le pagine visualizzate nella propria
cache. Per evitare che le pagine ASP vengano memorizzate nella cache , usiamo Response.Expires
<% Response.Expires = 0 %>
Il valore 0 forza le pagine memorizzate nella cache a morire immediatamente. Per evitare di
memorizzare qualsiasi cosa nella cache è necessario inserire il codice prima del tag <HTML>
Scrivere applicazioni Cross-Platform
Le applicazioni ASP possono essere eseguite su computer sui quali siano stati installati Windows
NT 4.0 ( o versioni successive ) o Windows 95 ( o Windows 98 ). In aggiunta, una versione ridotta
di ASP è disponibile sul Macintosh. Poiché Personal Web Server su Windows 95 e su Macintosh è
stato creato per scopi puramente personali ( pubblicazione di pagine Web personali ) , esistono
quindi differenze nelle diverse versioni di ASP.
ASP su Macintosh
Poiché la versione ASP su Macintosh è stata creata per scopi puramente personali, molte delle
caratteristiche di ASP su piattaforme Windows non sono disponibili.
ASP su Windows 95
Anche la versione ASP su Window95 ( o versioni successive ) è stata sviluppata per scopi
puramente personali. Sebbene l’esecuzione di pagine ASP si pienamente supportata, il Personal
Web Server non consente l’uso delle caratteristiche più avanzate di ASP.
ASP su Windows NT Workstation
Windows NT Workstation rappresenta la piattaforma ideale per sfruttare pienamente tutte le
caratteristiche offerte dalla tecnologia ASP.
La gestione dei file di testo in ASP
Il meccanismo proposto da Microsoft per la gestione dinamica delle pagine Web, ovvero le ASP,
consente anche la gestione dei file contenenti testo. In particolare ASP mette a disposizione due
oggetti che consentono di interagire con i file di testo, ovvero
FileSystemObject
TextStream
I due oggetti precedenti anche agendo entrambi su file testo svolgono compiti profondamente
diversi ma correlati fra loro.
FileSystemObject viene utilizzato per creare o aprire un file di testo, mentre TextStream viene
utilizzato per leggere o scrivere su un file già inizializzato con FileSystemObject.
Per illustrare come ASP gestisca i file di testo creiamo un’applicazione che consenta ad un utente
remoto di creare una propria homepage su un Web Server. L’unico strumento di cui avremo
bisogno per completare l’applicazione, oltre alle ASP, sarà una directory virtuale sul Web server
chiamata "freespace". Praticamente faremo finta di essere un provider che vuole offrire ai propri
utenti l’opportunità di inserire la propria HomePage all’interno del nostro sito. Per far questo
seguiremo la seguente strada:
creiamo un form dotato di un edit box che consenta all’utente di digitare del codice HTML,
successivamente salviamo sul Web Server il codice digitato dall’utente.
B.1 Il codice
Il primo passo è quello di mostrare all’utente un form col quale eseguire la sua identificazione.
I dati immessi verranno usati per assegnare un nome al file che dovrà contenere la Home Page del
cliente.
Riportiamo tutto il codice ASP.
<html>
<head>
<title>Default.asp</title>
</head>
<body>
<%
On Error Resume Next
Dim ObjFileSys
Dim ObjTextStream
Dim Filename
%>
<%
if IsEmpty(Request("Email")) Then
response.write("<form action='default.asp' method='POST'><br>")
response.write("Nome: <input type='Text' name='Nome' size='30'><br>")
response.write("Cognome: <input type='Text' name='Cognome' size='40'><br>")
response.write("Indirizzo E-mail: <input type='Text' name='Email'><br><br>")
response.write("<textarea name='myhomepage' cols='70'
rows='20'></textarea><br>")
response.write("<input type='Submit' name='OK' value='OK'>")
response.write("</form>")
else
Set objFileSys=Server.CreateObject("Scripting.FileSystemObject")
Filename=Server.MapPath("/freespace/" + request("Email") + ".asp")
Set ObjTextStream = ObjFileSys.OpenTextFile(Filename, ForAppending)
if err.value <> 0 then
Set ObjTextStream = ObjFileSys.CreateTextFile(Filename)
end if
ObjTextStream.Writeline(request("myhomepage"))
ObjTextStream.close
response.write("OK la tua Home Page &egrave; stata generata")
end if
%>
</body>
</html>
B.2 Vediamo nel dettaglio il codice ASP
Nelle prime righe
<%
On Error Resume Next
Dim ObjFileSys
Dim ObjTextStream
Dim Filename
%>
vengono inizializzate alcune variabili che risulteranno utili all’interno dello script. L’istruzione On
Error Resume Next indica che se si dovessero verificare errori essi dovranno essere intercettati e
l’esecuzione del programma non deve essere interrotta. Infatti al verificarsi di un errore verrà
impostato il valore di una variabile Err da 0 ad un codice identificante l’errore.
Successivamente viene eseguito un controllo sulla variabile Email:
if IsEmpty(Request("Email")) Then
Se è vuota verrà generato il form per l’inserimento dei dati.
Altrimenti se è piena viene eseguita il codice che crea fisicamente la Home Page utilizzando
come nome per il file la composizione ottenuta dalla somma dell’e-mail più la desinenza
.asp . Ad esempio http://nomesito/freespace/[email protected]
Poiché all’inizio il campo e-mail è vuoto, verranno eseguite le istruzioni
response.write("<form action='default.asp' method='POST'><br>")
response.write("Nome: <input type='Text' name='Nome' size='30'><br>")
response.write("Cognome: <input type='Text' name='Cognome' size='40'><br>")
response.write("Indirizzo E-mail: <input type='Text' name='Email'><br><br>")
response.write("<textarea name='myhomepage' cols='70'
rows='20'></textarea><br>")
response.write("<input type='Submit' name='OK' value='OK'>")
response.write("</form>")
che generano il form da riempire.
Dopo aver riempito il campo e-mail è possibile premere il pulsante submit che richiamerà ancora il
file default.asp. Poiché questa volta il campo e-mail è pieno verranno eseguite le istruzioni
Set objFileSys=Server.CreateObject("Scripting.FileSystemObject")
Filename=Server.MapPath("/freespace/" + request("Email") + ".asp")
Set ObjTextStream = ObjFileSys.OpenTextFile(Filename, ForAppending)
if err.value <> 0 then
Set ObjTextStream = ObjFileSys.CreateTextFile(Filename)
end if
ObjTextStream.Writeline(request("myhomepage"))
ObjTextStream.close
response.write("OK la tua Home Page &egrave; stata generata")
E’ in questa parte del codice che vengono creati i file. In particolare l’oggetto di tipo
FileSystemObject viene creato con l’istruzione:
Set objFileSys=Server.CreateObject("Scripting.FileSystemObject")
che crea un oggetto objFileSys del tipo FileSystemObject. Successivamente componiamo la
variabile FileName:
Filename=Server.MapPath("/freespace/" + request("Email") + ".asp")
Alla fine possiamo inizializzare il file testo:
Set ObjTextStream = ObjFileSys.OpenTextFile(Filename, ForAppending)
A questo punto dobbiamo dire la prima volta che si tenta di inizializzare il file in questo modo,
questa istruzione genererà un errore, infatti non si può aprire un file in modalità ForAppending (
scrivere in coda ) senza che il file esista. Ma grazie alla istruzione
On Error Resume Next
Quando il programma cerca di inizializzare il file che non esiste , l’algoritmo non si ferma e l’errore
viene conservato dentro la variabile err. In questo modo possiamo generare un test su tale variabile:
if err.value <> 0 then
Set ObjTextStream = ObjFileSys.CreateTextFile(Filename)
end if
e quindi creare il nuovo file.
Come possiamo vedere dal codice l’oggetto ObjFileSys serve per accedere al FileSystem mentre
ObjTextStream viene istanziato per manipolare il flusso dei dati, è cioè uno stream.
A questo punto possiamo scrivere il contenuto della variabile myhomepage all’interno del file
puntato da FileName:
ObjTextStream.Writeline(request("myhomepage"))
Alla fine chiudiamo il file.
B.3 La sintassi dell’oggetto TextStream
La sintassi esatta per la creazione di un oggetto di tipo TextStream è:
Set objFileSys = Server.createObject("Scripcting.FileSystemObject")
Set objTextStream = objFileSys.CreateTextFile( FileName,
[OverWrite], [Unicode])
Dove objFileSys e ObjTextStream sono i nomi di oggetto, Filename è il nome che punta al percorso
e al nome da creare. OverWrite è un valore booleano che può essere istanziato a False per evitare
che la creazione di un nuovo file possa eliminarne uno vecchio e già esistente con lo stesso nome. Il
valore di default di OverWrite è True. Unicode invece se impostato True consente di scrivere
all’interno del file in formato Unicode.
COM: Component Object Model, breve analisi della tecnologia
COM costituisce un modello di programmazione orientato a oggetti che definisce la modalità di
interazione degli oggetti all'interno di un'applicazione o tra applicazioni diverse. In base a questo
modello, il software client accede a un oggetto tramite un puntatore a un'interfaccia, ovvero un
insieme correlato di funzioni denominate metodi, implementata nell'oggetto stesso.
Ma cos'è un component? E' semplicemente un oggetto caratterizzato da dati ed interfacce, i primi
propri dell'oggetto, le seconde il mezzo per manipolare e lavorare sui primi.
E' possibile scrivere server COM in qualsiasi linguaggio che supporti questa tecnologia, come,
giusto per citarne alcuni, C++, Java, Delphi o Visual Basic.
E naturalmente è possibile riusarli nei progetti di ognuno di questi ambienti di sviluppo, oltre che in
un'applicazione ASP, visto che si tratta di semplici applicazioni compilate.
Ma perché l'uso di oggetti esterni? Prima di tutto sono implementabili in applicazioni scritte anche
in linguaggi diversi, favorendo la portabilità delle soluzioni create, ed inoltre permettono di
estendere una data applicazione (ASP ma non solo) in pratica all'infinito, creando ad hoc soluzioni
ai problemi più disparati.
Un server COM altro non è che una normale applicazione, che ha come differenza la prerogativa di
dover rendere pubbliche a priori le proprie funzionalità, dovendo interagire con l'esterno, e le
relative implementazioni.
Ma più specificamente, in ambito ASP, a cosa servono i server COM?
Presto detto: in pratica la maggior parte delle funzionalità di un'applicazione ASP sono gestite da
server COM. Giusto per citarne alcune, menzioniamo l'accesso al file system del server, a database
esterni, alle variabili di sessione o di applicazione, ai cookies, etc...
Ormai esistono milioni e milioni di server COM , per cui si è in grado di trovare agevolmente ciò
che fa al proprio caso.
Ad esempio sono molto usati i server COM per la spedizione di e-mail da pagine ASP, oltre
all'oggetto ADO che serve per l'accesso ai database.
C.1 Come creare in pochi passi un server component con Visual Basic
I component server-side (da ora server component) sono utili per moltissime ragioni; le più
importanti sono che un componente migliora la velocità e la portabilità di una soluzione, protegge
tutto il vostro lavoro, dato che si tratta di una DLL (Dynamic Link Library) e che quindi non
espone direttamente il codice sorgente.
Ma cos'è esattamente un server component? E' una specie di controllo Active-X, ma invece di
essere client side, come quelli sviluppati per Internet Explorer o lo stesso ambiente Visual Basic,
sono usati in ambiente server. La differenza fondamentale tra client e server component è che
l'ultimo ha l'assoluto divieto di esporre interfaccia utente, trattandosi di un componente che gira
sulla macchina server, e che quindi non deve esporre finestre o pulsanti, in quanto queste
verrebbero visualizzate sullo schermo della macchina server.
Cosa serve per creare un server component? Un linguaggio che supporti lo standard COM, come ad
esempio, Java, Visual C++, Delphi, o Visual Basic. Tutti i linguaggi menzionati, escluso VB,
richiedono una mole di lavoro impressionante per iniziare a conoscere i fondamenti.
Detto questo, per operare serve un sistema operativo a 32 bit (Window 95, 98 or NT) su cui devono
girare le ASP, tramite IIS o Personal Web Server (PWS). E' necessario avere installato Visual Basic
(dalla ver. 5 in poi) sullo stesso computer su cui dovranno essere sviluppati i components, altrimenti
sarà impossibile per VB usare il riferimento agli oggetti ASP.
A questo punto è necessario far partire Visual Basic. Apparirà una finestra che chiede come partire.
Selezionare "ActiveX DLL".
Dopo aver fatto doppio click su ActiveX DLL, Visual Basic crea un progetto ed una classe
predefinite. E' consigliabile rinominare sia Project1 che Class1 secondo i nostri gusti.
E' importante scegliere bene il nome, dato che per richiamare il component nelle nostre pagine sarà
necessario usare Project1.Class1.
Fatto questo, è necessario fare un riferimento a "Microsoft Active Server Pages Object Library", la
libreria necessaria per usare gli oggetti built-in ASP nel component.
Dal menu di Visual Basic, bisogna scegliere "Project", quindi "References". Una finestra mostrerà
tutti i riferimenti disponibili sul sistema. Questo riferimento si trova solo se sul sistema è installato
PWS o IIS. Nel caso in cui non lo trovaste, sarà necessario reinstallarli.
Nel nostro esempio, il nome del progetto sarà "Comp1", quello della classe "MyClass". La sintassi
con cui è necessario dichiarare componenti ASP in una pagina è:
Set ObjReference = Server.CreateObject("Comp1.MyClass")
Ora, una volta impostato un riferimento nella pagina ASP, sarà possibile accedere a tutte le Sub o le
Function del component, mediante una sintassi del tipo:
<%
Set ObjReference = Server.CreateObject("Comp1.MyClass")
ObjReference.Prova
%>
Naturalmente affinchè tutto funzioni, è necessario che nel nostro component sia presente una Sub o
una Function pubblica dal nome "Prova".
Parliamo ora della libreria per l'accesso agli oggetti built-in. Si tratta di una libreria molto
importante, in quanto si rivela molto utile per queste ragioni. Si può accedere dal component agli
oggetti Session, Application, Request, Response. Per usarlo nel component, oltre ad aver dovuto
impostare un riferimento (come prima specificato) alla libreria ASP, è necessario inserire una Sub
OnStartPage nel codice della classe. La Sub OnStartPage viene eseguita ogni volta che viene creata
un'istanza del component, per cui può essere utile anche per altri scopi, come quello di impostare
variabili condivise da alcune function/sub.
Risulterà una cosa del genere:
Public Sub OnStartPage(ASPScriptingContext As ScriptingContext)
Set MyScriptingContext = ASPScriptingContext
Set MyApplication = MyScriptingContext.Application
Set MyRequest = MyScriptingContext.Request
Set MyResponse = MyScriptingContext.Response
Set MyServer = MyScriptingContext.Server
Set MySession = MyScriptingContext.Session
End Sub
Non è tutto. E' anche necessario scrivere prima di questa sub, questo codice, per permettere a VB di
non generare un errore:
Private MyScriptingContext As ScriptingContext
Private MyApplication As Application
Private MyRequest As Request
Private MyResponse As Response
Private MyServer As Server
Private MySession As Session
A questo punto creeremo anche una Sub che scarichi dalla memoria questi riferimenti, in modo da
non appesantire il sistema. Per fare questo useremo la Sub OnEndPage, che viene richiamata alla
chiusura della classe.
Public Sub OnEndPage()
Set MyScriptingContext = Nothing
Set MyApplication = Nothing
Set MyRequest = Nothing
Set MyResponse = Nothing
Set MyServer = Nothing
Set MySession = Nothing
End Sub
Ora possiamo accedere dal codice VB del nostro component, a tutti i metodi e le proprietà offerte
dagli oggetti built-in ASP. Ad esempio, per scrivere in una pagina ASP, è possibile usare il codice
MyResponse.Write, che equivale in tutto e per tutto a scrivere in una pagina ASP Response.Write.
Dopo questa premessa, scriviamo il nostro metodo Prova. Lo faremo tramite questa sub:
Public Sub Prova()
MyResponse.Write ("<p>Il mio primo component in VB.</p>")
End Sub
Come è chiaro dal messaggio, si può inserire tranquillamente codice HTML, proprio come nelle
pagine ASP.
Per richiamare questo component nella nostre pagine ASP useremo:
<%
Set ObjReference = Server.CreateObject("Comp1.MyClass")
ObjReference.Prova
%>
che va messo nella pagina prova.asp, da creare.
A questo punto, tramite il menu "File/Save Project" di VB, salva il tutto. Questa operazione salva il
codice, ma non crea la DLL. Per farlo, è necessario bloccare PWS (o IIS) per compilare di nuovo la
DLL, altrimenti sarà impossibile usare lo stesso nome. Si tratta di un bug di cui non si conosce una
soluzione. Praticamente se si compila la DLL e la si usa, anche dopo aver bloccato PWS, non sarà
possibile sovrascrivere quel file, perché PWS continuerà a richiederlo (anche bloccato).
Dal menu File, ci sarà un'opzione "Make comp1.dll". Selezionandola verrà creata la DLL.
Usando il codice ASP di cui sopra (prova.asp), sarà possibile testare la DLL.
Con i component è possibile fare di tutto, da interi siti automatizzati, a semplici component che
calcolino dei dati particolari. Il vantaggio di usare component, è che il codice diventa più gestibile,
e rimane totalmente sicuro, perché trattandosi di codice compilato, è impossibile risalire dalla
DLL al codice che è stato usato.
Il server component, per funzionare, deve essere registrato nel sistema. In quello su cui è stato
sviluppato, viene registrato direttamente da VB, ma nel caso debba essere usato su un altro sistema,
sarà necessario utilizzare il comando regsvr32.exe, che si trova in genere in c:\windows\system. E'
necessario fare seguire al richiamo a questo file, il nome del component da registrare. Quindi, nel
caso il nostro comp1.dll si trovi in c:\inetpub\wwwroot\prova, dovremo lanciare questo comando:
regsvr32.exe c:\inetpub\wwwroot\prova\comp1.dll.
Ottimizzare il carico sul server
Quale impatto in termini di carico hanno le pagine ASP sul server?.
Questa é una serie di consigli da usare per migliorare le performance delle pagine ASP:
1 – Usare GLOBAL.ASA per file a livello application
2 – Rimuovere i commenti HTML
3 – Concentrare i comandi Response.Write
4 - Evitare di ridimensionare gli array
5 – Evitare le variabili pubbliche
6 – Usare percorsi di ricerca completi
7 – Evitare di usare intensivamente le "Server Variables"
8 – Usare "Option Explicit"
9 – Non abusare dell’oggetto "Session"
1 -Usare GLOBAL.ASA per file a livello application
Se le pagine leggono su file che non cambiano spesso o quasi mai, invece di usare l'oggetto
FileSystem Object, é più conveniente caricare i file in questione in un array a livello Application in
GLOBAL.ASA.
GLOBAL.ASA é un file (opzionale) dove si possono specificare eventi e quindi assegnare script e
dichiarare oggetti a livello session o application. GLOBAL.ASA non visualizza testo all'utente ma
conserva informazioni ed oggetti, gestendo gli eventi a livello application e session.
Quindi basta richiamare dalle pagine l'array con i dati. Questo implica leggere sul file una volta per
server, anziché una volta per ogni pagina per ogni utente. E' necessario poi creare comunque una
pagina speciale per permettere eventuali aggiornamenti, in quanto una volta caricato in una
variabile a livello application, questa rimarrà identica a se stessa fino a quando non verrà
aggiornata.
E' possibile implementare il tutto tramite un array oppure un oggetto Dictionary. Il file sarà letto
solo una volta e ciò permetterà di accedere alle informazioni tramite l'array o l'oggetto Dictionary
senza aver bisogno di fare una richiesta ogni volta che fosse necessario leggere informazioni da
quel file.
Nel caso fosse necessario aggiornare il contenuto dei dati, é possibile creare una pagina riservata
contenente uno script che esegue il comando Application.Lock, aggiorna le informazioni ed infine
esegue il comando Application.Unlock che mette a disposizione di tutti i dati.
2 - Rimuovere i commenti HTML
I commenti HTML (quelli contenuti nella pagine tra <!-- e -->) rallentano le prestazioni, specie con
IIS 3. Rimuovendoli si rende il tutto più veloce.
3 - Concentrare i comandi Response.Write
Se usi molti <%=...%> per scrivere in diverse parti del codice, prova a concentrare il tutto in un
unico Response.Write.
E' un buon sistema cercare di dividere la pagina in blocchi di HTML e script, in modo da
velocizzare il caricamento. Per ogni coppia di <% %> il server esegue un comando che va a
rallentare le prestazioni globali del server.
4 - Evitare di ridimensionare gli array
Per non togliere risorse al server, é più indicato usare come dimensione di un array quella più bassa
o meglio ancora quella ottimale, e solo se necesario, usando Redim portarla alla dimensione
necessaria. Tutto ciò significa risparmiare un po' di memoria, invece di allocarla e spendere qualche
mega di ram.
5 - Evitare le variabili pubbliche
Se stiamo scrivendo in VBScript oppure stiamo accendo a qualche controllo ActiveX o script java,
cerchiamo di non usare le "Public variables". Questa chiave é al momento usata solo per
compatibilità future, per cui é meglio usare Dim, dato che non esiste nessun vantaggio nell'usare
l'altro metodo.
6 - Usare percorsi di ricerca completi
Cerca di evitare di usare MapPath se possibile, cercando di usare il percorso completo. Usando
MapPath IIS deve andare a leggere il percorso con una speciale richiesta che tradotto vuol dire
decadimento delle prestazioni.
7 - Evitare di usare intensivamente le "Server Variables"
Ogni volta che si accede alle cosiddette "Server Variables", il web server le richiede tutte, per poi
fornire alla pagina ASP solo quella desiderata. Quindi se vogliamo ad esempio sapere solamente il
valore dell'header HTTP_ACCEPT, il server andrà per prima cosa a richiedere tutta lista delle
variabili, quindi ritornerà la variabile che ho chiesto. Tutto questo influisce sulle prestazioni.
Naturalmente nel corso di una pagina, dopo aver ricevuto la prima variabile, per le altre non ci sarà
un decadimento delle prestazioni, dato che il server le ha già memorizzate tutte.
8 - Usare "Option Explicit"
Usando Option Explicit Visual Basic genererà un messaggio d'errore qualora si cerchi di accedere
a variabili non dichiarate. Le variabili local non dichiarate sono lente più delle global. Inoltre questa
opzione può essere utile per scovare variabili non dichiarate nel tuo codice.
9 - Non abusare dell'oggetto "Session"
L'oggetto Session serve per memorizzare durante la sessione di navigazione di un singolo utente,
diverse informazioni. Le variabili contenute in questo oggetto vengono mantenute durante la
navigazione dell'utente da una pagina all'altra.
Il Web server crea automaticamente un oggetto Session ogniqualvolta viene richiesta per la prima
volta una pagina all'interno di una determinata applicazione e la distrugge quando non ci sono più
richieste (di solito dopo 10 minuti, ma il valore é modificabile tramite il commando
Session.Timeout=15, dove in questo caso abbiamo impostato il TimeOut della sessione a 15
minuti).
E' possibile disattivare l'oggetto Session, ma si perdono molte caratteristiche avanzate delle pagine
ASP in questo modo. E' meglio usarlo con parsimonia, evitando di memorizzarci tante variabili.
