3 pagine in totale: <<Indietro 1 [2] 3 Avanti >>
Un caso pratico: Membership API e Roles API per Classic ASP
L'integrazione di cui si è parlato permette di risolvere molti dei problemi legati allo sviluppo delle applicazioni web che utilizzano tecnologie miste. Un esempio significativo è rappresentato dalla necessità di portare in maniera del tutto trasparente l'autenticazione di ASP.NET sotto Classic ASP. L'esempio qui proposto in realtà vale per qualsiasi tipologia di tecnologia che non sia ASP.NET.
L'idea è quella di sfruttare le Membership e Roles API, che consentono di proteggere facilmente un'applicazione web basata su ASP.NET, per difendere con gli stessi criteri anche la parte legacy di un ipotetico sito, basata su Classic ASP.
Per cominciare, è necessario attivare e configurare le Membership e Roles API, come spiegato nell'articolo appena referenziato. A questo punto occorre creare un HttpModule, all'interno del quale venga intercettato l'evento AuthorizeRequest, avendo protetto l'applicazione ASP (che risiede sotto un particolare percorso) con i meccanismi di autorizzazione di ASP.NET stesso. Si noti che l'evento AuthorizeRequest si verifica ogni qual volta sia necessario garantire l'accesso ad una particolare risorsa protetta, dunque ben si presta alle nostre necessità.
All'interno dell'event handler andiamo a verificare che Roles API sia attivo, in questo modo possiamo sfruttare una nuova caratteristica offerta da ASP.NET 3.5, che ci consente di impostare header personalizzate nella richiesta che viene presa in carico dal filtro ISAPI associato all'estensione della pagina (nel caso dell'esempio l'estensione è .ASP, ma un discorso analogo può essere applicato anche per le pagine PHP).
void context_PreRequestHandlerExecute(object sender, EventArgs e)
{
HttpContext ctx = ((HttpApplication)sender).Context;
if (Roles.Enabled && ctx.User != null && ctx.User.Identity.IsAuthenticated)
ctx.Request.Headers.Add("Roles", string.Join(";", Roles.GetRolesForUser()));
}
A questo punto nella pagina ASP è possibile recuperare l'header valorizzata dall'HttpModule di ASP.NET per intercettare i ruoli utilizzati dall'utente, con uno snippet di codice come questo:
Username: <%=Request.ServerVariables("AUTH_USER") %><br />
Ruoli da ASP.NET Role API: <%=Request.ServerVariables("HTTP_Roles")%>
Allo scopo di evitare conflitti, al nome della header personalizzata specificata nell'HttpModule viene aggiunto il prefisso HTTP_ e, per recuperare il valore, è pertanto necessario tenere a mente questa modifica. L'effetto è quello di aver sfruttato l'Integrated pipeline in maniera molto utile, con il minimo sforzo ed il massimo risultato.
Le novità di IIS 7.0 per uno sviluppatore non si fermano qui, ma di certo questa grande integrazione, così come la facilità di configurazione, resta una delle caratteristiche che troverà il favore di tutti gli sviluppatori.
Il punto di vista del sistemista
Le innovazioni presenti in IIS 7.0 sono davvero molte, sia lato amministrativo che lato sviluppatore. La pipeline integrata fornisce un potente meccanismo per estendere le funzionalità incluse in IIS, sfruttando i moduli e gli handler HTTP di ASP.NET. La presenza di un file di configurazione in formato XML centralizzato (applicationHost.config) va a sostituire il metabase presente nelle precedenti versioni, facilitando la gestione delle impostazioni dei siti. La nuova architettura di IIS e del WAS consente di concepire il sistema non più solo come un HTTP server, ma come un application server in grado di fornire un ambiente di hosting anche per servizi WCF.
Al di là delle nuove feature appena menzionate, per un amministratore di sistema la caratteristica più significativa è pearltro rappresentata dalla possibilità di poter delegare totalmente o in parte la gestione e la configurazione di un singolo website o di un application folder, lasciando a chi realizza un sito o un'applicazione web un certo grado di autonomia nelle scelte di deployment e settaggio.
Delegation
Le nuove funzionalità di feature delegation e remote administration sono le innovazioni più importanti ed utili lato amministrativo in quanto permettono di delegare agli sviluppatori la gestione e la modifica delle impostazioni di IIS senza dover dare accessi amministrativi al server, così da evitare inutili e pericolosi accessi da parte di personale non autorizzato o non preparato a dovere.
La delegation permette la completa autonomia da parte degli sviluppatori, i quali sono finalmente messi nella condizione di poter apportare tutte le modifiche del caso direttamente nel file web.config anche per aspetti riguardanti direttamente il web server. Solo per fare un esempio, per un gestore di un sito diventa possibile impostare e personalizzare le estensioni MIME, così da non dover sempre dipendere dall'amministratore di sistema. Allo stesso tempo l'amministratore può configurare IIS in modo tale da autorizzare o impedire la modifica delle impostazioni relative al sito, a seconda dei casi e delle specifiche esigenze.
Vediamo un esempio significativo per capire meglio come funziona il meccanismo di delega. Supponiamo di voler impostare per tutto il web server i seguenti default document: index.aspx, index.htm, default.aspx e default.htm, lasciando peraltro agli utenti la possibilità di poterli modificare. Per ottenere questo effetto, abbiamo la necessità di modificare il file applicationHost.config, impostando per la sezione defaultDocument l'attributo overrideModeDefault con il valore Allow. Questa impostazione fornisce il permesso ai gestori dei siti di configurare i default document a piacimento, in modo indipendente da quanto definito per l'intero sistema.
<section name="defaultDocument" overrideModeDefault="Allow" />
In ogni caso, per poter fornire un insieme di possibili valori predefiniti, occorre impostare nella sezione defaultDocument inclusa nell'elemento system.webServer del file applicationHost.config i nomi dei file di default. In questo modo tutti i nuovi website avranno i quattro default document impostati, ma essi potranno essere modificati liberamente, per esempio utilizzando estensioni diverse in funzione della tecnologia di sviluppo utilizzata.
<system.webServer>
<defaultDocument enabled="true">
<files>
<add value="index.aspx"/>
<add value="index.htm"/>
<add value="default.aspx"/>
<add value="default.htm"/>
</files>
</defaultDocument>
</system.webServer>
Figura 3 - Aggiunta di un nuovo default document tramite IIS Manager
Nel caso in cui il permesso di modifica per una particolare sezione (nel nostro caso defaultDocument) sia stato assegnato dall'amministratore di sistema, la configurazione di un sito non dipende solo dal file applicationHost.config, ma anche dal file web.config. Pertanto, se aggiungiamo ai default document del sito "Default Web Site" il documento "test.aspx" da IIS Manager (vedi figura 3), otteniamo che il file web.config viene modificato di conseguenza e il nuovo valore viene aggiunto alla collezione dei default document validi per il sito in questione. Un discorso analogo può essere fatto anche nel caso della rimozione di un file di default.
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<defaultDocument>
<files>
<add value="test.aspx" />
</files>
</defaultDocument>
</system.webServer>
</configuration>
3 pagine in totale: <<Indietro 1 [2] 3 Avanti >>
Contenuti dell'articolo
- Pagina 1
- Pagina 2
- Pagina 3
Aggiungi un nuovo commento »»»
Per inserire un commento, devi registrarti alla nostra community.
Difficoltà
Contenuti
Stampa 
Download 
