L'agent utilisateur IE10 empêche ASP.Net de renvoyer Set-Cookie (IE10 ne définit pas les cookies)


91

Résumé

ASP.Net ne renvoie pas d'en- Set-Cookietête lors de l'utilisation d'IE 10. Cela signifie que, par exemple, vous ne pouvez pas vous connecter à un site ASP.Net en utilisant IE10 lors de l'utilisation de l'authentification par formulaire par exemple.

Détail

Nous testons actuellement l'une de nos applications Web héritées avec IE 10 [Aperçu 2].

Lorsque vous essayez de vous connecter à l'aide de l'authentification par formulaire, nous n'obtenons pas d'en- Set-Cookietête dans la réponse si l'agent utilisateur est celui d'IE 10. Nous avons essayé cela avec un site vierge .Net 2 et .Net 4.

Parce que nous ne pouvions pas / ne voulions pas le croire, nous avons même exécuté la requête HTTP suivante manuellement telnet- après avoir utilisé tous les outils habituels - et avons obtenu la même réponse.

GET http://test.ourdomain.co.uk/ HTTP/1.1
Accept: */*
Host: test.ourdomain.co.uk
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/6.0)
Content-Length: 0

La requête HTTP ci-dessus renvoie non Set-Cookiedans la réponse. Pourtant, si nous changeons simplement le User-Agent, Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/6.0)cela fonctionne!

Quelqu'un d'autre peut-il reproduire cela? Je ne trouve aucun problème connu avec les cookies IE10 autre qu'un problème qui affecte des modèles d'URL non standard.

Correctif

Une fois que devio a publié la réponse d'origine, avec une solution de contournement, nullptr a confirmé qu'il existe désormais un correctif pour cela .

http://support.microsoft.com/kb/2600088

J'ai promu le correctif à la question principale car il est juste plus pratique pour une référence future, mais veuillez voter pour les utilisateurs mentionnés.


1
Remarque - l'exemple ci-dessus provient de la configuration d'un cookie sur une demande d'obtention (en utilisant Response.SetCookie ())
isNaN1247

Une autre solution possible avec browserCaps : stackoverflow.com/a/13474958/1191905
Anton Skovorodko

Appliquons-nous le correctif à IIS ou à la machine cliente?
Arcadian

@ magic-c0d3r il s'agit d'un correctif pour .NET lui-même et doit donc être appliqué à la machine hébergeant IIS (c'est-à-dire le serveur Web)
isNaN1247

3
Le correctif pour .NET 2.0 / 3.5 peut également être intéressant: support.microsoft.com/kb/2600100
fortboise

Réponses:


66

Trouvé cette entrée sur MS Connect , le comportement est un bogue reconnu.

Solution de contournement suggérée (à partir de l'entrée):

== Solution de contournement ==

En attendant, pour le faire fonctionner et pour éviter des problèmes similaires à l'avenir, j'utilise un fichier ~ \ App_Browsers \ BrowserFile.browser avec ce qui suit:

<browsers>
<browser refID="Default">
<capabilities><!-- To avoid wrong detections of e.g. IE10 -->
<capability name="cookies" value="true" />
<capability name="ecmascriptversion" value="3.0" />
</capabilities>
</browser>
</browsers>

7
Oh mon ... c'est un peu un bogue - je doute fortement que tous les sites ASP.Net soient corrigés au moment de la sortie d'IE10.
isNaN1247

2
Merci pour cela. cela m'a aidé à lancer nos tests de compatibilité avec notre application. il était difficile de savoir au début s'il s'agissait de notre application ou de la version bêta, mais avoir une solution de contournement nous a rendus productifs
MikeJ

Cela fonctionne pour moi avec IE10 / Win8, mais PAS IE10 / Win7. Très étrange.
ScottE

1
Je suis surpris que cela fonctionne pour certaines personnes parce que cela n'a pas fonctionné pour moi. Voir la réponse cookieless = "UseCookies" ci-dessous pour une solution alternative qui, je pense, est plus à l'épreuve du temps et plus robuste.
mike nelson

71

Le problème réside dans le fait que certaines instances IIS pensent que IE10 est un navigateur sans cookie (c'est-à-dire qu'il ne peut pas prendre en charge les cookies). Dans notre cas problématique, le serveur définissait le cookie d'authentification et le renvoyait au navigateur, mais ignorait ensuite le cookie lors des demandes suivantes.

La solution consiste soit à corriger les capacités du navigateur afin qu'il sache que IE10 peut faire des cookies (décrit dans une autre réponse sur cette page), soit à modifier le comportement par défaut pour le forcer à utiliser des cookies même s'il pense que le navigateur ne peut pas faire de cookies.

Nous venons d'ajouter ce qui suit à notre section formulaires dans web.config:

cookieless = "UseCookies"

<authentication mode="Forms">
  <forms name=".AUTH" cookieless="UseCookies" loginUrl="/" timeout="10000" path="/" />
</authentication>

3
qui a résolu notre problème avec IE10
Oleg Yevteyev

1
Après avoir essayé les autres solutions et le hotfix refusant d'installer en disant qu'il n'était pas compatible avec notre serveur, j'ai essayé ceci. C'est la seule chose qui a résolu le problème pour nous.
Brian Surowiec

Tout ce que j'avais à faire était de modifier Web.config pour voir des résultats immédiats. Bravo
tuespetre

Je pense que c'est la bonne réponse. Le cookie était en cours de configuration, donc tout avait l'air bien dans Fiddler et ASP.NET était capable de le relire parfaitement (lorsque j'ai configuré une page de test) mais Forms Auth l'ignorait. Il s'agit d'une limitation sérieuse de Forms Auth mais votre correctif le fait fonctionner comme il se doit!
mike nelson

1
Il s'agit d'une solution bien meilleure et tenable pour la correction d'IIS.
generalnetworkerror

33

Un correctif est disponible pour ce problème [1].

1) http://support.microsoft.com/kb/2600088
1) http://support.microsoft.com/kb/2600217 (remplace la base de connaissances précédente)

En outre, [2] suggère que cela atteindra Windows Update en janvier 2012.

2) http://www.hanselman.com/blog/BugAndFixASPNETFailsToDetectIE10CausingDoPostBackIsUndefinedJavaScriptErrorOrMaintainFF5ScrollbarPosition.aspx


3
Génial, merci pour cela - j'ai promu le lien vers le corps principal de la question pour référence future.
isNaN1247 le

2
Confirmer. C'est toujours un bug pour le moment (08/2012). Je vais essayer le correctif.
Eric Nguyen

12
encore un bogue 04/2013 - wtf?
Scott Selby

Nous rencontrons toujours ce problème même si nous avons mis à jour le correctif KB. J'ai également ajouté les fichiers du navigateur au Web csproj. Aucun des deux ne semblait aider. Ce qui a aidé, c'est que nous avons ajouté un "site" à la boîte de dialogue Sites de confiance. Maintenant, nous redirigeons une IFrame à partir d'une application de marché lors de l'authentification unique. Je suppose qu'il existe un moyen moins invasif de gérer cette redirection, mais la documentation semble limitée à ce sujet.
Paul Shriner

3

Merci pour l'aide. Cela a fonctionné non.

  1. J'ai copié le fichier du site versC:\WINDOWS\microsoft.net\Framework\v2.0.50727\CONFIG\Browsers

  2. Exécuter dans l'invite de commande C:\WINDOWS\microsoft.net\Framework\v2.0.50727>aspnet_regbrowsers.exe -i

  3. Redémarrez IIS.

  4. Testé le site et il fonctionne sans aucune erreur.

Merci encore pour le feedback


2

Une mise à jour pour la réponse nullptr.

J'ai essayé aujourd'hui de télécharger le Microsoft KB2600088. Après avoir reçu le lien par mail, j'ai cliqué dessus puis il m'a conduit à la page qui dit qu'il n'est plus disponible.

Essayez ceci: http://support.microsoft.com/kb/2600217

Ce lien remplace KB2600088 et KB2628838.

MIcrosoft .Net Framework 4.5 est également disponible dès maintenant.


Merci d'avoir publié cette mise à jour. J'avais des problèmes avec ce lien support.microsoft.com/kb/2600088 principalement parce que IE sur mon serveur n'affichait pas la page correctement. Votre mise à jour m'a beaucoup aidé.
Daniel Hollinrake

0

Installation des différents correctifs que tout le monde mentionne et pour quelque raison que ce soit, le problème n'a pas été résolu.

Installé .NET Framework 4.5 complet et le problème a disparu.

Vous n'avez pas à mettre à jour les projets vers la cible 4.5. Installez-le simplement sur le serveur.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.