Почему ASP.NET формирует файлы cookie для проверки подлинности при запросе статического изображения? - PullRequest
14 голосов
/ 17 ноября 2010

У меня есть веб-сайт ASP.NET (MVC), который обслуживает статический контент (изображения), а также динамический контент из того же домена.Сайт использует аутентификацию форм и имеет контроллер входа в систему.Были некоторые очень странные / нерегулярные проблемы с людьми, входящими или выходящими из системы через случайные интервалы, и мы проследили это до проблемы с обратным прокси-сервером, кэширующим файл изображения с заголовком ответа set-cookie, который устанавливаетauth cookie.Как только это кэшируется, каждый получает один и тот же cookie-файл аутентификации, что приводит к некоторым очень странным результатам.

Мой вопрос: как на самом деле изображение получит заголовок set-cookie в первую очередь?Что делает модуль проверки подлинности форм ASP.NET, чтобы вызвать это - конечно, он устанавливает cookie в ответе основного содержимого HTML.Я получаю, что файл cookie авторизации затем отправляется со всеми последующими запросами в домен, но я не могу понять, как файл cookie устанавливается в первую очередь.

(Кстати, эта проблема также может быть виновной по крайней мередва существующих крупных сайта электронной коммерции, которые сталкиваются с похожими проблемами, но не имеют решения, поэтому было бы неплохо решить).

Ответ показан ниже (взят из 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

Обновление: дополнительная информация - мы используем IIS 7.5 на Win2008 R2, 64-разрядной версии, и приложение работает в пуле приложений, использующем интегрированный конвейер / .net 4.

Обновление 2: яне ищем решения проблемы, у нас уже есть.Я ищу ответ на вопрос, почему это произошло в первую очередь?Пожалуйста, не отвечайте, рассказывая мне о поддоменах или о том, как работают куки!

Обновление 3: добавление в запрос:

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;

Ответы [ 5 ]

2 голосов
/ 27 октября 2011

Для меня это похоже на ошибку в IIS. Я собираюсь написать некоторый соломенный код, чтобы увидеть, полностью ли я понимаю, что происходит, и опубликовать результаты. Я также протестирую его на IIS 7 и IIS 7.5, чтобы проверить, не отличается ли он.

Не похоже, чтобы в одном запросе были какие-либо файлы cookie, связанные с предыдущим запросом (у нас нет кэширующих прокси на нашем сайте, и это происходит с нами во внутренней сети, поэтому я пришел к выводу, что делает это где-то).

- Owen

1 голос
/ 20 ноября 2010

Я подозреваю, что на самом деле это не проблема .NET, и ключ к вашим проблемам - это обратный прокси.

При отправке статического содержимого по пути, созданному с помощью форм, файлы cookie, связанные с вашим подключением, будут отправляться вместе с ним.Итак, если вы вошли в систему как пользователь X, сессия 1 и получили изображение foo.png, ваш обратный прокси-сервер видит, что PNG-файл встречает заголовки, указывающие, что он может быть кэширован.

В следующий раз, когда запрашивается этот файл, обратный прокси-сервер обслуживает файл напрямую, вместе с файлом cookie, который был связан с этим файлом при его последнем получении.

В качестве эксперимента я предлагаю настроить обратный прокси-сервер, чтобы отключить его функции кэширования, и посмотреть, сохраняется ли проблема.

Если вам нужен обратный прокси-сервер для кэширования содержимого -затем я бы посоветовал посмотреть, можно ли прокси-серверу игнорировать файлы cookie для кэшированных файлов или переместить файлы в другой домен без файлов cookie / без аутентификации.

0 голосов
/ 22 ноября 2011

Ответ на этот вопрос сам, чтобы закрыть вопрос и не допустить дальнейших обновлений.

Основная причина поведения, которое я наблюдал, была в том, что встроенный конвейер установил файлы cookie для статических файлов (css, images, js)- см. ветку комментариев для получения дополнительной информации.

Это было решено, когда мы переместили статический контент на другой хост в рабочей / промежуточной среде.

0 голосов
/ 17 ноября 2010
Браузер

по умолчанию отправляет куки с каждым запросом, сделанным на same domain.

простое решение состоит в том, чтобы переместить ваши изображения в другой домен, например, у youtube ребята есть домен http://s.ytimg.com/yt/img/watch/ для сохранения всех изображений.

0 голосов
/ 17 ноября 2010

Поскольку вы можете использовать проверку подлинности с помощью форм для защиты статического содержимого.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...