Thread.CurrentPrincipal声称不正确

Question

我看到我的服务器上的请求似乎是由一个无关的客户端发出的,虽然我确定它们是由经过身份验证的用户制作的 - 我有fiddler日志显示客户端发送了有效的asp.net auth cookie和服务器日志表明cookie已到达且有效.所有浏览器都出现了这个问题.

数据流是:

1. 用户访问登录URL,在属于webfarm的计算机上(所有具有相同计算机的密钥,解密密钥)
2. 在成功的表单身份验证上,用户将重定向到受限制的URL(即其主页)
3. 主页正确呈现,知道用户的身份,并包含javascript以执行7个异步回发以获取其他数据
4. Javascript启动7个http.get请求,点击webfarm中的不同机器(假设循环)
5. 服务器验证请求:~0.01%无法进行身份验证.

思考？

现在详细说明:

极少数的异步请求落在我的服务器上(有证据表明它们没有被操纵或伪造)并且似乎是匿名的.在提出的7个请求中,有些数字可能有效,也可能无效(即5/7会成功,2会失败).成功/失败似乎没有任何模式.在我的请求看起来是匿名的情况下,CurrentPrincipal.Identity记录:

Thread.CurrentPrincipal.Identity.IsAuthenticated; // false
Thread.CurrentPrincipal.Identity.Name; // null (or empty, unsure off hand)

将http.context.request.params集合转储到日志文件中,我能够看到以下相关(和擦除)属性(下面的完整参数):

context: {"userId":10000,"userName":"johnsmith"}
HTTP_COOKIE:.ASPXAUTH=[valid auth cookie value]
HTTP_X_REQUESTED_WITH:XMLHttpRequest
X-Requested-With: XMLHttpRequest
    AUTH_TYPE: 
    AUTH_USER: 
    AUTH_PASSWORD: 
    LOGON_USER: 
    REMOTE_USER: 
    HTTP_COOKIE: .ASPXAUTH=[valid auth cookie value]

我知道auth cookie是有效的 - 在这些相同的请求期间,我能够解密auth cookie并提取以下内容:

CookiePath: /
Expiration: 9/23/2105 8:14:22 PM
Expired: False
IsPersistent: True
IssueDate: 8/30/2010 2:54:22 PM
Name: johnsmith
UserData: 
Version: 2

不知道如何继续这一点.我们最近迁移到mvc 2.0/asp.net 4.0似乎加剧了这个问题,但我的信心并不高.

我已经联系了一些有这个问题的客户,而且这更令人沮丧(但确实反映了我在日志中能够阅读的内容).一旦进入这种状态,就很难摆脱它.清除缓存和cookie似乎没有任何效果.但是,切换到新的浏览器,一般都可以.同样地,等待几个小时并使用相同的浏览器返回它也一般都可以,但并非总是如此.如前所述,所有浏览器都可以看到这种情况.

有什么建议？
凯文

------------
以下是我捕获的日志片段的剩余部分(为pii擦除):

8/30/2010 2:54:43 PM: Anonymous user detected:
    Identity Name:
    IsAuthenticated::False
HttpContextInformation to follow:

8/30/2010 2:54:43 PM: Request Param collection contents:
context: {"userId":10000,"userName":"johnsmith"}
    .ASPXAUTH: A3C6615642F1F543397160C84C0E016C8439BDF400B0130AADAB82C93E77FFF3BEAD7726223F02049FA65B2C3E1773928C0371C4F580F2432C1538551BC5654020AD76F37159BA6BB68D7A68744AE036
    ASP.NET_SessionId: m5vit3cyv0rsiosqg5xmhhuu
    ALL_HTTP: HTTP_CONNECTION:close
HTTP_ACCEPT:text/javascript, text/html, application/xml, text/xml, */*
HTTP_ACCEPT_ENCODING:gzip, deflate
HTTP_ACCEPT_LANGUAGE:en-us
HTTP_COOKIE:.ASPXAUTH=A3C6615642F1F543397160C84C0E016C8439BDF400B0130AADAB82C93E77FFF3BEAD7726223F02049FA65B2C3E1773928C0371C4F580F2432C1538551BC5654020AD76F37159BA6BB68D7A68744AE036
HTTP_HOST:www.host.com
HTTP_REFERER:http://www.host.com/
HTTP_USER_AGENT:Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_0 like Mac OS X; en-us) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8A293 Safari/6531.22.7
HTTP_X_FORWARDED_FOR:166.137.139.139
HTTP_X_REQUESTED_WITH:XMLHttpRequest

    ALL_RAW: Connection: close
Accept: text/javascript, text/html, application/xml, text/xml, */*
Accept-Encoding: gzip, deflate
Accept-Language: en-us
Cookie: .ASPXAUTH=A3C6615642F1F543397160C84C0E016C8439BDF400B0130AADAB82C93E77FFF3BEAD7726223F02049FA65B2C3E1773928C0371C4F580F2432C1538551BC5654020AD76F37159BA6BB68D7A68744AE036
Host: www.host.com
Referer: http://www.host.com/
User-Agent: Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_0 like Mac OS X; en-us) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8A293 Safari/6531.22.7
X-Forwarded-For: 166.137.139.139
X-Requested-With: XMLHttpRequest

    APPL_MD_PATH: /LM/W3SVC/792523/Root
    APPL_PHYSICAL_PATH: d:\localpath\
    AUTH_TYPE: 
    AUTH_USER: 
    AUTH_PASSWORD: 
    LOGON_USER: 
    REMOTE_USER: 
    CERT_COOKIE: 
    CERT_FLAGS: 
    CERT_ISSUER: 
    CERT_KEYSIZE: 
    CERT_SECRETKEYSIZE: 
    CERT_SERIALNUMBER: 
    CERT_SERVER_ISSUER: 
    CERT_SERVER_SUBJECT: 
    CERT_SUBJECT: 
    CONTENT_LENGTH: 0
    CONTENT_TYPE: 
    GATEWAY_INTERFACE: CGI/1.1
    HTTPS: off
    HTTPS_KEYSIZE: 
    HTTPS_SECRETKEYSIZE: 
    HTTPS_SERVER_ISSUER: 
    HTTPS_SERVER_SUBJECT: 
    INSTANCE_ID: 792523
    INSTANCE_META_PATH: /LM/W3SVC/792523
    LOCAL_ADDR: 10.248.50.207
    PATH_INFO: /resource
    PATH_TRANSLATED: d:\localpath\resource
    QUERY_STRING: context={%22userId%22:10000,%22userName%22:%22johnsmith%22}
    REMOTE_ADDR: 10.208.205.171
    REMOTE_HOST: 10.208.205.171
    REMOTE_PORT: 37966
    REQUEST_METHOD: GET
    SCRIPT_NAME: /resouce
    SERVER_NAME: www.host.com
    SERVER_PORT: 80
    SERVER_PORT_SECURE: 0
    SERVER_PROTOCOL: HTTP/1.0
    SERVER_SOFTWARE: Microsoft-IIS/6.0
    URL: /resource
    HTTP_CONNECTION: close
    HTTP_ACCEPT: text/javascript, text/html, application/xml, text/xml, */*
    HTTP_ACCEPT_ENCODING: gzip, deflate
    HTTP_ACCEPT_LANGUAGE: en-us
    HTTP_COOKIE: .ASPXAUTH=A3C6615642F1F543397160C84C0E016C8439BDF400B0130AADAB82C93E77FFF3BEAD7726223F02049FA65B2C3E1773928C0371C4F580F2432C1538551BC5654020AD76F37159BA6BB68D7A68744AE036
    HTTP_HOST: www.host.com
    HTTP_REFERER: http://www.host.com/
    HTTP_USER_AGENT: Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_0 like Mac OS X; en-us) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8A293 Safari/6531.22.7
    HTTP_X_FORWARDED_FOR: 166.137.139.139
    HTTP_X_REQUESTED_WITH: XMLHttpRequest


8/30/2010 2:54:43 PM: Auth Ticket collection contents:
    CookiePath: /
    Expiration: 9/23/2105 8:14:22 PM
    Expired: False
    IsPersistent: True
    IssueDate: 8/30/2010 2:54:22 PM
    Name: johnsmith
    UserData: 
    Version: 2

Answer 1

这个答案有效,但同时令人失望和惊慌.

我花了两个月的时间与MSDN技术支持兼职,我们终于找到了解决这个问题的方法.我将把它留给微软解决这个问题,因为它几乎肯定是.net框架中的一个问题.但首先,让我总结一下这个问题,提供额外的相关背景信息以及我们在此过程中发现的一些有趣的事情.

症状是短暂的:我们的网站有一些用户的报告,他们将通过我们的网站进行身份验证并查看正确的状态.但看似随机,他们将退出我们的网站,或偶尔,体验匿名视图.这是非常令人沮丧的,几乎不可能在室内复制.

还有症状:虽然所有浏览器和操作系统都受到一定程度的影响,但通过日志记录我们看到移动(iphone,ipad和android)浏览器受到了不成比例的影响.最后一个随机症状是:它对用户有一天工作,而不是下一个,下午晚些时候再次工作.当然,切换浏览器几乎总能解决问题.

我们很快就出现了一个身份验证问题,可能是围绕身份验证Cookie.奇怪的是,我能够证明(追踪)错误的请求包括我能够解密的适当的cookie,但.net框架以非确定的方式忽略了.我最终开始记录处于此状态的所有请求 - .net框架忽略了auth cookie,但看起来对我有效,并且发现大约2%的用户受到影响.

我从使用Thread.CurrentPrincipal.Identity切换到HttpContext.Current.User.Identity,无济于事,并尝试了一些其他设置.奇怪的是,我能够做出的唯一改变就是迁移到.net 4框架(从3.5开始).这个问题变得最糟糕.还尝试了各种负载均衡器配置,并且能够排除多个机器配置 - 发出auth cookie的同一台机器稍后会拒绝它.

重新迭代症状:我们有某些用户(非确定性),他们有时无法以经过身份验证的模式(也是非确定性)使用我们的网站.可爱.

By now, the product team in Redmond was involved, and also stumped. But they did come up with a suggestion, which ultimately resolved the issue, here goes: Try forcing the Microsoft.net framework to use cookies as the authentication mode, as opposed to using a cookieless state:

<authentication mode="Forms">
  <forms cookieless="UseCookies" />
</authentication>

Flipped the switch and instantly the problematic requests ended (once I expired the session of those in an odd state).

While I’m glad that the problem was resolved – or rather worked around, it’s the non-deterministic handling of various browsers that worries me. Why would the .net framework see a browser one day, and treat it as supporting cookies, and later the same day say it should use a cookieless session?

我最后担心的是,有多少其他网站在不知情的情况下丢失了2%的认证流量？考虑到修复,它感觉非常像.net 4框架中的错误.