Всем привет.

Этот топик — некая зарисовка на полях, которая, надеюсь, кому-нибудь пригодится, а кто-то — просто прочитает ее с интересом.

Не так давно мы запустили приложение для Твиттера по (не дай бог быть осужденным в пиаре) адресу lu.ly

За несколько недель до релиза мы перевели приложение с внутреннего домена для разработки на production-домен как вдруг столкнулись с непонятной ситуацией.

В Internet Explorer и 6-й и 7-й и 8-й версии не устанавливались некоторые cookie сайта.

Что происходит?

Точнее говоря — в Internet Explorer всех версий неожиданно перестала работать авторизация, вызываемая из библиотеки для Facebook-а.

Что самое странное — сама авторизация происходила и методы возвращали успешный результат.

Но уже на следующей странице — мы не получали никаких данных о том, что пользователь сайта как-то связан с Facebook-аккаунтом.

Сперва, нам и в голову не могло прийти что проблемы находятся на стороне сервера или клиентской части. Несколько часов конфигурирования Facebook-приложения ни к чему не привели.

И в чем дело?

После безуспешных попыток разобраться с Facebook-приложением мы перешли к серверной части, ожидая что проблема в нашем использовании Facebook-библиотеки. На площадке для разработки мы создали простое приложение в котором стали отслеживать — как именно Facebook сохраняет данные об авторизации для данного сайта.

Механизм работы заключался в следующем — как только библиотека Facebook-а на сайте получала ответ об успешной авторизации — пользователю устанавливался ряд cookies, обыкновенных доменных cookies.

И вот вывод отладочной информации и показал нам что cookies не ставятся.
Самым странным было то, что ряд кук все таки был установлен — работали сессии, работала авторизация на твиттере, и только Facebook-куки не до ходили до клиента.

Еще раз подчеркну — куки, выставляемые библиотекой Facebook-а были не кросдоменные, они выставлялись не на Facebook-сервере а на нашей машине для наших клиентов. И они пропадали.

И в чем причина?

Еще раз — в Фаирфоксе, Опере (и как я подозреваю, но не проверял — в Сафари и Хроме) все было хорошо. Куки не устанавливались только в всеми любимом Internet Explorer.

Дальше начались несколько часов затяжных боев. Мы проверили все — P3P заголовки, изрыли вдоль и поперек библиотеку Facebook-а и в итоге решили препарировать ее по кусочкам. Через 4 часа экспериментов от библиотеки остался только фрагмент устанавливающий куки. И он все равно не работал.

Ручная установка Expire-даты не помогала. Смена имени кук не помогала. В конце концов мы подумали — может быть проблема в веб-сервере? И перенесли все на другой сервер и на другой домен, где, о чудо, куки незамедлительно установились.

Теперь к сути. Еще раз напомню что домен — двухбуквенный.
Не знаю чем мы руководствовались но кто-то, больше из интереса, написал в гугле — «IE two letter domain»

Когда мы увидели результаты удивлению не было предела.

support.microsoft.com/kb/310676

Internet Explorer does not set a cookie for two-letter domains

Вот именно так. Для кук с явным указанием двухбуквенного доменного имени. Не ставит, и все.

Почему? А потому что куки нельзя ставить на Top Level Domains такие как .com, .net, .ru и… и домены подобные co.uk.

Но ведь никто особенно не знает какой домен еще может оказаться TLD в длительной перспективе. Разные браузеры с этим справляются по разному, нашел свой путь и Internet Explorer.

Если не сказано иначе любой двухбуквенный домен IE считает TLD-доменом и не ставит доменные куки на него

Но ведь должен же быть фикс?

Да фикс есть, Microsoft обещала это в своей статье и выпустила его.
Теперь конечный пользователь, если он все-таки хочет выставить куку на двухбуквенный домен волен это сделать.

Для этого всего-лишь надо установить специальный ключ в реестре как то рекомендует MS:

# Start Registry Editor
# Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0
# On the Edit menu, click Add Value, and then add the following registry entry:
Name: SpecialDomains
Type: REG_SZ
Value: lp. rg. ac.


Что делать веб-разработчикам?

Есть два ответа на этот вопрос.
Один скорее смешной, и его, опять же, рекомендует Microsoft:

To work around this problem, do not use a domain name with less than three letters. You may also want to use HTTP redirects that route requests for www.xx.xx to www.xxx.xx.

Другой — не менее топорный — не использовать доменных кук.

В ситуации с Facebook-библиотекой все решилось снятием домена с установки cookie после авторизации.

Что делать — в случае если доменные куки все-таки нужны? Вопрос остается открытым.

Надеюсь, что эта информация кому-то оказалась полезной, спасибо за внимание! :)

Update:
как верно подмечено информация об этом уже появлялась на хабре вот в этом посте —
djru.habrahabr.ru/blog/57463/

так же полезную информацию вы можете встретить

1. здесь — crisp.tweakblogs.net/blog/ie-and-2-letter-domain-names.html
где среди прочего отмечается что многие браузеры решают проблему определения TLD по своему.
Опера, для примера, при установке куки на двухбуквенный домен делает dns lookup по этому домену для проверки на его существование. Остается однако риск того что регистратор может сделать двухбуквенный домен доступным для резолвинга.

2. и здесь drupal.org/node/280623
где в качестве решения предлагается добавлять www к домену, что однако ограничивает пользователей, обращающихся к домену без www (а прелесть двухбуквенного домена во много связана именно с его коротким названием)

Update 2:
В процессе обсуждения выяснились подробности касательно поведения Firefox для TLD, а конкретно для географических доменов.

Очевидно, что список TLD-доменов жестко зашит в библиотеки фаирфокса, и среди прочего, в этом списке указаны географические домены.
Таким образом, доменные куки в Firefox на географические домены (такие как chel.ru — для Челябинска, tyumen.ru для Тюмени) ставится не будут.
Спасибо nickyx3.habrahabr.ru/ за наводку!