У меня есть веб-сайт ASP.NET(MVC), который обслуживает статический контент (изображения), а также динамический контент из того же домена. Сайт использует формы auth и имеет контроллер входа. Там были некоторые очень странные/нерегулярные проблемы с людьми, которые сами вошли в систему или из них случайным образом, и мы отследили ее до проблемы с обратным прокси-кешированием файла образа с заголовком ответа set-cookie, который устанавливает auth cookie. Как только это кэшируется, каждый получает тот же файл cookie, что приводит к очень странным результатам.
Мой вопрос: как на самом деле, если бы изображение получило заголовок set-cookie? Что делает модуль проверки подлинности форм ASP.NET, чтобы сделать это - наверняка он устанавливает cookie в основном ответе на контент HTML. Я получаю, что файл cookie auth затем отправляется со всеми последующими запросами в домен, но я не могу понять, как настроен файл cookie.
(Кстати, эта проблема также может быть виновником, по крайней мере, двух существующих крупных сайтов электронной коммерции, которые страдают от подобных проблем, без решения, поэтому было бы хорошо решить).
Ответ показан ниже (взято из скрипача).
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, 64bit, и приложение работает под пулом приложений, который использует интегрированный конвейер /.net 4.
Обновление 2: я не ищу решение проблемы, у нас уже есть. Я ищу ответ на вопрос, и почему это произошло в первую очередь? Пожалуйста, не отвечайте на вопрос о субдоменах или о том, как работают cookie!
Обновление 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;
Отвечая на это сам, чтобы закрыть вопрос и предотвратить дальнейшие обновления.
Основная причина того, что я наблюдал, была связана с встроенными конвейерными настройками файлов cookie на статические файлы (css, images, js) - см. комментарий для более подробной информации.
Он был решен, когда мы перемещали статический контент на другой хост в среде производства/промежуточной сборки.
Мне кажется ошибкой в IIS. Я собираюсь написать код соломенного человека, чтобы узнать, полностью ли я понимаю, что происходит, и опубликуйте результаты. Я также проверю его на IIS 7 и IIS 7.5, чтобы узнать, отличается ли это.
Похоже, что ни один запрос не должен получать ЛЮБЫЕ файлы cookie, связанные с предыдущим запросом (у нас нет каких-либо кеширующих прокси на нашем сайте, и это происходит с нами в нашей внутренней сети, поэтому мой вывод заключается в том, что IIS делая это где-то).
- Owen
Я подозреваю, что на самом деле это не проблема .NET, и ключ к вашим проблемам на самом деле является обратным прокси.
При обслуживании статического содержимого по пути, основанному на формах, файлы cookie, связанные с вашим соединением, будут отправляться вместе с ним. Итак, если вы вошли в систему как пользователь X, сеанс 1 и получите изображение foo.png, ваш обратный прокси видит, что файл PNG встречается с заголовками, указывающими, что он может быть кэширован.
В следующий раз, когда запрашивается этот файл, обратный прокси обслуживает файл напрямую, вместе с файлом cookie, который он связал с этим файлом, когда он последний раз получил его.
В качестве эксперимента я предлагаю установить обратный прокси, чтобы отключить его функции кэширования и посмотреть, не исчезла ли проблема.
Если вам нужен обратный прокси-сервер для кеширования контента, тогда я предлагаю вам посмотреть, можно ли прокси-серверу игнорировать файлы cookie для кэшированных файлов или перемещать файлы в другой домен без добавления cookie/без аутентификации,
Поскольку вы можете использовать аутентификацию форм для защиты статического содержимого.
браузер по умолчанию отправляет файлы cookie с каждым запросом, сделанным на same domain.
простым решением является перемещение ваших изображений в какой-либо другой домен, например, youtube у парней есть домен http://s.ytimg.com/yt/img/watch/ для сохранения всех изображений.