2010-11-17 19 views
14

Tengo un sitio web ASP.NET (MVC) que sirve contenido estático (imágenes), así como contenido dinámico del mismo dominio. El sitio usa formularios auth y tiene un controlador de inicio de sesión. Ha habido algunos problemas muy extraños/irregulares con las personas que se encuentran conectadas o desconectadas a intervalos aleatorios, y hemos rastreado a un problema con un caché de proxy inverso un archivo de imagen que tiene un encabezado de respuesta de conjunto de cookies que establece el cookie de autenticación Una vez que se almacena en caché, todos obtienen la misma cookie de autenticación, lo que genera resultados muy extraños.¿Por qué ASP.NET forma las cookies de configuración de autenticación en una solicitud de imagen estática?

Mi pregunta es: ¿cómo diablos una imagen obtendría un encabezado de conjunto de cookies en primer lugar? ¿Qué está haciendo el módulo de autenticación de formularios ASP.NET para causar esto? Seguramente establece la cookie en la respuesta principal de contenido HTML. Entiendo que la cookie de autenticación se envía con todas las solicitudes posteriores al dominio, pero no puedo averiguar cómo se establece la cookie en primer lugar.

(Por cierto, este problema también puede ser el culpable en al menos dos grandes sitios de comercio electrónico existentes que están sufriendo problemas similares, sin solución, por lo que sería una buena solución).

La respuesta se muestra a continuación (tomada 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 

Actualización: Información adicional - estamos utilizando IIS 7.5 en Win2008 R2, de 64 bits, y la aplicación se ejecuta en un grupo de aplicación que está utilizando la canalización integrada/.net 4.

Actualización 2: No estoy buscando una solución al problema, ya tenemos uno. Estoy buscando una respuesta a la pregunta, ¿por qué sucedió en primer lugar? ¡No responda contándome sobre subdominios o cómo funcionan las cookies!

Actualización 3: añadir en la solicitud:

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, pregunta muy interesante. @Hugo, ¿fue capaz de reproducir este comportamiento o es aleatorio? –

+0

@Hugo, ¿está aplicando SSL en su sitio porque noté que esta cookie se configuró sin el indicador "secure"? –

+0

Darin, sí, estamos aplicando SSL: todo el sitio se ejecuta bajo SSL, aunque el punto de terminación es el proxy inverso (IIS con ARR instalado), no los servidores web. La solución al problema es servir las imágenes de un subdominio/sitio diferente, pero como usted señala correctamente a continuación no responde la pregunta, que es cómo y por qué sucedió en primer lugar. –

Respuesta

0

Responder a esto mismo para cerrar la cuestión y evitar más cambios.

La causa principal del comportamiento que estaba viendo se debió a las cookies de configuración de interconexión integradas en archivos estáticos (css, images, js). Consulte la secuencia de comentarios para obtener más detalles.

Se solucionó cuando trasladamos el contenido estático a un host diferente en el entorno de producción/almacenamiento intermedio.

0

Como se puede utilizar la autenticación de formularios para asegurar el contenido estático.

+1

¿Y cómo responde esto a la pregunta? Mira el comentario que dejé en la respuesta de @Zain Shaikh. –

-2

navegador de forma predeterminada envía las cookies con cada solicitud realizada en el same domain.

la solución simple es mover sus imágenes a otro dominio, como youtube chicos tienen un dominio http://s.ytimg.com/yt/img/watch/ para guardar todas las imágenes.

+2

¿No lees la pregunta? ¿No ves el encabezado de respuesta 'Set-Cookie'? Esto está configurando una cookie y no el cliente pasando a través del encabezado 'Cookie' en la solicitud. –

+0

Gracias Darin :-) –

1

Sospecho que esto no es en realidad un problema .NET per-se, y la clave de sus problemas es en realidad el proxy inverso.

Al servir contenido estático de una ruta de autenticación de formularios, las cookies asociadas con su conexión se enviarán junto con ella. Por lo tanto, si ha iniciado sesión como usuario X, sesión 1 y obtiene la imagen foo.png, su proxy inverso verá que el archivo PNG aparece con encabezados que indican que se puede almacenar en caché.

La próxima vez que se solicite ese archivo, el proxy inverso está publicando el archivo directamente, junto con la cookie que tenía asociada con ese archivo cuando lo obtuvo por última vez.

Como experimento, sugiero configurar el proxy inverso para desactivar la funcionalidad de almacenamiento en caché y ver si el problema persiste.

Si necesita el proxy inverso a estar haciendo el almacenamiento en caché de contenido - a continuación, me gustaría sugerir a continuación, mirando a ver si el proxy se le puede decir a ignorar las cookies para los archivos almacenados en caché, o mover archivos a otro sin cookies/auth-menos dominio.

+0

Will, tiene toda la razón, este es el problema, que ya hemos resuelto en producción. Esto fue más una pregunta para la comunidad sobre por qué sucedió en primer lugar (establecer cookies en contenido estático). Atar IIS y ASP.NET juntos pueden haber sonado como una buena idea en ese momento, pero está resultando un verdadero dolor en los escenarios de producción (tengo otra pregunta abierta sobre la falla del servidor sobre las opciones de autenticación). –

+0

Hola Hugo, otra vez - No creo que sea .NET/IIS directamente, ese es el problema. Como mencioné, elimine el proxy inverso de la ecuación, y si tengo razón, el problema desaparece. Si estoy equivocado, entonces es algo más profundo. –

2

Parece un error en IIS para mí. Voy a escribir un código de hombre de paja para ver si entiendo completamente lo que está pasando y publicar los resultados. También lo probaré en IIS 7 e IIS 7.5 para ver si es diferente.

Realmente no parece que una solicitud deba obtener CUALQUIER cookie asociada con una solicitud anterior (NO tenemos ningún proxy de caché en nuestro sitio y esto nos está sucediendo en nuestra red interna, por lo que mi conclusión es que IIS lo está haciendo en alguna parte).

--Owen

+0

Bueno, no se puede reproducir en un simple ejemplo de hombre de paja (página web con un montón de imágenes, otra para establecer la cookie). De ninguna manera, no, ¿cómo es que alguna de las imágenes tiene el conjunto de cookies de una segunda máquina ... FWIW –

Cuestiones relacionadas