Autorizzazione basata sull'utente (C#)

di Scott Mitchell

Nota

Poiché questo articolo è stato scritto, i provider di appartenenza ASP.NET sono stati sostituiti da ASP.NET Identity. È consigliabile aggiornare le app per usare la ASP.NET Identity Platform anziché i provider di appartenenza in primo piano al momento della scrittura di questo articolo. ASP.NET Identity offre numerosi vantaggi rispetto al sistema di appartenenza ASP.NET, tra cui :

• Prestazioni migliori
• Miglioramento dell'estendibilità e della testability
• Supporto per OAuth, OpenID Connect e autenticazione a due fattori
• Supporto delle identità basate sulle attestazioni
• Interoperabilità migliore con ASP.Net Core

Scaricare codice o scaricare pdf

In questa esercitazione si esaminerà la limitazione dell'accesso alle pagine e la limitazione delle funzionalità a livello di pagina tramite diverse tecniche.

Introduzione

La maggior parte delle applicazioni Web che offrono account utente fa in parte per limitare determinati visitatori ad accedere a determinate pagine all'interno del sito. Nella maggior parte dei siti di messageboard online, ad esempio, tutti gli utenti, anonimi e autenticati, sono in grado di visualizzare i post del messageboard, ma solo gli utenti autenticati possono visitare la pagina Web per creare un nuovo post. E potrebbero essere presenti pagine amministrative accessibili solo a un utente specifico (o a un determinato set di utenti). Inoltre, la funzionalità a livello di pagina può variare in base all'utente. Quando si visualizza un elenco di post, gli utenti autenticati vengono visualizzati un'interfaccia per la classificazione di ogni post, mentre questa interfaccia non è disponibile per i visitatori anonimi.

ASP.NET semplifica la definizione delle regole di autorizzazione basate sull'utente. Con solo un po' di markup in Web.config, pagine Web specifiche o intere directory possono essere bloccate in modo che siano accessibili solo a un subset specificato di utenti. La funzionalità a livello di pagina può essere attivata o disattivata in base al metodo attualmente connesso tramite mezzi dichiarativi e programmatici.

In questa esercitazione si esaminerà la limitazione dell'accesso alle pagine e la limitazione delle funzionalità a livello di pagina tramite diverse tecniche. È possibile iniziare subito.

Un'occhiata al flusso di lavoro di autorizzazione URL

Come illustrato nell'esercitazione Panoramica dell'autenticazione moduli , quando il runtime di ASP.NET elabora una richiesta per una risorsa ASP.NET la richiesta genera un numero di eventi durante il ciclo di vita. I moduli HTTP sono classi gestite il cui codice viene eseguito in risposta a un evento specifico nel ciclo di vita della richiesta. ASP.NET fornito con diversi moduli HTTP che eseguono attività essenziali dietro le quinte.

Uno di questi moduli HTTP è FormsAuthenticationModule. Come illustrato nelle esercitazioni precedenti, la funzione primaria dell'oggetto FormsAuthenticationModule consiste nel determinare l'identità della richiesta corrente. Questa operazione viene eseguita controllando il ticket di autenticazione dei moduli, che si trova in un cookie o incorporato all'interno dell'URL. Questa identificazione viene eseguita durante l'eventoAuthenticateRequest.

Un altro modulo HTTP importante è , UrlAuthorizationModuleche viene generato in risposta all'evento (che si verifica dopo l'eventoAuthorizeRequestAuthenticateRequest). Esamina UrlAuthorizationModule il markup di configurazione in Web.config per determinare se l'identità corrente ha l'autorità per visitare la pagina specificata. Questo processo viene definito autorizzazione URL.

Si esaminerà la sintassi per le regole di autorizzazione URL nel passaggio 1, ma si esaminerà prima di tutto ciò che UrlAuthorizationModule fa a seconda che la richiesta sia autorizzata o meno. Se l'oggetto UrlAuthorizationModule determina che la richiesta è autorizzata, non esegue nulla e la richiesta continua attraverso il ciclo di vita. Tuttavia, se la richiesta non è autorizzata, il UrlAuthorizationModule ciclo di vita viene interrotto e indica all'oggetto Response di restituire uno stato HTTP 401 Non autorizzato . Quando si usa l'autenticazione dei moduli questo stato HTTP 401 non viene mai restituito al client perché se rileva FormsAuthenticationModule uno stato HTTP 401 viene modificato in un reindirizzamento HTTP 302 alla pagina di accesso.

La figura 1 illustra il flusso di lavoro della pipeline ASP.NET, l'oggetto e il FormsAuthenticationModuleUrlAuthorizationModule quando arriva una richiesta non autorizzata. In particolare, la figura 1 mostra una richiesta da parte di un visitatore anonimo per ProtectedPage.aspx, che è una pagina che nega l'accesso agli utenti anonimi. Poiché il visitatore è anonimo, la UrlAuthorizationModule richiesta viene interrotta e restituisce uno stato HTTP 401 Non autorizzato. Quindi FormsAuthenticationModule converte lo stato 401 in una pagina di accesso da 302 reindirizzamento. Dopo l'autenticazione dell'utente tramite la pagina di accesso, viene reindirizzato a ProtectedPage.aspx. Questa volta l'utente identifica l'utente FormsAuthenticationModule in base al ticket di autenticazione. Ora che il visitatore è autenticato, consente UrlAuthorizationModule l'accesso alla pagina.

Figura 1: Flusso di lavoro autenticazione form e autorizzazione URL (fare clic per visualizzare l'immagine full-size)

La figura 1 illustra l'interazione che si verifica quando un visitatore anonimo tenta di accedere a una risorsa che non è disponibile per gli utenti anonimi. In tal caso, il visitatore anonimo viene reindirizzato alla pagina di accesso con la pagina che ha tentato di visitare specificata nella querystring. Dopo aver eseguito l'accesso, l'utente verrà reindirizzato automaticamente alla risorsa che inizialmente tentava di visualizzare.

Quando la richiesta non autorizzata viene effettuata da un utente anonimo, questo flusso di lavoro è semplice ed è facile per il visitatore capire cosa è successo e perché. Tenere presente tuttavia che l'utente FormsAuthenticationModulenon autorizzato verrà reindirizzato alla pagina di accesso, anche se la richiesta viene effettuata da un utente autenticato. Ciò può causare un'esperienza utente confusa se un utente autenticato tenta di visitare una pagina per cui non ha autorità.

Si supponga che il sito Web abbia configurato le regole di autorizzazione URL in modo che la pagina OnlyTito.aspx ASP.NET sia accessibile solo a Tito. Si supponga ora che Sam visiti il sito, l'accesso e quindi tenti di visitare OnlyTito.aspx. L'oggetto UrlAuthorizationModule arresterà il ciclo di vita della richiesta e restituirà uno stato HTTP 401 Non autorizzato, che verrà FormsAuthenticationModule rilevato e quindi reindirizzato Sam alla pagina di accesso. Dal momento che Sam ha già effettuato l'accesso, tuttavia, potrebbe chiedersi perché è stata inviata alla pagina di accesso. Potrebbe essere motivo per cui le credenziali di accesso sono state perse in qualche modo o che ha immesso credenziali non valide. Se Sam reentererà le proprie credenziali dalla pagina di accesso in cui verrà eseguito l'accesso (di nuovo) e reindirizzato a OnlyTito.aspx. Verrà UrlAuthorizationModule rilevato che Sam non può visitare questa pagina e verrà restituito alla pagina di accesso.

La figura 2 illustra questo flusso di lavoro confuso.

Figura 2: il flusso di lavoro predefinito può causare un ciclo di confusione (fare clic per visualizzare l'immagine a dimensioni complete)

Il flusso di lavoro illustrato nella figura 2 può essere rapidamente confuso anche il visitatore più esperto del computer. Verranno esaminati i modi per evitare questo ciclo di confusione nel passaggio 2.

Nota

ASP.NET usa due meccanismi per determinare se l'utente corrente può accedere a una determinata pagina Web: autorizzazione URL e autorizzazione file. L'autorizzazione dei file viene implementata da , che determina l'autorità FileAuthorizationModuleconsultando gli elenchi di controllo di accesso dei file richiesti. L'autorizzazione dei file è più comunemente usata con autenticazione di Windows perché gli elenchi di controllo di accesso sono autorizzazioni che si applicano agli account Windows. Quando si usa l'autenticazione dei moduli, tutte le richieste a livello di sistema operativo e file system vengono eseguite dallo stesso account Windows, indipendentemente dall'utente che visita il sito. Poiché questa serie di esercitazioni è incentrata sull'autenticazione dei moduli, non verrà discusso dell'autorizzazione dei file.

Ambito dell'autorizzazione URL

Il UrlAuthorizationModule codice gestito fa parte del runtime di ASP.NET. Prima della versione 7 del server Web IIS (Internet Information Services), c'era una barriera distinta tra la pipeline HTTP di IIS e la pipeline del runtime di ASP.NET. In breve, in IIS 6 e versioni precedenti, ASP. UrlAuthorizationModule NET viene eseguito solo quando una richiesta viene delegata da IIS al runtime di ASP.NET. Per impostazione predefinita, IIS elabora il contenuto statico stesso, ad esempio pagine HTML, JavaScript e file di immagine, e passa solo le richieste al runtime di ASP.NET quando viene richiesta una pagina con estensione .aspx, .asmxo .ashx .

IIS 7, tuttavia, consente di integrare IIS e ASP.NET pipeline. Con alcune impostazioni di configurazione è possibile configurare IIS 7 per richiamare le UrlAuthorizationModule richieste per tutte le richieste, vale a dire che le regole di autorizzazione url possono essere definite per i file di qualsiasi tipo. IIS 7 include inoltre il proprio motore di autorizzazione URL. Per altre informazioni sull'integrazione ASP.NET e sulla funzionalità di autorizzazione url nativa di IIS 7, vedere Informazioni sull'autorizzazione url IIS7. Per un'analisi più approfondita dell'integrazione di ASP.NET e IIS 7, selezionare una copia del libro di Shahram Khosravi, Professional IIS 7 e ASP.NET Integrated Programming (ISBN: 978-0470152539).

In breve, nelle versioni precedenti a IIS 7, le regole di autorizzazione URL vengono applicate solo alle risorse gestite dal runtime di ASP.NET. Ma con IIS 7 è possibile usare la funzionalità di autorizzazione url nativa di IIS o integrare ASP. La rete si UrlAuthorizationModule trova nella pipeline HTTP di IIS, estendendo quindi questa funzionalità a tutte le richieste.

Nota

Esistono alcune differenze sottili ma importanti per il modo in cui ASP. La funzionalità di autorizzazione URL di UrlAuthorizationModule NET e IIS 7 elabora le regole di autorizzazione. Questa esercitazione non esamina le funzionalità di autorizzazione dell'URL di IIS 7 o le differenze nel modo in cui analizza le regole di autorizzazione rispetto a UrlAuthorizationModule. Per altre informazioni su questi argomenti, vedere la documentazione di IIS 7 su MSDN o in www.iis.net.

Passaggio 1: Definizione delle regole di autorizzazione URL inWeb.config

Determina UrlAuthorizationModule se concedere o negare l'accesso a una risorsa richiesta per una determinata identità in base alle regole di autorizzazione URL definite nella configurazione dell'applicazione. Le regole di autorizzazione vengono definite nell'elemento<authorization> sotto forma di <allow> e <deny> elementi figlio. Ogni <allow> elemento figlio e <deny> può specificare:

• Un utente specifico
• Elenco delimitato da virgole degli utenti
• Tutti gli utenti anonimi, contrassegnati da un punto interrogativo (?)
• Tutti gli utenti, denotati da un asterisco (*)

Il markup seguente illustra come usare le regole di autorizzazione URL per consentire agli utenti Tito e Scott e negare tutti gli altri:

<authorization>
 <allow users="Tito, Scott" />
 <deny users="*" />
</authorization>

L'elemento <allow> definisce gli utenti consentiti , Tito e Scott, mentre l'elemento <deny> indica che tutti gli utenti vengono negati.

Nota

Gli <allow> elementi e <deny> possono anche specificare le regole di autorizzazione per i ruoli. L'autorizzazione basata sui ruoli verrà esaminata in un'esercitazione futura.

L'impostazione seguente concede l'accesso a chiunque diverso da Sam (inclusi i visitatori anonimi):

<authorization>
 <deny users="Sam" />
</authorization>

Per consentire solo gli utenti autenticati, usare la configurazione seguente, che nega l'accesso a tutti gli utenti anonimi:

<authorization>
 <deny users="?" />
</authorization>

Le regole di autorizzazione vengono definite all'interno dell'elemento <system.web> in Web.config e si applicano a tutte le risorse ASP.NET nell'applicazione Web. Spesso, un'applicazione ha regole di autorizzazione diverse per sezioni diverse. Ad esempio, in un sito di e-commerce, tutti i visitatori possono esaminare i prodotti, vedere recensioni del prodotto, cercare il catalogo e così via. Tuttavia, solo gli utenti autenticati possono raggiungere il checkout o le pagine per gestire la cronologia delle spedizioni. Inoltre, possono essere presenti parti del sito accessibili solo da utenti selezionati, ad esempio gli amministratori del sito.

ASP.NET semplifica la definizione di regole di autorizzazione diverse per file e cartelle diversi nel sito. Le regole di autorizzazione specificate nel file della Web.config cartella radice si applicano a tutte le risorse ASP.NET nel sito. Tuttavia, è possibile eseguire l'override di queste impostazioni di autorizzazione predefinite per una determinata cartella aggiungendo un Web.config oggetto con una <authorization> sezione .

È possibile aggiornare il sito Web in modo che solo gli utenti autenticati possano visitare le pagine ASP.NET nella Membership cartella. A tale scopo, è necessario aggiungere un Web.config file alla Membership cartella e impostare le impostazioni di autorizzazione per negare gli utenti anonimi. Fare clic con il pulsante destro del mouse sulla Membership cartella nel Esplora soluzioni, scegliere il menu Aggiungi nuovo elemento dal menu di scelta rapida e aggiungere un nuovo file di configurazione Web denominato Web.config.

Figura 3: Aggiungere un Web.config file alla cartella (fare clic per visualizzare l'immagineMembership a dimensione intera)

A questo punto il progetto deve contenere due Web.config file: uno nella directory radice e uno nella Membership cartella .

Figura 4: L'applicazione deve ora contenere due Web.config file (fare clic per visualizzare l'immagine a dimensione intera)

Aggiornare il file di configurazione nella Membership cartella in modo che impedisca l'accesso agli utenti anonimi.

<?xml version="1.0"?>
<configuration>
 <system.web>
 <authorization>
 <deny users="?" />
 </authorization>
 </system.web>
</configuration>

Questo è tutto ciò che occorre fare.

Per testare questa modifica, visitare la home page in un browser e assicurarsi di essere disconnessi. Poiché il comportamento predefinito di un'applicazione ASP.NET consiste nel consentire a tutti i visitatori e poiché non sono state apportate modifiche di autorizzazione al file della Web.config directory radice, è possibile visitare i file nella directory radice come visitatore anonimo.

Fare clic sul collegamento Creazione di account utente nella colonna a sinistra. In questo modo si passerà a ~/Membership/CreatingUserAccounts.aspx. Poiché il Web.config file nella Membership cartella definisce le regole di autorizzazione per impedire l'accesso anonimo, la UrlAuthorizationModule richiesta viene interrotta e viene restituito lo stato HTTP 401 Non autorizzato. Modifica FormsAuthenticationModule questo valore in base a uno stato di reindirizzamento 302, inviandoci alla pagina di accesso. Si noti che la pagina a cui si sta tentando di accedere (CreatingUserAccounts.aspx) viene passata alla pagina di accesso tramite il ReturnUrl parametro querystring.

Figura 5: Poiché le regole di autorizzazione URL impediscono l'accesso anonimo, viene eseguito il reindirizzamento alla pagina di accesso (fare clic per visualizzare l'immagine a dimensione intera)

Al termine dell'accesso, viene eseguito il reindirizzamento alla CreatingUserAccounts.aspx pagina. Questa volta l'oggetto consente l'accesso UrlAuthorizationModule alla pagina perché non è più anonimo.

Applicazione di regole di autorizzazione URL a una posizione specifica

Le impostazioni di autorizzazione definite nella <system.web> sezione di Web.config si applicano a tutte le risorse ASP.NET in tale directory e alle relative sottodirectory (fino a quando non viene eseguito l'override da un altro Web.config file). In alcuni casi, tuttavia, potrebbe essere necessario che tutte le risorse ASP.NET in una determinata directory abbiano una configurazione di autorizzazione specifica, ad eccezione di una o due pagine specifiche. A tale scopo, è possibile aggiungere un <location> elemento in Web.config, puntandolo al file le cui regole di autorizzazione differiscono e definendo le regole di autorizzazione univoce in esso contenute.

Per illustrare l'uso dell'elemento per eseguire l'override <location> delle impostazioni di configurazione per una risorsa specifica, è possibile personalizzare le impostazioni di autorizzazione in modo che solo Tito possa visitare CreatingUserAccounts.aspx. A tale scopo, aggiungere un <location> elemento al file della Web.config cartella e aggiornarne il Membership markup in modo che abbia un aspetto simile al seguente:

<?xml version="1.0"?>
<configuration>
 <system.web>
 <authorization>
 <deny users="?" />
 </authorization>
 </system.web>

 <location path="CreatingUserAccounts.aspx">
 <system.web>
 <authorization>
 <allow users="Tito" />
 <deny users="*" />
 </authorization>
 </system.web>
 </location>
</configuration>

L'elemento <authorization> in <system.web> definisce le regole di autorizzazione URL predefinite per ASP.NET risorse nella cartella e nelle Membership relative sottocartelle. L'elemento consente di eseguire l'override <location> di queste regole per una determinata risorsa. Nel markup precedente l'elemento <location> fa riferimento alla CreatingUserAccounts.aspx pagina e specifica le relative regole di autorizzazione, ad esempio per consentire Tito, ma negare tutti gli altri.

Per testare questa modifica di autorizzazione, iniziare visitando il sito Web come utente anonimo. Se si tenta di visitare qualsiasi pagina nella Membership cartella, ad esempio UserBasedAuthorization.aspx, UrlAuthorizationModule nega la richiesta e si verrà reindirizzati alla pagina di accesso. Dopo aver eseguito l'accesso come, ad esempio, Scott, è possibile visitare qualsiasi pagina nella Membership cartella ad eccezione di CreatingUserAccounts.aspx. Il tentativo di visitare CreatingUserAccounts.aspx l'accesso come chiunque, ma Tito provocherà un tentativo di accesso non autorizzato, reindirizzando l'utente alla pagina di accesso.

Nota

L'elemento <location> deve essere visualizzato all'esterno dell'elemento della <system.web> configurazione. È necessario usare un elemento separato <location> per ogni risorsa le cui impostazioni di autorizzazione si desidera eseguire l'override.

Un'analisi di comeUrlAuthorizationModuleusa le regole di autorizzazione per concedere o negare l'accesso

Determina UrlAuthorizationModule se autorizzare una determinata identità per un PARTICOLARE URL analizzando le regole di autorizzazione URL una alla volta, a partire dalla prima e andando verso il basso. Non appena viene trovata una corrispondenza, all'utente viene concesso o negato l'accesso, a seconda che la corrispondenza sia stata trovata in un <allow> elemento o <deny> . Se non viene trovata alcuna corrispondenza, all'utente viene concesso l'accesso. Di conseguenza, se si vuole limitare l'accesso, è fondamentale usare un <deny> elemento come ultimo elemento nella configurazione dell'autorizzazione URL. Se si omette un<deny>a tutti gli utenti verrà concesso l'accesso.

Per comprendere meglio il processo usato dall'oggetto per determinare l'autorità UrlAuthorizationModule , considerare le regole di autorizzazione url di esempio esaminate in precedenza in questo passaggio. La prima regola è un <allow> elemento che consente l'accesso a Tito e Scott. Le seconde regole sono un <deny> elemento che nega l'accesso a tutti. Se un utente anonimo visita, inizia UrlAuthorizationModule chiedendo, è anonimo Scott o Tito? La risposta, ovviamente, è No, quindi procede alla seconda regola. È anonimo nel set di tutti? Poiché la risposta qui è Sì, la <deny> regola viene applicata e il visitatore viene reindirizzato alla pagina di accesso. Analogamente, se Jisun sta visitando, inizia UrlAuthorizationModule chiedendo, È Jisun o Scott o Tito? Dal momento che non è, il UrlAuthorizationModule procede alla seconda domanda, Jisun è nel set di tutti? Lei è, così anche lei, è negato l'accesso. Infine, se Tito visita, la prima domanda posta da UrlAuthorizationModule è una risposta affermativa, quindi Tito viene concesso l'accesso.

Poiché elabora UrlAuthorizationModule le regole di autorizzazione dall'alto verso il basso, l'arresto in qualsiasi corrispondenza, è importante che le regole più specifiche vengano prima di quelle meno specifiche. Ovvero, per definire regole di autorizzazione che vietano Jisun e utenti anonimi, ma consentono a tutti gli altri utenti autenticati, si inizierà con la regola più specifica, quella che influisce su Jisun, e quindi procedere alle regole meno specifiche, quelle che consentono tutti gli altri utenti autenticati, ma negando tutti gli utenti anonimi. Le regole di autorizzazione URL seguenti implementano questo criterio negando prima Jisun e negando quindi qualsiasi utente anonimo. A qualsiasi utente autenticato diverso da Jisun verrà concesso l'accesso perché nessuna di queste <deny> istruzioni corrisponderà.

<authorization>
 <deny users="Jisun" />
 <deny users="?" />
</authorization>

Passaggio 2: Correzione del flusso di lavoro per utenti non autorizzati e autenticati

Come illustrato in precedenza in questa esercitazione, nella sezione A Look at the URL Authorization Workflow (Esaminare il flusso di lavoro di autorizzazione URL), ogni volta che si verifica una richiesta non autorizzata, la UrlAuthorizationModule richiesta viene interrotta e viene restituito lo stato HTTP 401 Non autorizzato. Questo stato 401 viene modificato da FormsAuthenticationModule in uno stato di reindirizzamento 302 che invia l'utente alla pagina di accesso. Questo flusso di lavoro si verifica su qualsiasi richiesta non autorizzata, anche se l'utente è autenticato.

La restituzione di un utente autenticato alla pagina di accesso è probabilmente confonderla perché ha già eseguito l'accesso al sistema. Con un po' di lavoro è possibile migliorare questo flusso di lavoro reindirizzando gli utenti autenticati che effettuano richieste non autorizzate a una pagina che spiega che hanno tentato di accedere a una pagina con restrizioni.

Per iniziare, creare una nuova pagina ASP.NET nella cartella radice dell'applicazione Web denominata UnauthorizedAccess.aspx; non dimenticare di associare questa pagina alla Site.master pagina master. Dopo aver creato questa pagina, rimuovere il controllo Contenuto che fa riferimento a LoginContent ContentPlaceHolder in modo che venga visualizzato il contenuto predefinito della pagina master. Aggiungere quindi un messaggio che spiega la situazione, ovvero che l'utente ha tentato di accedere a una risorsa protetta. Dopo aver aggiunto un messaggio di questo tipo, il UnauthorizedAccess.aspx markup dichiarativo della pagina dovrebbe essere simile al seguente:

<%@ Page Language="C#" MasterPageFile="~/Site.master" AutoEventWireup="true"
CodeFile="UnauthorizedAccess.aspx.cs" Inherits="UnauthorizedAccess"
Title="Untitled Page" %>

<asp:Content ID="Content1" ContentPlaceHolderID="MainContent"
Runat="Server">
 <h2>Unauthorized Access</h2>
 <p>
 You have attempted to access a page that you are not authorized to view.
 </p>
 <p>
 If you have any questions, please contact the site administrator.
 </p>
</asp:Content>

È ora necessario modificare il flusso di lavoro in modo che, se una richiesta non autorizzata viene eseguita da un utente autenticato, viene inviata alla UnauthorizedAccess.aspx pagina anziché alla pagina di accesso. La logica che reindirizza le richieste non autorizzate alla pagina di accesso viene sepolta all'interno di un metodo privato della FormsAuthenticationModule classe, pertanto non è possibile personalizzare questo comportamento. Ciò che è possibile fare, tuttavia, è aggiungere la logica alla pagina di accesso che reindirizza l'utente a UnauthorizedAccess.aspx, se necessario.

Quando reindirizza FormsAuthenticationModule un visitatore non autorizzato alla pagina di accesso, aggiunge l'URL richiesto e non autorizzato alla stringa di query con il nome ReturnUrl. Ad esempio, se un utente non autorizzato ha tentato di visitare OnlyTito.aspx, verrà FormsAuthenticationModule reindirizzato a Login.aspx?ReturnUrl=OnlyTito.aspx. Pertanto, se la pagina di accesso viene raggiunta da un utente autenticato con una stringa di query che include il ReturnUrl parametro , si sa che questo utente non autenticato ha appena tentato di visitare una pagina che non è autorizzata a visualizzare. In questo caso, si vuole reindirizzarla a UnauthorizedAccess.aspx.

A tale scopo, aggiungere il codice seguente al gestore eventi della pagina di Page_Load accesso:

protected void Page_Load(object sender, EventArgs e)
{
    if (!Page.IsPostBack)
    {
        if (Request.IsAuthenticated && !string.IsNullOrEmpty(Request.QueryString["ReturnUrl"]))
        // This is an unauthorized, authenticated request...
        Response.Redirect("~/UnauthorizedAccess.aspx");
    }
}

Il codice precedente reindirizza gli utenti autenticati e non autorizzati alla UnauthorizedAccess.aspx pagina. Per visualizzare questa logica in azione, visitare il sito come visitatore anonimo e fare clic sul collegamento Creazione di account utente nella colonna a sinistra. Verrà visualizzata la ~/Membership/CreatingUserAccounts.aspx pagina, che nel passaggio 1 è stata configurata per consentire solo l'accesso a Tito. Poiché gli utenti anonimi non sono consentiti, ci FormsAuthenticationModule reindirizza alla pagina di accesso.

A questo punto siamo anonimi, quindi Request.IsAuthenticated restituisce false e non viene reindirizzato a UnauthorizedAccess.aspx. Viene invece visualizzata la pagina di accesso. Accedere come utente diverso da Tito, ad esempio Bruce. Dopo aver immesso le credenziali appropriate, la pagina di accesso reindirizza a ~/Membership/CreatingUserAccounts.aspx. Tuttavia, poiché questa pagina è accessibile solo a Tito, non è consentito visualizzarlo e viene immediatamente restituito alla pagina di accesso. Questa volta, tuttavia, Request.IsAuthenticated restituisce true (e il ReturnUrl parametro querystring esiste), quindi viene eseguito il reindirizzamento alla UnauthorizedAccess.aspx pagina.

Figura 6: Autenticato, utenti non autorizzati vengono reindirizzati a UnauthorizedAccess.aspx (Fare clic per visualizzare l'immagine a dimensioni complete)

Questo flusso di lavoro personalizzato presenta un'esperienza utente più sensibile e semplice eseguendo brevi circuiti il ciclo illustrato nella figura 2.

Passaggio 3: Limitazione delle funzionalità in base all'utente attualmente connesso

L'autorizzazione URL semplifica la specifica delle regole di autorizzazione grossolane. Come si è visto nel passaggio 1, con l'autorizzazione URL è possibile stabilire in modo breve quali identità sono consentite e quali sono negate dalla visualizzazione di una determinata pagina o di tutte le pagine in una cartella. In alcuni scenari, tuttavia, è possibile consentire a tutti gli utenti di visitare una pagina, ma limitare la funzionalità della pagina in base all'utente che la visita.

Si consideri il caso di un sito Web eCommerce che consente ai visitatori autenticati di rivedere i loro prodotti. Quando un utente anonimo visita una pagina di un prodotto, visualizzerebbe solo le informazioni sul prodotto e non verrebbe data l'opportunità di lasciare una revisione. Tuttavia, un utente autenticato che visita la stessa pagina visualizzerebbe l'interfaccia di revisione. Se l'utente autenticato non ha ancora esaminato questo prodotto, l'interfaccia consente loro di inviare una revisione; in caso contrario, mostra loro la revisione inviata in precedenza. Per seguire questo scenario, la pagina del prodotto potrebbe visualizzare informazioni aggiuntive e offrire funzionalità estese per gli utenti che lavorano per l'azienda eCommerce. Ad esempio, la pagina del prodotto potrebbe elencare l'inventario in magazzino e includere opzioni per modificare il prezzo e la descrizione del prodotto quando viene visitato da un dipendente.

Tali regole di autorizzazione di granularità fine possono essere implementate in modo dichiarativo o programmatico (o tramite una combinazione dei due). Nella sezione successiva verrà illustrato come implementare l'autorizzazione granulare fine tramite il controllo LoginView. Di seguito verranno esaminate le tecniche a livello di codice. Prima di poter esaminare l'applicazione di regole di autorizzazione di granularità fine, è tuttavia prima necessario creare una pagina la cui funzionalità dipende dall'utente che lo visita.

Verrà creata una pagina che elenca i file in una determinata directory all'interno di GridView. Oltre a elencare il nome, le dimensioni e le altre informazioni di ogni file, GridView includerà due colonne di LinkButtons: una denominata View e una denominata Delete. Se viene fatto clic su Visualizza collegamentoButton, verrà visualizzato il contenuto del file selezionato; se viene fatto clic su Delete LinkButton, il file verrà eliminato. Verrà inizialmente creata questa pagina in modo che la relativa visualizzazione ed eliminazione sia disponibile per tutti gli utenti. Nelle sezioni Uso del controllo LoginView e della limitazione a livello di codice delle funzionalità verrà illustrato come abilitare o disabilitare queste funzionalità in base all'utente che visita la pagina.

Nota

La pagina ASP.NET che si sta per compilare usa un controllo GridView per visualizzare un elenco di file. Poiché questa serie di esercitazioni si concentra sull'autenticazione dei moduli, l'autorizzazione, gli account utente e i ruoli, non si vuole dedicare troppo tempo a discutere i lavori interni del controllo GridView. Anche se questa esercitazione fornisce istruzioni dettagliate specifiche per la configurazione di questa pagina, non descrive i dettagli del motivo per cui sono state effettuate determinate scelte o quali effetti hanno sull'output sottoposto a rendering. Per un esame approfondito del controllo GridView, consultare l'esercitazione Uso dei dati in ASP.NET serie di esercitazioni 2.0.

Iniziare aprendo il UserBasedAuthorization.aspx file nella Membership cartella e aggiungendo un controllo GridView alla pagina denominata FilesGrid. Nel smart tag di GridView fare clic sul collegamento Modifica colonne per avviare la finestra di dialogo Campi. Da qui deselezionare la casella di controllo Genera automaticamente i campi nell'angolo inferiore sinistro. Aggiungere quindi un pulsante Select, un pulsante Delete e due BoundFields dall'angolo superiore sinistro (i pulsanti Select and Delete sono disponibili sotto il tipo CommandField). Impostare la proprietà del SelectText pulsante Select su Visualizza e le proprietà e DataField le prime proprietà di BoundField HeaderText su Name. Impostare la proprietà del HeaderText secondo BoundField su Size in Byte, sulla DataField relativa proprietà su Length, sulla DataFormatString relativa proprietà su {0:N0} e sulla relativa HtmlEncode proprietà su False.

Dopo aver configurato le colonne di GridView, fare clic su OK per chiudere la finestra di dialogo Campi. Dal Finestra Proprietà impostare la proprietà GridView DataKeyNames su FullName. A questo punto il markup dichiarativo di GridView dovrebbe essere simile al seguente:

<asp:GridView ID="FilesGrid" DataKeyNames="FullName" runat="server" AutoGenerateColumns="False">
 <Columns>
 <asp:CommandField SelectText="View" ShowSelectButton="True"/>
 <asp:CommandField ShowDeleteButton="True" />
 <asp:BoundField DataField="Name" HeaderText="Name" />
 <asp:BoundField DataField="Length" DataFormatString="{0:N0}"
 HeaderText="Size in Bytes" HtmlEncode="False" />
 </Columns>
</asp:GridView>

Con il markup di GridView creato, è possibile scrivere il codice che recupera i file in una determinata directory e associarli a GridView. Aggiungere il codice seguente al gestore eventi della Page_Load pagina:

protected void Page_Load(object sender, EventArgs e)
{
    if (!Page.IsPostBack)
    {
        string appPath = Request.PhysicalApplicationPath;
        DirectoryInfo dirInfo = new DirectoryInfo(appPath);

        FileInfo[] files = dirInfo.GetFiles();

        FilesGrid.DataSource = files;
        FilesGrid.DataBind();
    }
}

Il codice precedente usa la DirectoryInfo classe per ottenere un elenco dei file nella cartella radice dell'applicazione. Il GetFiles() metodo restituisce tutti i file nella directory come matrice di FileInfo oggetti, che viene quindi associato a GridView. L'oggetto FileInfo ha un assortimento di proprietà, ad esempio Name, Lengthe IsReadOnly, tra gli altri. Come si può vedere dal relativo markup dichiarativo, GridView visualizza solo le Name proprietà e Length .

Nota

Le DirectoryInfo classi e FileInfo sono disponibili nello System.IO spazio dei nomi. Pertanto, è necessario prefazione di questi nomi di classe con i nomi dello spazio dei nomi o avere lo spazio dei nomi importato nel file di classe (tramite using System.IO).

Passare un momento per visitare questa pagina tramite un browser. Verrà visualizzato l'elenco dei file che risiedono nella directory radice dell'applicazione. Facendo clic su una delle opzioni View o Delete LinkButtons, verrà generato un postback, ma non verrà eseguita alcuna azione perché è ancora necessario creare i gestori eventi necessari.

Figura 7: GridView elenca i file nella directory radice dell'applicazione Web (fare clic per visualizzare l'immagine full-size)

È necessario un mezzo per visualizzare il contenuto del file selezionato. Tornare a Visual Studio e aggiungere una casella di testo denominata FileContents sopra GridView. Impostare rispettivamente la proprietà TextMode su MultiLineColumnsRows e le relative proprietà e su 95% e 10.

<asp:TextBox ID="FileContents" runat="server" Rows="10"
TextMode="MultiLine" Width="95%"></asp:TextBox>

Creare quindi un gestore eventi per l'eventoSelectedIndexChanged gridView e aggiungere il codice seguente:

protected void FilesGrid_SelectedIndexChanged(object sender, EventArgs e)
{
    // Open the file and display it
    string fullFileName = FilesGrid.SelectedValue.ToString();
    string contents = File.ReadAllText(fullFileName);
    FileContents.Text = contents;
}

Questo codice usa la proprietà di SelectedValue GridView per determinare il nome completo del file selezionato. Internamente, l'insieme DataKeys viene fatto riferimento per ottenere l'oggetto SelectedValueDataKeyNames , pertanto è imperativo impostare la proprietà GridView su Name, come descritto in precedenza in questo passaggio. La File classe viene usata per leggere il contenuto del file selezionato in una stringa, che viene quindi assegnata alla FileContents proprietà di TextBox Text , visualizzando così il contenuto del file selezionato nella pagina.

Figura 8: il contenuto del file selezionato viene visualizzato nella casella di testo (fare clic per visualizzare l'immagine full-size)

Nota

Se si visualizza il contenuto di un file contenente il markup HTML e si tenta di visualizzare o eliminare un file, verrà visualizzato un HttpRequestValidationException errore. Ciò si verifica perché nel postback il contenuto di TextBox viene inviato al server Web. Per impostazione predefinita, ASP.NET genera un errore ogni volta che viene rilevato un HttpRequestValidationException postback potenzialmente pericoloso, ad esempio il markup HTML. Per disabilitare questo errore da quando si verifica, disattivare la convalida della richiesta per la pagina aggiungendo ValidateRequest="false" alla @Page direttiva. Per altre informazioni sui vantaggi della convalida delle richieste e sulle precauzioni da prendere durante la disabilitazione, vedere Convalida richiesta - Prevenzione degli attacchi di script.

Aggiungere infine un gestore eventi con il codice seguente per l'eventoRowDeleting GridView:

protected void FilesGrid_RowDeleting(object sender, GridViewDeleteEventArgs e)
{
    string fullFileName = FilesGrid.DataKeys[e.RowIndex].Value.ToString();
    FileContents.Text = string.Format("You have opted to delete {0}.", fullFileName);

    // To actually delete the file, uncomment the following line
    // File.Delete(fullFileName);
}

Il codice visualizza semplicemente il nome completo del file da eliminare in FileContents TextBox senza eliminare effettivamente il file.

Figura 9: fare clic sul pulsante Elimina non elimina effettivamente il file (fare clic per visualizzare l'immagine full-size)

Nel passaggio 1 sono state configurate le regole di autorizzazione url per impedire agli utenti anonimi di visualizzare le pagine nella Membership cartella. Per mostrare meglio l'autenticazione granulare, è possibile consentire agli utenti anonimi di visitare la UserBasedAuthorization.aspx pagina, ma con funzionalità limitate. Per aprire questa pagina fino ad essere accessibile da tutti gli utenti, aggiungere l'elemento seguente <location> al Web.config file nella Membership cartella:

<location path="UserBasedAuthorization.aspx">
 <system.web>
 <authorization>
 <allow users="*" />
 </authorization>
 </system.web>
</location>

Dopo aver aggiunto questo <location> elemento, testare le nuove regole di autorizzazione URL disconnessione dal sito. Come utente anonimo è necessario visitare la UserBasedAuthorization.aspx pagina.

Attualmente, qualsiasi utente autenticato o anonimo può visitare la UserBasedAuthorization.aspx pagina e visualizzare o eliminare i file. Facciamolo in modo che solo gli utenti autenticati possano visualizzare il contenuto di un file e solo Tito può eliminare un file. Tali regole di autorizzazione di granularità fine possono essere applicate in modo dichiarativo, a livello di codice o tramite una combinazione di entrambi i metodi. Si userà l'approccio dichiarativo per limitare chi può visualizzare il contenuto di un file; Verrà usato l'approccio programmatico per limitare chi può eliminare un file.

Uso del controllo LoginView

Come abbiamo visto nelle esercitazioni precedenti, il controllo LoginView è utile per visualizzare interfacce diverse per gli utenti autenticati e anonimi e offre un modo semplice per nascondere le funzionalità che non sono accessibili agli utenti anonimi. Poiché gli utenti anonimi non possono visualizzare o eliminare file, è necessario visualizzare textBox FileContents solo quando la pagina viene visitata da un utente autenticato. A questo scopo, aggiungere un controllo LoginView alla pagina, denominarlo LoginViewForFileContentsTextBoxe spostare il FileContents markup dichiarativo di TextBox nel controllo LoggedInTemplateLoginView.

<asp:LoginView ID=" LoginViewForFileContentsTextBox " runat="server">
 <LoggedInTemplate>
 <p>
 <asp:TextBox ID="FileContents" runat="server" Rows="10"
 TextMode="MultiLine" Width="95%"></asp:TextBox>
 </p>
 </LoggedInTemplate>
</asp:LoginView>

I controlli Web nei modelli di LoginView non sono più accessibili direttamente dalla classe code-behind. Ad esempio, i FilesGrid gestori eventi SelectedIndexChanged e RowDeleting gridView fanno riferimento al FileContents controllo TextBox con codice simile al seguente:

FileContents.Text = text;

Tuttavia, questo codice non è più valido. Spostando textBox FileContents nella LoggedInTemplate casella di testo non è possibile accedere direttamente. È invece necessario usare il FindControl("controlId") metodo per fare riferimento a livello di codice al controllo. Aggiornare i FilesGrid gestori eventi per fare riferimento a TextBox come segue:

TextBox FileContentsTextBox = LoginViewForFileContentsTextBox.FindControl("FileContents") as TextBox;
FileContentsTextBox.Text = text;

Dopo aver spostato TextBox nel controllo LoginView LoggedInTemplate e aggiornando il codice della pagina per fare riferimento a TextBox usando il FindControl("controlId") modello, visitare la pagina come utente anonimo. Come illustrato nella figura 10, textBox FileContents non viene visualizzato. Tuttavia, la visualizzazione linkButton è ancora visualizzata.

Figura 10: Il controllo LoginView esegue solo il rendering della casella di testo per utenti autenticati (fare clic per visualizzare l'immagineFileContents a dimensioni complete)

Un modo per nascondere il pulsante Visualizza per gli utenti anonimi consiste nel convertire il campo GridView in un campo TemplateField. Verrà generato un modello che contiene il markup dichiarativo per View LinkButton. È quindi possibile aggiungere un controllo LoginView al TemplateField e posizionare LinkButton all'interno di LoggedInTemplateLoginView, nascondendo così il pulsante Visualizza dai visitatori anonimi. A tale scopo, fare clic sul collegamento Modifica colonne dallo smart tag di GridView per avviare la finestra di dialogo Campi. Selezionare quindi il pulsante Seleziona dall'elenco nell'angolo inferiore sinistro e quindi fare clic sul collegamento Converti questo campo in un campo TemplateField. In questo modo verrà modificato il markup dichiarativo del campo da:

<asp:CommandField SelectText="View" ShowSelectButton="True"/>

Con:

<asp:TemplateField ShowHeader="False">
 <ItemTemplate>
 <asp:LinkButton ID="LinkButton1" runat="server" CausesValidation="False"
 CommandName="Select" Text="View"></asp:LinkButton>
 </ItemTemplate>
</asp:TemplateField>

A questo punto, è possibile aggiungere un oggetto LoginView al TemplateField. Il markup seguente visualizza solo View LinkButton per gli utenti autenticati.

<asp:TemplateField ShowHeader="False">
 <ItemTemplate>
 <asp:LoginView ID="LoginView1" runat="server">
 <LoggedInTemplate>
 <asp:LinkButton ID="LinkButton1" runat="server" CausesValidation="False"
 CommandName="Select" Text="View"></asp:LinkButton>
 </LoggedInTemplate>
 </asp:LoginView>
 </ItemTemplate>
</asp:TemplateField>

Come illustrato nella figura 11, il risultato finale non è che la colonna View sia ancora visualizzata anche se la visualizzazione LinkButtons all'interno della colonna è nascosta. Verrà illustrato come nascondere l'intera colonna GridView (e non solo LinkButton) nella sezione successiva.

Figura 11: Il controllo LoginView nasconde i linkbutton di visualizzazione per i visitatori anonimi (fare clic per visualizzare l'immagine full-size)

Limitazione a livello di codice delle funzionalità

In alcune circostanze, le tecniche dichiarative non sono sufficienti per limitare la funzionalità a una pagina. Ad esempio, la disponibilità di determinate funzionalità di pagina può dipendere dai criteri oltre al fatto che l'utente che visita la pagina sia anonima o autenticata. In questi casi, i vari elementi dell'interfaccia utente possono essere visualizzati o nascosti tramite mezzi programmatici.

Per limitare la funzionalità a livello di codice, è necessario eseguire due attività:

1. Determinare se l'utente che visita la pagina può accedere alla funzionalità e
2. Modificare a livello di codice l'interfaccia utente in base al fatto che l'utente abbia accesso alla funzionalità in questione.

Per illustrare l'applicazione di queste due attività, è possibile consentire solo a Tito di eliminare i file da GridView. La nostra prima attività, quindi, consiste nel determinare se è Tito che visita la pagina. Una volta determinato, è necessario nascondere (o visualizzare) la colonna Elimina di GridView. Le colonne di GridView sono accessibili tramite la Columns relativa proprietà. Viene eseguito il rendering di una colonna solo se la relativa Visible proprietà è impostata su true (impostazione predefinita).

Aggiungere il codice seguente al Page_Load gestore eventi prima di associazione dei dati a GridView:

// Is this Tito visiting the page?
string userName = User.Identity.Name;
if (string.Compare(userName, "Tito", true) == 0)
    // This is Tito, SHOW the Delete column
    FilesGrid.Columns[1].Visible = true;
else
    // This is NOT Tito, HIDE the Delete column
    FilesGrid.Columns[1].Visible = false;

Come illustrato nell'esercitazione Panoramica dell'autenticazione dei moduli , User.Identity.Name restituisce il nome dell'identità. Corrisponde al nome utente immesso nel controllo Login. Se è Tito che visita la pagina, la proprietà della seconda colonna di Visible GridView è impostata su true; in caso contrario, è impostata su false. Il risultato netto è che quando un utente diverso da Tito visita la pagina, un altro utente autenticato o un utente anonimo, la colonna Elimina non viene eseguito il rendering (vedere la figura 12); tuttavia, quando Tito visita la pagina, la colonna Delete è presente (vedere la figura 13).

Figura 12: la colonna Elimina non viene eseguito il rendering quando viene visitato da qualcuno diverso da Tito (ad esempio Bruce) (fare clic per visualizzare l'immagine a dimensioni complete)

Figura 13: la colonna Elimina viene eseguita per Tito (fare clic per visualizzare l'immagine a dimensioni complete)

Passaggio 4: Applicazione di regole di autorizzazione a classi e metodi

Nel passaggio 3 è stato impedito agli utenti anonimi di visualizzare il contenuto di un file e di impedire a tutti gli utenti ma a Tito di eliminare i file. Questa operazione è stata eseguita nascondendo gli elementi dell'interfaccia utente associati per i visitatori non autorizzati tramite tecniche dichiarative e programmatice. Per l'esempio semplice, nascondendo correttamente gli elementi dell'interfaccia utente era semplice, ma quali sono i siti più complessi in cui potrebbero esserci molti modi diversi per eseguire la stessa funzionalità? Limitando tale funzionalità agli utenti non autorizzati, cosa accade se si dimentica di nascondere o disabilitare tutti gli elementi dell'interfaccia utente applicabili?

Un modo semplice per garantire che non sia possibile accedere a una determinata parte di funzionalità da parte di un utente non autorizzato consiste nel decorare tale classe o metodo con l'attributoPrincipalPermission. Quando il runtime .NET usa una classe o esegue uno dei relativi metodi, verifica che il contesto di sicurezza corrente disponga dell'autorizzazione per usare la classe o eseguire il metodo. L'attributo PrincipalPermission fornisce un meccanismo attraverso il quale è possibile definire queste regole.

Viene illustrato l'uso dell'attributo nei gestori eventi e RowDeleting di SelectedIndexChanged GridView per impedire l'esecuzione PrincipalPermission da parte di utenti anonimi e utenti diversi da Tito. Tutto ciò che dobbiamo fare è aggiungere l'attributo appropriato a ogni definizione di funzione:

[PrincipalPermission(SecurityAction.Demand, Authenticated=true)]
protected void FilesGrid_SelectedIndexChanged(object sender, EventArgs e)
{
    ...
}

[PrincipalPermission(SecurityAction.Demand, Name="Tito")]
protected void FilesGrid_RowDeleting(object sender, GridViewDeleteEventArgs e)
{
    ...
}

L'attributo per il SelectedIndexChanged gestore eventi determina che solo gli utenti autenticati possono eseguire il gestore eventi, dove come attributo RowDeleting nel gestore eventi limita l'esecuzione a Tito.

Se, in qualche modo, un utente diverso da Tito tenta di eseguire il RowDeleting gestore eventi o un utente non autenticato tenta di eseguire il SelectedIndexChanged gestore eventi, il runtime .NET genererà un SecurityExceptionoggetto .

Figura 14: Se il contesto di sicurezza non è autorizzato a eseguire il metodo, viene generato un SecurityException oggetto (fare clic per visualizzare l'immagine a dimensioni complete)

Nota

Per consentire a più contesti di sicurezza di accedere a una classe o a un metodo, decorare la classe o il metodo con un PrincipalPermission attributo per ogni contesto di sicurezza. Vale a dire, per consentire sia a Tito che Bruce di eseguire il RowDeleting gestore eventi, aggiungere duePrincipalPermission attributi:

[PrincipalPermission(SecurityAction.Demand, Name="Tito")]

[PrincipalPermission(SecurityAction.Demand, Name="Bruce")]

Oltre a ASP.NET pagine, molte applicazioni hanno anche un'architettura che include vari livelli, ad esempio Logica di business e livelli di accesso ai dati. Questi livelli vengono in genere implementati come librerie di classi e offrono classi e metodi per l'esecuzione di logica di business e funzionalità correlate ai dati. L'attributo PrincipalPermission è utile per applicare le regole di autorizzazione a questi livelli.

Per altre informazioni sull'uso dell'attributo PrincipalPermission per definire le regole di autorizzazione sulle classi e sui metodi, vedere la voce di blog di Scott GuthrieAggiunta di regole di autorizzazione ai livelli di business e dati usando PrincipalPermissionAttributes.

Riepilogo

In questa esercitazione è stato illustrato come applicare le regole di autorizzazione basate sull'utente. Abbiamo iniziato con un'occhiata ad ASP. Framework di autorizzazione URL di NET. In ogni richiesta, il motore UrlAuthorizationModule di ASP.NET controlla le regole di autorizzazione URL definite nella configurazione dell'applicazione per determinare se l'identità è autorizzata ad accedere alla risorsa richiesta. In breve, l'autorizzazione URL semplifica la specifica delle regole di autorizzazione per una pagina specifica o per tutte le pagine in una determinata directory.

Il framework di autorizzazione URL applica le regole di autorizzazione in base a una pagina. Con l'autorizzazione URL, l'identità richiesta è autorizzata ad accedere a una determinata risorsa o meno. Molti scenari, tuttavia, richiedono regole di autorizzazione più granulari. Anziché definire chi può accedere a una pagina, potrebbe essere necessario consentire a tutti di accedere a una pagina, ma di visualizzare dati diversi o offrire funzionalità diverse a seconda dell'utente che visita la pagina. L'autorizzazione a livello di pagina comporta in genere la nascondere elementi dell'interfaccia utente specifici per impedire agli utenti non autorizzati di accedere alle funzionalità vietate. Inoltre, è possibile usare attributi per limitare l'accesso alle classi ed esecuzione dei relativi metodi per determinati utenti.

Programmazione felice!

Altre informazioni

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

• Aggiunta di regole di autorizzazione a livelli di business e dati tramite PrincipalPermissionAttributes
• autorizzazione ASP.NET
• Modifiche tra IIS6 e IIS7 Security
• Configurazione di file e sottodirectory specifiche
• Limitazione delle funzionalità di modifica dei dati in base all'utente
• Guida introduttiva al controllo LoginView
• Informazioni sull'autorizzazione DELL'URL IIS7
• UrlAuthorizationModule Documentazione tecnica
• Uso dei dati in ASP.NET 2.0

Informazioni sull'autore

Scott Mitchell, autore di più libri ASP/ASP.NET e fondatore di 4GuysFromRolla.com, ha lavorato con le tecnologie Web Microsoft dal 1998. Scott lavora come consulente indipendente, allenatore e scrittore. Il suo ultimo libro è Sams Teach Yourself ASP.NET 2,0 in 24 Ore. Scott può essere raggiunto all'indirizzo mitchell@4guysfromrolla.com o tramite il suo blog all'indirizzo http://ScottOnWriting.NET.

Grazie speciali

Questa serie di esercitazioni è stata esaminata da molti revisori utili. Interessati a esaminare i prossimi articoli MSDN? In tal caso, lasciami una riga in mitchell@4GuysFromRolla.com.

IndietroAvanti