除了关闭 cookie 之外，还有什么可能导致 ASP.NET FormsAuthentication Cookie 问题？
人们报告登录我们的 ASP.NET 站点之一时遇到问题。当我检查 IIS 日志时，他们登录后的浏览器似乎没有缓存 FormsAuthentication cookie。
我认为这不像“用户将浏览器设置为不接受 cookie”那么简单，因为：
a) 如果 cookie 一般不适用于他们的浏览器，那么他们在该过程中永远不会取得如此大的进展 - 例如，ASP.NET 会话 cookie 似乎工作正常。
b) 这些用户通常不知道如何关闭 cookie。
所以我认为一定是别的东西。除了用户简单地将浏览器设置为拒绝 cookie 之外，哪些类型的问题会导致 ASP.NET FormsAuthentication cookie 停止工作？
编辑：例如 这个答案另一个问题表明有时 FormsAuthentication Cookie 会因为太大而被丢弃 - 也许有人可以对此进行一些说明？
编辑：我们网站之一的 FormsAuthentication cookie 是 233 字节 - 是不是有点大？可以做得更小吗？也许这会有所帮助。
编辑：我注意到代码使用 FormsAuthentication.SetAuthCookie() 和 Response.Redirect() 而不是 FormsAuthentication.RedirectFromLoginPage() - 这可能是有关的？
People are reporting having trouble logging into one of our ASP.NET sites. When I check the IIS logs, it looks like the FormsAuthentication cookie is not being cached by their browsers after they log on.
I don't think its as simple as 'user has set their browser to not accept cookies' because:
a) If cookies in general weren't working for their browser, they'd never have got as far as they have in the process - the ASP.NET session cookies seem to be working OK, for example.
b) These generally aren't the kind of users who would even know how to turn cookies off.
So I think it must be something else. What sort of problems can cause ASP.NET FormsAuthentication cookies to stop working, apart from users simply setting their browsers to reject cookies?
edit: For example This answer to another question suggests that sometimes FormsAuthentication Cookies get dropped because they are too large - perhaps someone can shed some light on that?
edit: the FormsAuthentication cookie for one of our sites is 233 bytes - is that a bit big? Can it be made smaller? Maybe that would help.
edit: I notice the code uses FormsAuthentication.SetAuthCookie() and Response.Redirect() instead of FormsAuthentication.RedirectFromLoginPage() - could that be related?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我也遇到过类似的问题（不是使用 formsauthentication cookie，而是使用粘性负载均衡器 cookie），因为服务器没有正确的时间/时区配置，因此存在 cookie 过期日期早于当前时间的情况在用户的机器上。
请参阅此处：过期值如何用于 cookie 和缓存？< /a>
希望有帮助
I've had a similar problem (not with the formsauthentication cookie, but with a sticky loadbalancer cookie) because the server didn't have a proper time/timezone configuration, so there were cases when the cookie expiration date was previous than the current time in the users machine.
see here: How do expire values work for cookies and caching?
hope it helps
用户是否有可能通过 2 个不同的域访问您的网络服务器？例如，如果我访问 www.foo.com 并获取身份验证 cookie，然后重定向到 www.bar.com，则发送到 www.bar.com 的请求肯定不会包含 www.foo.com 设置的 cookie 。
如果您在 htp://login.foo.com 设置 cookie，然后重定向到 htp://content.foo.com，也会出现此问题。不过，我相信可以使用通配符配置 cookie，以便将其应用于 *.foo.com。
编辑：故意拼写错误“http”，以便此答案中没有实际可点击的垃圾链接。 :)
Is it possible the user is accessing your webserver via 2 different domains? For example, if I go to www.foo.com and get an authentication cookie, then redirect to www.bar.com, the request sent to www.bar.com certainly won't contain the cookie set by www.foo.com.
This issue would also happen if you set the cookie at htp://login.foo.com, then redirect to htp://content.foo.com. However, I believe the cookie could be configured using a wildcard, so that it would apply to *.foo.com.
Edit: deliberately misspelled "http" so that there aren't actual clickable garbage-links in this answer. :)
如果您的网站在网络场中运行，您可能需要设置相同的计算机密钥 在所有服务器上，或者如果用户切换服务器，则可能无法解密身份验证票证。
RedirectFromLoginPage()和SetAuthCookie后跟Response.Redirect()之间的区别在于，如果禁用 cookie，第一个也可以工作（事实上使用查询字符串参数来跟踪经过身份验证的用户）。If your site runs in a web farm you might need to set the same machine keys on all servers or if the user switches server it might not be able to decrypt the authentication ticket.
The difference between
RedirectFromLoginPage()andSetAuthCookiefollowed byResponse.Redirect()is that the first works also if cookies are disabled (in fact it uses a query string parameter to track authenticated users).是否是 Web 服务器名称或 DNS 名称的一部分包含下划线？
例如：
www2_http.mydomain.com
我记得在某个开发阶段遇到过这个问题，会话不会正常运行。从机器域名中删除下划线解决了我的问题。
问候
Could it be that the webserver name, or part of the DNS name contains an underscore?
eg:
www2_http.mydomain.com
I remember having that problem during some development stage, where the Sessions would not behave regularly. Removing the underscore from the machines domain name resolved the issue for me.
regards
您是否使用多个域来与同一个 Web 应用程序通信？请记住，cookie 是特定于域的，www.mydomain.com <> www.mydomain.net>> my.domain.net。
黑暗中刺探，你的 web.configs 中有机器密钥吗？
Are you using more than one domain to talk to the same web application? Remember that cookies are domain specific, www.mydomain.com <> www.mydomain.net <> my.domain.net.
A stab in the dark, do you have machine keys in your web.configs?
存在空闲超时 - 他们是否登录，然后一段时间没有执行任何操作，然后再次尝试访问该站点？你可以检查一下。并且，查看超时是否设置为滑动超时（例如，上次请求后 20 分钟）或固定超时（例如，登录后 20 分钟）。我认为滑动超时不是默认设置。
There is an idle timeout--are they logging in, then not doing anything for a while, then trying to access the site again? You might check that. And, see if the timeout is set to be a sliding timeout (e.g., 20 min after last request) or a fixed timeout (e.g., 20 min after login). I think the sliding timeout is not the default setting.
尝试以下步骤。
http:// blogs.msdn.com/b/rahulso/archive/2007/01/17/troubleshooting-cookies-a-case-study.aspx
我很早就写了这篇文章，但如果您密切关注，那么很有可能你会找到根本原因。
隔离根本原因是这里的关键。一旦您首先弄清楚问题发生的原因，解决问题就会非常简单。
拉胡尔
www.dotnetscraps.com
Try the following steps.
http://blogs.msdn.com/b/rahulso/archive/2007/01/17/troubleshooting-cookies-a-case-study.aspx
I wrote this long back, but if you follow it closely the chances are high that you will find the root cause.
Isolation of the root cause is the key here. Fixing the issue will be pretty simple once you figure out why it is happening in the first place.
Rahul
www.dotnetscraps.com