4 ms·

I used to be strongly in the no-www camp for aesthetic reasons, but have since come around. There are legitimate reasons why having www (or any subdomain) is im

I used to be strongly in the no-www camp for aesthetic reasons, but have since come around. There are legitimate reasons why having www (or any subdomain) is important in any large site. The CNAME argument is obsolete since most DNS providers support ALIAS records now. The static no-cookie argument doesn't really matter since you could always serve static content on a separate domain altogether (ex: fbcdn.net). However, if you want to run hosted services on subdomains, you run into an important security issue. For example, say you have Zendesk hosted on support.mysite.com. You don't want to leak session cookies from mysite.com to support.mysite.com. In most browsers, you can just specify the cookie domain and it will only be sent to the root domain. However, NO versions of IE respect this (even IE 10+) [1]. So your IE users will always leak session cookies to hosted services on subdomains. In any reasonably secure site, this is unacceptable (especially when you start using other hosted services for status.mysite.com, careers.mysite.com, etc etc). Unfortunately, this is pretty much impossible to work around, unless you want to ban IE users from using your site entirely. Solution: Just use www (or any other subdomain, if you want to be different) from the start, and save yourself the headache of migrating later. [1] http://blogs.msdn.com/b/ieinternals/archive/2009/08/20/wininet-ie-cookie-internals-faq.aspx http://blogs.msdn.com/b/ieinternals/archive/2009/08/20/winin...

ecesena 12y ago
What about internal services with subdomains? What if, for instance, you have myservice.mysite.com and you want to share cookies among www and myservice? I mean, would you recommend to set cookies with domain mysite.com and thus have a different domain for external services, like support.mysite.net, or...? (genuinely asking, I don't mean to criticize, sorry if the english is not perfect :)
- dlubarov 12y ago
  Exactly - if you have a combination of trusted and untrusted subdomains, like www.mysite.com support.mysite.com wordpress.mysite.com Then it's impossible to give only certain ones access to your session cookie. You could use *.secure.mysite.com for all internal apps, but that seems ugly. You could also not use subdomains for any internal apps, like Google, but that's limiting in other ways - notably, it makes it impossible to have any security isolation between internal apps.
  - spiralganglion 12y ago
    Downvoters — Please explain why this is a bad post. As someone in the process of learning how to run web services, explicit discussion of benefits and costs is very helpful.
    - eru 12y ago
      Don't read too much into early downvotes on HN.
    - brianbarker 12y ago
      You'll be down voted over nothing on this site. It's not worth defending.
- possibilistic 12y ago
  Use oauth tokens or a similar mechanism to clone session tokens between (sub)domains without leaking them. This is also a great way to provide subdomain permission and expiry scope. Issue a master session cookie at login.mydomain or account.mydomain. If your user hits a subdomain and is not logged in, forward them there (in the background) and see if you can grant them a redeemable token for the round trip. If so, they can get a cookie issued by the subdomain in exchange for the token when they return.
  - ecesena 12y ago
    Thanks. I'm currently using subdomains only for trusted services, but I will definitely look towards this direction. I guess there is still some tricks when the user lands in a subdomain and needs to be redirected to another, e.g. www -> mobile, but I'll figure out the details :)
Tomte 12y ago
Me as well. The really big argument for me was: laypeople just expect the "www". Losing it means having to repeat and explain things. It's just not worth it.
- ef4 12y ago
  That particular problem has an easy technical solution. Just serve a redirect from the one you don't want to use to the one you do. Users can still type whatever the heck they want. You still have a canonical single version for SEO purposes.
  - Tomte 12y ago
    I have had people ask where the "www" went and what that means. The technical "solution" is only half the story. You break people's expectations, you get questions.
    - username42 12y ago
      Do the redirect always the other way. People understand when the www appears that you have done something to help them.
raamdev 12y ago
I ran into that IE bug a few years ago while working on some PHP code. For those curious what that bug might look like, I did a quick writeup of my findings [1] and posted the solution that I used to work around IE's bad behavior. [1] http://raamdev.com/2010/php-session-permission-denied-errors-with-sub-domains-and-ie7-or-ie8/ http://raamdev.com/2010/php-session-permission-denied-errors...
- wolf550e 12y ago
  1. That blog is written by someone who does not know what HTTP request and response headers are. 2. The solution provided does not solve the problem of foo.com not trusting bar.foo.com.
  - raamdev 12y ago
    1. Yes, I admit, I don't know everything. My old self admittedly knows less than my present self (the post was written 4 years ago), who most likely, I hope, knows less than my future self. I posted the link in the hope that others may find it valuable to see how such a bug might manifest itself. 2. The post was written in an exploratory tone, not a factual, "here are the facts, here's how to solve this problem across all scenarios" tone. Thanks for your feedback.
walden42 12y ago
Leaking cookies to subdomains IS a problem, but it shouldn't be too big of a deal security-wise if they are encrypted (as they usually are).
- staunch 12y ago
  No, it's always a security problem. http://en.wikipedia.org/wiki/Session_hijacking http://en.wikipedia.org/wiki/Session_hijacking
- tdammers 12y ago
  Assuming you're referring to the "SECURE" flag; this flag merely instructs the browser to only send the cookie over HTTPS (never plain HTTP), but the browser will merrily send it to any server that matches the cookie domain, and the way HTTPS works, this means whoever receives the cookie will be legitimately able to decrypt it.
Aardwolf 12y ago
So the only argument remaining, is IE?

ecesena 12y ago

What about internal services with subdomains? What if, for instance, you have myservice.mysite.com and you want to share cookies among www and myservice? I mean, would you recommend to set cookies with domain mysite.com and thus have a different domain for external services, like support.mysite.net, or...? (genuinely asking, I don't mean to criticize, sorry if the english is not perfect :)

dlubarov 12y ago
Exactly - if you have a combination of trusted and untrusted subdomains, like www.mysite.com support.mysite.com wordpress.mysite.com Then it's impossible to give only certain ones access to your session cookie. You could use *.secure.mysite.com for all internal apps, but that seems ugly. You could also not use subdomains for any internal apps, like Google, but that's limiting in other ways - notably, it makes it impossible to have any security isolation between internal apps.
- spiralganglion 12y ago
  Downvoters — Please explain why this is a bad post. As someone in the process of learning how to run web services, explicit discussion of benefits and costs is very helpful.
  - eru 12y ago
    Don't read too much into early downvotes on HN.
  - brianbarker 12y ago
    You'll be down voted over nothing on this site. It's not worth defending.
possibilistic 12y ago
Use oauth tokens or a similar mechanism to clone session tokens between (sub)domains without leaking them. This is also a great way to provide subdomain permission and expiry scope. Issue a master session cookie at login.mydomain or account.mydomain. If your user hits a subdomain and is not logged in, forward them there (in the background) and see if you can grant them a redeemable token for the round trip. If so, they can get a cookie issued by the subdomain in exchange for the token when they return.
- ecesena 12y ago
  Thanks. I'm currently using subdomains only for trusted services, but I will definitely look towards this direction. I guess there is still some tricks when the user lands in a subdomain and needs to be redirected to another, e.g. www -> mobile, but I'll figure out the details :)

Tomte 12y ago

Me as well. The really big argument for me was: laypeople just expect the "www". Losing it means having to repeat and explain things. It's just not worth it.

ef4 12y ago
That particular problem has an easy technical solution. Just serve a redirect from the one you don't want to use to the one you do. Users can still type whatever the heck they want. You still have a canonical single version for SEO purposes.
- Tomte 12y ago
  I have had people ask where the "www" went and what that means. The technical "solution" is only half the story. You break people's expectations, you get questions.
  - username42 12y ago
    Do the redirect always the other way. People understand when the www appears that you have done something to help them.

raamdev 12y ago

I ran into that IE bug a few years ago while working on some PHP code. For those curious what that bug might look like, I did a quick writeup of my findings [1] and posted the solution that I used to work around IE's bad behavior. [1] http://raamdev.com/2010/php-session-permission-denied-errors-with-sub-domains-and-ie7-or-ie8/ http://raamdev.com/2010/php-session-permission-denied-errors...

wolf550e 12y ago
1. That blog is written by someone who does not know what HTTP request and response headers are. 2. The solution provided does not solve the problem of foo.com not trusting bar.foo.com.
- raamdev 12y ago
  1. Yes, I admit, I don't know everything. My old self admittedly knows less than my present self (the post was written 4 years ago), who most likely, I hope, knows less than my future self. I posted the link in the hope that others may find it valuable to see how such a bug might manifest itself. 2. The post was written in an exploratory tone, not a factual, "here are the facts, here's how to solve this problem across all scenarios" tone. Thanks for your feedback.

walden42 12y ago

Leaking cookies to subdomains IS a problem, but it shouldn't be too big of a deal security-wise if they are encrypted (as they usually are).

staunch 12y ago
No, it's always a security problem. http://en.wikipedia.org/wiki/Session_hijacking http://en.wikipedia.org/wiki/Session_hijacking
tdammers 12y ago
Assuming you're referring to the "SECURE" flag; this flag merely instructs the browser to only send the cookie over HTTPS (never plain HTTP), but the browser will merrily send it to any server that matches the cookie domain, and the way HTTPS works, this means whoever receives the cookie will be legitimately able to decrypt it.

Aardwolf 12y ago

So the only argument remaining, is IE?