为什么 ASP.NET 表单身份验证在静态图像请求上设置 cookie?

发布于 2024-10-02 14:53:21 字数 1597 浏览 7 评论 0原文

我有一个 ASP.NET (MVC) 网站,它提供静态内容(图像)以及来自同一域的动态内容。该站点使用表单身份验证,并有一个登录控制器。人们发现自己以随机的时间间隔登录或退出,出现了一些非常奇怪/不规则的问题,我们已将其追溯到反向代理缓存图像文件的问题,该图像文件具有 set-cookie 响应标头,该标头设置身份验证 cookie。一旦被缓存,每个人都会获得相同的身份验证 cookie,这会导致一些非常奇怪的结果。

我的问题是 - 图像到底是如何获得 set-cookie 标头的? ASP.NET 表单身份验证模块做了什么导致了这种情况 - 当然它在主要 HTML 内容响应上设置了 cookie。我知道身份验证 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

更新:附加信息 - 我们在 Win2008 R2、64 位上使用 IIS 7.5,并且该应用程序在使用集成管道/.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;

I have an ASP.NET (MVC) website that is serving static content (images) as well as dynamic content from the same domain. The site uses forms auth, and has a login controller. There have been some very strange / irregular issues with people finding themselves logged in or out at random intervals, and we've tracked it down to an issue with a reverse proxy caching an image file that has a set-cookie response header that sets the auth cookie. Once this is cached, everyone then gets the same auth cookie, which leads to some very weird outcomes.

My question is - how on earth would an image get a set-cookie header in the first place? What is the ASP.NET forms authentication module doing to cause this - surely it sets the cookie on the main HTML content response. I get that the auth cookie is then sent with all subsequent requests to the domain, but I cannot figure out how the cookie is set in the first place.

(BTW this issue may also be the culprit in at least two existing large ecommerce sites that are suffering from similar problems, with no solution, so it would be a good one to solve).

The response is shown below (taken from 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

Update: additional info - we are using IIS 7.5 on Win2008 R2, 64bit, and the app is running under an app pool that is using the integrated pipeline / .net 4.

Update 2: I am not looking for a solution to the problem, we have one already. I am looking for an answer to the question, which is why it happened in the first place? Please don't answer telling me about subdomains or how cookies work!

Update 3: adding in the request:

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;

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

烧了回忆取暖 2024-10-09 14:53:21

我怀疑这本身并不是 .NET 问题,问题的关键实际上是反向代理。

当从经过表单验证的路径提供静态内容时,与您的连接关联的 cookie 将随之发送。
因此,如果您以用户 X、会话 1 的身份登录并获取图像 foo.png,则您的反向代理会看到 PNG 文件带有表明可以缓存的标头。

下次请求该文件时,反向代理将直接提供该文件以及上次获取该文件时与该文件关联的 cookie。

作为实验,我建议设置反向代理以关闭其缓存功能并查看问题是否仍然存在。

如果您确实需要反向代理来缓存内容,那么我建议您查看是否可以告诉代理忽略缓存文件的 cookie,或者将文件移动到另一个无 cookie/无身份验证的域。

I suspect this isn't actually a .NET problem per-se, and the key to your issues is actually the Reverse Proxy.

When serving static content from a forms-auth'ed path, the cookies associated with your connection will get sent along with it.
So, if you're signed in as user X, session 1 and get image foo.png, your reverse proxy is seeing the PNG file come across with headers indicating it can be cached.

The next time that file is being requested, the reverse proxy is serving the file directly, along with the cookie it had associated with that file when it last got it.

As an experiment, I suggest setting the reverse-proxy to turn off it's caching functionality and see if the problem persists.

If you do need the reverse proxy to be doing caching of content - then I'd suggest then looking to see if the proxy can be told to ignore cookies for cached files, or moving files to another cookieless/auth-less domain.

泅人 2024-10-09 14:53:21

对我来说似乎是 IIS 中的一个错误。我将编写一些稻草人代码,看看我是否完全理解正在发生的事情并发布结果。我还将在 IIS 7 和 IIS 7.5 上测试它,看看是否有不同。

看起来一个请求确实不应该获得与前一个请求关联的任何 cookie(我们的网站上没有任何缓存代理,而这种情况发生在我们的内部网络上,所以我的结论是 IIS 正在某处执行此操作) )。

——欧文

Seems like a bug in IIS to me. I'm going to write some straw-man code to see if I fully understand what's going and and post the results. I'll also test it on IIS 7 and IIS 7.5 to see if it's different.

It really doesn't seem that one request should get ANY cookies associated with a previous request (we DO NOT have any caching proxies on our site and this is happening to us on our internal network, so my conclusing is that IIS is doing it somewhere).

--Owen

堇色安年 2024-10-09 14:53:21

因为您可以使用表单身份验证来保护静态内容。

Because you can use Forms Authentication to secure static content.

悲欢浪云 2024-10-09 14:53:21

我自己回答这个问题是为了结束问题并防止进一步更新。

我所看到的行为的根本原因是静态文件(css、图像、js)上的集成管道设置 cookie - 请参阅评论线程以获取更多详细信息。

当我们将静态内容移动到生产/暂存环境中的不同主机时,这个问题得到了解决。

Answering this myself to close out the question and prevent further updates.

The root cause of the behaviour that I was seeing was due to the integrated pipeline setting cookies on static files (css, images, js) - see the comment thread for further details.

It was solved when we moved static content to a different host in the production / staging environment.

你没皮卡萌 2024-10-09 14:53:21

默认情况下,浏览器会在同一域上发出的每个请求中发送 Cookie。

简单的解决方案是将您的图像移动到其他域,例如 youtube 人员有一个域 http://s.ytimg.com/yt/img/watch/保存所有图像。

browser by default sends the cookies with each request made on the same domain.

the simple solution is to move your images to some other domain, like youtube guys have a domain http://s.ytimg.com/yt/img/watch/ to save all the images.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文