Comment by adrianmacneil | Hacker News Reader

Comment by adrianmacneil | Hacker News Reader

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/winin...

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 :)

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.

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.

Don't read too much into early downvotes on HN.

You'll be down voted over nothing on this site. It's not worth defending.

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.

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 :)

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...

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.

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.

So the only argument remaining, is IE?

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.

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.

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.

Do the redirect always the other way. People understand when the www appears that you have done something to help them.

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).

No, it's always a security problem. http://en.wikipedia.org/wiki/Session_hijacking

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.

Reply on news.ycombinator.com