Risolvere i problemi relativi all'autenticazione dei moduli

Il cookie di autenticazione forms viene perso

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

Timeout del ticket di autenticazione dei moduli

L'altra causa comune per cui un utente deve essere reindirizzato è se il ticket di autenticazione forms è scaduto. Il timeout del ticket di autenticazione dei moduli può essere effettuato in due modi. Il primo scenario si verifica se si usa una scadenza assoluta. Con una scadenza assoluta, il ticket di autenticazione scade alla scadenza del periodo di scadenza. Ad esempio, si imposta una scadenza di 20 minuti e un utente visita il sito alle 14.00. L'utente verrà reindirizzato alla pagina di accesso se visita il sito dopo le 14.20.

Se usi la scadenza scorrevole, lo scenario è un po' più complicato. Il cookie e il ticket risultante vengono aggiornati se l'utente visita il sito dopo la mezza scadenza. Ad esempio, è possibile impostare una scadenza di 20 minuti usando la scadenza scorrevole. Un utente visita il sito alle 14:00 e riceve un cookie che scadrà alle 14.20. La scadenza viene aggiornata solo se l'utente visita il sito dopo le 14.10. Se l'utente visita il sito alle 14:09, il ticket non viene aggiornato perché metà della scadenza non è passata. Se l'utente attende 12 minuti, visitando il sito alle 14.21, il ticket sarà scaduto. L'utente viene reindirizzato alla pagina di accesso.

Un modo per affrontare questo tipo di problema consiste nel registrare le informazioni sui cookie di autenticazione dei moduli e sui ticket. In questo modo, è possibile verificare se il cookie è stato ricevuto da IIS e quali sono i valori. È possibile farlo scrivendo un HttpModule e quindi collegando tale modulo nella pipeline della richiesta. Non sarà necessario modificare il codice dell'applicazione per ottenere le informazioni necessarie.

L'esempio allegato funziona in Microsoft .NET Framework 1.1 e .NET Framework 2.0 e contiene commenti in tutto. L'esempio include i file seguenti:

• FormsAuthEvents.cs: classe che implementa IHttpModule e collegamenti all'evento Application_BeginRequest.

• FormsAuthInfo.cs: classe che recupera il cookie e decrittografa il ticket di autenticazione forms. Controlla anche il file di Web.config dell'applicazione per verificare che l'autenticazione forms sia abilitata.

• FormsAuthConfig.cs: classe che legge le informazioni del file FormsAuthLogger.config.

• Log.cs: Il file che accetta un stringbuilder e scrive i valori in un file di log.

• FormsAuthLogger.config: il file XML letto dal file Log.cs. Questo file deve trovarsi nella cartella /bin con la DLL compilata. Il file consente di configurare quanto segue:

  • Filtra per IP: è possibile filtrare l'acquisizione dei dati in base all'IP del client. In questo modo, è possibile registrare solo le richieste provenienti da un client noto per riprodurre il problema. In questo modo si riducono le dimensioni del log.

  • Tipo di acquisizione: specifica dove salvare il file. L'impostazione predefinita è la cartella File di ASP.NET temporanei, ma è possibile salvarla ovunque, purché l'account del processo di lavoro abbia la possibilità di scrivere nella cartella.

Nota: fornisco un collegamento per il download del codice fornito nel file di FormsAuthLogger.zip.

Vi faccio notare le aree principali qui:

1. Creare una classe che implementa l'interfaccia IHttpModule.

   public class FormsAuthEvents : IHttpModule 
   {
   …code…
   }

2. Collega l'evento che vuoi esaminare. In questo esempio viene usato l'evento Application_BeginRequest. In questo modo è possibile esaminare ogni richiesta e determinare se dispone del cookie di autenticazione forms e registrare FormsAuthenticationTicket se il cookie è presente.

   public void Init(HttpApplication application) 
   {
   //Wire up the BeginRequest event
   application.BeginRequest += (new EventHandler(this.Application_BeginRequest));
   }

3. Implementare l'evento Application_BeginRequest.

   private void Application_BeginRequest(Object source, EventArgs e)
   {
      …code to log the ticket…
   }
   

4. Recuperare il cookie di autenticazione di forms e decrittografarlo.

5. Registrare i valori. Consiglierei di registrare quanto segue oltre alle informazioni sui moduli. In questo modo sarà possibile allineare le informazioni di autenticazione dei moduli ai log di IIS, se necessario:

   • Data: consente di vedere quando è stata inviata la richiesta.

   • RequestType: indica se la richiesta è un oggetto Get o un Post.

   • URL: mostra il modello di richieste che causano il problema.

   • Referrer

   • ClientIP: legami nelle richieste a un cliente specifico.