I recently changed the code in my online West Wind Web Store to specifically write the one cookie I use in the app to a specific path so that there's no interference with other virtuals also running the store. I thought this was necessary to run successfully with multiple stores.

Changing Cookie paths is easy enough and since I use a common cookie class this was easy to do in one place by just making sure that the app writes out the cookie with a common path. By default I write out the Application path with something like this:

public void WriteCookie(string Value, bool NonPersistent)

{

    HttpCookie Cookie = new HttpCookie(CookieName,Value);

    Cookie.Path = HttpContext.Current.Request.ApplicationPath + "/";

    if (!NonPersistent)

       Cookie.Expires = DateTime.Now.AddMonths(CookieTimeoutInMonths);

    HttpContext.Current.Response.Cookies.Add(Cookie);

}

I tested this locally and it worked just dandy, so this seemed like an easy enough fix for multiple store cookie overlap.

But surprise, surprise I didn't test with HTTPS/SSL. The live store switches from http:// to https:// once the order is submitted and with the application path scoped cookie, and it turns out both IE and FireFox loose the cookie in this transition. If the user was previous logged in to his profile the profile is lost.

Worse, even trying to reconnect the cookie under https seems to fail – it looks like under https cookie paths don't work. Everytime I try to reconnect to a new cookie after assigning it is lost.

The code starts working on the live site as soon as I comment out the Path assignment.

    // Cookie.Path = HttpContext.Current.Request.ApplicationPath + "/";

Put the above code back in and - boom - it fails to work again.

I took a look at the cookie files and the cookies look just fine. The requests go from http:// to https:// without anything code manipulating the cookie – the cookie just disappears.

WebStoreUser

12139eff

www.west-wind.com/wwstore/

1024

4039391232

30053033

3782347520

29759130

*

What's odd is that I can see the cookie file actually change as I go through these requests in the http to https transition. If I run the same exact code without the https transition it works fine. If I remove the path from the cookie, it works fine as well.

Weird. 

Now, lest you think I track my profile with a cookie – no, the cookie is used only to attach to the profile once. The cookie is a permanent cookie I write out so users can automatically reattach to their profile when they return to the site. After the initial Cookie lookup a Session variable tracks the users customer id that points at the customer record. But of course when the cookie goes, the ASP.NET Session Cookie goes with it so the customer link is lost.

I'm not quite sure what the heck is happening because don't have a tool to examine the secure https content (Fiddler doesn't work with https) to see where the cookie gets dropped.

It works now having changed back to the root path, but anybody have any idea why a virtual path would fail in https?