Обновление с .NET 3.0 до 3.5:Сайты, настроенные на сервер состояний, возвращаются к InProc при работе в Web Garden

Question

Сценарий:

Возьмем сервер под управлением .NET 3.0 и ASP.NET Веб-сайт, работающий в пуле приложений, в котором включены Web gardens (количество процессов:3).Конфигурация web.config выглядит следующим образом:

    <sessionState
      cookieless="UseCookies"
      cookieName=".authz"
      mode="StateServer"
      regenerateExpiredSessionId="true"
      stateConnectionString="tcpip=127.0.0.1:42424"
      timeout="60"
      useHostingIdentity="true" />

Теперь обновите компьютер до версии .NET 3.5 SP1.Перезагрузите сервер.Результат:сеансы больше не поддерживаются между экземплярами w3wp.exe, как будто все они вернулись к InProc.Сокращение до 1 рабочего процесса является текущим обходным решением.

Что здесь странного:Один и тот же код на разных серверах не вызывает никаких проблем.Я сталкивался с этой проблемой раньше, но она волшебным образом исчезла после перезагрузки.Я уже один раз перезапускался, но пока никакой радости.

Сравнение двух machine.configs и web.configs двух серверов:идентичные.

Кто-то другой столкнулся с этой проблемой, но ответа там нет.

Есть какие-нибудь идеи?I'm действительно зашел в тупик по этому поводу.

Answer 1

Итак, этот был просто потрясающим.

Проблема, по-видимому, возникает, когда выполняются все следующие условия:

• Вы используете Windows Server 2003 (IIS 6.0) и веб-сайт ASP.NET 2.0.
• Веб-сайт настроен на использование веб-садов, где максимальное количество рабочих процессов больше 1.Из-за этого вы настроили свое приложение на использование хранилища сеансов вне процесса;в этом сценарии ASP.NET Государственная служба, запущенная на локальном компьютере.
• Идентификатор пула приложений устанавливается не на СЕТЕВУЮ СЛУЖБУ, а на пользовательскую учетную запись пользователя с низкими привилегиями, созданную вами для наилучшая практика развертывания.
• Вы запускаете программу установки, которая обновляет .NET framework;в моем случае это было обновление с .NET 3.0 до .NET 3.5 SP1.

Когда обновление завершается и вы перезагружаете сервер, вы обнаруживаете, что ваши переменные сеанса часто теряются при обновлении страницы, поскольку существует только 1 шанс из 3, что вы получите исходный рабочий процесс, который обслуживал ваш первоначальный запрос.Но это не должно иметь значения, поскольку вы используете ASP.NET государственную службу.Что сломалось?

При использовании ASP.NET государственной службы ASP.NET используется значение, называемое machineKey зашифровать и / или хэшировать все данные сеанса, которые будут сохранены (я не знаю, шифруется ли это или хэшируется, или и то, и другое, но это не важное различие для данного обсуждения).Это делается для того, чтобы, когда какой-либо рабочий процесс запрашивает данные у службы, используя идентификатор сеанса, он мог быть уверен, что данные не были изменены во время их хранения во внешнем источнике данных.

Если вы находитесь на веб-ферме, то у вас, вероятно, есть статический machineKey определенный в вашем web.config файл, и эта проблема не возникает.Но для сценария веб-сада с одним сервером вы, вероятно, полагаетесь на значение по умолчанию machineKey настройка, которая установлена на AutoGenerate,IsolateApps для ASP.NET приложений 2.0.Это означает, что ASP.NET автоматически генерирует машинный ключ, уникальный для вашего пула приложений.Он восстанавливает этот ключ в соответствии с некоторым алгоритмом, но это не важно для данного обсуждения.

Сгенерированное значение обычно сохраняется в реестре в разделе HKLM\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0\AutoGenKeys\{SID of the Application Pool Identity}.Но установщик .NET Framework неправильно (я действительно считаю, что это ошибка) уничтожает этот раздел реестра и, в довершение ко всему, сбрасывает разрешения для этого ключа, так что ваш пользовательский идентификатор пула приложений не может выполнять запись в запись реестра, когда он переходит к созданию своего нового машинного ключа.

В результате каждый рабочий процесс, запускаемый в web garden, использует свою собственную копию машинного ключа в памяти, которую он сгенерировал как раз вовремя, фактически случайно создавая сценарий веб-фермы.Например, рабочий процесс A запускается, видит, что нет AutoGenKey запись существует (действительно, она даже не может Читать него), создает свои собственные и начинает использовать это в хэш-данные, передаваемые на государственной службе ASP.NET .Он пытается сохранить этот новый машинный ключ в записи реестра, но без сбоев.Рабочий процесс B запускается, видит, что нет AutoGenKey запись существует, генерирует свою собственную и начинает использовать это для хэширования данных ... Вы видите, к чему это ведет.

В результате теперь у вас есть данные сеанса, хэшированные с помощью трех разных машинных ключей.Хотя данные для идентификатора сеанса существуют, два из трех рабочих процессов отклонят их как недопустимые / подделанные, поскольку они используют свой собственный ключ.

Вы могли бы обойти это, явно установив пользовательский machineKey в вашем web.config файл.

Или вы могли бы повторно запустить aspnet_regiis.exe -ga MachineName\ApplicationPoolUserName в командной строке, чтобы исправить нарушенные разрешения.

Ваша проблема решена.Пора ложиться спать.

---

ОБНОВЛЕНИЕ от 30 июня: Согласно моему отчету по этому вопросу о Microsoft Connect ( Microsoft Connect ), Microsoft указала, что они исправили установщик таким образом, что это поведение не будет происходить, начиная с обновлений до .NET 4.Это все еще может произойти для всех будущих обновлений 3.0 / 3.5, поэтому я оставлю этот вопрос / ответ в силе.