9

I am losing the ASP.NET_SessionId when switching between pages on my site. The issue happens in Chrome/Firefox/Safari. It does not happen in IE. It is rather strange...here is my scenario.

My site can be accessed by entering www.example.org or example.org in browser (this is an important piece of info as you will see).

I enter example.org. From my home page, I log into to my site (note: I am not using ASP.NET forms authentication). I am sent to my default user page (e.g., userpage.aspx). From this page, I click on an <a> that sends me to a different page on my site. The <a> link is full-qualified (e.g., http://www.example.org/page2.aspx). When I get sent to the new page, my session is lost!

So, I ran Fiddler to try and discover the problem. What I found was interesting. The Request Header tag Referer was getting lost between pages.

Here are the steps:

  1. Go to example.org.
  2. Login to example.org.
  3. I get redirected to userpage.aspx. The Referer is http://example.org. The ASP.NET_SessionId is set.
  4. I click on the <a> (e.g., http://www.example.org/page2.aspx). After the page is rendered, the ASP.NET_SessionId is lost.

The lost ASP.NET_SessionId is lost consistently is Chrome/Firefox/Safari. This does not happen in IE.

If repeat the above steps by substituting example.org with www.example.org, the ASP.NET_SessionId is not lost. It works, correctly each time.

Any thoughts on this behavior?

Uwe Keim
  • 39,551
  • 56
  • 175
  • 291
Steve
  • 927
  • 3
  • 10
  • 23

2 Answers2

7

Add this to your web.config under the <system.web> element

<httpCookies domain=".mysite.com" />

See if there is any change in behavior. It sounds as though sub-domains are failing although I thought the cookie was based at the root domain to begin with. this should force it that way.

Adam Tuliper
  • 29,982
  • 4
  • 53
  • 71
  • I think you may be onto something. The cookie is only one side of the equation on the session state management. There's also the server. I believe that from the perspective of IIS, www.mysite.com is a different application than just mysite.com. Even if they point to the same physical files/directories, they are distinct entities, and the session is based on httpcontext.current, which is linked to the current applicaiton scope. (I hope someone smarter than me can word that better and verify if I'm right on that. I'm probably not. I'm actually just putting that out and hoping to learn.) – David Apr 04 '12 at 14:21
  • @DavidStratton they will all exist in the same app pool. All configured host headers will point to the same app pool. I this case I think the browser just isn't sending the cookie over because of the cookie domain (so its working as designed) The important thing here (not noted in the OP) is if fiddler shows the cookie being sent over or not. – Adam Tuliper Apr 04 '12 at 16:29
3

In my case the following was the issue:

In my local Visual Studio environment, my development "web.config" file accidentially contained the following:

<configuration>
    <system.web>
        <httpCookies requireSSL="true" />
    </system.web>
</configuration>

Since the development IIS Express runs at http://localhost:7561, which is not HTTPS, this check triggered to not set/accept any cookies, including the session ID cookie.

Solution was to simply comment out the <httpCookies requireSSL="true" /> line.


Another, similar issue I could imagine is that the Content-Security-Policy HTML meta tag, that also controls how cookies are handled, could also be configured to not allow the session ID cookie to be set.

Uwe Keim
  • 39,551
  • 56
  • 175
  • 291