Browser sometimes loses HttpCookie for authentication after postback and redirect

Question

For some time this has been a problem, but very sporadic and difficult to isolate.

From time to time, authenticated browsers in a web application have been open for some time, they have registered and left the same web application several times, they have several tabs in almost any browser (Chrome, IE, Firefox, Safari) and, apparently, by chance, they lose the ability to save AuthCookie after installation and to accompany redirection. Closing the browser and starting a new session solves the problem, as did opening another browser and attempting authentication.

Our team uses authentication for all of our websites and web applications. This is a fairly typical setting, in which the login form is displayed, the user enters the credentials, and the cookie is set in the click postbackback event, then redirection occurs on the same page where the cookie is then linked and used to complete authentication.

In this situation

FormsAuthentication.FormsCookieName = ".WebAuth" 

Inside the event:

  FormsAuthenticationTicket authTicket = new FormsAuthenticationTicket(1, Username, DateTime.Now, DateTime.Now.AddMinutes(SessionTimeout), false, Username); HttpCookie faCookie = new HttpCookie(FormsAuthentication.FormsCookieName, FormsAuthentication.Encrypt(authTicket)); Response.Cookies.Add(faCookie); Response.Redirect(Request.RawUrl, true); 

After redirecting to PreInit:

 HttpCookie authCookie = Request.Cookies[cookieName]; 

At this point, the authCookie variable is usually not null, but in these isolated circumstances that I described above, the cookie is returned after the redirect.

This happens in a very random way, sometimes a few weeks before affecting one of our developers. As I said, restarting the browser fixes the problem.

Today it happened on our dev server when using Chrome. I registered with the application, allowed the application to wait for a session, and then tried to log in again. When trying to log in, the cookie could not be set. I remotely connected Visual Studio to a process on the server to start debugging. All the time when I could execute my code, even deploy new versions of the code on the server with updates, restart the application, restart IIS on the server, attach and join the project, and the problem persists in Chrome. In Firefox, I was able to authenticate without problems.

From Chrome, the login will be verified, try setting Cookie Response as described above. Before the redirect, I could see the correctly set Cookie Response, as well as a copy of it in the cookie files. However, with each redirect after an apparently successful login to the cookie system, the Response and Request Cookies are gone.

I turned on Trace in the app to view the collection of cookies:

The request cookie collection also contains .WebAuth, as well as ASP.NET_SessionId and several ASPSESSIONIDxxxxxxxx, but when loading the page, only ASP.NET_SessionId and ASPSESSIONIDxxxxxxxx cookies are available in the Request.Cookies area, there are no .WebAuth signs. However, there are several cookies in the page trace information after rendering. WebAuth, it is just that the page does not seem to have access to them.

First of all, in the working version, after authentication, the Trace info page has both .WebAuth Response and Request Cookie. But in a broken browser window Cookie Response is missing.

Anyone else have experience? This is such a grumbling problem and so sporadic, but I would really like to solve it. I am concerned that this may affect users, and we will not know, because the description of the problem is so confusing.

Answer 1

Depending on your scenario, you can use browser restrictions on the number of cookies for the domain / total. The restrictions are relatively high, but exist (spec: http://www.ietf.org/rfc/rfc2109.txt , section 6.3, some recent information - http://www.nczonline.net/blog/2008/05/17/ browser-cookie-restrictions / )

If you do this again, try looking at the actual server responses (for example, using Fiddler) to see if cookies are being sent to the browser. Check which cookies are set for the domain and the current page (depending on the browser, there are different ways to do this, in all browsers you can see some cookies by doing the following in the javascript address bar :alert(document.cookie) )

Answer 2

This is an intermittent cookie problem. The session is simply disconnected.

Try changing false to true on this line:

 FormsAuthenticationTicket authTicket = new FormsAuthenticationTicket(1, Username, DateTime.Now, DateTime.Now.AddMinutes(SessionTimeout), true, Username); 

Also add

 faCookie.Expires = DateTime.Now.AddMinutes(SessionTimeout); 

Answer 3

I got into a similar situation, everything was exactly as you described. But later the reason was found.

ASP.NET and IIS realized that MyApplication and myapplication are equal to one, but browsers use them as different. Therefore, when we set cookies for / MyApplication, they are not sent to the server when we go to / myapplication.

Further correction:

  protected void Application_BeginRequest(object sender, EventArgs e) { string url = HttpContext.Current.Request.Url.PathAndQuery; string application = HttpContext.Current.Request.ApplicationPath; if (!url.StartsWith(application)) { HttpContext.Current.Response.Redirect(application + url.Substring(application.Length)); Response.End(); return; } }