DetailPage-MSS-KB

Base de connaissances

Numéro d'article: 910439 - Dernière mise à jour: jeudi 30 mai 2013 - Version: 2.0

 
Colonne vocale d'assistance ASP .NET

Résolution des problèmes de l'authentification par formulaires

Pour personnaliser cette colonne à vos besoins, nous souhaitons vous inviter à soumettre vos idées sur les sujets qui vous intéressent et problèmes que vous souhaitez voir traités dans de futurs articles de la Base de connaissances et des colonnes Support Voice. Vous pouvez soumettre vos idées et commentaires à l'aide de la Demandez-le (http://support.microsoft.com/common/survey.aspx?scid=sw;en;1176&p0=&p1=&p2=&p3=&p4=) . Il existe également un lien vers le formulaire au bas de cette colonne.

Sommaire

Bienvenue dans la chronique ASP.NET Support Voice ! Mon nom est Jerry Orman. J'ai ont été avec Microsoft sur 5 ans et ont passé la majeure partie de mon temps consacré aux technologies liées à la Web tel que Microsoft FrontPage et le nouvelles technologies Microsoft SharePoint. J'ai passé l'année dernière utilisation Microsoft ASP.NET en tant qu'un ingénieur du support. Ce mois-ci à la voix prise en charge colonne, je vais vous expliquer comment résoudre les problèmes de l'authentification par formulaires dans Microsoft ASP.NET.

Résolution des problèmes de l'authentification par formulaires

Lorsque vous utilisez l'authentification par formulaires dans une application ASP.NET, Il peut s'avérer nécessaire pour résoudre un problème qui se produit lorsque l'utilisateur est au hasard redirigé vers la page de connexion. Dans un monde idéal, ce problème peut se produire d'une manière qui vous permet de joindre facilement un débogueur et capture le problème. Dans les environnements de production, toutefois, c'est rarement le cas. Pour résoudre un problème aléatoire comme celle-ci, vous devez enregistrer les informations relatives au problème afin que vous pouvez réduire la racine cause.

Dans cet article, nous aborderons brièvement la Concept de l'authentification de formulaires. Nous allons ensuite dans les scénarios conduire à un utilisateur est redirigé vers la page de connexion et comment capturer des données qui est pertinente pour isoler le problème. Nous traiterons également comment implémenter une interface IHttpModule pour enregistrer les informations d'authentification de formulaires.

Vue d'ensemble de l'authentification de formulaires

Lorsqu'un utilisateur s'authentifie sur 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 de formulaires chiffré. Le cookie est transmis au serveur à chaque demande pour 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, le FormsAuthenticationModule classe est ajoutée dans le fichier Machine.config. La classe FormsAuthenticationModule gère le processus de FormsAuthentication.

Voici une entrée à partir 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 formulaires est similaire au suivant :
  1. Le client envoie un verbe HTTP GET à Default.aspx. Aucun cookie d'authentification de formulaires n'est envoyé.
  2. Le serveur envoie une réponse 302 (redirection) vers Login.aspx.
  3. Le client envoie un verbe HTTP POST vers Login.aspx. Il inclut les informations de connexion.
  4. Le serveur envoie une réponse 302 (redirection) à Default.aspx. Le cookie d'authentification de formulaires est inclus.
  5. Le client envoie un verbe HTTP GET à Default.aspx. Cela inclut le cookie d'authentification de formulaires.
Pour plus d'informations sur la mise en œuvre et à l'aide de l'authentification par formulaires, reportez-vous aux sites Web MSDN suivants :
http://msdn2.Microsoft.com/en-us/library/7t6b43z4.aspx (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.formsauthentication(vs.71).aspx)
http://msdn2.Microsoft.com/en-us/library/System.Web.Security.FormsAuthenticationTicket (vs.71) .aspx (http://msdn2.microsoft.com/en-us/library/system.web.security.formsauthenticationticket(vs.71).aspx)
Pour plus d'informations sur le partage des cookies d'authentification, visitez le site Web ASP.NET :
http://QuickStarts.ASP.NET/QuickstartV20/ASPNET/doc/Security/Formsauth.aspx (http://quickstarts.asp.net/QuickStartv20/aspnet/doc/security/formsauth.aspx)

Raisons qu'un utilisateur peut être redirigé vers la page de connexion

Le cookie d'authentification de formulaires est perdu

Scénario 1

Dans ce scénario, un utilisateur ouvre une session le site Web. À un moment donné, le client envoie une demande au serveur et le Classe FormsAuthenticationModule ne reçoit pas le cookie. Vous pouvez déterminer si une demande de l'utilisateur ne contient-elle pas le cookie en activant le cookie journalisation dans Microsoft Internet Information Services (IIS). Pour ce faire, procédez comme suit :
  1. Ouvrez la Console de gestion Microsoft (MMC).
  2. Cliquez droit sur le site Web, puis cliquez surPropriétés.
  3. Cliquez sur le Site Web onglet, puis cliquez sur Activer Enregistrement.
  4. Assurez-vous que le format de journal est W3C étendu de fichier journal Format.
  5. Cliquez sur Propriétés.
  6. Cliquez sur le Avancée onglet, puis cliquez surPropriétés étendues.
  7. Sous Propriétés étendues, cliquez pour sélectionner le Cookie(cs(cookie)) case à cocher et le « Referer » (cs(Referer)) .
Une fois que ce problème se produit, déterminer quel client avait la problème et cette adresse IP du client. Filtrer le journal IIS de cette adresse IP du client, et d'afficher le cookie> colonne.

Remarque : Vous pouvez utiliser Log Parser pour analyser les journaux IIS. Pour télécharger l'Analyseur de journal, reportez-vous au site Web de Microsoft à l'adresse suivante :
http://www.Microsoft.com/downloads/details.aspx?FamilyId=890cd06b-abf8-4c25-91b2-f8d975cf8c07 (http://www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07)
Après avoir établi la liste des demandes de ce spécifique utilisateur, recherchez les demandes à la page de connexion. Vous savez qu'elles ont été redirigées à cette page et que vous souhaitez voir les demandes avant le la redirection s'est produite. Si vous voyez quelque chose de similaire à la suivante, le client soit n'a pas envoyé que 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.
Réduire ce tableauAgrandir ce tableau
MéthodePageRéponseCookies
GET/ Default.aspx302 (Redirection)Non Cookies
GET/Login.aspx200 (Succès)Non Cookies
POST/Login.aspx302 (Redirection)Non Cookies
GET/ Default.aspx200 (Succès).ASPXAUTH
GET/SomePage.aspx302 (Redirection)Non .Cookie ASPXAUTH
Il s'agit des autres demandes, suivis d'une requête à une page sur le site sans le.Cookie ASPXAUTH.
Réduire ce tableauAgrandir ce tableau
MéthodePageRéponseCookies
GET/SomePage.aspx302 (Redirection)Non .Cookie ASPXAUTH
GET/Login.aspx200 (Succès)Non .Cookie ASPXAUTH
POST/Login.aspx302 (Redirection)Non .Cookie ASPXAUTH
GET/SomePage.aspx200 (Succès).ASPXAUTH

Remarque : La première requête à partir de cet utilisateur n'est pas susceptible d'avoir un formulaire cookie d'authentification, sauf si vous créez un cookie persistant. Le journal IIS affiche uniquement les cookies qui ont été reçus dans la demande. La première demande pour que le cookie d'authentification de formulaires sera sur la demande après un réussi tentative de connexion.
Scénario 2

Le cookie d'authentification de formulaires peut également être perdu lorsque la limite de cookie du client est dépassée. Dans Microsoft Internet Explorer, il existe une limite de 20 cookies. Une fois le cookie vingtième créé sur le client, les cookies précédentes sont supprimés à partir du client collection. Si le.Cookie ASPXAUTH est supprimé, l'utilisateur sera redirigé vers la page de connexion lors du traitement de la demande suivante.

Vous pouvez résoudre ces deux scénarios de la même façon. Regardez simplement la demande avant que la redirection vers la page de connexion. Si la demande à cette page génère les cookies, ce sera quelque chose à examiner.

Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
306070  (http://support.microsoft.com/kb/306070/ ) Limites de nombres et la taille d'un cookie dans Internet Explorer

Vous pouvez utiliser Fiddler pour afficher les en-têtes HTTP qui sont envoyés au client. Une fois que vous capturez le trafic, double-cliquez sur une requête puis cliquez sur En-têtes Pour afficher l'en-tête Set-Cookie. Si vous suivez un connexion établie, vous verrez l'en-tête Set-Cookie dans la réponse d'un connexion réussie.

Pour télécharger Fiddler, visitez le site Web de Fiddler suivant :
http://www.fiddlertool.com/Fiddler/ (http://www.fiddlertool.com/fiddler/)
Scénario 3

Une fois que la demande ne quitte le client, il existe différentes couches qui peut affecter les paquets sont envoyés. Pour déterminer si un périphérique réseau est suppression du cookie, vous devez capturer une trace réseau sur le client et le serveur, puis recherchez dans le corps de la demande pour le cookie. Vous souhaitez Examinez la demande du client pour vous assurer que le cookie a été envoyé et vérifiez si le serveur trace afin de vous assurer que le serveur a reçu le cookie.

Demande du client

Il s'agit d'une demande GET après l'authentification de l'utilisateur. Le informations de ticket d'authentification de formulaires sont mis en surbrillance en bleu. Cela permet de confirmer que les informations du cookie quitté le client. Lorsque vous utilisez une capture réseau outil, tels que Netmon, vous voyez le trafic qui en fait s'est passé par le biais de la adaptateur.
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
Demande côté serveur

Lorsque vous examinez la demande qui a atteint le serveur, vous Voulez vous assurer que le serveur a reçu les mêmes informations que le client a envoyé. Si le serveur n'a pas reçu les mêmes informations, vous devez étudier d'autres périphériques sur le réseau pour déterminer où le cookie a été supprimé.

Remarque : Ont également été instances des filtres ISAPI supprimer les cookies. Si vous confirmez que le serveur Web a reçu le cookie, mais le cookie n'est pas répertorié dans les journaux IIS, vérifiez que le filtre ISAPI. Vous devrez peut-être supprimer les filtres pour voir si le problème est résolu.

Expiration du ticket d'authentification forms

L'autre pour un utilisateur est redirigé se produit généralement si le authentification par formulaires ticket a expiré. L'authentification de formulaires ticket peut expirer de deux manières. Le premier scénario se produit si vous utilisez expiration absolue. Avec une expiration absolue, le ticket d'authentification expire lorsque le expiration du délai d'expiration. Par exemple, vous définissez une expiration de 20 minutes et un utilisateur visite le site à 14 h 00. L'utilisateur sera redirigé vers la page de connexion si l'utilisateur visite le site après 14 h 20.

Si vous utilisez l'expiration décalée, le scénario est un peu plus compliqué. Le cookie et le ticket qui en résultent sont mise à jour si l'utilisateur visite le site après que le délai d'expiration est expiré de moitié. Par exemple, vous définissez une expiration de 20 minutes par l'expiration décalée. Un utilisateur visite le site à 14 h 00, et l'utilisateur reçoit un cookie est configuré pour expirer à 14 h 20. La date d'expiration est actualisé uniquement si l'utilisateur visite le site après 14 h 10. Si l'utilisateur visite le site à 14 h 09, le ticket n'est pas mis à jour car la moitié des le délai d'expiration n'a pas été. Si l'utilisateur attend ensuite 12 minutes, visitez le site à 14 h 21, le ticket aura expiré. L'utilisateur est redirigé vers la connexion page.

Une approche de ce type de problème consiste à enregistrer les formulaires informations de cookie et le ticket d'authentification. De cette façon, vous pouvez voir si le cookie a été reçue par IIS et quelles sont les valeurs. Vous pouvez le faire en écrivant un HttpModuleet puis brancher ce module dans le pipeline de requête. Vous ne devrez pas modifier le code de votre application pour obtenir les informations vous besoin.

L'exemple joint fonctionne dans le Microsoft.NET Framework 1.1 et de.NET Framework 2.0 et a commentaires sur l'ensemble. L'exemple inclut les fichiers suivants :
  • FormsAuthEvents.cs : La classe qui implémente l'interface IHttpModule et est étroitement liée à l'événement Application_BeginRequest .
  • FormsAuthInfo.cs : La classe qui récupère le cookie et Déchiffre le ticket d'authentification de formulaires. Il vérifie également l'application Fichier Web.config afin de s'assurer que l'authentification par formulaire est activée.
  • FormsAuthConfig.cs : La classe qui lit les informations à partir de la Fichier FormsAuthLogger.config.
  • Log.cs : Le fichier qui accepte un stringbuilder et écrit les valeurs dans un fichier journal.
  • FormsAuthLogger.config : Le fichier XML qui est lu par le fichier Log.cs. Cela 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 IP : vous pouvez filtrer la capture des données par IP du client. De cette façon, vous pouvez vous connecter uniquement les demandes d'un client qui est connu pour reproduire le problème. Cela réduit la taille du journal.
    • Type de capture : Cela indique 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 vous propose un lien de téléchargement pour le code fourni dans le Fichier FormsAuthLogger.zip.

Je vous donnerai ici les principaux domaines :
  1. Créez une classe qui implémente l'interface IHttpModule .
    public class FormsAuthEvents : IHttpModule 
    {
    		…code…
    }
  2. Associer l'événement que vous souhaitez consulter. Dans cet exemple, Nous utilisons l'événement Application_BeginRequest . De cette façon, nous pouvons examiner chaque demande et déterminer si Il a le cookie d'authentification de formulaires et le journal FormsAuthenticationTicket si le cookie existe.
    public void Init(HttpApplication application) 
    {
    	//Wire up the BeginRequest event
    	application.BeginRequest += (new EventHandler(this.Application_BeginRequest));
    }
  3. Implémenter l'événement Application_BeginRequest .
    private void Application_BeginRequest(Object source, EventArgs e)
    {	
       …code to log the ticket…
    }
    
  4. Récupérer le cookie d'authentification de formulaires, puis déchiffrer Il s'agit.
  5. Consigne les valeurs. Je recommanderais de journalisation suivants Outre les informations de formulaires. Cela vous permettra d'aligner vos formulaires informations d'authentification dans les journaux IIS, si nécessaire :
    • Date : Permet de voir quand la demande est arrivée dans.
    • RequestType : Indique que la demande est Get ou une POST.
    • URL : Affiche le modèle de demandes qui ont précédé le problème.
    • Point d'accès
    • ClientIP : Ties dans les requêtes à une spécifique client.

Comme toujours, n'hésitez pas à soumettre des idées sur des sujets que vous souhaitez adressée dans les chroniques à venir ou dans la Base de connaissances à l'aide du Demandez-le (http://support.microsoft.com/common/survey.aspx?scid=sw;en;1176&p0=&p1=&p2=&p3=&p4=) .

Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft ASP.NET 1.1
  • Microsoft ASP.NET 1.0
  • Microsoft ASP.NET 2.0
Mots-clés : 
kbtshoot kbiis kbcode kbasp kbmt KB910439 KbMtfr
Traduction automatiqueTraduction automatique
IMPORTANT : Cet article est issu d'une traduction automatique réalisée par un logiciel Microsoft et non par un traducteur professionnel. Cette traduction automatique a pu aussi être révisée par la communauté Microsoft grâce à la technologie Community Translation Framework (CTF). Pour en savoir plus sur cette technologie, veuillez consulter la page http://support.microsoft.com/gp/machine-translation-corrections/fr. Microsoft vous propose en effet des articles traduits par des professionnels, des articles issus de traductions automatiques et des articles issus de traductions automatiques révisées par la communauté Microsoft, de manière à ce que vous ayez accès à tous les articles de notre Base de connaissances dans votre langue. Il est important de noter que les articles issus de la traduction automatique, y compris ceux révisés par la communauté Microsoft, peuvent contenir des erreurs de vocabulaire, de syntaxe ou de grammaire. Microsoft ne pourra être tenu responsable des imprécisions, erreurs, ainsi que de tout dommage résultant d’une traduction incorrecte du contenu ou de son utilisation par les clients.
La version anglaise de cet article est la suivante: 910439  (http://support.microsoft.com/kb/910439/en-us/ )
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.
Partager
Options de support supplémentaire
Forums du support Microsoft Community
Nous contacter directement
Trouver un partenaire Microsoft Certified Partner
Microsoft Store