Differenze principali tra IIS e il server di sviluppo ASP.NET (C#)
Durante il test di un'applicazione ASP.NET in locale, è probabile che si stia usando il server Web di sviluppo ASP.NET. Tuttavia, il sito Web di produzione è 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ù tedesche.
Introduzione
Ogni volta che un utente visita un'applicazione ASP.NET il suo browser invia una richiesta al sito Web. Tale richiesta viene selezionata dal software server Web, che coordina il runtime di ASP.NET per generare e restituire il contenuto per la risorsa richiesta. I nternet I nformation S ervices (IIS) sono una suite di servizi che forniscono funzionalità comuni basate su Internet per i server Windows. IIS è il server Web più comunemente usato per le applicazioni ASP.NET negli ambienti di produzione; è più probabile che il software server Web usato dal provider host Web possa servire 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 ASP.NET Development Server è 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 ASP.NET Development Server viene avviato automaticamente e usato 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 visitano 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 è raro che gli ambienti abbiano impostazioni di configurazione diverse. L'uso di software server Web diversi 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 ASP.NET Development Server. A causa di queste differenze esistono scenari in cui il codice viene eseguito in modo impeccabile 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. Per poter eseguire questa pagina ASP.NET senza errori, il contesto di sicurezza deve disporre delle autorizzazioni appropriate a livello di file system, ovvero 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 ASP.NET Development Server avranno gli stessi diritti di accesso di un amministratore. Tuttavia, ASP.NET richieste gestite da IIS sono associate a un account computer specifico. Per impostazione predefinita, l'account del servizio di rete viene usato da IIS versioni 6 e 7, anche se il provider host Web potrebbe aver configurato un account univoco per ogni cliente. Di più, il provider 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 ospitate nell'ambiente di produzione.
Per visualizzare questo tipo di errore in azione ho creato una pagina nel sito Web Recensioni libro che crea un file su disco che archivia la data e l'ora più recente che qualcuno ha visualizzato l'argomento Teach Yourself ASP.NET 3.5 in 24 Ore di revisione. Per seguire questa procedura, aprire la ~/Tech/TYASP35.aspx pagina e aggiungere il codice seguente al Page_Load gestore eventi:
protected void Page_Load(object sender, EventArgs e)
{
string filePath = Server.MapPath("~/LastTYASP35Access.txt");
string contents = string.Format("Last accessed on {0} by {1}",
DateTime.Now.ToString(), Request.UserHostAddress);
System.IO.File.WriteAllText(filePath, contents);
}
Nota
Il File.WriteAllText metodo crea un nuovo file se non esiste e quindi scrive il contenuto specificato. Se il file esiste già, il contenuto esistente viene sovrascritto.
Successivamente, visitare la pagina di revisione di 3,5 ore ASP.NET in 3,5 ore nell'ambiente di sviluppo usando il server di sviluppo ASP.NET. Supponendo che l'utente sia connesso 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 l'indirizzo IP dell'utente e la data e l'ora dell'utente vengono archiviati nel LastTYASP35Access.txt file. Puntare il browser a questo file; verrà visualizzato un messaggio simile a quello mostrato nella figura 1.
Figura 1: Il file di testo contiene l'ultima data e ora in cui è stata visitata la revisione del libro (fare clic per visualizzare l'immagine full-size)
Distribuire l'applicazione Web nell'ambiente di produzione e quindi visitare la pagina di revisione ospitata Insegnare se stessi ASP.NET 3,5 in 24 ore . A questo punto si dovrebbe visualizzare 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 del computer anonimo ASP.NET, in questo caso la pagina funzionerà senza errori. Se, tuttavia, il provider host Web impedisce 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 del computer predefinito usato da IIS non dispone delle autorizzazioni per scrivere nel file system (fare clic per visualizzare l'immagine a dimensioni complete)
La buona notizia è che la maggior parte dei provider host Web ha un certo tipo 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 rivedere la pagina di revisione del libro. Se necessario, contattare il provider host Web per assistenza su come concedere le autorizzazioni di scrittura all'account di ASP.NET predefinito. Questa volta che la pagina deve essere caricata senza errori e il LastTYASP35Access.txt file deve essere creato correttamente.
Il problema è che perché il server di sviluppo ASP.NET opera in un contesto di sicurezza diverso rispetto a IIS, è possibile che le pagine di ASP.NET che leggono o scrivono nel file system, leggono o scrivono nel registro eventi di Windows o leggono o scrivono nel Registro eventi di Windows funzionino come previsto per lo sviluppo, ma generano eccezioni quando si esegue l'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 eventi di Windows. Prendere nota anche di tutte le pagine ASP.NET che leggono o scrivono nel file system, in quanto potrebbe essere necessario concedere privilegi di lettura e scrittura nelle cartelle appropriate nell'ambiente di produzione.
Differenze sulla gestione del contenuto statico
Un'altra differenza fondamentale tra IIS e ASP.NET Development Server è la modalità di gestione delle richieste per il contenuto statico. Ogni richiesta che entra nel server di sviluppo ASP.NET, sia per una pagina ASP.NET, un'immagine o un file JavaScript, viene elaborata dal runtime di ASP.NET. Per impostazione predefinita, IIS richiama solo il runtime di ASP.NET quando una richiesta viene inserita per una risorsa ASP.NET, ad esempio una pagina Web ASP.NET, un servizio Web e così via. Richieste di contenuto statico: immagini, file CSS, file JavaScript, file PDF, file ZIP e simili vengono recuperati da IIS senza il coinvolgimento del runtime di ASP.NET. È possibile indicare a IIS di usare il runtime di ASP.NET durante la gestione del contenuto statico; consultare la sezione "Esecuzione di autenticazione Forms-Based e autenticazione URL nei file statici con IIS 7" in questa esercitazione per altre 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 ha l'autorizzazione per visualizzare il contenuto richiesto). Una forma comune di autenticazione è l'autenticazione basata su moduli, in cui un utente viene identificato immettendo le proprie credenziali, in genere un nome utente e una password, nelle caselle di testo in una pagina Web. Dopo aver convalidato le credenziali, il sito Web archivia un cookie di 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.
Nota
Per un esame approfondito di ASP. Autenticazione basata su moduli, autorizzazione URL e altre funzionalità correlate all'account utente, assicurarsi di consultare le esercitazioni sulla sicurezza del sito Web.
Prendere in considerazione un sito Web che supporta gli account utente che usano l'autorizzazione basata su moduli e dispone di una cartella che, usando l'autorizzazione URL, è configurata per consentire solo agli 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 scoprire, creare una nuova cartella nel sito Recensioni libro, aggiungere alcuni file PDF e configurare il sito per usare l'autorizzazione URL per impedire agli utenti anonimi di visitare questa cartella. Se si scarica l'applicazione demo si noterà che ho creato una cartella denominata PrivateDocs e aggiunto un PDF dalle esercitazioni sulla sicurezza del sito Web (come adattarsi!). 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"?>
<?xml version="1.0"?>
<configuration>
<system.web>
<authorization>
<deny users="?" />
</authorization>
</system.web>
</configuration>
Infine, ho configurato l'applicazione Web per usare l'autenticazione basata su moduli aggiornando il Web.config file 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 in 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
L'immissione di questo URL nella barra degli indirizzi causa l'invio di una richiesta al server di sviluppo ASP.NET per il file. Il ASP.NET Development Server disattiva la richiesta al runtime di ASP.NET per l'elaborazione. Poiché non è ancora stato eseguito l'accesso e poiché la cartella è configurata per negare l'accesso anonimo, il runtime di ASP.NET reindirizza automaticamente la Web.configPrivateDocs pagina di accesso alla pagina di accesso( Login.aspx vedere la figura 3). Quando si reindirizza l'utente alla pagina di accesso, ASP.NET include un ReturnUrl parametro querystring che indica la pagina in cui l'utente tentava di visualizzare. Dopo aver eseguito correttamente l'accesso all'utente, è possibile tornare a questa pagina.
Figura 3: Gli utenti non autorizzati vengono reindirizzati automaticamente alla pagina di accesso (fare clic per visualizzare l'immagine full-size)
Ora vediamo come questo comportamento si comporta in produzione. Distribuire l'applicazione e immettere l'URL diretto in uno dei PDF nella cartella in PrivateDocs produzione. In questo modo viene 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 di 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 nel file (fare clic per visualizzare l'immagine full-size)
Esecuzione di Forms-Based autenticazione e autenticazione URL nei file statici con IIS 7
Esistono alcune tecniche che è possibile usare per proteggere il contenuto statico dagli 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 di 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 contenuto statico come file PDF). Contattare il provider di host Web per informazioni su come configurare il sito Web per l'uso della pipeline integrata.
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 tornare al file PDF. Questa volta che IIS gestisce la richiesta, fornisce alla logica di autenticazione e 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).
Nota
Se il provider host Web usa ancora IIS 6, non è possibile usare la funzionalità della pipeline integrata. Una soluzione alternativa consiste nell'inserire i documenti privati in una cartella che impedisce l'accesso HTTP (ad esempio App_Data) e quindi creare una pagina per la gestione di questi documenti. Questa pagina può essere denominata GetPDF.aspxe viene passato il nome del PDF tramite un parametro querystring. La GetPDF.aspx pagina verifica innanzitutto che l'utente abbia l'autorizzazione per visualizzare il file e, in tal caso, userebbe il Response.WriteFile(filePath) metodo per inviare di nuovo il contenuto del file PDF richiesto al client richiedente. Questa tecnica funziona anche per IIS 7 se non si vuole abilitare la pipeline integrata.
Riepilogo
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 del server di sviluppo ASP.NET 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 e funzioni allo stesso modo indipendentemente dall'ambiente.
Buon programmatori!
Altre informazioni
Per altre informazioni sugli argomenti descritti in questa esercitazione, vedere le risorse seguenti: