Guida ASP

Ecco una guida un pò lunghetta ma decisamente completa sul linguaggio di programmazione ASP.

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

• 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:

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:

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”
<% Call PrintDate %>
<script LANGUAGE=Jscript RUNAT=Server>
function PrintDate()
{
var x
x = new Date()
Response.Write(x.+ getDate())
}
</script>
Commenti

//Questa è l’istruzione di cui si parlava

//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> Do Loop con while <% counter = 1 thismonth = month(now()) Do while counter < thismonth + 1 response.write "month number ” & counter & ” “
response.write “__________” & “

“
If counter >13 then
exit do
end if
counter = counter+1
Loop
%>

</body>
</html>
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

//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”

<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"> <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> Commenti 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> <% for counter = 1 to 5 response.write "now we are looping” & “
“
next
%>
</body> Commenti

//In questa prima parte, l’uso di for next, è quello tradizionale

Esempio con “For…Next” 2
<html>
<head>
<title>Esempio 5</title>
<body bgcolor=”#FFFFFF"> </head> <% for counter = 1 to 5 response.write "now we are on loop number ” &
counter & “
“
next
%>
</body></html> Commenti

Esempio con “For…Next” 3
<html>
<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 & “
“
next
%>
</body></html> Commenti

//In questo caso invece l’incremento avviene specificando il passo attraverso l’istruzione step

Esempio con “For…Next” 4
<html>
<head>
<title>Esempio 7</title></head>
<body>
<%
for counter = 50 to 25 step –5
response.write “now we are on loop number ” &
counter & “
“
next
%>
</body></html> Commenti

//L’istruzione step può essere usata anche per un “conto alla rovescia”

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”

<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> Commenti Esempio con "Do…Loop" <title>Esempio 6</title> <body bgcolor="#FFFFFF"> <html> <%DO%> ‘ not ready yet! <%LOOP%> </body> </html> Commenti //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 uccida!) 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
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.recordset”)
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(“/”)
& “aspapplicmotorelibri.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:inetpubwwwrootaspapplicmotorelibri.mdb;" 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="http://pcfantasy.forumfree.it/libri.asp?ID=%22&rst%280%29&%22″> ‘”&rst(2)&”‘ </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 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 Please enter your First Name <input NAME="NameFirst” size =”40″ value=<%=fn%>>

Please enter your Last Name
<input NAME=”NameLast” size =”40″ value=<%=ln%>>

Please enter your State abbreviation
<input NAME=”State” MaxLength=”2″ value=<%=st%>>
</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") & "" response.write Request.Cookies("thatperson")("firstname") & "" response.write Request.Cookies("thatperson")("state") & "" %> </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) %>

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. Eventi Application
2. Eventi Session
3. Dichiarazioni
4. 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

E’ possibile creare oggetti con uno scope di sessione o applicazione nei file Global.asa usando i tag . 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

. . .

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.

REM Object Script

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—

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>

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.

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:

<form action=”loginNow.asp” method=”POST"> Username: <input type="text” name=”username” size=”22"> Password: <input type="password” name=”password” size=”22"> </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!.
Ora può andare sulla tua pagina protetta

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:
 Name -> <input NAME="userName” size=”20"> Password -> <input NAME="userPassword” size=”20"> </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! Try <a href="http://pcfantasy.forumfree.it/securitylogin.asp”>Logging in 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’> ") response.write("Nome: <input type=’Text’ name=’Nome’ size=’30’> ") response.write("Cognome: <input type=’Text’ name=’Cognome’ size=’40’> ") response.write("Indirizzo E-mail: <input type=’Text’ name=’Email’> ") response.write("<textarea name=’myhomepage’ cols=’70′ rows=’20’> ") 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 è 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/login@dominio.asp

Poiché all’inizio il campo e-mail è vuoto, verranno eseguite le istruzioni

response.write(“<form action=’default.asp’ method=’POST’> ") response.write("Nome: <input type=’Text’ name=’Nome’ size=’30’> ") response.write("Cognome: <input type=’Text’ name=’Cognome’ size=’40’> ") response.write("Indirizzo E-mail: <input type=’Text’ name=’Email’> ") response.write("<textarea name=’myhomepage’ cols=’70′ rows=’20’> ") 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 è 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 (“Il mio primo component in VB.

“)
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:windowssystem. 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:inetpubwwwrootprova, dovremo lanciare questo comando:
regsvr32.exe c:inetpubwwwrootprovacomp1.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.