Не удалось выполнить проверку MAC-адреса viewstate, но встречается только на одном из 2 серверов webfarm (правильный ключ машины)

Question

Итак, у меня есть что-то странное, и я не могу точно определить, что именно вызывает его. Мой asp.net проект жить с состоянием сеанса на двух производственных серверах, которые синхронизируются с помощью следующей команды:

msdeploy -verb:sync -source:webserver,computername=%MACHINE%,username=Administrator,password=%PASSWORD% -dest:webserver 2<&1 

приложение является asp.net 4.0 веб-сайт, который работает на двух Server 2008 R2 веб-серверы за балансировка нагрузки, когда пользователи настроены на один сервер после их подключения. У нас есть <MachineKey> набор жестко закодирован с ключами проверки и дешифрования в корневом сайте приложения и между обоими серверами одинаковый. Мое приложение настроено на пересылку событий исключения в нашу систему электронной почты.

Что происходит, так это то, что я получаю страшную «проверку MAC-адреса представлений» с серверов, но даже несмотря на то, что нагрузка на сервер составляет 50/50, ошибки вступают в разделение 99/1. Таким образом, один веб-сервер генерирует эти ошибки значительно чаще, чем другие. Это странно, учитывая, что серверы синхронизированы, и все конфигурации идентичны.

Я проделал обширный поиск по этой проблеме, и кажется довольно сложным найти какое-либо решение, которое не упоминает или не делает следующее.

• <MachineKey> не идентичен между серверами. (Я знаю, что это не моя проблема)
• Настройка enableViewStateMac=false или некоторые другие настройки, которые ставят под угрозу безопасность сайта.
• Убедитесь, что все теги действий по форме входов ссылки на той же странице, они размещены на
• Убедитесь, что идентификатор экземпляра серверов одинаковы (они)
• Если пользователь щелкает через страницы перед была загружена целая страница (viewstate) (мое viewstate настроено для рендеринга в верхней части страницы).
• Проблемы с Response.Redirect и Server.Transfer

Теперь я устранил все, кроме двух последних в качестве возможных причин. Мое приложение работает отлично уже более года без каких-либо проблем, и прямо перед появлением этих ошибок я включил состояние сеанса SQL, перенесил проект с .NET 3.5 на .NET 4.0 и установил для режима развертывания режима сервера в розницу. Я попытался переработать пулы приложений и выполнить «сброс iis» безрезультатно.

Есть ли у кого-нибудь еще какие-либо предложения относительно того, на что я могу смотреть? Итог i do NOT хочу исправить это, открыв отверстия безопасности на моем сайте.

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

Здесь сочные немного из моего web.config (я удалил некоторую конфиденциальную информацию)

<system.web> 
    <httpRuntime requestValidationMode="2.0"/> 
    <globalization culture="en-US" uiCulture="en-US" resourceProviderFactoryType="WebResourceFactory"/> 
    <compilation debug="true" defaultLanguage="c#" explicit="true" strict="true" targetFramework="4.0"> 
     <assemblies> 
     </assemblies> 
    </compilation> 
    <authentication mode="Forms"> 
     <forms name=".ASPXAUTH" loginUrl="Login.aspx" protection="All" slidingExpiration="true"/> 
    </authentication> 
    <authorization> 
     <deny users="?"/> 
    </authorization> 
    <sessionState mode="SQLServer" sqlConnectionString="connection" compressionEnabled="true" /> 
    <pages theme="Blue" controlRenderingCompatibilityVersion="3.5" clientIDMode="AutoID"> 
<machineKey validationKey="key" decryptionKey="key" decryption="3DES" validation="SHA1" /> 
    </system.web> 

EDIT: Подчеркнут, что я использую состояние SQL сеанса с балансировкой нагрузки, установленной предпочитать пользователь маршрута к серверу, на котором они начали.

Answer 1

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

1: Установленные эти окна обновления:

2: Моя аутентификация формы печенья была установлена ​​настойчив, но мой куки сессии был установлен на сессии браузера. Я установил свои файлы cookie для проверки подлинности на основе браузера.

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

4: Перезагрузка сервера.

Вот и все! С тех пор я не получил ошибок.

Answer 2

Существует дополнительная возможность, что вы не указали в вашем списке - ViewStateUserKey.

Я видел проблемы с приложениями, где ViewStateUserKey был установлен на идентификатор сеанса при входе в систему и (в решающей степени) до того, как любые данные будут сохранены в сеансе. Поскольку ASP.NET не сохраняет идентификаторы сеанса до тех пор, пока один или несколько объектов не будут сохранены в сеансе, это означает, что идентификатор постоянно менялся, а ViewState не выполнял проверку. Даже если вы сохранили что-то в сеансе, сеанс будет отличаться на каждом сервере, если вы используете стандартную модель процесса, а не хранилище состояний или хранилище сеансов SQL (как вы это делаете). Разумеется, любое заданное значение или значение сервера, которое невозможно прогнозировать на серверах, используемых вместе с ViewStateUserKey, также вызывает эту проблему.

В противном случае наиболее распространенными причинами этой проблемы я видел, где атрибут «Действие» установлен в форме, которая равна , а не URL-адрес той же страницы, что и форма (это позволяет разработчикам использовать PHP или платформы, которые не пытаются абстрагироваться от HTTP) или отсутствуют атрибуты машинного ключа в Web.config в многосерверных средах (которые вы, похоже, рассмотрели).