2010-11-17 40 views
14

Je dispose d'un site Web ASP.NET (MVC) qui diffuse du contenu statique (images) ainsi que du contenu dynamique provenant du même domaine. Le site utilise des formulaires auth et dispose d'un contrôleur de connexion. Il y a eu des problèmes très étranges/irréguliers avec des personnes qui se sont déconnectées ou déconnectées à des intervalles aléatoires, et nous avons suivi un problème avec un reverse proxy en cache un fichier image qui a un en-tête de réponse set-cookie cookie auth. Une fois que cela est mis en cache, tout le monde obtient le même cookie d'authentification, ce qui conduit à des résultats très étranges.Pourquoi ASP.NET forme-t-il des cookies de configuration d'authentification sur une demande d'image statique?

Ma question est - comment diable une image aurait-elle un en-tête set-cookie en premier lieu? Que fait le module d'authentification des formulaires ASP.NET pour provoquer cela - il définit sûrement le cookie sur la réponse du contenu HTML principal. J'obtiens que le cookie d'authentification est alors envoyé avec toutes les demandes ultérieures au domaine, mais je ne peux pas comprendre comment le cookie est placé en premier lieu.

(BTW ce problème peut également être le coupable dans au moins deux grands sites de commerce électronique existants qui souffrent de problèmes similaires, sans solution, il serait donc un bon à résoudre).

La réponse est indiquée ci-dessous (tirée de fiddler).

HTTP/1.1 200 OK 
Cache-Control: public, max-age=86400,max-age=86400 
Content-Type: image/png 
Last-Modified: Thu, 04 Nov 2010 16:00:52 GMT 
Accept-Ranges: bytes 
ETag: "0528474397ccb1:0" 
Server: Microsoft-IIS/7.5 
Set-Cookie: my-auth-cookie=6BC25F1EF71989466A48C0120E7739E; path=/; HttpOnly 
Date: Wed, 17 Nov 2010 17:15:08 GMT 
Content-Length: 15790 

Mise à jour: informations complémentaires - nous utilisons IIS 7.5 sur Win2008 R2, 64bit, et l'application est en cours d'exécution sous un pool d'application qui utilise le pipeline intégré/.net 4.

Mise à jour 2: Je ne cherche pas de solution au problème, nous en avons déjà un. Je cherche une réponse à la question, c'est pourquoi c'est arrivé en premier lieu? Merci de ne pas me parler des sous-domaines ou du fonctionnement des cookies!

Mise à jour 3: ajouter à la demande:

GET https://www.example.com/sprite.png HTTP/1.1 
Host: www.example.com 
Connection: keep-alive 
Cache-Control: no-cache 
Pragma: no-cache 
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.7 (KHTML, like Gecko) Chrome/7.0.517.44 Safari/534.7 
Accept-Encoding: gzip,deflate,sdch 
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6 
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 
Cookie: my-auth-cookie=6BC25F1EF71989466A48C0120E7739E; 
+0

+1, question très intéressante. @Hugo, as-tu pu reproduire ce comportement ou est-ce aléatoire? –

+0

@Hugo, appliquez-vous SSL sur votre site parce que je remarque que ce cookie est défini sans le drapeau 'secure'? –

+0

Darin, oui nous appliquons SSL - tout le site fonctionne sous SSL, bien que le point de terminaison soit le proxy inverse (IIS avec ARR installé) pas les serveurs web eux-mêmes. La solution au problème est de servir les images d'un sous-domaine/site différent, mais comme vous le faites remarquer à juste titre ci-dessous, cela ne répond pas à la question, qui est comment/pourquoi cela est arrivé en premier lieu. –

Répondre

0

moi-même répondre à cette dénouer la question et éviter de nouvelles mises à jour.

La cause première du comportement que je voyais était due aux cookies intégrés de configuration de pipeline sur les fichiers statiques (css, images, js) - voir le fil de commentaires pour plus de détails.

Il a été résolu lorsque nous avons déplacé du contenu statique vers un hôte différent dans l'environnement de production/stockage intermédiaire.

0

Parce que vous pouvez utiliser l'authentification des formulaires pour sécuriser le contenu statique.

+1

Et comment cela répond à la question? Voir le commentaire que j'ai laissé sur @Zain Shaikh réponse. –

-2

Le navigateur par défaut envoie les cookies à chaque demande faite sur le same domain. La solution simple est de déplacer vos images vers un autre domaine, comme youtube les gars ont un domaine http://s.ytimg.com/yt/img/watch/ pour enregistrer toutes les images.

+2

Vous ne lisez pas la question? Ne voyez-vous pas l'en-tête de réponse 'Set-Cookie'? Cela définit un cookie et non le client le passant par l'en-tête 'Cookie' dans la demande. –

+0

Merci Darin :-) –

1

Je suppose que ce n'est pas réellement un problème. NET, et la clé de vos problèmes est en fait le proxy inverse. Lorsque vous diffusez du contenu statique à partir d'un chemin authentifié par un formulaire, les cookies associés à votre connexion sont envoyés avec lui. Ainsi, si vous êtes connecté en tant qu'utilisateur X, session 1 et obtenez image foo.png, votre proxy inverse voit le fichier PNG traverser avec des en-têtes indiquant qu'il peut être mis en cache.

La prochaine fois que ce fichier est demandé, le proxy inverse sert le fichier directement, avec le cookie associé à ce fichier lors de son dernier accès. Comme expérience, je suggère de définir le proxy inverse pour désactiver sa fonctionnalité de mise en cache et voir si le problème persiste. Si vous avez besoin du proxy inverse pour faire la mise en cache du contenu - alors je suggère de regarder si le proxy peut être dit d'ignorer les cookies pour les fichiers en cache, ou de déplacer les fichiers vers un autre cookieless/auth-less domaine.

+0

Will, vous avez raison, c'est le problème que nous avons déjà résolu en production. Il s'agissait plus d'une question à la communauté sur la raison pour laquelle cela s'est produit en premier lieu (mise en place de cookies sur le contenu statique). Lier IIS et ASP.NET ensemble peut sembler une bonne idée à l'époque, mais cela prouve une vraie douleur dans les scénarios de production (j'ai une autre question ouverte sur serverfault sur les options d'authentification). –

+0

Salut Hugo, encore une fois - Je ne pense pas que c'est .NET/IIS directement c'est le problème. Comme je l'ai mentionné, supprimer le proxy inverse de l'équation, et si j'ai raison - le problème disparaît. Si j'ai tort, alors c'est quelque chose de plus profond. –

2

Cela me semble un bogue dans IIS. Je vais écrire du code pour voir si je comprends bien ce qui se passe et afficher les résultats. Je vais également tester sur IIS 7 et IIS 7.5 pour voir si c'est différent.

Il ne semble pas qu'une requête doive obtenir TOUS les cookies associés à une demande précédente (nous n'avons pas de proxy de mise en cache sur notre site et cela nous arrive sur notre réseau interne, donc je conclus que IIS le fait quelque part).

--Owen

+0

Eh bien, ne peut pas reproduire dans un exemple simple homme-paille (page Web avec un tas d'images, un autre pour mettre cookie). Pas question, non comment l'une des images a le jeu de cookies d'une 2ème machine ... FWIW –