2011-01-14 1 views
9

Если вы открываете веб-страницу на одном из сайтов, размещенных на нашем сервере, оставьте его на 20 минут, а затем отправьте форму, возникает ошибка Validation of viewstate MAC failed..Проверка MAC-адреса viewstate не удалась, если на странице за 20 минут

Какие возможные причины могут быть для этого?

ответ

10

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

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

Кажется, что Plesk устанавливает время ожидания на 5 минут в пулах приложений, что и вызывало эту ошибку.

Чтобы изменить это сделать следующее:

  1. Открыть IIS
  2. Нажмите на пулах приложений узла
  3. Расположить пула приложений вашего веб-приложения
  4. правой кнопкой мыши и выберите пункт Настройки Advanace
  5. Set значение «Время ожидания» (минуты) до 0 или увеличить его до 30 минут
+1

Рад, что вы получили эту работу, я никогда не думал о тайм-ауте простоя и предполагал, что это была бы разумная ценность. Во всяком случае, я получаю вознаграждение за усилия? :) – Kev

+0

Ха-ха, конечно, спасибо за вашу помощь! – Curt

+0

Хммм вы можете попробовать отредактировать свой ответ, пожалуйста? Он заявляет, что заперт до его редактирования, тогда я могу проголосовать: S – Curt

11

Там несколько причин, это может произойти:

Авто-Произведенные машины Ключей:

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

Чтобы преодолеть этот набор этих клавиш с фиксированными значениями в:

`c:\%systemroot%\microsoft.net\framework\v2.0.50727\CONFIG\machine.config` 

Вам нужно добавить элемент <machineKey> конфигурации в разделе <system.web>. Там очень хорошая статья здесь, которая объясняет, как это сделать:

How To: Configure MachineKey in ASP.NET 2.0

Прокрутка вниз к разделу «Web Farm Deployment Considerations» и Генерировать криптографически случайные ключи.

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

Неверное значение формы action (3.5SP1):

Там также случай (после 3.5SP1), где, если вы установите атрибут вашей формы ASP.NET action нечто иное, чем страница быть вывешены назад и вы не используете postbacks перекрестных ссылок, тогда вы получите эту ошибку. Но вы видите это сразу:

Validation of viewstate MAC failed after installing .NET 3.5 SP1

Timing/Long Running Страницы:

Там также крайний случай для страниц, которые занимают много времени, чтобы вынести где, если страница частично вынесено и постбэк:

Validation of viewstate MAC failed error

Причина корня Это исключение появляется из-за того, что элементы управления, использующие DataKeyNames , требуют шифрования ViewState. Когда VIEWSTATE шифруются (По умолчанию режима, Авто, для шифрования, если контроль требует, чтобы в противном случае нет), Page добавляет поля как раз перед закрытием в тега.Но это скрытое поле , возможно, не было отображено в браузере с длинными страницами и , если вы сделаете обратную ссылку перед его выполнением, браузер инициирует обратную связь без это поле (в форме post collection). Конечный результат заключается в том, что если это поле , опущено на обратной стороне, страница не знает, что Viewstate зашифрована и вызывает вышеупомянутое исключение. I.E. страница будет полностью загружена , прежде чем вы сделаете обратную передачу.

+0

Привет, Kev, спасибо за ваш ответ indepth. Однако мы уже вручную указали машинные ключи. Я не верю, что значение «действие» для нас является проблемой, поскольку мы не объясняем это, и мы также сталкиваемся с этой проблемой в ASP.NET 2.0. Кроме того, поскольку мы не выполняем форму в течение 20 + минут, я не считаю, что страница, не имеющая достаточного времени для загрузки, имеет значение. Приветствия. – Curt

+0

Можете ли вы подумать о любой другой возможной причине, почему это может быть? Ваша помощь очень ценится, поскольку мы изо всех сил пытаемся решить это! – Curt

+0

@ Курт - хм, это головной скребок. Вы видите что-нибудь интересное в журналах событий в то время, когда он происходит? – Kev

0

Не удалось выполнить проверку MAC-адреса viewstate. Если это приложение размещено веб-фермой или кластером, убедитесь, что в конфигурации указан тот же алгоритм validationKey и validation. AutoGenerate не может использоваться в кластере Как я узнал, в заголовке моей главной страницы был добавлен тег <base .... , который я добавил в последнем галстуке и перед публикацией. Этот тег указывает URL-адрес по умолчанию и цель по умолчанию для всех ссылок на странице. На этот раз это была главная причина вины.

2

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

Я считаю это довольно суровым, так как это сценарий, с которым может столкнуться приложение, и такая основная ошибка мешает вам правильно обрабатывать его. Насколько я понял, это связано с тем, что по умолчанию для обработки этих ключей используется machine.config, в котором указано, что ключи автоматически генерируются и изолируются для каждого приложения. Я думаю, что в этом случае ASP.Net является временным ключом и сохраняет его на уровне рабочего процесса, а когда этот рабочий процесс ушел, проблема возникает и не может быть обработана.

Альтернатива конфигурации машинного ключа решает проблему, очевидно, лучше установить ее на файл web.config, а не весь machine.config, чтобы сохранить его на самом низком уровне детализации.

Другой вариант - отключить проверку состояния состояния просмотра, также через web.config. Это будет зависеть от уровня безопасности вашего приложения и от риска вмешательства в состояние просмотра.

И лучший вариант - избегать использования состояния представления с помощью приложения MVC.

+2

Я верю, что вы забыли ссылку на '* этот пост *' ... – LSerni

+0

Я с энтузиазмом повторю предложение лучшего варианта Диего. :-) Я ненавижу длинные автогенерированные идентификаторы HTML-элементов на странице веб-форм ASP.Net. Я обнаружил, что у JQuery datatables есть проблемы, когда идентификатор элемента HTML получает больше 50 символов. С webforms для меня не редкость иметь идентификаторы HTML-элементов с более чем 70 символами, особенно если я в конечном итоге использую вложенные репитеры и страницы управления ascx. – Bryan

Смежные вопросы