3 ms·
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 h
by bjt 13y ago
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 http://en.wikipedia.org/wiki/HTTP_cookie#Domain_and_Path
- sliverstorm 13y agoSo 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.
- moot 13y agoI 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.
- sliverstorm 13y agoI 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.
- kibibu 13y agoWe 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.
- cheald 13y agoYou could use beta.www.domain.com.
- jamesjporter 13y agoThis makes a ton of sense, but it might be unorthodox enough to scare off some users thinking it was a scam of some sort.