ASP.NET: невозможно проверить данные

Question

В чем причина этого исключения в ASP.NET? Очевидно, это исключение состояния просмотра, но я не могу воспроизвести ошибку на странице, которая вызывает исключение (простая форма TextBox с двумя кнопками и навигационными ссылками).

FWIW, я не управляю веб-фермой.

Исключение

Сообщение об ошибке: невозможно проверить данные.

Источник ошибки: System.Web

Ошибка целевого сайта: байт [] GetDecodedData (Byte [], Byte [], Int32, Int32, Int32 ByRef)

Почтовые данные

VIEWSTATE:

/ wEPDwULLTE4NTUyODcyMTFkZF96FHxDUAHIY3NOAMRJYZ + CKsnB

EVENTVALIDATION:

/ wEWBAK + 8ZzHAgKOhZRcApDF79ECAoLch4YMeQ2ayv / Gi76znHooiRyBFrWtwyg =

Трассировка стека исключений

   at System.Web.UI.ViewStateException.ThrowError(Exception inner, String persistedState, String errorPageMessage, Boolean macValidationError)
   at System.Web.UI.ObjectStateFormatter.Deserialize(String inputString)
   at System.Web.UI.ObjectStateFormatter.System.Web.UI.IStateFormatter.Deserialize(String serializedState)
   at System.Web.UI.Util.DeserializeWithAssert(IStateFormatter formatter, String serializedState)
   at System.Web.UI.HiddenFieldPageStatePersister.Load()
   at System.Web.UI.Page.LoadPageStateFromPersistenceMedium()
   at System.Web.UI.Page.LoadAllState()
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
   at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
   at System.Web.UI.Page.ProcessRequest()
   at System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context)
   at System.Web.UI.Page.ProcessRequest(HttpContext context)
   at ASP.default_aspx.ProcessRequest(HttpContext context)
   at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

~ Уильям Райли-Лэнд

Answer 1

Наиболее вероятной причиной этой ошибки является то, что когда обратная передача останавливается до того, как все состояние просмотра загружается (пользователь нажимает кнопки «Стоп» или «Назад»), состояние просмотра не сможет проверить и выдать ошибку.

Другие потенциальные причины:

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

Обновление: Статья Microsoft по проблеме . В дополнение к вышесказанному они предлагают две другие возможные причины:

• Модификация viewstate с помощью брандмауэров / антивирусного программного обеспечения
• Публикация с одной страницы aspx на другую.

Answer 2

В .NET 3.5 SP1 свойство RenderAllHiddenFieldsAtTopOfForm было добавлено в конфигурацию PagesSection.

Web.config

<configuration>

    <system.web>

        <pages renderAllHiddenFieldsAtTopOfForm="true"></pages>

    </system.web>

</configuration>

Интересно, что по умолчанию это значение true. Таким образом, по сути, если вы используете .NET 3.5 SP1, то ViewState автоматически отображается в верхней части формы (до загрузки остальной части страницы), тем самым устраняя полученную ошибку ViewState.

Answer 3

У меня возникла проблема с некоторыми конкретными версиями Safari 3. Мое решение состояло в том, чтобы переместить ViewState в верхнюю часть формы (расширить класс Page и переписать метод Render для версии 3.5 SP1 или .Net 3.5 SP1 и более поздние версии делают это по умолчанию) и разделяют ViewState на несколько разных полей вместо одного файла монстра. См. Chunking ViewState в ASP.NET 2.0 (maxPageStateFieldLength)

Answer 4

Этот бесплатный онлайн-инструмент: http://aspnetresources.com/tools/machineKey создает элемент machineKey под элементом system.web в файле web.config. Вот пример того, что он генерирует:

<machineKey validationKey="1619AB2FDEE6B943AD5D31DD68B7EBDAB32682A5891481D9403A6A55C4F91A340131CB4F4AD26A686DF5911A6C05CAC89307663656B62BE304EA66605156E9B5" decryptionKey="C9D165260E6A697B2993D45E05BD64386445DE01031B790A60F229F6A2656ECF" validation="SHA1" decryption="AES" />

---

Как только вы видите это в своем файле web.config, сама ошибка внезапно становится понятной. Полученная вами ошибка говорит

"убедитесь, что в конфигурации указаны те же validationKey и алгоритм проверки ".

Когда вы смотрите на этот элемент machineKey, внезапно вы видите, о чем он говорит.

---

Путем «жесткого кодирования» этого значения в вашем файле web.config ключ, используемый asp.net для сериализации и десериализации вашего состояния просмотра, остается неизменным, независимо от того, какой сервер в ферме серверов его забирает. Ваше шифрование становится «переносимым», поэтому ваше представление состояния становится «переносимым».

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

Answer 5

Я нашел корень этой проблемы на своем веб-сайте, и мне, наконец, удалось решить ее. Это не прямой ответ на ваш вопрос, но я хотел поделиться этой небольшой информацией.

В прошлом я пробовал все (в том числе решение, предложенное Джеффаксом выше), но безрезультатно, и я не хотел устанавливать enableViewStateMac="false" (как упоминал Релшарк выше) для моей страницы, потому что это просто скрывает проблема.

Что вызвало проблему в моем случае? Проблема была вызвана использованием модуля Intelligencia.UrlRewriter (версия 2.0 RC 1, сборка 6) на некоторых страницах моего веб-сайта. Я использовал несколько дружественных для SEO ссылок, и это вызывало ошибку проверки ViewState. Когда я использовал «нормальные» ссылки (вместо SEO-дружественных ссылок), проблема исчезла!

Я воспроизвел проблему несколько раз, чтобы убедиться, что это не ложная тревога (я использую ASP.NET 3.5).

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

Answer 6

"обратная передача остановлена ​​до того, как загрузится все состояние просмотра"

У меня была именно эта проблема раньше, и это было причиной.

Изначально мы отключили свойство ViewStateMac (enableViewStateMac="false" в директиве page), чтобы решить его, но это не является истинным решением проблемы и может угрожать целостности данных. В конечном итоге мы решили эту проблему, отключив кнопку отправки до тех пор, пока страница не загрузится полностью, и обрезали размер нашего представления, отключив его на некоторых элементах управления.

Answer 7

Я получил эту ошибку, когда у меня на странице была настройка тега формы без атрибута действия, а затем в выделенном фрагменте кода я изменил атрибут действия формы на «Action.aspx».

И в JavaScript я отправил форму (theForm.submit ();)

Я думаю, что в моем случае это была проблема безопасности, и вы не можете ее изменить, если она уже установлена ​​на странице ...?

Answer 8

Не уверен, поможет ли это кому-либо, но моим решением было исключение machineKey из моей веб-конфигурации для передачи моего файла cookie.