Asp.net файлы cookie проверки подлинности форм не соблюдают тайм-аут с IIS7

аутентификация cookies, кажется, тайм-аут после короткого периода времени (день или около того). Я использую проверку подлинности форм и имею тайм-аут= "10080"с slidingExpiration=" false " в интернете.конфиг. С этим параметром срок действия файла cookie должен истечь примерно через 7 дней после успешной аутентификации пользователя.

это работало так, как рекламировалось с IIS6, но когда я переместил сайт в IIS7, cookie истекает намного быстрее. Я подтвердил это поведение на нескольких машинах с IE и Firefox, заставляя меня поверить, что это настройка IIS7.

есть ли скрытая настройка, специфичная для IIS7, связанная с аутентификацией? Все остальные типы аутентификации отключены для веб-сайта, за исключением анонимного отслеживания пользователей.

5 ответов


файл cookie аутентификации зашифрован с помощью machineKey значение из местных web.config или глобальной machine.config. Если нет такого ключа -явно set, ключ будет автоматически сгенерирован, но он не сохраняется на диске – следовательно, он изменится всякий раз, когда приложение будет перезапущено или "переработано" из-за бездействия, и новый ключ будет создан при следующем ударе.

решение проблемы так же просто, как добавление


Я понимаю, что куки истекли потребляющей стороной-браузером, а это означает, что IIS не имеет права голоса в этом


задать состояние сеанса, настроенное в IIS как в процессе использовать cookies Time out = необходимое время Используйте идентификатор хостинга для олицетворения

также установите EnableSessionState в true (что тоже по умолчанию)

и самое главное запустить пул приложений в классическом режиме.

надеюсь, ваша проблема будет решена.


прежде всего я должен сказать, что эти "рекомендации" являются общими, а не исключительными для iis-7. В web.конфиг под <system.web> вы либо <sessionState mode="StateServer" stateConnectionString="tcpip=localhost:42424" timeout="130" cookieless="false"/> (что требует ASP.NET служба сервера состояния сеанса, работающая на localhost) или <sessionState mode="InProc" timeout="130" cookieless="false"/>. Основное отличие заключается в том, что в InProc данные о состоянии сеанса помещаются в сам процесс приложения. В другой настройке другая служба выполняет хранение, и приложение просто опрашивает ее, чтобы получить необходимые данные. Использовав оба (а также как режим состояния сеанса sql-server) InProc является наименее надежным, но самым быстрым. Sql-сервер является самым надежным и самым медленным, а режим StateServer находится где-то посередине и ненадежен только в случае сбоя питания/системы. Сказав это, я должен сказать, что для сайта с низким количеством запросов штраф за производительность незначителен.

Теперь мой опыт показал, что InProc совершенно непредсказуем по своей стабильности; у меня была такая же проблема с вами. Я смог расширить стабильность приложения, настроив настройки пула приложений, я полностью удалил проблему, переключившись на SessionState (что также позволяет сбить приложение и не потерять данные о состоянии сеанса).

причины, по которым вы можете пострадать от применения/стабильность сессии:

  1. IIS и пул приложений. Каждый каталог virtul веб-сайта назначается пулу приложений (по умолчанию " DefaultAppPool") который имеет ряд настроек, среди которых вы определяете интервал, который процесс "перерабатывается" - и как таковой сохраняет системные ресурсы. Если вы не измените настройки, приложение может вызвать один из критериев для процесса recycler, а это означает, что ваше приложение лопнул

  2. антивирус. В приложении ASP.NET если веб.config (и любой ребенок .конфигурационные файлы приложение зависит от) файл трогается приложение перезапускается. Теперь есть случаи, когда антивирусная программа может коснуться интернета.конфигурационный файл (скажем, раз в день?) и как таковое приложение перезапускается и данные сеанса теряются.

  3. плохая конфигурация В частности, для проверки подлинности форм параметры и поведение, связанные с временем, всегда зависят от веб-сеанса с сеансом аутентификации, находящимся под веб-сеансом.

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


недавно у меня была та же проблема, когда мой сайт тайм-аут каждые 20 минут, хотя я установил тайм-аут сеанса на 2 часа. Я обнаружил, что это было потому, что рабочий процесс IIS тайм-аут каждые 20 минут:http://technet.microsoft.com/en-us/library/cc783089 (WS.10).aspx