Nous avons une application ASP.NET qui utilise Forms Auth. Lorsque les utilisateurs se connectent, un cookie d'identification de session et un ticket Forms Auth (stocké sous forme de cookie) sont générés. Il s'agit de cookies de session, et non de cookies permanents. Il est intentionnel et souhaitable que lorsque le navigateur se ferme, l'utilisateur soit effectivement déconnecté.
Une fois que l'utilisateur s'est connecté, une nouvelle fenêtre s'ouvre en utilisant la fonction window.open('location here'); . La page qui s'ouvre est en fait l'espace de travail dans lequel l'utilisateur travaille pendant le reste de sa session. D'autres fenêtres contextuelles sont également utilisées à partir de cette page.
Dernièrement, un certain nombre de clients (utilisant tous les dernières versions d'IE8) se sont plaints que, lorsqu'ils se connectent, la fenêtre contextuelle initiale les ramène à l'écran de connexion plutôt qu'à leur page d'accueil. Par ailleurs, les utilisateurs peuvent parfois se connecter, arriver sur la page d'accueil (qui se trouve à nouveau dans une nouvelle fenêtre pop-up), et tout semble bien se passer, jusqu'à ce que d'autres fenêtres pop-up soient créées, et qu'elles les redirigent à nouveau vers l'écran de connexion.
Pour tenter de résoudre le problème, j'ai utilisé le bon vieux Fiddler. Lorsque le problème a commencé à se manifester, j'ai remarqué que le navigateur n'envoyait pas le cookie de session ASP.NET session ID OU le cookie de session Forms Auth ticket, même si la réponse au POST de connexion pousse clairement vers le bas ces cookies.
Le plus étrange, c'est que si je fais CTRL+N pour ouvrir une nouvelle fenêtre à partir de la fenêtre qui s'est affichée et qui ne contient pas les cookies de session, puis que je tape manuellement l'URL de la page d'accueil, ces cookies réapparaissent comme par magie. Cependant, les window.open(); continueront à être interrompus, à ne pas envoyer les cookies de session et à renvoyer l'utilisateur à l'écran de connexion.
Il est important de noter que parfois, sans raison apparente, ces mêmes utilisateurs peuvent soudainement se connecter et travailler normalement pendant un certain temps, avant de retomber en panne.
Je me suis assuré qu'aucun module complémentaire de navigateur, plug-in, barre d'outils, etc. n'est en cours d'exécution. J'ai ajouté notre site en tant que site de confiance et réduit les paramètres de sécurité à Faible, j'ai modifié la politique de confidentialité des cookies en "acceptant tout" et j'ai même désactivé les paramètres automatiques de la politique, en la 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 fermes de serveurs, de grappes, etc. Le serveur se trouve derrière un serveur ISA, mais à part cela, c'est assez simple.
J'ai cherché pendant des jours et je n'ai rien trouvé d'exploitable. Parfois, je n'arrive même pas à reproduire le problème de manière fiable. J'ai trouvé quelques références à des personnes ayant ce même problème, mais elles semblent faire référence à un problème qui a été prétendument corrigé dans une version bêta ou RC (exemple : IE8 perd des cookies lors de l'ouverture d'une nouvelle fenêtre après une redirection ). Il s'agit des versions d'IE les plus récentes, avec les correctifs les plus récents.
Je sais que je peux essayer d'installer des cookies permanents au lieu de cookies de session. Cependant, cela a des conséquences dramatiques sur la sécurité de notre application.
Mise à jour
Il semble que le problème disparaisse automatiquement lorsque l'utilisateur est ajouté en tant qu'administrateur local sur la machine. Seul l'avenir nous dira si ce changement a une incidence permanente (et positive) sur ce problème.
Il est temps de sortir ProcMon et de voir s'il y a un problème d'accès aux ressources.
Mise à jour n°2
Il semble qu'il y ait plusieurs angles d'attaque pour ce qui semble être un problème unique. J'ai signalé il y a longtemps que le fait de faire de l'utilisateur un administrateur local semblait aider. Et c'est ce qui s'est passé pour un certain nombre d'utilisateurs. Bien sûr, ce n'est pas vraiment une solution, mais cela nous a permis d'avancer.
Ensuite, de plus en plus d'utilisateurs ont commencé à signaler le problème, et le correctif de l'administrateur n'a pas aidé. Les utilisateurs semblaient être principalement des utilisateurs de Win7, mais Vista était également touché. Il s'agissait aussi principalement d'installations 64 bits.
Le réglage de TabProcGrowth sur 0 ou 1 (l'un ou l'autre a fonctionné), comme l'ont suggéré certains membres ci-dessous, semble avoir largement résolu le problème. Je vais donc transférer ma réponse acceptée à la première personne qui l'a suggérée, car elle a eu beaucoup plus d'impact.
Il s'agit d'un problème incroyablement frustrant à résoudre, car il est difficile à reproduire et se produit souvent avec des utilisateurs avec lesquels je n'ai pas de communication directe, ou le temps que j'arrive à les joindre, il ne semble pas fonctionner. Tout ce que je peux dire, c'est que quelque chose ne va pas avec la fonction de fusion de sessions, mais je n'ai pas beaucoup de données à fournir à Microsoft pour trouver une solution permanente.
