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.

Background Info

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 and within it's method, register to the 's .  My good friend (way back in the day) that explains how to do this pretty well.  (FYI, this is the exact same way the the 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.

Application Layout

Since I can't go into details on how our application is actually laid out, .  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:

Project layout

Development Environment

When within the VS2005 WebDev Server and within my local IIS, the application worked seamlessly.  I used both IE7 with and FF 2.0.0.11 with to see if the request (and cookie) were coming in correctly.  As you can see from the screen shots, you'll conclude the same.

Fiddler2_requests

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.

FireBug proxy requests

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).

Runtime Environment

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:

Fiddler2_request_list

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
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Location: /sample/secure/default.aspx
Set-Cookie: .ASPXAUTH=0257C3AA5560C267C9FA6EB8B1CC5B580614CD539BEE998CBD636B111507737F465372D6663EAA62D06ADF3B2535CA215F49A96FFA2F05722FB115C9E6B8498F; expires=Mon, 31-Dec-2007 11:09:14 GMT; path=/; HttpOnly
Cache-Control: private

-- Raw HTTP request from Request #22, as you can see there are NO cookies

GET /sample/secure/default.aspx HTTP/1.1
Referer: /sample/default.aspx?ReturnUrl=%2fsample%2fsecure%2fdefault.aspx
Accept-Language: en-us
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; ...)
Proxy-Connection: Keep-Alive
Pragma: no-cache

If it look for the cookie within the 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 2.0.0.11, the application works as expected!

PostMortem

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!