Résolution des problèmes liés à l’authentification par formulaire

S’applique à : Internet Information Services

Souvent, lors de l’utilisation de l’authentification par formulaire dans une application web ASP.NET, il est nécessaire de résoudre un problème qui se produit lorsqu’une demande nouvelle ou en cours est redirigée par intermittence vers la page de connexion de l’application. Vous pouvez déboguer ce problème sur l’IDE Visual Studio en attachant un débogueur dans un environnement de développement. Toutefois, dans les environnements de production, la tâche peut s’avérer compliquée. Pour résoudre ce type de problème aléatoire, vous devez journaliser les informations relatives au problème afin d’identifier précisément sa cause première.

Cet article décrit brièvement le concept d’authentification par formulaire. Il décrit également différents scénarios concernant une redirection d’un utilisateur vers la page de connexion et la façon de capturer des données pertinentes pour isoler le problème. En outre, il explique également comment implémenter une IHttpModule interface pour consigner les informations d’authentification par formulaire.

Vue d’ensemble de l’authentification par formulaire ASP.NET

L’authentification par formulaire vous permet d’authentifier les utilisateurs à l’aide de votre propre code, puis de conserver un jeton d’authentification dans un cookie ou dans l’URL. L’authentification par formulaire participe au cycle de vie de la page ASP.NET par le biais de la FormsAuthenticationModule classe. Vous pouvez accéder aux informations et fonctionnalités d’authentification par formulaire à l’aide de la FormsAuthentication classe.

Pour utiliser l’authentification par formulaire, créez une page de connexion qui collecte les informations d’identification de l’utilisateur et inclut du code pour authentifier les informations d’identification. En règle générale, vous configurez l’application pour rediriger les demandes vers la page de connexion lorsque les utilisateurs essaient d’accéder à une ressource protégée, telle qu’une page qui nécessite l’authentification. Si les informations d’identification de l’utilisateur sont valides, vous pouvez appeler des méthodes de la FormsAuthentication classe pour rediriger la requête vers la ressource demandée à l’origine avec un ticket d’authentification approprié (cookie). Si vous ne souhaitez pas la redirection, vous pouvez simplement obtenir le cookie d’authentification par formulaire ou le définir. Lors des demandes suivantes, votre navigateur transmet le cookie d’authentification à la demande, qui contourne ensuite la page de connexion.

Par défaut, la FormsAuthenticationModule classe est ajoutée dans le fichier Machine.config . La FormsAuthenticationModule classe gère le processus d’authentification par formulaire.

Vous pouvez voir l’entrée suivante dans le fichier Machine.config :

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

Vous pouvez configurer l’authentification par formulaire à l’aide de l’élément de configuration d’authentification, par exemple, définir une page de connexion. Dans le fichier de configuration, spécifiez une URL pour rediriger les demandes non authentifiées vers la page de connexion.

Une fois l’authentification réussie, le FormsAuthenticationModule module définit la valeur de la propriété User sur une référence à l’utilisateur authentifié. L’exemple de code suivant montre comment lire l’identité de l’utilisateur authentifié par les formulaires.

String authUser2 = User.Identity.Name;

Une méthode pratique pour utiliser l’authentification par formulaire consiste à utiliser l’appartenance et les contrôles de connexion ASP.NET. ASP.NET appartenance vous permet de stocker et de gérer les informations utilisateur et inclut des méthodes d’authentification des utilisateurs. Les contrôles de connexion et l’appartenance ASP.NET sont complémentaires. Ces fonctionnalités encapsulent la logique nécessaire pour inviter les utilisateurs à saisir leurs informations d’identification, valider ces informations, récupérer ou réinitialiser les mots de passe, et plus encore. En effet, l’appartenance et les contrôles de connexion ASP.NET fournissent une couche d’abstraction qui simplifie l’authentification par formulaire. Ces fonctionnalités remplacent la plupart ou tout le travail que vous devez généralement faire pour utiliser l’authentification par formulaire.

Scénarios

Voici des scénarios pour qu’une demande soit redirigée vers la page login.aspx :

Le cookie d’authentification par formulaire est perdu.

Scénario 1

Vous vous connectez au site web. À un moment donné, le client envoie une demande au serveur et la FormsAuthenticationModule classe ne reçoit pas le cookie.

Scénario 2

La perte du cookie d’authentification par formulaire peut également se produire si la limite du nombre de cookies du client est dépassée. Dans Microsoft Internet Explorer, il existe une limite de 20 cookies. Une fois le compteur atteint 20, les 19 cookies précédents sont supprimés de la collection du client. Si le cookie ASPXAUTH est supprimé, vous êtes redirigé vers la page de connexion lorsque la requête suivante est traitée.

Scénario 3

Après que la requête quitte le client, différents niveaux d’infrastructure peuvent affecter les paquets envoyés. Pour vérifier si un périphérique réseau supprime le cookie, vous devez capturer une trace réseau à la fois sur le client et sur le serveur, puis examiner le corps de la requête pour le cookie. Il est essentiel d’examiner la requête du client pour vérifier que le cookie a été envoyé, ainsi que la trace du serveur pour confirmer que le serveur a bien reçu le cookie.

Délai d’expiration du ticket d’authentification par formulaire

Dans ASP.NET applications 2.0 et versions ultérieures, par défaut, la valeur d’authentification timeout par formulaire est passée à 30 minutes. Cela signifie qu’après 30 minutes d’inactivité, vous serez invité à vous reconnecter.

Note

Lorsque vous accédez à un site web chaque fois, l’horloge de la fenêtre de 30 minutes est réinitialisée. Seulement s’il est inactif, il y a un délai d’attente.

Si vous souhaitez modifier la timeout valeur pour qu’elle soit plus longue, vous pouvez facilement modifier la timeout valeur dans votre fichier web.config local (la timeout valeur est en minutes) :

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

Scénario 4

L’authentification par formulaire peut expirer avant la valeur de l’attribut timeout défini dans le fichier de configuration.

Si le ticket d’authentification par formulaire est généré manuellement, la timeout propriété du ticket remplace la valeur définie dans le fichier de configuration. Par conséquent, si cette valeur est inférieure à la valeur du fichier de configuration, le ticket d’authentification par formulaire expire avant la valeur de l’attribut du fichier timeout de configuration et vice versa. Par exemple, supposons que l’attribut FORMS timeout est défini sur 30 dans le fichier Web.config et que la valeur d’expiration du ticket est définie sur 20 minutes. Dans ce cas, le ticket d’authentification par formulaire expire après 20 minutes, puis vous devez vous reconnecter.

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

Scénario 5

Dans les applications web ASP.NET 4 qui utilisent l’authentification par formulaire, le message du journal des événements indique ce qui suit :

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

Collecte et résolution des problèmes liés à la collecte de données

Scénario de résolution des problèmes 1

Vous pouvez déterminer si une demande 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) d’IIS.
  2. Cliquez avec le bouton droit sur le site web, puis sélectionnez Propriétés.
  3. Sélectionnez l’onglet Site web, puis activez la journalisation.
  4. Assurez-vous que le format du journal est le format de fichier journal étendu W3C.
  5. Sélectionnez Propriétés.
  6. Sélectionnez l’onglet Avancé , puis sélectionnez Propriétés étendues.
  7. Sous Propriétés étendues, cochez les cases Cookie(cs(Cookie)) et Referer (cs(Referer)).

Quand le problème survient, identifiez le client qui a rencontré le problème, ainsi que son adresse IP. Filtrez le journal IIS sur l’adresse IP de ce client et affichez la <COOKIE> colonne.

Note

Utilisez l’analyseur de journal pour analyser les journaux IIS.

Une fois que vous avez la liste des demandes d’un 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.

Note

La première demande n’est probablement 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. Première demande d’avoir le cookie d’authentification par formulaire après une tentative de connexion réussie.

Scénario de résolution des problèmes 2

Microsoft Internet Explorer respecte les recommandations de la norme RFC 2109 concernant les limitations minimales suivantes :

  • Au moins 300 cookies.
  • Au moins 4 096 octets par cookie (comme mesuré par la taille des caractères qui composent le cookie non terminal dans la description de syntaxe de l’en-tête Set-Cookie).
  • Au moins 20 cookies par hôte ou nom de domaine unique.

La perte du cookie d’authentification par formulaire peut également se produire si la limite du nombre de cookies du client est dépassée. Dans Microsoft Internet Explorer, il existe une limite de 20 cookies. Une fois le compteur atteint 20, les 19 cookies précédents sont supprimés de la collection du client. Si le cookie ASPXAUTH est supprimé, vous êtes redirigé vers la page de connexion lorsque la requête suivante est traitée. Vous pouvez utiliser Fiddler pour voir les en-têtes de requête ou de réponse HTTP pour voir si vous recevez le cookie du client. Téléchargez Fiddler.

Lancez l’outil Fiddler sur l’ordinateur client, supprimez les traces HTTP existantes, accédez à votre application implémentant l’authentification par formulaire et essayez de vous connecter à l’application et observez le trafic HTTP sur Fiddler pour voir s’il existe un échange de cookies d’authentification par formulaire entre le client et le serveur. Après avoir capturé le trafic, double-cliquez sur une demande, puis sélectionnez En-têtes pour afficher l’en-tête Set-Cookie. Si vous tracez une connexion réussie, vous verrez l’en-tête Set-Cookie dans la réponse d’une connexion réussie.

Par défaut, Internet Explorer peut stocker un maximum de 20 cookies pour chaque domaine. Si un serveur du domaine envoie plus de 20 cookies à un ordinateur client, le navigateur de cet ordinateur abandonnera automatiquement certains des cookies les plus anciens.

Chaque cookie se compose d’une paire nom-valeur unique. Cette paire peut être suivie de paires attribut-valeur séparées par des points-virgules. Cette limite a été augmentée afin de faciliter le développement et l’hébergement d’applications web sur des domaines nécessitant l’utilisation de nombreux cookies. L’installation de la mise à jour 937143 augmente le nombre de cookies qu’Internet Explorer peut stocker pour chaque domaine, le passant de 20 à 50. Pour plus d’informations, consultez Internet Explorer et Microsoft Edge forum aux questions (FAQ) pour les professionnels de l’informatique.

Scénario de résolution des problèmes 3

Une fois la requête quitté le client, il existe différentes couches qui peuvent affecter les paquets envoyés (pare-feu, proxys et équilibreurs de charge). Pour déterminer si un appareil 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 pouvez examiner la demande du client pour vous assurer que le cookie a été envoyé, puis vérifier la trace du serveur pour vous assurer que le serveur a reçu ce cookie.

Requête client

Il s’agit d’une GET demande après l’authentification de l’utilisateur. Les informations du ticket d’authentification par formulaire sont mises en évidence en gris. Cela confirme que les informations de cookie ont quitté le client. Lorsque vous utilisez un outil de capture réseau, tel que WireShark, vous voyez le trafic qui est passé par l’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

Requête côté serveur

Lorsque vous voyez la demande qui a atteint le serveur, assurez-vous que le serveur a reçu les mêmes informations que celles envoyées par le client. 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é.

Note

Des cas de suppression des cookies ont également été constatés sur certaines instances de filtres ISAPI. 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, vérifiez les filtres ISAPI. Vous devrez peut-être supprimer les filtres pour vérifier si le problème est résolu.

Scénario de résolution des problèmes 5

  • Si le scénario implique une batterie de serveurs web, assurez-vous que les fichiers de configuration sur chaque serveur de la batterie de serveurs web ont la même valeur pour la clé de validation et les clés de déchiffrement, qui sont utilisées respectivement pour le hachage et le déchiffrement. Pour maintenir la cohérence sur tous les serveurs de la batterie de serveurs, utilisez la machineKey suivante :

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

    Pour plus d’informations sur les clés d’ordinateur, consultez Clé machine et Planifier la sécurité des applications.

    Pour savoir comment générer des clés de machine, consultez Paramètres de la clé d’ordinateur.

  • Comparez les timeout valeurs des deux formulaires, autrement dit le module d’authentification et le module de session, sur tous les serveurs web.

  • Comparez la version System.Web.dll sous le dossier Framework pour ASP.NET 4 entre tous les serveurs web de la batterie de serveurs. Échec de l’authentification par formulaire pour la requête. La raison est que le ticket fourni n’était pas valide. Cela se produit en raison d’une mise à jour de fiabilité manquante 1 pour MS .NET Framework 4 sur l’un des serveurs web.

  • Appliquez ce correctif pour le kb2533523 de .NET Framework 4 sur le serveur concerné par ce problème, puis redémarrez le serveur. Le problème est résolu. Pour plus d’informations, consultez La mise à jour de fiabilité 1 pour .NET Framework 4.

Plus d’informations

Exclusion de responsabilité de tiers

Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.

  • Last updated on