Résoudre les problèmes d’authentification par formulaire

Le cookie d’authentification par formulaire est perdu

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

Le ticket d’authentification par formulaire expire

L’autre cause courante de redirection d’un utilisateur est si le ticket d’authentification par formulaire a expiré. Le ticket d’authentification par formulaire peut expirer de deux manières. Le premier scénario se produit si vous utilisez l’expiration absolue. Avec l’expiration absolue, le ticket d’authentification expire à l’expiration du délai d’expiration. Par exemple, vous définissez une expiration de 20 minutes et un utilisateur visite le site à 14h00. L’utilisateur est redirigé vers la page de connexion si l’utilisateur visite le site après 14h20.

Si vous utilisez l’expiration glissante, le scénario est un peu plus compliqué. Le cookie et le ticket résultant sont mis à jour si l’utilisateur visite le site après que le délai d’expiration a expiré à moitié. Par exemple, vous définissez une expiration de 20 minutes à l’aide d’une expiration glissante. Un utilisateur visite le site à 14h00 et l’utilisateur reçoit un cookie qui est défini pour expirer à 14h20. L’expiration est mise à jour uniquement si l’utilisateur visite le site après 14h10. Si l’utilisateur visite le site à 14h09, le ticket n’est pas mis à jour, car la moitié du délai d’expiration n’est pas écoulée. Si l’utilisateur attend ensuite 12 minutes et qu’il visite le site à 14h21, le ticket est arrivé à expiration. L’utilisateur est redirigé vers la page de connexion.

Une façon d’aborder ce type de problème consiste à journaliser les informations de ticket et de cookie d’authentification par formulaire. De cette façon, vous pouvez voir si le cookie a été reçu par IIS et quelles sont les valeurs. Pour ce faire, écrivez un HttpModule, puis branchez ce module dans le pipeline de requête. Vous n’aurez pas à modifier le code de votre application pour obtenir les informations dont vous avez besoin.

L’exemple joint fonctionne dans Microsoft .NET Framework 1.1 et .NET Framework 2.0 et contient des commentaires tout au long. L’exemple inclut les fichiers suivants :

• FormsAuthEvents.cs : classe qui implémente IHttpModule et lie à l’événement Application_BeginRequest.

• FormsAuthInfo.cs : classe qui récupère le cookie et déchiffre le ticket d’authentification par formulaire. Il vérifie également le fichier Web.config de l’application pour s’assurer que l’authentification par formulaire est activée.

• FormsAuthConfig.cs : classe qui lit les informations du fichier FormsAuthLogger.config.

• Log.cs : fichier qui accepte un stringbuilder et écrit les valeurs dans un fichier journal.

• FormsAuthLogger.config : fichier XML lu par le fichier Log.cs. Ce fichier doit se trouver dans le dossier /bin avec la DLL générée. Le fichier vous permet de configurer les éléments suivants :

  • Filtrer par adresse IP : vous pouvez filtrer la capture de données par adresse IP du client. De cette façon, vous pouvez enregistrer uniquement les demandes d’un client connu pour reproduire le problème. Cela réduit la taille du journal.

  • Type de capture : spécifie où enregistrer le fichier. La valeur par défaut est le dossier Temporary ASP.NET Files, mais vous pouvez l’enregistrer n’importe où tant que le compte de processus de travail a la possibilité d’écrire dans le dossier.

Remarque Je vais fournir un lien de téléchargement pour le code fourni dans le fichier FormsAuthLogger.zip.

Je vais souligner les main domaines ici:

1. Créez une classe qui implémente l’interface IHttpModule.

   public class FormsAuthEvents : IHttpModule 
   {
   …code…
   }

2. Branchez l’événement que vous souhaitez examiner. Dans cet exemple, nous utilisons l’événement Application_BeginRequest. De cette façon, nous pouvons examiner chaque demande et déterminer si elle contient le cookie d’authentification par formulaire et enregistrer le FormsAuthenticationTicket si le cookie est présent.

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

3. Implémentez l’événement Application_BeginRequest.

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

4. Récupérez le cookie d’authentification par formulaire, puis déchiffrez-le.

5. Journaliser les valeurs. Je vous recommande de journaliser les éléments suivants en plus des informations sur les formulaires. Cela vous aidera à aligner vos informations d’authentification par formulaire dans les journaux IIS, si nécessaire :

   • Date : vous permet de voir quand la demande a été envoyée.

   • RequestType : indique si la requête est get ou post.

   • URL : affiche le modèle de requêtes menant au problème.

   • Referrer

   • ClientIP : lie les requêtes à un client spécifique.