Condividi tramite

Risoluzione dei problemi relativi all'autenticazione basata su form

Si applica a: Internet Information Services

Spesso, quando si usa l'autenticazione basata su form in un'applicazione Web ASP.NET, è necessario risolvere un problema che si verifica quando una richiesta nuova o in corso viene reindirizzata in modo intermittente alla pagina di accesso dell'applicazione. È possibile eseguire il debug di questo problema nell'IDE di Visual Studio collegando un debugger in un ambiente di sviluppo. Negli ambienti di produzione, tuttavia, l'attività diventa frenetica e problematica. Per risolvere un problema casuale come questo, è necessario registrare le informazioni relative al problema in modo da limitare la causa radice.

Questo articolo illustra brevemente il concetto di autenticazione basata su form. Vengono inoltre illustrati vari scenari relativi a un utente reindirizzato alla pagina di accesso e a come acquisire i dati rilevanti per isolare il problema. Viene inoltre illustrato come implementare un'interfaccia IHttpModule per registrare le informazioni di autenticazione basata su form.

Panoramica dell'autenticazione basata su form di ASP.NET

L'autenticazione basata su form consente di autenticare gli utenti usando il proprio codice e quindi di mantenere un token di autenticazione in un cookie o nell'URL. L'autenticazione basata su form partecipa al ciclo di vita della pagina ASP.NET tramite la FormsAuthenticationModule classe . È possibile accedere alle informazioni e alle funzionalità di autenticazione basata su moduli usando la FormsAuthentication classe .

Per usare l'autenticazione basata su form, creare una pagina di accesso che raccoglie le credenziali dall'utente e include il codice per autenticare le credenziali. In genere, si configura l'applicazione per reindirizzare le richieste alla pagina di accesso quando gli utenti tentano di accedere a una risorsa protetta, ad esempio una pagina che richiede l'autenticazione. Se le credenziali dell'utente sono valide, è possibile chiamare i metodi della FormsAuthentication classe per reindirizzare la richiesta alla risorsa richiesta originariamente con un ticket di autenticazione appropriato (cookie). Se non si vuole il reindirizzamento, è sufficiente ottenere il cookie di autenticazione basata su form o impostarlo. Nelle richieste successive, il browser passa il cookie di autenticazione con la richiesta, che quindi ignora la pagina di accesso.

Per impostazione predefinita, la FormsAuthenticationModule classe viene aggiunta nel file Machine.config . La FormsAuthenticationModule classe gestisce il processo di autenticazione basata su form.

Nel file Machine.config è possibile visualizzare la voce seguente:

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

È possibile configurare l'autenticazione basata su form usando l'elemento di configurazione di autenticazione, ad esempio impostando una pagina di accesso. Nel file di configurazione specificare un URL per reindirizzare le richieste non autenticate alla pagina di accesso.

Dopo l'autenticazione, il FormsAuthenticationModule modulo imposta il valore della proprietà User su un riferimento all'utente autenticato. Nell'esempio di codice seguente viene illustrato come leggere a livello di codice l'identità dell'utente autenticato dai moduli.

String authUser2 = User.Identity.Name;

Un modo pratico per usare l'autenticazione basata su form consiste nell'usare ASP.NET appartenenza e ASP.NET controlli di accesso. ASP.NET'appartenenza consente di archiviare e gestire le informazioni utente e include metodi per autenticare gli utenti. ASP.NET controlli di accesso funzionano con l'appartenenza ASP.NET. Incapsulano la logica per richiedere agli utenti le credenziali, convalidare gli utenti, ripristinare o sostituire le password e così via. In effetti, ASP.NET appartenenza e ASP.NET controlli di accesso forniscono un livello di astrazione sull'autenticazione basata su form. Queste funzionalità sostituiscono la maggior parte o tutte le operazioni che normalmente è necessario eseguire per usare l'autenticazione basata su form.

Scenari

Di seguito sono riportati gli scenari per una richiesta di reindirizzamento alla pagina login.aspx :

Il cookie di autenticazione basata su form viene perso.

Scenario 1

Si accede al sito Web. A un certo punto, il client invia una richiesta al server e la FormsAuthenticationModule classe non riceve il cookie.

Scenario 2

Il cookie di autenticazione basata su form può anche essere perso quando viene superato il limite di cookie del client. In Microsoft Internet Explorer è previsto un limite di 20 cookie. Quando il contatore raggiunge 20, i 19 cookie precedenti vengono rimossi dalla raccolta del client. Se il cookie ASPXAUTH viene rimosso, si viene reindirizzati alla pagina di accesso quando viene elaborata la richiesta successiva.

Scenario 3

Dopo che la richiesta lascia il client, esistono vari livelli che possono influire sui pacchetti inviati. Per determinare se un dispositivo di rete rimuove il cookie, è necessario acquisire una traccia di rete nel client e nel server e quindi cercare nel corpo della richiesta il cookie. Si vuole esaminare la richiesta client per assicurarsi che il cookie sia stato inviato e controllare la traccia del server per assicurarsi che il server abbia ricevuto il cookie.

Timeout del ticket di autenticazione basata su form

Per impostazione predefinita, nelle applicazioni ASP.NET 2.0 il valore di autenticazione timeout dei moduli è stato modificato in 30 minuti. Ciò significa che, dopo 30 minuti di inattività, verrà richiesto di eseguire di nuovo l'accesso.

Note

Quando si accede a un sito Web ogni volta, viene reimpostato l'orologio della finestra di 30 minuti. Solo se è inattiva c'è un timeout.

Se si vuole modificare il timeout valore in modo che sia più lungo, è possibile modificare facilmente il timeout valore nel file web.config locale (il timeout valore è espresso in minuti):

<system.web> 
 <authentication mode="Forms">     
   <forms timeout="120"/>                 
 </authentication>
</system.web>

Scenario 4

L'autenticazione del modulo può scadere prima del valore dell'attributo timeout definito nel file di configurazione.

Se il ticket di autenticazione form viene generato manualmente, la timeout proprietà del ticket sostituisce il valore impostato nel file di configurazione. Pertanto, se tale valore è minore del valore nel file di configurazione, il ticket di autenticazione form scade prima del valore dell'attributo del file timeout di configurazione e viceversa. Si supponga, ad esempio, che l'attributo FORMS di timeout sia impostato su 30 nel file Web.config e che il valore di scadenza del ticket sia impostato su 20 minuti. In questo caso, il ticket di autenticazione form scade dopo 20 minuti e quindi è necessario eseguire di nuovo l'accesso.

Event code: 4005
Event message: Forms authentication failed for the request. Reason: The ticket 
supplied has expired.

Scenario 5

In ASP.NET 4 applicazione Web usando l'autenticazione basata su form, il messaggio del registro eventi indica:

Event code: 4005 
Event message: Forms authentication failed for the request. Reason: The ticket supplied was invalid.

Raccolta dati e risoluzione dei problemi

Scenario di risoluzione dei problemi 1

È possibile determinare se una richiesta non contiene il cookie abilitando la registrazione dei cookie in Microsoft Internet Information Services (IIS). A tale scopo, effettuare i passaggi seguenti:

  1. Aprire IIS Microsoft Management Console (MMC).
  2. Fare clic con il pulsante destro del mouse sul sito Web e quindi scegliere Proprietà.
  3. Selezionare la scheda Sito Web e quindi selezionare Abilita registrazione.
  4. Assicurarsi che il formato del log sia W3C Extended Log file format ( Formato di file di log esteso W3C).
  5. Selezionare Proprietà.
  6. Selezionare la scheda Avanzate e quindi proprietà estese.
  7. In Proprietà estese selezionare le caselle di controllo Cookie(cs(Cookie)) e Referer (cs(Referer)).

Dopo che si verifica questo problema, determinare quale client ha avuto il problema e l'indirizzo IP del client. Filtrare l'accesso IIS all'indirizzo IP del client e visualizzare la <COOKIE> colonna.

Note

Usare Il parser di log per analizzare i log iis.

Dopo aver ottenuto l'elenco delle richieste da un utente specifico, cercare le richieste nella pagina di accesso. Si sa che sono stati reindirizzati a questa pagina e si desidera visualizzare le richieste prima che si sia verificato il reindirizzamento. Se viene visualizzato un messaggio simile al seguente, il client non ha inviato il cookie o il cookie è stato rimosso nella rete tra il client e il server.

Note

La prima richiesta non avrà probabilmente un cookie di autenticazione basata su form, a meno che non si stia creando un cookie permanente. Il log iis mostrerà solo i cookie ricevuti nella richiesta. Prima richiesta di avere il cookie di autenticazione basata su form dopo un tentativo di accesso riuscito.

Scenario di risoluzione dei problemi 2

Microsoft Internet Explorer è conforme alle limitazioni minime consigliate per RFC 2109 seguenti:

  • Almeno 300 cookie.
  • Almeno 4.096 byte per cookie (misurata in base alle dimensioni dei caratteri che comprendono il cookie non terminale nella descrizione della sintassi dell'intestazione Set-Cookie).
  • Almeno 20 cookie per host o nome di dominio univoco.

Il cookie di autenticazione basata su form può anche essere perso quando viene superato il limite di cookie del client. In Microsoft Internet Explorer è previsto un limite di 20 cookie. Quando il contatore raggiunge 20, i 19 cookie precedenti vengono rimossi dalla raccolta del client. Se il cookie ASPXAUTH viene rimosso, si viene reindirizzati alla pagina di accesso quando viene elaborata la richiesta successiva. È possibile usare Fiddler per visualizzare le intestazioni di richiesta o risposta HTTP per verificare se si riceve il cookie dal client. Scaricare Fiddler.

Avviare lo strumento Fiddler nel computer client, rimuovere tracce HTTP esistenti, accedere all'applicazione implementando l'autenticazione basata su moduli e provare ad accedere all'applicazione e osservare il traffico HTTP in Fiddler per verificare se si verifica uno scambio di cookie di autenticazione basata su moduli tra il client e il server. Dopo aver acquisito il traffico, fare doppio clic su una richiesta e quindi selezionare Intestazioni per visualizzare l'intestazione Set-Cookie. Se si traccia un account di accesso riuscito, verrà visualizzata l'intestazione Set-Cookie nella risposta di un account di accesso riuscito.

Per impostazione predefinita, Internet Explorer può archiviare un massimo di 20 cookie per ogni dominio. Se un server nel dominio invia più di 20 cookie a un computer client, il browser nel computer client rimuove automaticamente alcuni cookie obsoleti.

Ogni cookie è costituito da una singola coppia nome-valore. Questa coppia può essere seguita da coppie attributo-valore separate da punti e virgola. Questo limite è stato aumentato per semplificare lo sviluppo e l'hosting di applicazioni Web nei domini che devono usare molti cookie. L'installazione dell'aggiornamento 937143 aumenta il numero di cookie che Internet Explorer può archiviare per ogni dominio da 20 a 50. Per altre informazioni, vedere Domande frequenti su Internet Explorer e Microsoft Edge per professionisti IT.

Scenario di risoluzione dei problemi 3

Dopo che la richiesta lascia il client, esistono vari livelli che possono influire sui pacchetti inviati (firewall, proxy e servizi di bilanciamento del carico). Per determinare se un dispositivo di rete rimuove il cookie, è necessario acquisire una traccia di rete nel client e nel server e quindi cercare il cookie nel corpo della richiesta. È possibile esaminare la richiesta client per assicurarsi che il cookie sia stato inviato e quindi controllare la traccia del server per assicurarsi che il server abbia ricevuto tale cookie.

Richiesta client

Si tratta di una GET richiesta dopo che l'utente è stato autenticato. Le informazioni sul ticket di autenticazione basata su form sono evidenziate in grigio. Ciò conferma che le informazioni sul cookie hanno lasciato il client. Quando si usa uno strumento di acquisizione di rete, ad esempio WireShark, viene visualizzato il traffico effettivamente passato attraverso la scheda.

47 45 54 20 68 74 74 70-3a 2f 2f 6c 6f 63 61 6c   GET http://local
68 6f 73 74 2f 46 6f 72-6d 73 41 75 74 68 4c 6f   host/FormsAuthLo
67 54 65 73 74 2f 57 65-62 46 6f 72 6d 31 2e 61   gTest/WebForm1.a
73 70 78 20 48 54 54 50-2f 31 2e 31 0d 0a 41 63   spx HTTP/1.1..Ac
63 65 70 74 3a 20 69 6d-61 67 65 2f 67 69 66 2c   cept: image/gif,
…Other headers of the GET request…
63 68 65 0d 0a 43 6f 6f-6b 69 65 3a 20 2e 41 53   che..Cookie: .AS
50 58 41 55 54 48 3d 33-43 45 46 39 42 39 41 30   PXAUTH=3CEF9B9A0
43 33 37 41 44 46 36 33-45 36 42 44 33 37 42 36   C37ADF63E6BD37B6
39 43 44 41 32 35 30 30-30 46 38 30 37 32 38 46   9CDA25000F80728F
35 31 43 39 35 36 36 44-31 34 43 35 34 31 34 35   51C9566D14C54145
38 31 43 39 33 45 32 41-30 31 44 44 43 44 45 46   81C93E2A01DDCDEF
32 34 41 31 37 34 32 39-34 31 30 43 30 39 37 34   24A17429410C0974
42 33 45 43 42 30 36 34-32 32 38 45 33 35 33 39   B3ECB064228E3539
39 41 38 32 32 42 33 42-39 33 36 44 46 30 38 46   9A822B3B936DF08F
42 41 42 44 33 45 31 30-32 44 30 30 32 31 30 43   BABD3E102D00210C
32 45 31 33 39 38 30 37-39 42 32 33 35 32 39 46   2E1398079B23529F
34 46 35 44 37 34 41 3b-20 50 72 6f 66 69 6c 65   4F5D74A; Profile
3d 56 69 73 69 74 6f 72-49 64 3d 62 32 34 65 62   =VisitorId=b24eb

Richiesta lato server

Quando viene visualizzata la richiesta che ha raggiunto il server, assicurarsi che il server abbia ricevuto le stesse informazioni inviate dal client. Se il server non ha ricevuto le stesse informazioni, è necessario analizzare altri dispositivi in rete per determinare dove è stato rimosso il cookie.

Note

Sono state inoltre presenti istanze di filtri ISAPI che rimuovono i cookie. Se si conferma che il server Web ha ricevuto il cookie, ma il cookie non è elencato nei log IIS, controllare i filtri ISAPI. Potrebbe essere necessario rimuovere i filtri per verificare se il problema è stato risolto.

Scenario di risoluzione dei problemi 5

  • Se lo scenario prevede una web farm, assicurarsi che i file di configurazione in ogni server della Web farm abbiano lo stesso valore per la chiave di convalida e le chiavi di decrittografia, che vengono usate rispettivamente per hashing e decrittografia. Per mantenere la coerenza in tutti i server della farm, usare il valore machineKey seguente:

    <machineKey validationKey="<yourKey>" decryptionKey="<yourKey>" validation="SHA1" />

    Per altre informazioni sulle chiavi del computer, vedere Machine Key and Plan Application Security.For more information on machine keys, see Machine Key and Plan Application Security.

    Per informazioni su come generare chiavi del computer, vedere Impostazioni chiave computer.

  • Confrontare i valori per entrambi i timeout moduli, ovvero il modulo di autenticazione e il modulo di sessione, in tutti i server Web.

  • Confrontare la versione System.Web.dll nella cartella Framework per ASP.NET 4 tra tutti i server Web nella farm. Autenticazione basata su form non riuscita per la richiesta. Il motivo è che il ticket fornito non è valido. Ciò si verifica a causa della mancanza dell'aggiornamento di affidabilità 1 per MS .NET Framework 4 in uno dei server Web.

  • Installare l'aggiornamento di affidabilità 1 per .NET Framework 4 kb2533523 nel server mancante e riavviato il server. Il problema è stato risolto Per altre informazioni, vedere Reliability Update 1 per .NET Framework 4.

Ulteriori informazioni

Dichiarazione di non responsabilità sulle informazioni di terze parti

I prodotti di terzi citati in questo articolo sono prodotti da società indipendenti da Microsoft. Microsoft non rilascia alcuna garanzia implicita o esplicita relativa alle prestazioni o all'affidabilità di tali prodotti

  • Last updated on