Почему IE не позволяет пользователям входить на веб-сайт, если он не находится в режиме «Приват»?

Question

Я не совсем уверен, что это принадлежит SuperUser.com. Я также рассматривал ServerFault.com и StackOverflow.com, но в целом, я думаю, что он должен принадлежать здесь?

Мы размещаем веб-сайт с одинаковым кодом, отвечающим на несколько доменных имен. 28 декабря (без каких-либо изменений, развернутых на веб-сайте) процент пользователей неожиданно не смог войти в систему, и пустая страница входа в систему была снова отображена, даже когда были введены правильные учетные данные. Проблема все еще продолжается.

После удаленного управления ПК пострадавшего пользователя мы обнаружили следующее:

• Эта проблема затрагивает Internet Explorer 9.
• Пользователь может войти в систему с того же компьютера в Chrome.
• Пользователь может войти в сеанс браузера In Private, используя IE9.
• Пользователь может войти в систему, если веб-сайт добавлен в зону безопасности «Надежные сайты».
• Пользователь НЕ может войти в систему из сеанса IE в безопасном режиме (начался с iexplore -extoff).
• Только одно имя хоста, на которое отвечает веб-сайт, предотвращает вход в систему, эта же учетная запись пользователя на другом имени хоста работает нормально (обратите внимание, что это идентичный код и база данных работает на стороне сервера), даже если этот сайт не находится в зоне доверенных сайтов.

Серия HTTP-запросов в случае сбоя:

1. GET запрос на защищенную страницу, возвращает ответ 302 FOUND на страницу входа.
2. ПОЛУЧИТЬ запрос на страницу входа.
3. POST для входа на страницу, содержащую учетные данные, возвращает перенаправление на защищенную страницу.
4. GET запрос к защищенной странице ... по какой-то причине аутентификация не удалась, и браузер перенаправлен на страницу входа, как в шаге 1.

Дополнительная информация:

• Операционная система - Windows 7 Ultimate Edition.
• AV система AVG Internet Security 2012.

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

Любые идеи, что вызывает ошибку входа в систему?

Обновление 06 января 2012

Расширенное ведение журнала показало, что .ASPXAUTH cookie устанавливается в шаге 3. Срок его действия истекает через 28 дней, его путь - / , домен - mysite.com , а его значением является билет в зашифрованном виде, как и ожидалось.

Однако файл cookie не принимается веб-сервером на шаге 4. Другие куки-файлы представляются серверу на шаге 4, но только этого не хватает.

Я видел, что куки обычно устанавливаются с доменом, начинающимся с точки, но мои нет. Должно ли это быть .mysite.com вместо mysite.com? Однако, если бы это было неправильно, это предположительно затронуло бы всех пользователей?

Answer 1

Мой анализ в моем обновлении о том, что куки не возвращаются на сервер, был неверным. В какой-то момент перед тем, как мой код регистрации запустился, cookie удалялся со стороны сервера сбора cookie.

Используя Wireshark, я определил, что на самом деле две копии .ASPXAUTH cookie отправлялись на сервер, один был недействительным, а другой действительным. Технически, порядок файлов cookie недетерминирован, поэтому я думаю, что это повлияло на людей, чьи браузеры сначала отправляли неверные файлы cookie ... ASP.NET просто не рассматривал второй, действительный файл cookie.

Как упомянуто выше, рассматриваемый файл cookie был .ASPXAUTH - имя по умолчанию для файла cookie аутентификации .NET. Мы полагаем, что две его копии существовали, поскольку, возможно, они были отправлены в другой домен в прошлом (один раз как www.mysite.com а в другое время - как .mysite.com).

Самым простым решением, которое работало идеально, было изменение имени файла cookie для аутентификации путем установки следующего в Web.config:

<authentication mode="Forms">
    <forms name="SOMEOTHERCOOKIENAME" />
</authentication>

Затем просто убедитесь, что новый файл cookie отправляется только с одним значением, которое будет соответствовать данному запросу!

Answer 2

У меня было что-то очень похожее, cookie для аутентификации ASP.NET не устанавливался в IE или Chrome, как это ни странно, хотя это было в Firefox (я до сих пор не могу объяснить, почему это так).

Что оказалось для меня проблемой, так это то, что серверное время было неправильным, прошло 30 минут. Поэтому в 9:50, когда я вошел на сайт, сервер установил время истечения срока действия cookie на 10:10, но на моем компьютере было время 10:20, поэтому срок действия cookie уже истек. Обновление времени на сервере решило проблему для меня

Answer 3

Любые идеи, что вызывает ошибку входа в систему?

Печенье.

• Приватный режим, вероятно, имеет отдельный набор файлов cookie (иначе он вряд ли будет приватным)
• Разные браузеры имеют отдельные куки
• Файлы cookie обычно относятся к доменному имени сайта.

Все это соответствует описанию вашей проблемы.

---

Обновить:

• Проверьте настройки cookie для соответствующей Зоны безопасности (Интернет, Локальный, Доверенный, Ограниченный).
  В IE8: Tools, Internet Options, Privacy, Sites
  Может быть, mysite.com заблокирован в соответствующей зоне?

• Проверьте ваши фактические куки
  В IE8: Tools, Internet Options, General, Browsing History, Settings, View Files
  Ищите cookie:username/mysite.com/

• Проверьте нестандартные настройки обработки файлов cookie
  Они могут блокировать сторонние куки (если это применимо)
  Возможно, вам будет предложено принять / отклонить новые файлы cookie.

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

Answer 4

В окне "Свойства обозревателя", "Общие", "История просмотра", "Настройки", вы можете изменить настройку «проверить новую версию ...» с "Автоматически" (3-й вариант) на «Каждый визит ...» (1-й вариант).

У меня была почти идентичная проблема, и этот обходной путь работал. Никогда не нашел в чем проблема ...

Также (но я не думаю, что это ваш случай), проверьте разницу часов между сервером и клиентом.