Colonne vocale de prise en charge ASP .NET

Résolution des problèmes d’authentification par formulaire

Bienvenue dans la colonne ASP.NET Support Voice ! Je m’appelle Jerry Orman. J’ai travaillé avec Microsoft depuis 5 ans et j’ai passé la plupart de mon temps à me concentrer sur les technologies liées au web telles que Microsoft FrontPage et les nouvelles technologies Microsoft SharePoint. J’ai passé la dernière année à travailler avec Microsoft ASP.NET en tant qu’ingénieur du support technique. Ce mois-ci, dans la colonne Support Voice, je vais vous expliquer comment résoudre les problèmes d’authentification par formulaire dans Microsoft ASP.NET.

Résolution des problèmes d’authentification par formulaire

Lorsque vous utilisez l’authentification par formulaire dans une application ASP.NET, vous pouvez trouver nécessaire de résoudre un problème qui se produit lorsque l’utilisateur est redirigé de manière aléatoire vers la page de connexion. Dans un monde idéal, ce problème se produirait d’une manière qui vous permettrait d’attacher facilement un débogueur et de capturer le problème. Toutefois, dans les environnements de production, c’est rarement le cas. Pour résoudre un problème aléatoire comme celui-ci, vous devez journaliser les informations relatives au problème afin de pouvoir en limiter la cause racine.Dans cette colonne, nous allons aborder brièvement le concept d’authentification par formulaire. Nous allons ensuite examiner les scénarios qui conduisent à rediriger un utilisateur vers la page de connexion et comment capturer les données pertinentes pour isoler le problème. Nous allons également expliquer comment implémenter une interface IHttpModule pour journaliser les informations d’authentification par formulaire.

Vue d’ensemble de l’authentification par formulaire

Lorsqu’un utilisateur s’authentifie auprès d’un site Web à l’aide de l’authentification par formulaire, le serveur crée un cookie. La valeur du cookie est un ticket d’authentification par formulaire chiffré. Le cookie est transmis au serveur à chaque demande à l’application, et la classe FormsAuthenticationModule déchiffre la valeur du cookie et détermine si l’utilisateur est valide ou non.Par défaut, la classe FormsAuthenticationModule est ajoutée dans le fichier Machine.config. La classe FormsAuthenticationModule gère le processus FormsAuthentication.Voici une entrée du fichier Machine.config :

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

Le trafic HTTP général pour l’authentification à l’aide de l’authentification par formulaire ressemble à ce qui suit :

  1. Le client envoie un HTTP GET à Default.aspx. Aucun cookie d’authentification par formulaire n’est envoyé.

  2. Le serveur envoie une réponse 302 (redirection) à Login.aspx.

  3. Le client envoie une requête HTTP POST à Login.aspx. Il inclut les informations de connexion.

  4. Le serveur envoie une réponse 302 (redirection) à Default.aspx. Le cookie d’authentification par formulaire est inclus.

  5. Le client envoie un HTTP GET à Default.aspx. Cela inclut le cookie d’authentification par formulaire.

Pour plus d’informations sur l’implémentation et l’utilisation de l’authentification par formulaire, visitez les sites Web MSDN suivants :

http://msdn2.microsoft.com/en-us/library/7t6b43z4.aspx

http://msdn2.microsoft.com/en-us/library/system.web.security.formsauthentication(vs.71).aspx

http://msdn2.microsoft.com/en-us/library/system.web.security.formsauthenticationticket(vs.71).aspxPour plus d’informations sur le partage de cookies d’authentification par formulaire, visitez le site Web ASP.NET suivant :

http://quickstarts.asp.net/QuickStartv20/aspnet/doc/security/formsauth.aspx

Raisons pour lesquelles un utilisateur peut être redirigé vers la page de connexion

Le cookie d’authentification par formulaire est perdu

Scénario 1

Dans ce scénario, un utilisateur se connecte au site Web. À un moment donné, le client envoie une requête au serveur, et La classe FormsAuthenticationModule ne reçoit pas le cookie. Vous pouvez déterminer si une requête utilisateur ne contient pas le cookie en activant la journalisation des cookies dans Microsoft Internet Information Services (IIS). Pour ce faire, procédez comme suit :

  1. Ouvrez la console MMC (Microsoft Management Console) IIS.

  2. Cliquez avec le bouton droit sur le site web, puis cliquez surPropriétés.

  3. Cliquez sur l’onglet Site web , puis sur Activer la journalisation.

  4. Vérifiez que le format de journal est W3C Extended Log File Format.

  5. Cliquez sur Propriétés.

  6. Cliquez sur l’onglet Avancé , puis surPropriétés étendues.

  7. Sous Propriétés étendues, sélectionnez la zone de case activée Cookie(cs)) et la zone de case activée Referer (cs(Referer)).

Après ce problème, déterminez quel client a rencontré le problème et l’adresse IP de ce client. Filtrez le journal IIS sur l’adresse IP de ce client et affichez la colonne <cookie>.Remarque Vous pouvez utiliser l’analyseur de journaux pour analyser les journaux IIS. Pour télécharger Log Parser, visitez le site web Microsoft suivant :

http://www.microsoft.com/download/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07 Une fois que vous avez la liste des demandes de cet utilisateur spécifique, recherchez les demandes sur la page de connexion. Vous savez qu’ils ont été redirigés vers cette page et que vous souhaitez voir les demandes avant la redirection. Si vous voyez quelque chose de similaire à ce qui suit, le client n’a pas envoyé le cookie ou le cookie a été supprimé sur le réseau entre le client et le serveur.Il s’agit de la connexion initiale.

Méthode

Page

Réponse

Cookies

AVOIR

/Default.aspx

302 (redirection)

Aucun cookies

AVOIR

/Login.aspx

200 (succès)

Aucun cookies

PUBLIER

/Login.aspx

302 (redirection)

Aucun cookies

AVOIR

/Default.aspx

200 (succès)

. ASPXAUTH

AVOIR

/SomePage.aspx

302 (redirection)

Non. ASPXAUTH Cookie

Il s’agit d’autres demandes, suivies d’une demande à une page sur le site sans . Cookie ASPXAUTH.

Méthode

Page

Réponse

Cookies

AVOIR

/SomePage.aspx

302 (redirection)

Non. ASPXAUTH Cookie

AVOIR

/Login.aspx

200 (succès)

Non. ASPXAUTH Cookie

PUBLIER

/Login.aspx

302 (redirection)

Non. ASPXAUTH Cookie

AVOIR

/SomePage.aspx

200 (succès)

. ASPXAUTH

Remarque La première demande de cet utilisateur n’est pas susceptible d’avoir un cookie d’authentification par formulaire, sauf si vous créez un cookie persistant. Le journal IIS affiche uniquement les cookies reçus dans la demande. La première demande pour avoir le cookie d’authentification par formulaire sera sur la demande après une tentative de connexion réussie.

Scénario 2

Le cookie d’authentification par formulaire peut également être perdu lorsque la limite de cookies du client est dépassée. Dans Microsoft Internet Explorer, il existe une limite de 20 cookies. Une fois le 20e cookie créé sur le client, les cookies précédents sont supprimés de la collection du client. Si . Le cookie ASPXAUTH est supprimé, l’utilisateur est redirigé vers la page de connexion lors du traitement de la requête suivante.Vous pouvez résoudre ces deux scénarios de la même façon. Examinez la demande juste avant la redirection vers la page de connexion. Si la demande adressée à cette page génère des cookies, il s’agit d’un élément à examiner.Vous pouvez utiliser Fiddler pour afficher les en-têtes HTTP envoyés au client. Après avoir capturé le trafic, double-cliquez sur une demande, puis cliquez sur En-têtes pour afficher l’en-tête Set-Cookie. Si vous tracez une connexion réussie, l’en-tête Set-Cookie s’affiche dans la réponse d’une connexion réussie.Pour télécharger Fiddler, visitez le site Web Fiddler suivant :

http://www.fiddlertool.com/fiddler/

Scénario 3

Une fois que la requête a quitté le client, différentes couches peuvent affecter les paquets envoyés. Pour déterminer si un périphérique réseau supprime le cookie, vous devez capturer une trace réseau sur le client et le serveur, puis rechercher le cookie dans le corps de la demande. Vous souhaitez examiner la demande du client pour vous assurer que le cookie a été envoyé et case activée la trace du serveur pour vous assurer que le serveur a reçu le cookie.Demande du client Il s’agit d’une requête GET après l’authentification de l’utilisateur. Les informations de ticket d’authentification par formulaire sont mises en évidence en bleu. Cela confirme que les informations de cookie ont quitté le client. Lorsque vous utilisez un outil de capture réseau, comme Netmon, vous voyez le trafic qui a réellement transité par la carte.

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

Requête côté serveur Lorsque vous examinez la requête qui a atteint le serveur, vous souhaitez vous assurer que le serveur a reçu les mêmes informations que celles que le client a envoyées. Si le serveur n’a pas reçu les mêmes informations, vous devez examiner d’autres appareils sur le réseau pour déterminer où le cookie a été supprimé.Remarque Il y a également eu des cas de filtres ISAPI supprimant les cookies. Si vous confirmez que le serveur Web a reçu le cookie, mais que le cookie n’est pas répertorié dans les journaux IIS, case activée les filtres ISAPI. Vous devrez peut-être supprimer les filtres pour voir si le problème est résolu.

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.

Besoin d’aide ?

Vous voulez plus d’options ?

Explorez les avantages de l’abonnement, parcourez les cours de formation, découvrez comment sécuriser votre appareil, etc.

Les communautés vous permettent de poser des questions et d'y répondre, de donner vos commentaires et de bénéficier de l'avis d'experts aux connaissances approfondies.