Differenze principali tra IIS e il server di sviluppo ASP.NET (VB)

di Scott Mitchell

Scaricare il PDF

Quando si testa un'applicazione ASP.NET in locale, è probabile che si stia usando il server Web di sviluppo ASP.NET. Tuttavia, il sito Web di produzione è molto probabilmente basato su IIS. Esistono alcune differenze tra il modo in cui questi server Web gestiscono le richieste e queste differenze possono avere conseguenze importanti. Questa esercitazione illustra alcune delle differenze più dettagliate.

Introduzione

Ogni volta che un utente visita un'applicazione ASP.NET il browser invia una richiesta al sito Web. Tale richiesta viene prelevata dal software del server Web, che si coordina con il runtime ASP.NET per generare e restituire il contenuto per la risorsa richiesta. I nternet I nformation S ervices (IIS) è una suite di servizi che fornisce funzionalità comuni basate su Internet per i server Windows. IIS è il server Web più comunemente usato per ASP.NET applicazioni in ambienti di produzione; è molto probabile che il software del server Web usato dal provider di host Web gestisca l'applicazione ASP.NET. IIS può essere usato anche come software server Web nell'ambiente di sviluppo, anche se ciò comporta l'installazione di IIS e la configurazione corretta.

Il server di sviluppo ASP.NET è un'opzione server Web alternativa per l'ambiente di sviluppo; viene fornito con ed è integrato in Visual Studio. A meno che l'applicazione Web non sia stata configurata per l'uso di IIS, il server di sviluppo ASP.NET viene avviato e usato automaticamente come server Web la prima volta che si visita una pagina Web da Visual Studio. Le applicazioni Web demo create di nuovo nell'esercitazione Determinazione dei file da distribuire erano entrambe applicazioni Web basate su file system non configurate per l'uso di IIS. Pertanto, quando si visita uno di questi siti Web da Visual Studio viene usato il server di sviluppo ASP.NET.

In un mondo perfetto gli ambienti di sviluppo e produzione sarebbero identici. Tuttavia, come illustrato nell'esercitazione precedente, non è insolito che gli ambienti abbiano impostazioni di configurazione diverse. L'uso di software server Web diverso negli ambienti aggiunge un'altra variabile che deve essere presa in considerazione durante la distribuzione di un'applicazione. Questa esercitazione illustra le differenze principali tra IIS e il server di sviluppo ASP.NET. A causa di queste differenze esistono scenari in cui il codice viene eseguito perfettamente nell'ambiente di sviluppo genera un'eccezione o si comporta in modo diverso quando viene eseguito nell'ambiente di produzione.

Differenze di contesto di sicurezza

Ogni volta che il software del server Web gestisce una richiesta in ingresso, associa tale richiesta a un particolare contesto di sicurezza. Queste informazioni sul contesto di sicurezza vengono usate dal sistema operativo per determinare quali azioni sono consentite dalla richiesta. Ad esempio, una pagina ASP.NET potrebbe includere codice che registra un messaggio a un file su disco. Affinché questa pagina ASP.NET venga eseguita senza errori, il contesto di sicurezza deve disporre delle autorizzazioni appropriate a livello di file system, vale a dire le autorizzazioni di scrittura per tale file.

Il ASP.NET Development Server associa le richieste in ingresso al contesto di sicurezza dell'utente attualmente connesso. Se si è connessi al desktop come amministratore, le pagine ASP.NET gestite dal server di sviluppo ASP.NET avranno gli stessi diritti di accesso di un amministratore. Tuttavia, le richieste ASP.NET gestite da IIS sono associate a un account macchina specifico. Per impostazione predefinita, l'account macchina del servizio di rete viene usato da IIS versioni 6 e 7, anche se il provider di hosting web potrebbe aver configurato un account univoco per ogni cliente. Inoltre, il provider di host Web ha probabilmente concesso autorizzazioni limitate a questo account del computer. Il risultato netto è che potrebbero essere presenti pagine Web eseguite senza errori nell'ambiente di sviluppo, ma generare eccezioni correlate all'autorizzazione quando sono ospitate nell'ambiente di produzione.

Per mostrare questo tipo di errore in azione ho creato una pagina nel sito Web Recensioni Libri che crea un file su disco che archivia la data e l'ora più recenti che qualcuno ha visualizzato la recensione Teach Yourself ASP.NET 3.5 in 24 Hours. Per seguire la procedura, aprire la ~/Tech/TYASP35.aspx pagina e aggiungere il codice seguente al Page_Load gestore eventi:

Protected Sub Page_Load(ByVal sender As Object, ByVal e As  System.EventArgs) Handles Me.Load

    Dim filePath As  String = Server.MapPath("~/LastTYASP35Access.txt")

    Dim contents As  String = String.Format("Last accessed on {0} by {1}", _

                                 DateTime.Now.ToString(), Request.UserHostAddress)

     System.IO.File.WriteAllText(filePath, contents)

End Sub

Visitare quindi la pagina di revisione del libro Teach Yourself ASP.NET 3.5 in 24 ore nell'ambiente di sviluppo usando ASP.NET Development Server. Supponendo di aver eseguito l'accesso al computer con un account con autorizzazioni adeguate per creare e modificare un file di testo nella directory radice dell'applicazione Web, la revisione del libro viene visualizzata come prima, ma ogni volta che la pagina viene visitata la data e l'ora e l'indirizzo IP dell'utente viene archiviato nel LastTYASP35Access.txt file. Puntare il browser a questo file; verrà visualizzato un messaggio simile a quello illustrato nella figura 1.

Figura 1: Il file di testo contiene la data e l'ora dell'ultima visita della recensione del libro (fare clic per visualizzare l'immagine a dimensione intera)

Distribuire l'applicazione Web nell'ambiente di produzione e quindi visitare la pagina di recensione del libro Teach Yourself ASP.NET 3.5 in 24 Hours ospitata. A questo punto dovrebbe essere visualizzata la pagina di revisione del libro come normale o il messaggio di errore mostrato nella figura 2. Alcuni provider di host Web concedono autorizzazioni di scrittura all'account ASP.NET computer anonimo, nel qual caso la pagina funzionerà senza errori. Qualora il provider di hosting web proibisca l'accesso in scrittura per l'account anonimo, viene generata un'eccezioneUnauthorizedAccessException quando la TYASP35.aspx pagina tenta di scrivere la data e l'ora correnti nel LastTYASP35Access.txt file.

Figura 2: L'account computer predefinito usato da IIS non dispone delle autorizzazioni per la scrittura nel file system (fare clic per visualizzare l'immagine a dimensione intera)

La buona notizia è che la maggior parte dei provider di host Web ha una sorta di strumento di autorizzazioni che consente di specificare le autorizzazioni del file system nel sito Web. Concedere all'account anonimo ASP.NET l'accesso in scrittura alla directory radice e quindi visitare nuovamente la pagina della recensione del libro. Se necessario, contattare il provider di host Web per assistenza su come concedere le autorizzazioni di scrittura all'account ASP.NET predefinito. Questa volta la pagina deve essere caricata senza errori e il LastTYASP35Access.txt file deve essere creato correttamente.

Il risultato è che, poiché il server di sviluppo ASP.NET opera in un contesto di sicurezza diverso da IIS, è possibile che le pagine ASP.NET che leggono o scrivono nel file system, leggono o scrivono nel registro eventi di Windows o leggono o scrivono nel Registro di sistema di Windows funzionino come previsto per lo sviluppo, ma generano eccezioni quando si esegue l'ambiente di produzione. Quando si compila un'applicazione Web che verrà distribuita in un ambiente di hosting Web condiviso, non leggere o scrivere nel registro eventi o nel Registro di sistema di Windows. Prendere nota anche di tutte le pagine ASP.NET che leggono o scrivono nel file system, perché potrebbe essere necessario concedere privilegi di lettura e scrittura per le cartelle appropriate nell'ambiente di produzione.

Differenze nella gestione del contenuto statico

Un'altra differenza principale tra IIS e il server di sviluppo ASP.NET è il modo in cui gestiscono le richieste per il contenuto statico. Ogni richiesta che entra in ASP.NET Development Server, sia per una pagina ASP.NET, un'immagine o un file JavaScript, viene elaborata dal runtime di ASP.NET. Per impostazione predefinita, IIS richiama il runtime di ASP.NET solo quando viene inviata una richiesta per una risorsa ASP.NET, ad esempio una pagina Web ASP.NET, un servizio Web e così via. Le richieste di contenuto statico: immagini, file CSS, file JavaScript, file PDF, file ZIP e simili, vengono recuperate da IIS senza coinvolgere il runtime di ASP.NET. È possibile istruire IIS a utilizzare il runtime di ASP.NET per servire contenuti statici; consultare la sezione "Esecuzione dell'autenticazione Forms-Based e dell'autenticazione URL nei file statici con IIS 7" in questo tutorial per maggiori informazioni.

Il runtime di ASP.NET esegue una serie di passaggi per generare il contenuto richiesto, tra cui l'autenticazione (identificazione del richiedente) e l'autorizzazione (determinare se il richiedente dispone dell'autorizzazione per visualizzare il contenuto richiesto). Una forma comune di autenticazione è l'autenticazione basata su form, in cui un utente viene identificato immettendo le proprie credenziali, in genere un nome utente e una password, nelle caselle di testo di una pagina Web. Dopo la convalida delle credenziali, il sito Web archivia un cookie del ticket di autenticazione nel browser dell'utente, che viene inviato con ogni richiesta successiva al sito Web ed è ciò che viene usato per autenticare l'utente. Inoltre, è possibile specificare regole di autorizzazione URL che determinano quali utenti possono o non possono accedere a una determinata cartella. Molti siti Web ASP.NET usano l'autenticazione basata su moduli e l'autorizzazione url per supportare gli account utente e per definire parti del sito accessibili solo agli utenti autenticati o agli utenti che appartengono a un determinato ruolo.

Si consideri un sito Web che supporta gli account utente che usano l'autorizzazione basata su moduli e ha una cartella che, usando l'autorizzazione URL, è configurata per consentire solo gli utenti autenticati. Si supponga che questa cartella contenga ASP.NET pagine e file PDF e che la finalità sia che solo gli utenti autenticati possano visualizzare questi file PDF.

Cosa accade se un visitatore tenta di visualizzare uno di questi file PDF immettendo l'URL direttamente nella barra degli indirizzi del browser? Per scoprirlo, creare una nuova cartella nel sito Recensioni libri, aggiungere alcuni file PDF e configurare il sito in modo da usare l'autorizzazione URL per impedire agli utenti anonimi di visitare questa cartella. Scaricando l'applicazione demo, si nota che ho creato una cartella denominata PrivateDocs e aggiunto un PDF dai miei tutorial di sicurezza dei siti web (come appropriato!). La PrivateDocs cartella contiene anche un Web.config file che specifica le regole di autorizzazione URL per negare gli utenti anonimi:

<?xml version="1.0"?>

<configuration>

    <system.web>

         <authorization>

            <deny  users="?" />

         </authorization>

     </system.web>

</configuration>

Infine, l'applicazione Web è stata configurata per l'uso dell'autenticazione basata su form aggiornando il file Web.config nella directory radice, sostituendo:

<authentication mode="Windows" />

Con:

<authentication mode="Forms" />

Usando il ASP.NET Development Server, visitare il sito e immettere l'URL diretto a uno dei file PDF nella barra degli indirizzi del browser. Se è stato scaricato il sito Web associato a questa esercitazione, l'URL dovrebbe essere simile al seguente: http://localhost:portNumber/PrivateDocs/aspnet_tutorial01_Basics_vb.pdf

Se si immette questo URL nella barra degli indirizzi, il browser invia una richiesta al server di sviluppo ASP.NET per il file. Il server di sviluppo ASP.NET esegue la richiesta al runtime di ASP.NET per l'elaborazione. Poiché non abbiamo ancora effettuato l'accesso e poiché nella cartella PrivateDocs è configurato per negare l'accesso anonimo, il runtime ASP.NET reindirizza automaticamente l'utente alla pagina di accesso Login.aspx (come mostrato nella Figura 3). Quando si reindirizza l'utente alla pagina di accesso, ASP.NET include un ReturnUrl parametro querystring che indica la pagina che l'utente stava tentando di visualizzare. Dopo che l'utente ha effettuato con successo l'accesso, può essere riportato a questa pagina.

Figura 3: Gli utenti non autorizzati vengono reindirizzati automaticamente alla pagina di accesso (fare clic per visualizzare l'immagine a dimensione intera)

Vediamo ora come si comporta questo comportamento nell'ambiente di produzione. Distribuire l'applicazione e immettere l'URL diretto a uno dei PDF nella cartella di produzione PrivateDocs. Verrà richiesto al browser di inviare una richiesta IIS per il file. Poiché viene richiesto un file statico, IIS recupera e restituisce il file senza richiamare il runtime di ASP.NET. Di conseguenza, non è stato eseguito alcun controllo dell'autorizzazione URL; il contenuto del PDF presumibilmente privato è accessibile a chiunque conosca l'URL diretto al file.

Figura 4: Gli utenti anonimi possono scaricare i file PDF privati immettendo l'URL diretto del file (fare clic per visualizzare l'immagine a dimensione intera)

Esecuzione dell'autenticazione Forms-Based e dell'autenticazione URL nei file statici con IIS 7

Esistono due tecniche che è possibile usare per proteggere il contenuto statico da utenti non autorizzati. IIS 7 ha introdotto la pipeline integrata, che sposa il flusso di lavoro di IIS con il flusso di lavoro del runtime ASP.NET. In breve, è possibile indicare a IIS di richiamare i moduli di autenticazione e autorizzazione del runtime di ASP.NET tutte le richieste in ingresso (incluso il contenuto statico come i file PDF). Per informazioni su come configurare il sito Web per l'uso della pipeline integrata, contattare il provider di host Web.

Dopo aver configurato IIS per l'uso della pipeline integrata, aggiungere il markup seguente al Web.config file nella directory radice:

<system.webServer>

      <modules>

          <add  name="FormsAuthenticationModule"  type="System.Web.Security.FormsAuthenticationModule" />

          <remove  name="UrlAuthorization" />

          <add  name="UrlAuthorization"  type="System.Web.Security.UrlAuthorizationModule" />

          <remove  name="DefaultAuthentication" />

          <add  name="DefaultAuthentication"  type="System.Web.Security.DefaultAuthenticationModule" />

      </modules>

</system.webServer>

Questo markup indica a IIS 7 di usare i moduli di autenticazione e autorizzazione basati su ASP.NET. Ri-distribuire l'applicazione e quindi visitare nuovamente il file PDF. Questa volta che IIS gestisce la richiesta, fornisce all'autenticazione e alla logica di autorizzazione del runtime di ASP.NET l'opportunità di esaminare la richiesta. Poiché solo gli utenti autenticati sono autorizzati a visualizzare il contenuto nella PrivateDocs cartella, il visitatore anonimo viene reindirizzato automaticamente alla pagina di accesso (fare riferimento alla figura 3).

Sommario

Le applicazioni Web in un ambiente di produzione vengono ospitate usando il software server Web IIS di Microsoft. Nell'ambiente di sviluppo, tuttavia, l'applicazione può essere ospitata tramite IIS o il server di sviluppo ASP.NET. Idealmente, lo stesso software server Web deve essere usato in entrambi gli ambienti perché l'uso di software diverso aggiunge un'altra variabile nella combinazione. Tuttavia, la facilità d'uso di ASP.NET Development Server lo rende una scelta interessante nell'ambiente di sviluppo. La buona notizia è che esistono solo alcune differenze fondamentali tra IIS e il server di sviluppo ASP.NET e, se si è consapevoli di queste differenze, è possibile adottare misure per garantire che l'applicazione funzioni allo stesso modo indipendentemente dall'ambiente.

Buon programmatori!

Altre informazioni

Per altre informazioni sugli argomenti illustrati in questa esercitazione, vedere le risorse seguenti:

• integrazione ASP.NET con IIS 7.0
• Uso dell'autenticazione dei forum di ASP.NET con tutti i tipi di contenuto in IIS 7 (video)
• Server Web in Visual Web Developer