Click here to Skip to main content
15,891,745 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
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

C#
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?
Posted
Updated 27-Nov-12 0:46am
v3

1 solution

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.
 
Share this answer
 
Comments
fjdiewornncalwe 15-Jan-13 10:17am    
Are you running on a web farm with load balancing? If so, then you absolutely need to implement the same machine key into the web.config on each of the servers.
Mr.Thursday 16-Jan-13 0:22am    
At the moment no. For now it's all hosted on one server, but that will change soon. So in that regard, I would have had to make this change eventually anyway.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
Top Experts
Last 24hrsThis month


CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900