IE8 perd les cookies de session dans des fenêtres popup
Nous avons une application ASP.NET qui utilise l'authentification par formulaire. Lorsque les utilisateurs se connectent, un cookie d’ID de session et un ticket d’authentification par formulaire (stockés sous forme de cookie) sont générés. Ce sont des cookies de session, pas des cookies permanents. Il est intentionnel et souhaitable que, lorsque le navigateur se ferme, l'utilisateur soit effectivement déconnecté.
Une fois qu'un utilisateur se connecte, une nouvelle fenêtre apparaît avec window.open('location here');. La page qui est ouverte est effectivement l'espace de travail dans lequel l'utilisateur travaille pendant le reste de sa session. À partir de cette page, d'autres fenêtres contextuelles sont également utilisées.
Récemment, un certain nombre de clients (utilisant tous les dernières versions d'IE8) se sont plaints du fait que, lorsqu'ils se connectent, la fenêtre contextuelle initiale les ramène à l'écran de connexion plutôt qu'à leur page d'accueil. Alternativement, les utilisateurs peuvent parfois se connecter, accéder à la page d'accueil (qui se trouve dans une nouvelle fenêtre contextuelle), et tout semble aller pour le mieux, jusqu'à ce que des fenêtres contextuelles supplémentaires soient créées, où il commence à les rediriger vers l'écran de connexion. encore.
En essayant de résoudre le problème, j'ai utilisé le bon vieux Fiddler. Lorsque le problème commence à se manifester, j'ai remarqué que le navigateur n'envoie pas le cookie de session d'ID de session ASP.NET OR le cookie de session de ticket Forms Auth, même si la réponse au journal est dans POST. enfonce clairement ces cookies.
Ce qui est plus étrange, c’est que si je CTRL + N ouvre une nouvelle fenêtre à partir de la fenêtre qui manque les cookies de session, puis saisisse manuellement l’URL de la page d’accueil, ces cookies réapparaissent comme par magie. Cependant, les appels ultérieurs avec window.open(); continueront d'être interrompus, n'envoyant pas les cookies de session et entraînant l'utilisateur à l'écran de connexion.
Il est important de noter que parfois, sans raison valable apparemment, ces mêmes utilisateurs peuvent soudainement se connecter et travailler normalement pendant un certain temps, puis ils redeviennent cassés.
Maintenant, je me suis assuré qu'il n'y avait pas d'extensions de navigateur, de plug-ins, de barres d'outils, etc. en cours d'exécution. J'ai ajouté notre site en tant que site de confiance et abandonné les paramètres de sécurité sur Bas, j'ai modifié la politique de confidentialité des cookies pour "accepter tout" et même désactivé les paramètres de stratégie automatiques, le forçant manuellement à tout accepter et à inclure les cookies de session. Rien ne semble l'affecter.
Notez également que l'application Web réside sur un seul serveur. Il n'y a pas d'équilibrage de charge, de jardins Web, de batteries de serveurs, de clusters, etc. Le serveur réside derrière un serveur ISA, mais à part cela, il est assez simple.
Je fais des recherches depuis des jours et je n'ai rien trouvé qui puisse faire l'objet d'une action. Zut, parfois je ne peux même pas le reproduire de manière fiable. J'ai trouvé quelques références à des personnes ayant le même problème, mais elles semblent faire référence à un problème qui aurait été résolu dans une version bêta ou RC (exemple: IE8 perd les cookies lorsque vous ouvrez une nouvelle fenêtre après une redirection ) . Ce sont des versions de publication d'IE, avec des correctifs à jour.
Je sais que je peux essayer de définir des cookies permanents au lieu des cookies de session. Toutefois, cela a des conséquences considérables sur la sécurité de notre application.
Mettre à jour
Il semble que le problème disparaisse automatiquement lorsque l'utilisateur est ajouté en tant qu'administrateur local sur la machine. Seul le temps nous dira si ce changement affecte ce problème de manière permanente (et positive).
Il est temps d'arrêter ProcMon et de voir s'il y a un problème d'accès aux ressources.
Mise à jour # 2
Il semble y avoir plusieurs angles à ce qui semble être un problème singulier. J'ai signalé il y a longtemps que faire de l'utilisateur un administrateur local semblait aider. Et ce fut le cas pour un certain nombre d'utilisateurs. Bien sûr, ce n'est pas vraiment une solution, mais cela nous a permis de continuer à marcher.
Ensuite, plusieurs utilisateurs ont commencé à signaler le problème et le correctif administratif n'aidait pas. Les utilisateurs semblaient être principalement Win7, mais Vista était également affecté. Ils semblaient également être principalement des installations 64 bits.
Le réglage de TabProcGrowth sur 0 ou 1 (que cela fonctionne) comme suggéré par certains membres ci-dessous semble avoir largement résolu le problème. Donc, je vais transmettre ma réponse acceptée à la première personne qui a suggéré cela, car cela a eu beaucoup plus d'impact.
Tenter de résoudre ce problème est extrêmement frustrant, car il est difficile à reproduire et se produit souvent avec des utilisateurs avec lesquels je ne communique pas directement ou, au moment où je les ai contactés, cela ne semble pas fonctionner. Tout ce que je peux dire, c'est que quelque chose ne va pas avec la fonctionnalité de fusion de session, mais je n'ai pas beaucoup de données à transmettre à Microsoft pour trouver une solution permanente.
C'est la 'nouvelle' fonctionnalité dans IE8!
Consultez le blog IE8 ci-dessous pour en savoir plus.
IE8 peut utiliser plusieurs processus pour gérer un nombre x de fenêtres IE. Lorsque vous traversez un espace de processus, vous perdez vos cookies (l'ID de session Asp.Net semble être conservé sur cette limite de processus).
Personnellement, je pense que c'est cassé ou un bug. Comme nous le savons, les cookies doivent être conservés et renvoyés lorsque vous vous dirigez vers la "même cible de domaine". IE8 a un comportement de traitement différent pour la sécurité. le fait qu'il se comporte mal et que "supprime les cookies même si vous vous rendez dans le même domaine cible dans une autre fenêtre" est tout simplement un bug pour moi.
Vous pouvez modifier le nombre de processus utilisés par IE8 via les options d'Internet Explorer, ehh .. modification d'un paramètre de registre !!!!!! (C’est ce qui en fait un bogue à mon avis. IE fournir une interface utilisateur pour modifier ces paramètres le rendrait "niveau entreprise acceptable".
Ce qui concerne,
Marvin Smit
Dahinter stehen mehrere Möglichkeiten -
- AC & Vista (Musste auftauchen !!). Achie Sie insbesondere auf das Verhalten im geschützten Modus.
- Problèmes rencontrés Session Merging-Funktion in IE8 sein. Vous aussi, à partir de rien, à ce moment-là!Ctrl+NVerknüpfung bewirkt, dass die Cookies in Ihrem Fall magisch gesendet werden.
- Problème avec la construction de la constructionIE (mais, après le mois précédent, avec le monde, construction de la version précédente). Möglicherweise möchten Sie die in Microsoft Connect verfügbaren Détails sur les identifiants Fehler 408806 und 92032 überprüfen.
Nous avons résolu ce problème en modifiant le paramètre "Définir la croissance du processus de l'onglet" sur 0.
Bien que le mode protégé ne soit pas activé et que la zone soit "Intranet". Évidemment, il s’agit d’un problème ou d’un bogue sous Windows 7 64 bits, comme d’autres l’ont dit.
Cette page (n ° 4) m’amène à la solution: http://blog.httpwatch.com/2009/04/07/seven-things-you-should-known-about-ie-8/
Quoiqu'il en soit, un autre changement concernant les cookies d'un onglet à l'autre a été mis en place dans cette mise à jour de sécurité du 12 novembre 2013, qui annule la fonctionnalité de notre application dans toutes les versions d'IE. Nous effectuons l'authentification OpenID dans une fenêtre contextuelle afin de ne pas avoir à rediriger l'utilisateur de la page sur laquelle il était en train de naviguer lorsqu'il a cliqué pour la première fois sur le lien de connexion. Le cookie de session pour la connexion est correctement envoyé dans la requête dans la fenêtre contextuelle, mais il n'est jamais vu par la fenêtre principale du navigateur. La requête suivante adressée au serveur ne comporte donc pas ce cookie de session comme il se doit, et ainsi vous connecter ne fonctionne jamais réellement.
Quelqu'un at-il des solutions possibles à cela?
Nous avons eu ce problème sur IE6,7 et 8. Le scénario est la fenêtre parente (1) ouvre une fenêtre modale (2), la fenêtre modale contient un lien vers une fenêtre non modale (3). J'avais l'habitude d'obtenir un identifiant de session différent dans la 3ème fenêtre.
La solution de contournement mentionnée ici a résolu le problème http://support.Microsoft.com/kb/831678
Je connais ce problème depuis IE 5, je n'utilise donc les variables de session que dans les fenêtres contextuelles modales .... Lorsque j'ouvre une fenêtre contextuelle non modale, je remplace toutes les variables de session par ASP. Cache NET et nouvelles collections d'objets ... Mais c'est très fatiguant!
Les autres navigateurs (Firefox) n'ont pas ce problème ...
Je crois que c'est en fait un bug dans IE; Je l'ai signalé ici pour voir les commentaires reçus: http://social.msdn.Microsoft.com/Forums/en-US/83bb3b91-1c1f-4d51-9281-9bc5f51d3640/log-in-fails-cookie- is-not-sent-to-origining-tab? forum = iewebdevelopment
J'ai également trouvé une solution réalisable pour ce problème. Il semble y avoir un problème avec la manière dont IE8 gère l'ouverture de servlets dans une autre fenêtre avec un chemin relatif tel que/test. Il semble ouvrir une nouvelle session ainsi qu'une nouvelle fenêtre. Notre solution pratique est qu'au lieu d'ouvrir une nouvelle fenêtre avec un chemin relatif, nous avons simplement utilisé une page jsp. Ainsi, lorsque nous naviguons vers une URL, nous ne naviguons plus vers/test. Nous naviguons vers un fichier spécifique. Dans le fichier jsp, nous transmettons la demande au chemin relatif. Cela semble fonctionner, ce qui est assez délicat, car la seule différence est que nous plaçons un fichier spécifique entre les deux.
J'espère que ça aide.
Depuis IE8, nous (et nos clients) sommes également confrontés au même problème. Nous avons un service asp pour créer des formulaires. Cette application utilise de nouvelles fenêtres pour l’ajout d’éléments ou la gestion de comptes d’utilisateur, par exemple. Au hasard (lors de l'ouverture d'une nouvelle fenêtre), l'application ne reçoit pas l'identifiant de session requis pour l'authentification par d'autres cookies «permanents». Par conséquent, l'identifiant de session est un cookie temporaire. La plupart du temps, ça se passe bien, mais à d'autres moments, la session est interrompue à chaque fois qu'une nouvelle fenêtre est ouverte. Nous devons conseiller à nos clients de fermer toutes les fenêtres IE et de recommencer.
En tant que développeur Web, j'utilise IE de manière extensive. Personnellement, je ne rencontre pas le problème ci-dessus. Mais je pense un lié. Quelques fois par jour IE se bloque totalement (ne répond plus) lors de l'ouverture d'une nouvelle fenêtre. Lorsque je tue un certain IE processus à l'aide du gestionnaire de tâches, IE commence à répondre à nouveau. Mais dans la plupart des cas, il est préférable de tout recommencer avec une nouvelle instance propre d'IE. Pour cette raison, je tue le processus avec le moins d’utilisation de RAM, ce qui entraîne la fermeture de tous les processus IE.
Microsoft affirme que ces problèmes/bugs sont résolus dans la version finale ne me donne pas confiance en leurs efforts pour résoudre le problème.
Je rencontrais un problème similaire avec l'utilisation de variables de session pour transmettre des valeurs à une fenêtre contextuelle. Je viens juste de finir d'écrire les valeurs dans un cookie persistant, puis de le lire dans la fenêtre contextuelle. Cela peut ne pas fonctionner avec le problème que vous aviez avec l'authentification par formulaires, mais si nous utilisons simplement des variables de session pour transmettre certaines valeurs à une fenêtre dans IE8, les cookies persistants semblent avoir fonctionné pour moi.
edit: voir aussi ce fil de discussion
Vous pouvez également utiliser la méthode LocalStoprage pour réinitialiser la valeur dans la fenêtre parente
J'ai un problème similaire, mais pas identique. Nous chargeons une page Web qui ouvre une fenêtre contextuelle avec window.open() dans un contrôle de navigateur IE. Sur les ordinateurs dotés de IE6 et IE8, un nouvel ID de session est toujours attribué à la fenêtre contextuelle par ASP lors du lancement à partir du contrôle. Cependant, lorsqu'il est lancé à partir d'un navigateur normal (IE ou Firefox), la fenêtre contextuelle obtient l'identificateur de session existant.
Je peux voir lors du lancement à partir du contrôle qu'un nouveau processus iexplore.exe est créé; ainsi, le comportement de perte de session est logique compte tenu de ce qui a été mentionné sur les cookies en mémoire non transférés au nouveau processus.
J'essaie toujours de trouver moi-même une solution de contournement ...
Mettre à jour
Compris une solution réalisable! Il est possible de sous-classer SessionIDManager et de spécifier que cette classe doit être utilisée à la place de la classe par défaut (<sessionState sessionIDManagerType="..."> dans Web.config). La sous-classe peut rechercher un paramètre de requête contenant l'ID de session existant dans un remplacement de CreateSessionID() et le renvoyer s'il est trouvé. Cela permet essentiellement à une page de demander à être "fusionnée" dans une session existante dont elle a connaissance.
L'appel à window.open() a alors simplement besoin du paramètre de requête spécifié dans son URL.
Haw-Bin
Eu un problème similaire avec PHP5 et IE8. Lors de l'ouverture d'une fenêtre contextuelle en Javascript avec window.open, IE8 a perdu le cookie de session et a forcé l'utilisateur à se connecter à agan.
Pendant ce temps, les autres fenêtres popup fonctionnaient correctement.
Le coupable s’est avéré être une étiquette d’image. Le système de gabarit génère dynamiquement les valeurs src = de l'image et une image manquante a généré une balise d'image avec une clause src vide (
Je suppose que cela a quelque chose à voir avec IE interprétant la balise src vide comme une URL non sécurisée et isolant la session dans la fenêtre contextuelle sans en informer l'utilisateur.