.NET can't find the cookie that I created in classic asp in some cases.

Question

I'm the only developer supporting a website that's a mix of classic asp and .NET. I had to add some .net pages to a classic asp application. This application requires users to login. The login page, written in classic asp, creates a cookie that .net pages use to identify the logged in user and stores information in session vars for the other classic asp pages to use. In classic asp the cookie code is as follows:

response.cookies("foo")("value1") = value1
response.cookies("foo")("value2") = value2
response.cookies("foo").Expires = DateAdd("N", 15, Now())
response.cookies("foo").Path = "/"

In the .NET codebehind Page_Load code, I check for the cookie using the code below.

if(!IsPostBack) {
if(Request.Cookies["foo"] != null) { ... } else { //redirect to cookie creation page, cookiefoo.asp } }

The vast majority of the time this works with no problems. However, we have some users that get redirected to a cookie creation page because the Page_Load code can't find the cookie. No matter how many times the user is redirected to the cookie creation page, the referring page still can find the cookie, foo. The problem is happening in IE7 and I've tried modifying the privacy and cookie settings in the browser but can't seem to recreate the problem the user is having.

Does anyone have any ideas why this could be happening with IE7?

Thanks.

Answer 1

Using Fiddler is a good way to try to figure out what's going on. You can see the exact Set-Cookie that the browser is getting.

Answer 2

General rule of cross-platform cookie testing: dump all the cookies to screen so you can see your data. It might not explain exactly why it's happening, but it should tell you what is happening.

Answer 3

Okay second answer: If it's a really small subset of users, you might want to see what software they have installed on their computer. There might be a common anti-spyware/adware application on all their machines that is messing with your cookies.

If you can't get answers from those users on that, or there's nothing suspect it might be worth creating a special little test script to write a cookie and post the result back to you on the next page-load.

You want to keep it as simple as possible (no user interaction after loading the link) so make it:

1. Set the cookie in classic ASP
2. Redirect to another ASP page.
3. Read the cookies and email it to you.
4. Redirect to a ASPNET page.
5. Read the cookie and email it.

You might want to set a cookie in ASPNET too and try reading it back out.

Answer 4

The code you posted should break if the IE7 privacy settings is set to block first party cookies. Did you try that in your experiments?

Using Fiddler as Lou said it a good idea although the Set-Cookie response header is less interesting than subsequent Cookie request headers to see whether the client is fowarding them to the server.

Answer 5

I recall this happening in a similar application I had written; some pages were classic ASP, while others ASP.NET. The cookies were seemingly disappearing between the .NET and classic ASP pages.

IIRC, the .NET side needed to Server.HTMLEncode/HTMLDecode the cookies. Sorry, but I don't have the exact code I used, but this should get you going in the right direction.

Answer 6

One thing about cookies that can be very hard to debug is that cookies are case-sensitive when it comes to the domain. So, a cookie that was issued for "www.abc.com/dir1/alpha/" can not be accessed from code if the user typed "www.abc.com/dir1/Alpha/".

Another thing to watch out for in your ASP.NET pages is

Page.Response.Redirect("~/alpha");

ASP.NET will modify the case of the relative URL based on the case of the actual filepath. If you have mixed-cases in your directory structure, then use

Page.Response.Redirect(Page.ResolveUrl("~/alpha").ToLower());