Подтвердить что ты не робот

Asp.net формирует аутентификацию cookie, не соблюдая тайм-аут с IIS7

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

Решение проблемы так же просто, как добавить раздел конфигурации <machineKey> в web.config или, возможно, (желательно?) на machine.config на сервере (непроверенный):

<system.web>
  ...
  <machineKey 
    validationKey="..."
    decryptionKey="..."
    validation="SHA1"
    decryption="AES"/>
  ...
</system.web>

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

Ответ 2

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

Ответ 3

Установить состояние сеанса, настроенное в IIS как В процессе Использовать файлы cookie Время ожидания = необходимое время Использовать идентификатор хостинга для олицетворения

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

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

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

Ответ 4

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

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

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

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

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

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

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

Ответ 5

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