Hacker News Reader

Comment by bjt | Hacker News Reader

But then you still have to remain vigilant against a clueless dev or random JS lib on www.domain.com setting a cookie for .domain.com, which your browser will helpfully include with requests to cdn.domain.com. With the completely separate root you're protected from that.

http://en.wikipedia.org/wiki/HTTP_cookie#Domain_and_Path

View on HN

So basically it doesn't have to be that way, but to protect yourself from cluelessness/stupidity, you do it.

Kind of like Unix permissions vs. jails/virtual machines. Both are secure, but one is more secure against incompetence than the other.

I wouldn't agree. There are completely legitimate reasons to set cookies on *.domain.com -- it isn't "clueless/stupid" to do so, just less ideal.

I wasn't making a statement, just trying to clarify and then making an analogy to verify my understanding. I think I omitted a question mark where I should have had one.

Certainly, it is not automatically a bad idea to set such cookies. I see that.

We use wildcard cookies to let users login to www.domain and peek at beta.domain without logging in again. This isn't incompetence so much as reducing user drag. Perhaps I should have set it up to use www.domain/beta/ instead.

Unfortunately, this means our cookies are sent to static.domain. Worse, once we get rid of beta.domain there's no going back on wildcard cookies - there's no way to force clients to expunge cookies.

You could use beta.www.domain.com.

This makes a ton of sense, but it might be unorthodox enough to scare off some users thinking it was a scam of some sort.

Reply on news.ycombinator.com