"Проверка MAC-адреса viewstate не удалась. Если это приложение размещено веб-сайтом..."

Я столкнулся с ужасным:

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

Ошибка.

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

Я положил

<pages enableEventValidation="false" enableViewStateMac="false" viewStateEncryptionMode="Never">

В моем web.config, чтобы остановить проблему, но это вряд ли похоже на исправление для меня.

Дело в том, что я никогда не использовал viewState в своем приложении. Я знаю, что asp.net по умолчанию использует viewstate для хранения некоторых вещей, но я сомневаюсь, что значения по умолчанию, хранящиеся здесь, будут вызывать ошибки.

Я заметил, что проблема возникает, когда я postBack и страница еще не закончила загрузку.

Спасибо

Изменить: Пожалуйста, может кто-то проверить мой сайт www.vittoriosaStarsNursery.com и посмотреть, не получилось ли вы, что я получил выше? Я не получаю его локально, но люди продолжают говорить мне, что они его получают.

Ответ 1

Разве это не случай размещения одного лайнера в вашем web.config

<machineKey decryptionKey="A4B12CCDD50E95F8GB9GFH6JKAT4Y0U0I2OF2DF2AAFE5AB46189C,IsolateApps" validation="AES" validationKey="480CDF2AS9S9AS5CFDGF0GHFH9JJH4KHKAKLJ2L9F3SAS82A6C16911A29EF48903783F94529C21570AACB72766FB38CD4CE7B85B0ACE3149DC5FC1CCF1AA1CECE3579659996593B06,IsolateApps"/>

Ответ 2

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

Я нашел это, посмотрев информацию о событии в журналах Eventviewer/Application и "Категория задачи", называемую "Веб-событие". Затем, на тот период времени, когда это событие произошло, я посмотрел, были ли какие-либо переработанные события, которые произошли непосредственно перед этим (журналы Eventviewer/System и "Source", называемые "WAS".

По умолчанию приложение будет перерабатывать каждые 1740 минут (29 часов). Если это повторение произошло, когда пользователь занят на сайте и отправил сообщение обратно на сервер, сервер больше не распознает сеанс/просмотр и не отклоняет то, что отправлено назад.

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

Надеюсь, что кто-то поможет там.

Ответ 3

Тебе не понравится мой ответ. Эта ошибка в основном неизбежна в веб-формах. Моим решением было оставить webforms для MVC3 и бритвы.

Я заметил, что проблема, похоже, происходит, когда я postBack и страница еще не закончила загрузку.

Это один из самых простых способов вызвать эту ошибку. В ASP.NET 3.5 (или 4.0) есть параметр, который вы можете убедиться, что viewstate загружается очень рано на странице, чтобы попытаться уменьшить его. Он все еще не решает проблему.

Разделение объекта просмотра не решает проблему.

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

Ответ 4

На моем сайте этот метатег вызывал ошибку:

<base href="http://www.SITEURL.COM" />

У меня есть раскрывающийся список, я обновляю в другом раскрывающемся списке измененный выбор. Поэтому, когда произошел postback (выпадающий список №2 с измененным индексом), я получил исключение.

Я пробовал все остальное от применения machinekey к web.config и установки этих атрибутов на странице

EnableViewState="false" EnableViewStateMac="false"

Ответ 5

Я использую VS 2010 против Windows Web Server 2008, и в итоге я обнаружил, что у меня было два ключа для одной и той же службы в разделе appSettings webconfig. Я пошел в IIS и проверил настройки приложения в виртуальном каталоге и получил ошибку, исправил ее в WebConfig и устранил проблему. Я создал машинный ключ, но это не устранило проблему. Также

страницы (...) validateRequest = "false" enableEventValidation = "false" enableViewStateMac = "false" viewStateEncryptionMode = "Никогда" /

Настройки. FWIW...

Ответ 6

Я использовал эту статью Microsoft для создания моего собственного ключа проверки подлинности machineKey и decryptionKey. Как отмечали другие, это можно поместить в раздел system.web в файле web.config, хотя есть проблемы с безопасностью, если другие люди получают ключ.

Ответ 7

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

Возьмите, например, вы работаете в гараже и имеете список рабочих мест. Вы переходите на страницу, в которой перечислены задания. Теперь вы нажимаете задание, которое переходит на другую страницу, добавляющую задание (например, job.aspx? Id = 1). На этой странице есть флажок, который помечает работу как завершенную. Как только вы отметите этот флажок, он отправляет данные обратно на ту же страницу и записывает в базу данных, что задание завершено. Но как сервер знает, какая задание будет отмечена как полная, потому что вы только что вернули true или false из этого флажка. Однако, если при первом запуске страницы сведений о задании вы записываете идентификатор задания в Viewstate, тогда, когда вы публикуете этот флажок, вы можете читать в jobid из viewstate.

Почему не хорошо использовать незашифрованное окно просмотра?

Представьте, что сервер должен сделать, чтобы отметить задание как полное. Вероятно, для запуска базы данных необходимо запустить команду sql. Что-то вроде работ UPDATE SET завершено = GETDATE() WHERE id = 1.

Если ваше viewstate не было зашифровано, и я мог бы добавить свой собственный идентификатор работы, я бы добавил что-то вроде '; DELETE FROM jobs; который затем отменит начальную команду UPDATE и удалит ВСЕ ваши задания... не очень хорошо для гаража:)