c# - Thread.CurrentPrincipal 错误地声称是匿名的

Question

我在我的服务器上看到似乎是由匿名客户端发出的请求，尽管我确定它们是由经过身份验证的用户发出的 - 我有 fiddler 日志显示客户端发送了有效的 asp.net auth cookie，和服务器日志表明 cookie 已到达并且有效。已在所有浏览器中观察到该问题。

数据流是:

1. 用户在属于网络场的机器上访问登录 url(全部使用同一台机器，解密 key )
2. 在成功的表单例份验证中，用户被重定向到一个受限制的 url，即他们的主页
3. 主页正确呈现，知道用户的身份，并包含 javascript 以执行 7 个异步回发以获取额外数据
4. Javascript 启动 7 个 http.get 请求，命中网络场中的不同机器(假设循环法)
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 而加剧，但我的信心不高，这就是原因。

我已经联系了少数遇到此问题的客户，这更令人沮丧(但确实反射(reflect)了我能够在日志中阅读的内容)。一旦进入这种状态，就很难摆脱。清除缓存和 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

这个答案有效，但同时令人失望和担忧。

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

症状转瞬即逝:我们的网站有一些用户报告说他们会通过我们的网站进行身份验证并看到正确的状态。但看似随机，他们会退出我们的网站，或者偶尔会体验匿名 View 。这非常令人沮丧，几乎不可能在内部在本地复制。

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

我们很快假设存在身份验证问题，可能与身份验证 cookie 相关。奇怪的是，我能够证明(跟踪)出错的请求包含一个我能够解密的正确 cookie，但 .net 框架以不确定的方式忽略了它。我最终开始记录所有处于这种状态的请求——auth cookie 被 .net 框架忽略，但对我来说似乎有效，并且发现大约 2% 的用户受到影响。

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

重申症状:我们有某些用户(非确定性)有时无法在经过身份验证的模式下使用我们的网站(也是非确定性的)。可爱的。

到现在为止，雷德蒙德的产品团队参与其中，但也被难住了。但他们确实提出了一个建议，最终解决了这个问题，这里是:尝试强制 Microsoft.net 框架使用 cookie 作为身份验证模式，而不是使用无 cookie 状态:

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

打开开关，有问题的请求立即结束(一旦我终止了那些处于奇怪状态的 session )。

虽然我很高兴问题得到解决——或者更确切地说是解决了，但让我担心的是各种浏览器的非确定性处理。为什么 .net 框架有一天会看到一个浏览器，并将其视为支持 cookie，而在同一天晚些时候又说它应该使用无 cookie session ？

我最后担心的是，有多少其他网站在不知情的情况下丢失了 2% 的经过身份验证的流量？考虑到修复，感觉很像 .net 4 框架中的错误。