17

I have an application where, in the course of using the application, a user might click from

virginia.usa.com

to

newyork.usa.com

Since I'd rather not create a new session each time a user crosses from one subdomain to another, what's a good way to share session info across multiple subdomains?

Blegger
  • 4,272
  • 4
  • 30
  • 36
marclar
  • 3,026
  • 5
  • 35
  • 56

5 Answers5

41

You tagged this with ASP.NET and IIS, so I will assume that is your environment. Make sure you have this in your web.config:

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

If your 2 subdomains map to the same application, then you are done. However, if they are different applications you will need to do some additional work, like using a SQL Server based Session storage (and hacking the stored procedures to make sure all applications share the same session data) or with an HttpModule to intercept the application name, since even with shared cookies and the same machine key, 2 applications will still use 2 different stores for their session data.

Matt Connolly
  • 1,233
  • 2
  • 13
  • 20
  • Thanks a lot Matt! We've used [this solution](http://stackoverflow.com/a/2174338/177710) before but it kept OutputCaching from working. Your solution makes our OutputCache finally work :-D – Oliver Jan 24 '12 at 22:41
  • 2
    I tried this on my localhost (with the subdomain in my hosts file) and it doesn't work. I can pull up the subdomain fine, but, going from one to the other results in the session lost and the user having to log in again. Any ideas? – Marc Sep 21 '12 at 21:37
  • I think this link has a good solution http://support.microsoft.com/kb/2527105 (How to share session state across subdomains) from Microsoft support, it depend on HTTP module, so you don't have to update the out-of-the-box session SQL DB. – Tarek El-Mallah May 08 '14 at 15:22
  • web.config domain virginia.usa.com or web.config domain newyork.usa.com? Please help me – HOÀNG LONG Dec 07 '18 at 23:52
3

I recently went thru this and learned the hard way. Localhost is actually considered a TLD. Cookie domains require at least a second level domain - test.com. If you want cookies to work for a domain and all it's sub-domains, prefix with a '.' - .test.com.

When running/debugging locally, setting a domain of localhost will fail, and it will fail even if the domain is set properly because visual studio uses localhost by default.

This default localhost can be changed in the project properties so that the project will actually run at cookie domain test.com. Essentially, if the address in the browser matches , you can get it to work.

My issue is documented here: Setting ServiceStack Cookie Domain in Web.Config Causes Session Id to Change on Every Request

Hope this helps.

Community
  • 1
  • 1
vm0112
  • 121
  • 1
  • 9
3

Track your own sessions and use a cookie with an appropriate domain setting, ie. .usa.com.

Alternatively, if you're using PHP, I believe there's a setting to change the default domain setting of the session cookie it uses, that may be useful too.

The settings you're looking for are:

session.use_cookies = 1
session.use_only_cookies = 1
session.cookie_domain = .usa.com
Matthew Scharley
  • 127,823
  • 52
  • 194
  • 222
0

Matt's answer is definitely the way to go if you have multiple subdomains pointing at the same IIS app (which is exactly the situation I have right now, using wildcard DNS and then doing subdomain 'sniffing' on the receiving end).

However, I wanted to add something that I experienced in case anyone is finding that this is not working for them. Setting the httpCookies line alone didn't do it for me, I had to add a machineKey entry into my web.config file:

machineKey decryptionKey="12...D1" validationKey="D7..8B"

Particularly odd since I am not in a web farm setup (unless AWS/EC2 is effectively acting as such).. As soon as I did this, it worked like a champ.

Chris
  • 73
  • 1
  • 6
0

If you're using PHP, one hack would be to make a little include script (or two) to do the following:

1 Serialize your $_SESSION array 2 Pass that string as a hidden input, making all your links to those buttons in separate forms using POST. 3 Also include a boolean hidden input to let your script know whether it needs to use the current session or unserialize $_POST['session'] 4 Deploy this across your site, calling things where appropriate

I wouldn't do this if there's actually a sanctioned way to transfer a session. I hope you've at least considered using cookies.

Robert Elwell
  • 6,598
  • 1
  • 28
  • 32