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

Ответ 1

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

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

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

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

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

Ответ 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, которую вы получаете.

Ответ 3

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

Ответ 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 для сериализации и десериализации вашего состояния просмотра, остается неизменным, независимо от того, какой сервер в ферме серверов выбирает его. Ваше шифрование становится "портативным", поэтому ваше viewstate становится "портативным".

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

Ответ 5

"postback останавливается до того, как загрузится все содержимое viewstate"

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

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

Ответ 6

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

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

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

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

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

Ответ 7

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

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

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

Ответ 8

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