Absurdité. Les cookies résident sur les clients. Rien que vous puissiez faire sur le serveur supprimera les cookies stockés sur les clients.

Vous le pensiez, non? Le cookie n'est pas supprimé du serveur avant la fin de l'application_beginrequest. Je sais à quel point cela sonne ridicule, c'est pourquoi je pose cette question. J'ai un débogage en hausse et quand je marche de l'application_beginrequest à Application_AuthentiCaequest, la valeur de httpcontext.current.request.cokies [". Aspxauth"] passe de {system.web.httpcookie} à null.

... Le client envoie évidemment toujours le cookie. C'est toujours dans le navigateur et dans la demande. Mais il est caché de la majorité du traitement par le serveur de la demande en raison de cette suppression.

OK, vous êtes confondu entre httpcontext.current.request.cokies [". Aspxauth"] et ce qui est sur le client. Peu importe cette collection sur le serveur. Le client va vous envoyer ce cookie sur la demande suivante.

Non, je ne suis vraiment pas. La question est simplement la question suivante: pourquoi httpcontext.current.request.cokies [". Aspxauth"] passe de {System.Web.httpcookie} à NULL quand j'arrive, dans une seule demande, à partir de Application_BeGinReQuest?

Ok, je vois maintenant que vous l'avez effacé. Êtes-vous sûr que les cookies sont disponibles si tôt dans le pipeline? Peut-être vérifier avant l'authentification d'événement pour voir si des cookies sont présents à ce moment-là.

Je viens d'ajouter les "informations de débogage" à la question ci-dessus qui répond quelque peu à cette question. Le cookie est toujours visible dans demande.Cookies lors du formateur ... Mais si le pool d'applications a été recyclé puisque le cookie a été distribué, il est supprimé des .cookies après la fin de cet événement.

Vous avez également reçu une exception après le recyclage, il n'est donc pas inattendu que celui-ci soit supprimé. Plus important encore, votre exception ne fait aucun doute en raison du cookie signé avec une valeur de Per-AppDomain. Si cela change (comme sur un recyclage), il sera impossible pour la nouvelle Appdomain de déchiffrer le cookie crypté de l'ancien Appdomain.

Oui exactement! Je suis d'accord. Donc, ma seule question est la suivante: pourquoi cela ne se produit-il pas pour l'une de mes configurations IIS? Je veux que cela se produise partout, parce que cela rend le sens total pour moi. Il semble que, dans les 2K3 IIS, il ne soit pas utiliser de valeur Per-AppDomain lors de la signature ou de la restauration en quelque sorte après la recyclage de la piscine de l'App ... pas sûr.

Je ne sais pas. Cela dépend peut-être du timing. Vérifiez la machine.Config pour le réglage de la machine.

Malheureusement, même avec un réglage de machineKey.validationkey = "autogénérer, isolatopps" et hichette.decryptionkey = "autogénère, isolateAppps", ce comportement continue.

Désolé, ma question était ces paramètres de la même manière que tous les serveurs.

Pour autant que je puisse dire, oui. Web.configs identiques. Y a-t-il un moyen de dire quelle valeur de machine est en réalité utilisé, au cas où il sera remplacé quelque part que je ne connais pas? Il se comporte bien comme un autogénère n'est pas sur ou ne fonctionne pas.