АСП.НЕТ:Невозможно проверить данные

StackOverflow https://stackoverflow.com/questions/140303

Вопрос

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

Кстати, я не управляю веб-фермой.

Исключение

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

Источник ошибки:Система.Веб

Ошибка целевого сайта:Byte [] getDecodedData (byte [], byte [], int32, int32, int32 byref)

Публикация данных

СОСТОЯНИЕ ВИДА:

/wEPDwULLTE4NTUyODcyMTFkZF96FHxDUAHIY3NOAMRJYZ+CKsnB

ПРОВЕРКА СОБЫТИЯ:

/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)

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

Это было полезно?

Решение

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

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

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

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

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

Другие советы

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

Веб.конфигурация

<configuration>

    <system.web>

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

    </system.web>

</configuration>

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

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

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

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

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

«Убедитесь, что конфигурация определяет тот же валидационный клад и алгоритм проверки».

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

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

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

«постбэк останавливается до загрузки всех состояний просмотра»

Раньше у меня была именно такая проблема, и причина была в этом.

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top