<machineKey decryptionKey = "AutoGenerate" ... игнорируется IIS. Не сделает недействительными файлы cookie предыдущей сессии - PullRequest
Новая
       31

<machineKey decryptionKey = "AutoGenerate" ... игнорируется IIS. Не сделает недействительными файлы cookie предыдущей сессии

8 голосов
/ 10 июля 2009

(см. Вопрос ниже для получения дополнительной информации):

Есть ли ситуации, в которых 

<machineKey
      validationKey="AutoGenerate,IsolateApps"
      decryptionKey="AutoGenerate,IsolateApps"/>

в web.config не удастся автоматически сгенерировать новый machineKey при перезапуске пула приложений? Это поведение, которое я вижу ...

Я использую стандартную ASP.NET FormsAuthentication в приложении MVC. Если я войду в систему с помощью FormsAuthentication.GetAuthCookie и не использую постоянный файл cookie (полагаясь на сеанс браузера, чтобы запомнить мое авторизованное состояние), я ожидаю, что переработка пула приложений IIS сделает недействительными знания сеанса об этом файле cookie ... и, таким образом, выйдите из системы всех пользователей, у которых нет постоянных файлов cookie.

Это происходит при одной из моих установок IIS (XP), но в другой конфигурации IIS (Server 2K3) файл cookie FormsAuthentication (под стандартным именем «.ASPXAUTH») остается действительным и продолжает авторизовать пользователя.

Кто-нибудь знает, почему это происходит или какая конфигурация контролирует это поведение?

Очевидно, что переработка пула приложений не контролирует, отправляет ли браузер cookie .ASPXAUTH или нет (пока я не закрыл свой браузер и срок действия cookie не истек).

В случае установки IIS, которая должным образом запрещает аутентификацию после перезагрузки, я вижу входящий файл cookie в Request.Cookies во время события Application_BeginRequest ... но как только элемент управления переходит к следующему событию, доступному в Global.asax.cs (Application_AuthenticateRequest), файл cookie был удален из коллекции Request.Cookies .

Почему этого не происходит для обеих конфигураций IIS / ASP.NET?

Если это не ясно, более простой способ сформулировать вопрос:

Почему HttpContext.Current.Request.Cookies[".ASPXAUTH"] изменяется от {System.Web.HttpCookie} до нуля, когда я выполняю шаг, в одном запросе, с Application_BeginRequest до Application_AuthenticateRequest?

Больше отладочной информации:

Если я присоединю следующий код к событию FormsAuthentication_OnAuthenticate Global.asax.cs ... 

var cookie = Request.Cookies[FormsAuthentication.FormsCookieName];
if (cookie != null)
{
    var val = cookie.Value;
    try
    {
        FormsAuthenticationTicket ticket = FormsAuthentication.Decrypt(val);
    }
    catch (Exception)
    {
    }
}

... затем во время запроса до Я перезапускаю пул приложений IIS, исключений не будет. После перезапуска пула приложений IIS, когда из браузера отправляется точно такой же файл cookie .ASPXAUTH, возникает криптографическое исключение («Заполнение недопустимо и не может быть удалено».)

Почему это?

Ответы [ 2 ]

3 голосов
/ 19 июня 2018

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

Модификатор AutoGenerate указывает, что ASP.NET генерирует случайный ключ и сохраняет его в локальном центре безопасности (LSA)

https://msdn.microsoft.com/en-us/library/w8h3skw9%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

«Локальный орган безопасности (LSA)» означает пользователя, назначенного для пула приложений, подробности см. Ниже, так как это оказалось проблемой.

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

  1. HKLM / ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ / Microsoft / Windows NT / CurrentVersion / ProfileList (для получения SID только что созданного пользователя; если пользователя нет, то это уже плохой признак)
  2. HKU / [UserSIDFromBefore] /Software/Microsoft/ASP.NET / ... (там должен храниться ключ машины)

Решение заключалось в том, чтобы один раз войти в систему под этим пользователем на компьютере (обычный экран входа в Windows), чтобы создать соответствующие разделы реестра. Хотя могут быть более быстрые или более тонкие способы создания разделов реестра.

0 голосов
/ 10 июля 2009

Файлы cookie проверки подлинности с помощью форм не имеют ничего общего с состоянием сеанса.

...