0

Using Windows Identity Foundation (asp.net, mvc 3), I set the cookieHandler config in web.config like so: 

    <cookieHandler requireSsl="true" domain=".website.qa" />

.qa is our quality assurance and testing build domain. Locally, I have it set to

    <cookieHandler requireSsl="true" domain=".website.local" />

And this worked fine. I needed to override domain from default because the auth cookie needed to be seen across different subdomains (e.g. asdf.website.qa and qwer.website.qa). The local builds are just that, locally run from the developer's computer. QA builds are pushed to a server. Firefox and IE were ok with this domain, but Chrome didn't seem to set the cookie at all. The problem was fixed by changing the QA site to be asdf.website.qaa, and:

    <cookieHandler requireSsl="true" domain=".website.qaa" />

Is there a feature in Chrome that blocks two letter top level domains on cookies? Or am I thinking about this incorrectly?

ryanhallcs
  • 237
  • 1
  • 14
  • No answer, but I read that Chrome (and Mozilla) use the [Public Suffix List](http://publicsuffix.org/), and according to that list `.qa` is an official TLD (for Qatar), but `.qaa` and `.local` are not. This may or may not be relevant here. – MarnixKlooster ReinstateMonica Apr 13 '12 at 20:59
  • Certainly relevant and I didn't know that list was used. Now just confuses me more because .local was able to set cookies. However, it was a locally running application as well. And also when I didn't set the WIF domain (i.e. used default) for cookies, .qa was working. It only didn't set the cookie when I switched it from default to .website.qa. – ryanhallcs Apr 16 '12 at 22:06

0 Answers0