A couple of weeks ago, I spent a good part of a day troubleshooting an issue with creating persistent cookies from ASP.NET 2.0 and how they're handled by IE7. Fortunately for us (specifically me), this occurred in our test environment so only developers in the project were affected by it.
Our application is using a custom authentication cookies to help reduce the request overhead to our database (pretty common scenario). This can be done by implementing your own IHttpModule and within it's Init method, register to the HttpApplication's AuthenticateRequest Event. My good friend Heath Stewart wrote an article (way back in the day) that explains how to do this pretty well. (FYI, this is the exact same way the the FormsAuthenticationModule does its "magic".) One of the things we wanted to change on this authentication scheme is to add our custom user data and to change the default expiration time of the ASP.NET authentication cookie from 30 to 20 minutes. Granted, the change of expiration time can be done by specifying the time out value within web.config but still leaves us short from adding our custom user data to the authentication cookie. So we rolled our own, keeping it close the "out of the box" implementation.
Since I can't go into details on how our application is actually laid out, I've come up with a simple VS2005 project that mimics its basic layout. At the core, there's a login page that will authenticate the user, then redirect the user to the "secure" part of the portal (pretty typical for web applications). The restrictions of who can access the secure part are defined within the web.config. See the image below as reference:
When I ran the project within the VS2005 WebDev Server and within my local IIS, the application worked seamlessly. I used both IE7 with Fiddler2 and FF 126.96.36.199 with FireBug to see if the request (and cookie) were coming in correctly. As you can see from the screen shots, you'll conclude the same.
This is the output from Fiddler2 going to localhost.com. I had to add an alias to the hosts file to point 127.0.0.1 to localhost.com so Fiddler2 can pick up it locally. It's a bit of a hack, but it worked.
The image above is the output from FireBug going against the same URL, the only thing you can't see in this screen shot is that the expiration date for the cookie, but trust me it's there. As you can see it's pretty much the same as the output from Fiddler2 (the only difference is the encryption of the cookie since they're two distinct requests from two different browsers).
Now, the I moved the application to our test environment the story changed when I tried accessing the web application with IE7. For some reason, the authentication cookie was not being sent with the GET request for /secure/default.aspx. Below are the requests that Fiddler captured for me that proves the point:
The response for Request #21 creates the .ASPXAUTH cookie and returns it to the client. However, Request #22 does not send the cookie to the application making ASP.NET redirect the request back to the login page (default.aspx), this is Request #23. Here's the raw text from the scenario:
-- Raw HTTP response from Request #21
HTTP/1.1 302 Found
Date: Mon, 31 Dec 2007 10:39:14 GMT
Set-Cookie: .ASPXAUTH=0257C3AA5560C267C9FA6EB8B1CC5B580614CD539BEE998CBD636B111507737F465372D6663EAA62D06ADF3B2535CA215F49A96FFA2F05722FB115C9E6B8498F; expires=Mon, 31-Dec-2007 11:09:14 GMT; path=/; HttpOnly
-- Raw HTTP request from Request #22, as you can see there are NO cookies
GET /sample/secure/default.aspx HTTP/1.1
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; ...)
If it look for the cookie within the Temporary Internet Files folder, the cookie is not present. For some reason, IE7 ignores the request to persist the cookie and removes it from the request. When I try accessing the application with FF 188.8.131.52, the application works as expected!
Prior to me doing all that research, I did a couple of quick searches to find out that some people were experiencing similar symptoms with IE7 and persistent cookies. Here are some of the links I've found:
I unfortunately, didn't the time to come up with an elegant solution to the problem so for now I disabled the persisting of the cookie from my code and that "fixed the glitch." Once I get some free time, I plan on looking into this a bit further to figure out the root cause (unless a reader gives it to me first .. ;-) ).
I hope this helps anybody else running into this same issue!