Store Session cookie for groups of subdomains in ASP.NET IIS7

Question

I have an application running ASP.NET. I have different domains and different sub-domains. I want the domains to share session with their sub domains.

For Example, the following domains access this application:
www.example1.com
print.example1.com
www.example2.com
print.example2.com

If a user goes to www.example1.com and print.example1.com, I want it to use the same session. If the user were to go to www.example2.com and print.example2.com, I would want it to use a different session than the *.example1.com.

The way I used to handle it was a hack in page_load that works perfectly in IIS6:
Response.Cookies["ASP.NET_SessionId"].Value = Session.SessionID;
Response.Cookies["ASP.NET_SessionId"].Domain = SiteUtility.GetCookieDomain();
(SiteUtility.GetCookieDomain would return .example1.com or .example2.com depending on the url of the request)

Unfortunately, this no longer seems to work for iis7. Each subdomain/domain a user goes to, the user gets a new session cookie.

I then found the web.config entry:
'<httpCookies domain=".example1.com" />.

This works great for sharing session cookie between example1.com subdomains. Unfortunately, this completely screws up session state for *.example2.com.

Any ideas on how I can solve this?

Answer 1

rather than using SiteUtility.GetCookieDomain(), try using:

var domainSansTLD = Request.Url.Host.Replace(".com", "");
var secondLevelDomain = domainSansTLD.Substring(domainSansTLD.LastIndexOf('.'));
var cookieDomain = secondLevelDomain + ".com";

Answer 2

First way,

Store session as file in a location that both servers can access (this is good for virtual servers or shared folders). This method is a bit unreliable and shared folders and lag thus causing problems.

Okay, I was going to write a couple of other methods but I'm sure they'll be posted as they have more knowledge with asp.net than I, however, I do have a personal preference that I think would be a good option.

This option would be a memcache server. Essentially it's a database that runs off RAM and you point all of your sessions to it (tcp://mem.domain.com:1234 ... sorry I can't remember the usual port off the top of my head).

I hope I was of some help,

Jon

Answer 3

Have you tried creating a HttpModule that intercepts the EndRequest-event, iterates over the Response.Cookies collection, finds the session-cooke and changes its Domain property before actually sending it to the client.

Edit:

Kevin at the end determined that one of the subdomains was in a trusted state in ie8 while the other was not. When both are in a trusted state (and presumambly both in an untrusted state) it works. I did spent the most time on this, so Kevin want to give me the credit for the answer.