views:

624

answers:

2

I have a FormsAuthentication cookie that is persistent and works independently in a development, test, and production environment. I have a user that can authenticate, the user object is created, the authentication cookie is added to the response:

'Custom object to grab the TLD from the url
authCookie.Domain = myTicketModule.GetTopLevelDomain(Request.ServerVariables("HTTP_HOST"))
FormsAuthentication.SetAuthCookie(authTicket.Name, False)
Response.SetCookie(authCookie)

The user gets processed a little bit to check for a first time login, security questions, etc, and is then redirected with the following tidbit:

Session.Add("ForceRedirect", "/FirstTimeLogin.aspx")
Response.Redirect("~/FirstTimeLogin.aspx", True)

With a debug break, I can verify that the cookie collection holds both a cookie not related to authentication that I set for a different purpose and the formsauthentication cookie. Then the next step in the process occurs at the ApplicationAuthenticateRequest in the global.asax:

Sub Application_AuthenticateRequest(ByVal sender As Object, ByVal e As EventArgs)
    Dim formsCookieName As String = myConfigurationManager.AppSettings("FormsCookieName")
    Dim authCookie As HttpCookie = Request.Cookies(formsCookieName) 

At this point, for this ONE user authCookie is nothing. I have 15,000 other users who are not impacted in this manner. However, for one user the cookie just vanishes without a trace. I've seen this before with w3wp.exe exceptions, state server exceptions and other IIS process related exceptions, but I'm getting no exceptions in the event log. w3wp.exe is not crashing, the state server has some timeouts but they appear unrelated (as verified by timestamps) and it only happens to this one user on this one domain (this code is used across 2 different TLDs with approximately 10 other subdomains).

One avenue I'm investigating is that the cookie might just be too large. I would think that there would be a check for the size of the cookie going into the response, and I wouldn't think it would impact it this way. Any ideas why the request might dumping the cookie?

NOTE: The secondary cookie I mentioned that I set also gets dumped (and it's very tiny).

EDIT-NOTE: The session token is NOT lost when this happens. However, since the authentication cookie is lost, it is ignored and replaced on a subsequent login.

A: 

A potential issue is the way you redirect; by setting the boolean value to true you send a ThreadAbortException and you may lose the session token. Either set the boolean value to false or use FormsAuthentication.RedirectFromLoginPage

Nip
No, setting the boolean to true causes the ThreadAbordException to be ignored. I tried FormsAuthentication.RedirectFromLoginPage with the same effect. Of note, the session token is NOT lost. It remains.
Joel Etherton
According to the mdsn documentation http://msdn.microsoft.com/en-us/library/a8wa7sdt(VS.80).aspx `endResponse` indicates whether execution of the current page should terminate, so setting it to false is the way to avoid the `ThreadAbordException`. With that said, I am afraid I cannot really help. Have you looked at changing the expiration date?
Nip
A: 

It turns out that the cookie data being dumped into the cookie for this particular user happened to exceed the maximum allowed size in its encrypted format. Unencrypted, the data fit, but once the encryption was run on it the size grew too large to handle. This caused the cookie and any cookies added after it to be dropped from the response header.

Chopping the amount of data injected into the cookie solved the issue.

Joel Etherton