Почему мой единый вход в ASP.NET перестал работать? - PullRequest
Новая
       9

Почему мой единый вход в ASP.NET перестал работать?

4 голосов
/ 07 февраля 2011

У меня есть веб-приложение .NET 2.0, которое действует как заглушка аутентификации для более старого веб-приложения .NET 1.1. Таким образом, пользователь входит в систему через приложение 2.2, а затем перенаправляется в приложение 1.1, чтобы заняться своими делами. Я использовал технику , описанную Скоттом Гатри , с соответствующими машинными ключами в локальных файлах web.config, чтобы билет аутентификации мог быть прочитан обоими приложениями. Эта техника работала для меня в пяти случаях в течение нескольких лет.

До сих пор.

По состоянию на это утро четыре из наших сопряженных приложений, настроенных, как описано выше, перестали работать в рабочей среде: мы получаем отскок после (казалось бы) успешной попытки аутентификации. Во время попытки входа я возвращаюсь на страницу входа. Я проверил журналы событий и журналы IIS и не нашел никаких последствий. Мы видим, что cookie-файл auth установлен в наших браузерах. Мы пробовали несколько браузеров (IE и Chrome). В выходные я знаю, что на веб-сервере было установлено более десятка патчей, в одном из которых была добавлена ​​Framework 4.0, но я не знаю, вызвало ли какое-либо из этих патчей проблему. Интересно, что перед Рождеством я заметил то же поведение на своем устройстве для разработчиков. С тех пор ни одно из четырех сопряженных приложений не было повторно развернуто, поэтому не думайте, что это была проблема развертывания, которая привела к его распространению в производство.

Существует одна пара приложений, которая все еще работает, и мы сравниваем код и конфигурацию, чтобы увидеть, что случилось, но пока мы ничего не нашли (иначе я бы не стал пишу этот пост!)

UPDATE Я понял, что эта одинокая пара приложений делает правильно: она обрабатывает авторизацию через код . Поэтому я разработал обходной путь для моих больных приложений:

ОРИГИНАЛ: 

<authorization>
    <allow deny="?" /> 
</authorization>

Временное решение: 

<authorization>
    <allow users="*" /> 
</authorization>

Затем я добавил код на свою базовую страницу ASPX для проверки подлинности cookie: 

if (Request.Cookies.Get(FormsAuthentication.FormsCookieName) == null)
    Response.Redirect(System.Configuration.ConfigurationSettings.AppSettings["MembershipLoginURL"],true);

Кажется, мой код выполняет роль, которую раньше выполняла ASP.NET, а именно проверка того, авторизован ли пользователь. Итак - у меня есть обходной путь, но загадка остается.

Кто-нибудь знает, был ли патч от Microsoft, выпущенный за последние четыре месяца (наш сервер был только что обновлен за четыре месяца патчей), который отключил возможность ASP.NET аутентифицировать / дешифровать куки-файлы между веб-приложениями на версии .NET?

Ответы [ 2 ]

2 голосов
/ 08 февраля 2011

Я получил ответ от Скотта Гатри ... проблема, с которой я столкнулся, была вызвана обновлением Windows.

Вот исправление: ИСПРАВЛЕНИЕ: Проблема совместимости файлов cookie проверки подлинности форм между приложениями ASP.NET .NET Framework 1.1 и .NET Framework 2.0 с пакетом обновления 2 (SP2) после установки обновления безопасности из бюллетеня по безопасности MS10-070

Я установил это исправление на своем локальном компьютере с XP SP3, а также на подготовительных и производственных компьютерах под управлением Windows 2003, и это определенно устранило проблему.

1 голос
/ 07 февраля 2011

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

У меня есть порядок операций для этих вещей,Когда вы видите проблему, устраните ее.Если вы не можете отладить его, используйте его (поместите код в этот журнал, что происходит внутри приложения).Если вы не можете это использовать, то попробуйте.

Если вы еще не используете инструмент сравнения, я настоятельно рекомендую использовать его.Мне нравится Beyond Compare от Scooter Software, но есть много других хороших.Установите его на свой сервер и запустите diff между рабочим и нерабочим конфигами.Это может сказать вам ответ прямо здесь.

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

...