MVC 3 / ASPNET Auth - 几乎随机重定向到Account / LogOff [英] MVC 3/ASPNET Auth - Almost Randomly Redirecting To Account/LogOff
问题描述
对我来说这是一个非常奇怪的事情，我现在已经和它斗争了一段时间。我真的希望有人可以提供帮助。
我有一个相当典型的MVC 3网站，我似乎只是在IE和Firefox中遇到这个问题。 Chrome很好地播放。幸运的是，我们公司的大多数客户目前使用Chrome。
问题是在一个看似随机的时间点，浏览器会自动重定向当我点击链接时，我进入了Account / LogOff操作，从那里它显然会回到登录页面。这个链接将继续相同的行为。
我说看似随机，因为今天该链接将起作用，明天它不会和其他所有（或大多数 - 我从来没有超过问题链接一次给这个问题）链接将是好的。有时重启服务器/开发环境会解决问题，有时则不会。浏览器将继续重定向到LogOff。
我已经尝试查看Referrer URL，但是将永远无法访问所引用的控制器/操作。 （如果我在动作中放置一个断点，则会错过，下一个点就是LogOff动作）
如果我在LogOff中查看堆栈跟踪动作，我看不到应用程序来自哪里的任何信息。我也尝试了本页中的建议：在ASP.NET MVC上发布堆栈跟踪，但我不明白为什么我被重定向到LogOff操作。
在击中LogOff之前，我似乎唯一可以获得断点的地方是Global.asax中的Application_BeginRequest，但是无法看到它从哪里开始。
我的猜测是，在某个地方，ASPNET Auth决定用户不再进行身份验证，并重定向到LogOff操作。问题是与ASPNET Auth相关的cookie仍然存在，其中有数据并且它们还没有过期。
无论如何，我希望我已经给了足够的有关问题的信息。
提前致谢。
好的，所以我可能更近了一步。我遇到了这篇文章和看看我的global.asax中的Application_AuthenticateRequest发生了什么。
我不太确定为什么，当我点击链接时，Application_AuthenticateRequest被访问3倍。当链接工作时（如我可以遵循它并且它不会让我退出），.ASPAUTH cookie的值保持不变。我通过添加断点和监视来检查这个
HttpContext.Current.Request.Cookies [ .ASPXAUTH]。价值
当链接不起作用时，cookie第一次有值，另外两次为null。因此，因为ASPXAUTH cookie为null，系统会自动重定向到LogOut操作。
如果我考虑他们在链接中发布的解决方案，我不确定是否这适用于我。据我所知，加密的cookie仍然很小（如几百个字符长）并且不接近4096字节。此外，我在测试断开的链接时只有3个cookie，在任何给定时间我最多有5个cookie。
任何想法？
好的，所以我对饼干过期抱有预感。所以我看看是否有办法在Forms身份验证中保留（强制）cookie，这导致我 如何在IIS7中生成机器密钥 [ ^ ]
唯一我可以测试这个理论的方法是继续正常工作和调试网站。 （这就是为什么我花了这么长时间才发布这个答案。）因为我介绍了这个解决方案似乎问题已经解决了。
有趣的是我前几天，我有一个建筑师，有20年的开发经验，关于我的问题。他看了我的代码，并确信这是表单身份验证代码中的一个错误。
我希望这可以帮助一些遇到同样问题的人。
This is a very strange one for me and I''ve been battling with it for a while now. I really hope someone can help.
I have a fairly typical MVC 3 Website and I only seem to be getting this problem in IE and Firefox. Chrome plays along nicely. Lucky for me, the majority of our company''s clients uses Chrome at the moment.
Problem is at a seemingly random point in time, the browser will automatically redirect me to the Account/LogOff action when I click on a link, and from there it will obviously go back to the Login page. This link will then continue with the same behavior.
I say "seemingly random" because today that link will work, tomorrow it won''t and all other (or the majority - I have never had more than on problem link giving this problem at a time) links will be fine. Sometimes restarting the server/dev environment will take care of the problem, other times it won''t. The browser will just keep redirecting to LogOff.
I have tried looking at the Referrer URL, but the controller/action being referred to will never be reached. (If I place a breakpoint in the action, it is missed and the next point reached would be the LogOff action)
If I look at the stacktrace when in the LogOff Action, I can''t see any info from where the application has come from. I have also tried what was suggested in this page: Posting the Stack Trace on ASP.NET MVC, but I cannot see why I am being redirected to the LogOff action.
The only place I seem to be able to have a breakpoint get hit before hitting LogOff, is Application_BeginRequest in the Global.asax, but can''t see where it is going from there on.
My guess is that somewhere along the line, ASPNET Auth decides the user isn''t authenticated any more and redirects to the LogOff action. Problem is that the cookies associated with ASPNET Auth all still exist, have data in them and they haven''t expired yet.
Anyway, I hope I have given enough info on the problem.
Thanks in advance.
[Edit]
OK, so I might have gotten a step closer. I came across this article and looked to see what is happening in my Application_AuthenticateRequest in my global.asax.
I am not quite sure why, by when I click on a link, Application_AuthenticateRequest gets accessed 3 times. When a link works (as in I can follow it and it doesn''t log me out), the value of the .ASPAUTH cookie stays the same. I checked this by adding a breakpoint and a watch over
HttpContext.Current.Request.Cookies[".ASPXAUTH"].Value
When the link does not work, the first time the cookie has a value, then the other two times it is null. Thus, because the ASPXAUTH cookie is null, the system automatically redirects to the LogOut action.
If I consider the solution they posted in the link, I am not sure if this applies to me. As far as I can tell, the encrypted cookie is still small (as in a few hundred characters long) and not close to 4096 bytes. Also, I have only 3 cookies going at the time I when tested the broken link and I have a maximum of 5 cookies at any given time.
Any idea?
OK, so I had a hunch about cookies expiring. So I looked at whether there is a way to keep (force) cookies in Forms Authentication alive and that led me to How to Generate Machine Key in IIS7[^]
The only way I could test this theory was to keep working and debugging the site as normal. (And that''s why it took me so long to post this answer.) Since I introduced this solution it seems that the problem has been solved.
Interestingly I spoke an Architect the other day, with 20 years dev experience, about my problem. He looked at my code and is convinced this is a bug in the Forms Authentication code.
I hope this helps some people who are experiencing the same problem I have.
这篇关于MVC 3 / ASPNET Auth - 几乎随机重定向到Account / LogOff的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
