Сбой проверки состояния просмотра в веб-ферме - обычные подозреваемые устранены

Я думаю, что испробовал все стандартные ответы на эту проблему, и я знаю, что прочитал сотни вопросов и сообщений об этой проблеме, но ни один из них не решил ее и не пролил свет на причину есть в моем сценарии. (Я пропал на 5 часов и не ближе :-()

  • У меня есть веб-ферма из 2 серверов.

  • Я установил ключ машины и ключ проверки в machine.config на обеих машинах.

  • Шифрование: SHA1, дешифрование: AES — это значения по умолчанию, может помочь их изменить?

  • Я проверил, что никакие другие файлы конфигурации в цепочке (web.cfg, apphost и т. д.) не имеют настройки для этих значений.

  • Я добавил страницу на сайт (на основе этого SO), который возвращает значения ключа компьютера обратно и проверяет, что они одинаковы для запросов к обеим компьютерам и соответствуют значениям, указанным в файле .config компьютера.

  • Состояние сеанса на стороне сервера находится на общем сервере состояний, я проверил, что идентификатор сеанса остается постоянным между запросами к 2 серверам.

  • Я убедился, что страница полностью загружена, а скрытое поле __EVENTVALIDATION было отображено на странице до начала публикации. Размер состояния просмотра не так уж и плох — 7,64 КБ.

Когда страница обрабатывается из запроса на сервер 1, а затем отправляется обратно на сервер 2, я получаю ужасное...

Error Message:

Unable to validate data.
at System.Web.Configuration.MachineKeySection.GetDecodedData(Byte[] buf, Byte[] modifier,   Int32 start, Int32 length, Int32& dataLength)
at System.Web.UI.ObjectStateFormatter.Deserialize(String inputString)   HttpApplication.RecordError => HttpApplication.RaiseOnError => global_asax.Application_Error

Пост запускается стандартной, настоящей кнопкой ссылки asp, на странице нет ajax.

Любая помощь будет принята с благодарностью.

Установка enableViewStateMAC = false не является решением :-)


asp.net machinekey viewstate
person RobD    schedule 08.04.2013    source источник

Ответы (3)


arrow_upward
2
arrow_downward

Получив в наследство серверы в том состоянии, в котором они были настроены, я ни разу не усомнился в валидности ключей!!! ...Только что проверил, что они совпадают на обоих серверах...

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

Проблема решена

Мораль истории: если сомневаетесь, сгенерируйте новые ключи

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

person RobD    schedule 09.04.2013

arrow_upward
1
arrow_downward

Если вы установили, что машинные ключи одинаковы на обоих ящиках, может ли это быть их шифрование/дешифрование?

Пробовали ли вы использовать Triple DES и установить ключ расшифровки в файле machine.config на обоих серверах?

Проверьте здесь

person Adam Hey    schedule 09.04.2013

arrow_upward
1
arrow_downward

Также простой способ убедиться, что ключи машин одинаковы, — добавить такую ​​строку в файл web.config.

NB: Предполагая, что у вас один и тот же файл web.config на обоих серверах, и убедитесь, что validationKey и decryptionKey действительны.

Вы можете использовать http://aspnetresources.com/tools/machineKey для его создания.

<system.web>
  <machineKey validationKey="*D9B0EDEA69D81A89BF5FBA2B08BAF691013F86B89A1F6BA8068C6ECC9539074" decryptionKey="*AE2B1966AF65D08F03EDFB" validation="SHA1" decryption="AES" />
person Johan    schedule 09.04.2013