IE8 не применяет куки в домене - только на одном компьютере - PullRequest
6 голосов
/ 11 ноября 2009

У меня есть интересная проблема, которая ставит меня в тупик.

У меня есть созданный фрагмент производственного кода, который считывает cookie-файл токена IBM LTPA, установленный машиной, управляемой другим отделом, проверяет ее и использует для входа в систему, которой управляет моя группа (путем установки некоторых специальных файлов cookie) , Этот процесс единого входа полностью прозрачен для конечного пользователя и отлично работает в течение нескольких лет во всех браузерах.

Недавно я заметил, что он не работает должным образом на моей машине с IE8. Недавно я обновил Windows Vista до Windows 7. Однако я не уверен, что это не работало на моей машине до или после обновления, так как это работало так долго, и у меня нет причин регулярно проверять его. FireFox 3.5 и Chrome 4 dev на этой же машине работают как положено. IE6 на XP SP3 virtual на этой машине работает нормально. IE8 на нескольких компьютерах дома работает нормально (как Windows Server 2008, так и Windows 7).

В целях диагностики я удалил все кэшированные данные из моего dev IE8 (кеш WinInet), чтобы начать с чистого листа. Я запустил Fiddler, чтобы отследить процесс и определить, что не работает. То, что я нашел, было довольно интересно, и я не могу это объяснить.

После входа в систему на начальном сайте - назовем его ltpa.domain.com, cookie-файлы сеанса отправляются с сервера, как и ожидалось, с помощью заголовка Set-Cookie. Я проверяю, что домен правильно установлен в .domain.com и что путь /. Все последующие запросы от браузера после входа в систему отправляют все куки обратно на сервер с каждым запросом, как и ожидалось. Фактически, это портал, и есть некоторый дополнительный контент, скажем, portal.domain.com, который также извлекается; все куки также правильно передаются на этот сервер.

Теперь интересный момент - когда я делаю запрос к myserver.domain.com, куки-файлы уровня домена, установленные ltpa.domain.com, не передаются на myserver.domain.com, даже если они должны быть. Процесс единого входа автоматически перенаправляет обратно на ltpa.domain.com, если файлы cookie отсутствуют (и передает файл cookie клиенту, который процесс входа в систему ltpa использует для перенаправления) - файл cookie уровня домена установленный myserver не переносится обратно на ltpa.domain.com.

Опять же, это только происходит в этом единственном экземпляре IE8 на моем компьютере разработчика, о котором я знаю. Этот процесс используется тысячи раз в день с довольно большой базой пользователей, и мы не получили никаких других жалоб от конечных пользователей - поэтому нет никаких признаков того, что это системная проблема с IE8 или чем-то подобным.

Мне кажется, что myserver.domain.com и ltpa.domain.com рассматриваются как отдельные домены, хотя это не так.

Есть две интересные вещи, о которых стоит упомянуть - но это могут быть красные селедки, как это всегда было и никогда не вызывало проблем.

  • DNS здесь немного прикольный. LTPA.domain.com разрешает внешний IP. Однако myserver.domain.com разрешает внутренний IP-адрес. Выполнение обратного поиска по этому IP дает внутреннее имя DNS - скажем, myserver.internal.domain.com. Я предположил, что, возможно, IE8 делал какой-то обратный поиск для предотвращения атак на основе DNS - поэтому я изменил свой файл HOSTS и указал myserver.domain.com на внешний IP для целей тестирования. Я проверил в Fiddler, что запросы поступают на внешний IP-адрес, но это не имеет значения для файлов cookie. Они еще не прошли.

  • Ранее myserver.domain.com находился в разделе «Надежные сайты» на страницах настройки безопасности IE WinInet. Я удалил его и еще один сайт, который был там. Давайте назовем эту машину my2.domain.com; эта машина по совпадению (или, может быть, нет?) также не передает файлы cookie домена, установленные ltpa.domain.com. В этом случае мне не нужно передавать куки, но я все равно проверил их, чтобы увидеть, не влияла ли эта проблема на другие машины. В строке состояния IE ltpa.domain.com, portal.domain.com и myserver.domain.com отображаются в зоне «Интернет». Что странно в том, что my2.domain.com по-прежнему показывает «Надежные сайты» в строке состояния, даже если это не указано в диалоговом окне ?? Да, я перезагрузился после внесения изменений.

Другие заметки.

  • Мне известны другие проблемы с доменами IE и не .com, цитируемыми значениями файлов cookie и другими аномалиями файлов cookie, о которых упоминалось здесь в stackoverflow и в других разделах Interwebs. Ни один из них не применяется. Я прочитал статью IEInternals Эрика Лоу о внутренних файлах cookie - http://blogs.msdn.com/ieinternals/archive/2009/08/20/WinINET-IE-Cookie-Internals-FAQ.aspx

  • В IE не включены веселые надстройки. Просто Flash, Silverlight, помощник входа в Live ID и Fiddler2.

  • Нет правил InPrivate для фильтрации содержимого, относящегося к моему домену.

  • Поскольку я на ноутбуке, я попробовал IE8 из моей домашней сети (после перезагрузки), чтобы исключить проблемы с DNS. У меня такое же поведение дома, поэтому, насколько я могу судить, фанк DNS не проблема.

  • Я несколько раз просматривал все настройки IE, думая, что мог пропустить неясные настройки cookie. Настройки конфиденциальности указаны на «Medium», и нет сайтов с особой обработкой.

  • С помощью инструментов разработчика я убедился, что опция «Всегда обновлять с сервера» снята.

  • Не думаю, что я могу сообщить об этом в Microsoft, поскольку не могу воспроизвести проблему где-либо еще.

Так что на данный момент я в растерянности. Если не считать какого-либо диагностического режима в IE8, о котором я не знаю, или наличия кода для его отладки ... У меня закончились хорошие идеи.

Я думаю, что я либо столкнулся с ошибкой, некоторые настройки реестра или что-то подобное были подправлены, либо что-то где-то испортилось.

Есть идеи?

Ответы [ 2 ]

3 голосов
/ 12 ноября 2009

Я думаю, что я разыскал проблему здесь.

Это должно быть ошибкой в ​​IE. Ну, на самом деле, два, если мы расщепляем волосы.

Несмотря на то, что я удалил myserver.domain.com и my2.domain.com из списка сайтов Trusted Sites в диалоговом окне безопасности IE довольно рано, оба сайта остались в конфигурации зоны в реестре! Мне удалось выяснить это путем поиска в реестре имен моих серверов и вуаля, небольшая детективная работа оказалась плодотворной.

Под подразделом есть HKEY_LOCAL_MACHINE \ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ \ Microsoft \ Windows \ CurrentVersion \ Настройки Интернета \ ZoneMap \ Domains

для domain.com

И под domain.com осталось два подключа для двух разных серверов, которые я удалил из диалогового окна списка «Надежные узлы» - оба с REG_DWORD для значения *, установленного на 2. Это, конечно, означает, что сайт переходит в Trusted Сайты.

Мне удалось откопать старую статью «Сценарист», в которой обсуждались именно этот ключ и доступные значения для изменения зон. http://blogs.technet.com/heyscriptingguy/archive/2005/05/02/how-can-i-add-a-site-to-internet-explorer-s-restricted-sites-zone.aspx

Возможно, эти настройки в пользовательском интерфейсе устарели, но все еще читаются / используются? Я не знаю, но ясно, что есть несоответствие ч / б, что показано в пользовательском интерфейсе и что фактически используется.

Кроме того, как упоминалось в предыдущем комментарии, при попадании в корень myserver.domain.com (что привело к получению 403 от сервера между прочим), строка состояния показала «Интернет | Защищенный режим: Выкл., Который только добавляет путаницы, поскольку должен читаться как «Надежные сайты | Защищенный режим: Выкл.

Таким образом, решение оказалось либо

a - удалить указанные выше ключи reg, чтобы все переместилось в зону интернета ИЛИ ЖЕ b - добавить * .domain.com в список доверенных сайтов, чтобы все перемещалось в зону Интернета

Надеюсь, вы сможете подать эти проблемы в команду IE, Эрик?

Спасибо, что направили меня в правильном направлении!

1 голос
/ 11 ноября 2009

Вы должны быть очень осторожны со словом «домен», так как многие люди используют его для обозначения множества разных вещей.

http://blogs.msdn.com/ieinternals/archive/2009/09/19/Private-Domain-Names-and-Public-Suffixes-in-Internet-Explorer.aspx

Из описания очень похоже на то, что вы столкнулись с проблемой № 3 в разделе «Устранение неполадок при входе в систему», описанном в этом посте: http://blogs.msdn.com/ieinternals/archive/2009/09/11/Troubleshooting-Stored-Login-Problems-in-IE.aspx

Вам необходимо решить проблему с зоной / уровнем целостности, чтобы решить проблему с cookie.

...