Colonne vocale d’ASP .NET prise en charge
Résolution des problèmes liés à l’authentification par formulaires
Pour personnaliser cette chronique selon vos besoins, nous souhaitons vous inviter à soumettre vos idées sur des sujets qui vous intéressent et des problèmes que vous voulez voir traités dans de futurs articles de la Base de connaissances et des chroniques Support Voice. Vous pouvez nous envoyer vos commentaires à l’aide de l’écran Ask For It . Il existe également un lien vers le formulaire au bas de cette colonne.
Bienvenue dans la colonne vocale d’assistance ASP.NET ! Mon nom est Jerry Orman. J’ont été avec Microsoft depuis plus de 5 ans et passé la plupart de mon temps consacré aux technologies liées à Web tel que Microsoft FrontPage et les nouvelles technologies Microsoft SharePoint. J’ai passé l’année dernière utilisation avec ASP.NET Microsoft sous la forme d’un technicien du support technique. Ce mois dans la colonne d’assistance vocale, je vais vous expliquer comment résoudre les problèmes liés à l’authentification par formulaires dans Microsoft ASP.NET.
Résolution des problèmes liés à l’authentification par formulaires
Lorsque vous utilisez l’authentification par formulaires dans une application ASP.NET, vous serez peut-être amené à résoudre un problème qui se produit lorsque l’utilisateur est redirigé de façon aléatoire à la page de connexion. Dans un monde idéal, ce problème se produit d’une manière qui permet de joindre un débogueur et capturer le problème facilement. Dans les environnements de production, toutefois, c’est rarement le cas. Pour résoudre un problème aléatoire comme celui-ci, vous devez enregistrer les informations relatives au problème de sorte que vous pouvez limiter la cause racine.
Dans cet article, nous étudierons brièvement le concept de l’authentification par formulaire. Nous allons ensuite dans les scénarios de conduire à un utilisateur d’être redirigé vers la page de connexion et comment faire pour capturer des données pertinentes pour isoler le problème. Nous aborderons é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 auprès d’un site Web à l’aide de l’authentification par formulaires, 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 à l’application et la classe FormsAuthenticationModule décrypte 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 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 formulaire ressemble à ce qui suit :
-
Le client envoie un verbe HTTP GET à Default.aspx. Aucun cookie d’authentification forms n’est envoyé.
-
Le serveur envoie une réponse 302 (redirection) vers Login.aspx.
-
Le client envoie un verbe HTTP POST vers Login.aspx. Il inclut les informations de connexion.
-
Le serveur envoie une réponse 302 (redirection) à Default.aspx. Le cookie d’authentification forms est inclus.
-
Le client envoie un verbe HTTP GET à Default.aspx. Cela inclut le cookie d’authentification par formulaires.
Pour plus d’informations sur l’implémentation et l’utilisation de l’authentification par formulaires, 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 des cookies d’authentification, visitez le site Web d’ASP.NET :
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 par formulaires est perdu
Scénario 1
Dans ce scénario, un utilisateur ouvre une session sur le site Web. Dans certains cas, le client envoie une demande au serveur et
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 de session dans Microsoft Internet Information Services (IIS). Pour ce faire, procédez comme suit :
-
Ouvrez la Console de gestion Microsoft (MMC).
-
Sur le site Web, puis cliquez sur
Propriétés. -
Cliquez sur l’onglet Site Web , puis cliquez sur Activer la journalisation.
-
Assurez-vous que le format de journal est Au Format de fichier journal étendu W3C.
-
Cliquez sur Propriétés.
-
Cliquez sur l’onglet Avancé , puis cliquez sur
Les propriétés étendues. -
Sous Propriétés étendues, activez la case à cocher de Cookie(cs(Cookie)) et le « referer » (cs(Referer)) case à cocher.
Une fois que ce problème se produit, déterminer le client qui avait le problème et l’adresse IP de ce client. Filtrer le journal IIS sur cette adresse IP du client et d’afficher la colonne <cookies>.
Remarque Vous pouvez utiliser Log Parser pour analyser les journaux IIS. Pour télécharger l’Analyseur de journal, visitez le site Web de Microsoft à l’adresse suivante :
http://www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07Une fois que la liste des demandes d’un utilisateur spécifique, recherchez les demandes à la page de connexion. Vous savez qu’ils ont été redirigés vers cette page, et que vous souhaitez voir les demandes avant que la redirection s’est produite. Si vous voyez quelque chose de semblable à la suivante, le client soit 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 |
|
Télécharger |
/Default.aspx |
302 (redirection) |
Pas de Cookies |
|
Télécharger |
/Login.aspx |
200 (succès) |
Pas de Cookies |
|
Publier |
/Login.aspx |
302 (redirection) |
Pas de Cookies |
|
Télécharger |
/Default.aspx |
200 (succès) |
.ASPXAUTH |
|
Télécharger |
/SomePage.aspx |
302 (redirection) |
N°. Cookie ASPXAUTH |
Il s’agit des autres requêtes, suivis d’une requête à une page sur le site sans le. Cookie ASPXAUTH.
|
Méthode |
Page |
Réponse |
Cookies |
|
Télécharger |
/SomePage.aspx |
302 (redirection) |
N°. Cookie ASPXAUTH |
|
Télécharger |
/Login.aspx |
200 (succès) |
N°. Cookie ASPXAUTH |
|
Publier |
/Login.aspx |
302 (redirection) |
N°. Cookie ASPXAUTH |
|
Télécharger |
/SomePage.aspx |
200 (succès) |
.ASPXAUTH |
Remarque La première requête à partir de cet utilisateur n’est pas susceptible d’avoir un cookie d’authentification forms, sauf si vous créez un cookie persistant. Le journal d’IIS affiche uniquement les cookies qui ont été reçus dans la demande. La première demande pour que le cookie d’authentification forms sera sur la demande, après une tentative d’ouverture de session réussie.
Scénario 2
Le cookie d’authentification de formulaires peut également être perdu lorsque le nombre limite de cookies du client est dépassée. Dans Microsoft Internet Explorer, il existe une limite de 20 cookies. Une fois que le cookie 20 est créé sur le client, cookies précédentes sont supprimés de la collection du client. 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 manière. Observez la demande juste avant la redirection vers la page de connexion. Si la demande pour cette page génère les cookies, il s’agit de 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 du nombre et des limites de taille des cookies 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 les en-têtes pour afficher l’en-tête Set-Cookie. Si vous suivez une connexion réussie, vous verrez l’en-tête Set-Cookie dans la réponse de connexion réussie.
Pour télécharger Fiddler, visitez le site Web de Fiddler suivant :
Scénario 3
Une fois que la requête ne quitte le client, il existe différentes couches qui peuvent affecter les paquets qui sont 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 et que vous affichez dans le corps de la demande pour le cookie. Vous souhaitez donner à la demande du client pour vous assurer que le cookie a été envoyé, vérifier la trace du serveur pour vous assurer que le serveur a reçu le cookie.
Demande du client
Il s’agit d’une demande GET après que l’utilisateur a été authentifié. Les informations de ticket d’authentification forms sont mis en surbrillance en bleu. Cela confirme que les informations du cookie quitté le client. Lorsque vous utilisez un outil de capture de réseau, tels que Netmon, vous consultez le trafic qui a en fait par le biais de la carte.
47 45 54 20 68 74 74 70-3a 2f 2f 6c 6f 63 61 6c GET http://local68 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 de côté serveur
Lorsque vous examinez la demande qui atteint le serveur, vous souhaitez 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 de filtres ISAPI suppression des 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, vérifiez les filtres ISAPI. Il se peut que vous deviez supprimer les filtres pour voir si le problème est résolu.
Expiration du délai du ticket d’authentification par formulaires
L’autre cause courante pour un utilisateur d’être redirigé est si le ticket d’authentification par formulaire a expiré. Le ticket d’authentification par formulaires peut expirer de deux manières. Le premier scénario se produit si vous utilisez l’expiration absolue. Avec une expiration absolue, le ticket d’authentification expire lorsque le délai d’expiration arrive à expiration. Par exemple, vous définissez une date d’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 complexe. Le cookie et le ticket qui en résultent sont mis à 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 date d’expiration de 20 minutes via l’expiration décalée. Un utilisateur visite le site à 14 h 00, et l’utilisateur reçoit un cookie qui est configuré pour expirer à 14 h 20. La date d’expiration est uniquement mis à jour 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é du délai d’expiration n’a pas été. Si l’utilisateur attend ensuite 12 minutes, en visitant le site à 14 h 21, le ticket expire. L’utilisateur est redirigé vers la page de connexion.
Une approche ce type de problème consiste à consigner les informations de cookie et le ticket d’authentification de formulaires. De cette façon, vous pouvez voir si le cookie a été reçu par IIS et les valeurs. Vous pouvez effectuer cette opération en écrire un HttpModule, puis brancher ce module dans le pipeline de requête. Vous ne devez pas modifier le code de votre application pour obtenir les informations dont vous avez besoin.
L’exemple joint fonctionne dans le Microsoft.NET Framework 1.1 et de.NET Framework 2.0 et comporte des commentaires dans l’ensemble. L’exemple comprend les fichiers suivants :Remarque je vous propose un lien de téléchargement pour le code fourni dans le fichier FormsAuthLogger.zip.
Je vous donnerai les principales zones ici :
Comme toujours, n’hésitez à soumettre des idées sur des sujets que vous souhaitez traités dans de futurs des colonnes ou dans la Base de connaissances à l’aide de la
Formulaire Ask For It .
