Должен ли я игнорировать случайную недопустимую ошибку viewstate?
Время от времени (примерно раз в день) мы видим следующие типы ошибок в наших журналах для ASP.NET 3.5 применение
- недопустимое состояние просмотра
- недопустимый аргумент postback или callback
Являются ли они чем-то, что" просто случается " время от времени с ASP.NET заявление? Кто-нибудь порекомендовал бы нам потратить много времени, пытаясь диагностировать, что вызывает проблемы?
10 ответов:
Ну, это зависит. Недопустимое состояние просмотра может произойти по разным причинам.
- Viewstate слишком велик и не закончил отрисовку до того, как пользователь вызывает обратную передачу на странице. Исправление обычно заключается в отключении всех элементов управления, запускающих обратную связь, и включении их на стороне клиента после завершения загрузки страницы-см. http://blogs.msdn.com/tom/archive/2008/03/14/validation-of-viewstate-mac-failed-error.aspx
- Вы используете viewstate Mac (и вы должны быть, для причины безопасности), но вы не задали ключ машины, и пул приложений был повторно использован для создания нового ключа. Не забудьте установить ViewStateUserKey.
- Кто-то использует старую версию IE на mac, где он усекает скрытые поля формы. В этом случае вам нужно будет переместить viewstate из страницы всостояние сеанса .
- проблемы Viewstate MAC обычно указывают на то, что вы находитесь на веб-ферме и забыли установить ключ компьютера в web.конфиг. Однако, если вы сделали это тогда это, вероятно, кто-то пытается делать плохие вещи (боты, размещающие комментарии, кто-то пытается вызвать события для отключенных элементов управления и т. д.) Причину их следует отследить, хотя бы для того, чтобы исключить потенциальные проблемы безопасности.
Что бы вы ни делали не надо отключите проверку состояния просмотра или события.
Одна из проблем может быть связана с тем, что маршрутизаторы пользователей усекают поля формы. Способ обойти это-установить MaxPageStateFieldLength в небольшое число (например, 100) в web.config и ViewState разбивается на небольшие куски. Это очень просто сделать, и эта статья полностью объясняет это.
BlowDart имеет правильный ответ Для проблемы недопустимого состояния представления. Это, вероятно, ваш пул приложений перерабатывается и меняется ключ шифрования.
Смотрите эти сообщения для поддержки:
Ошибка недопустимого состояния просмотра в приложении .NET
Создание постоянного входа пользователя с членством ASP .Net
Исключения не" просто случаются " время от времени. Они всегда происходят по уважительным причинам, некоторые из которых уже перечислены в других ответах.
Однако, чтобы облегчить проблемы с ViewState, рассмотрите возможность его полного отключения. Как ASP.NET разработчики мы часто склонны использовать ViewState во всех местах, где он не нужен, потому что он используется по умолчанию. Я обычно думаю об использовании статического html, прежде чем рассматривать использование элемента управления. Если вы все же решите использовать элемент управления, подумайте, действительно ли он должен быть включен режим ViewState. Отключение его часто приводит к лучшему времени загрузки страницы, так что если вы можете, сделайте это.
Я хотел бы, чтобы он был отключен по умолчанию, чтобы люди были вынуждены думать таким образом, но это не так.Обновление для ответа комментарий:
Из верхней части моей головы я придумываю 3 возможности отключить ViewState.
Отключите ViewState, если данные загружаются при каждой обратной передаче. Это часто будет иметь место, если вы создаете сайты с поддержкой AJAX (это real AJAX не тот вид UpdatePanel;)), где вы обычно загружаете данные на первой загрузке, а затем перезагружаете / обновляете данные с помощью AJAX-запросов. В некоторых случаях вы можете даже загружать данные при каждом посещении с единственной целью отключить ViewState,а затем кэшировать данные на сервере.
Вы также можете отключить ViewState, если вы привязываете данные к содержимому, которое действительно статично. Иногда я нахожу список, который привязан к небольшой статической таблице basedata в база данных или что-то в этом роде. Теперь это может быть опасно, но если я убежден, что данные не изменятся, я могу переместить данные на страницу как статическое содержимое (вы можете обернуть его в отдельный элемент управления, чтобы у вас не было нескольких статических копий данных). Но если данные изменятся, вам придется изменить их вручную.
Простые элементы управления, такие как метки, часто являются хорошими кандидатами для отключения ViewState.
Наконец-то вы можете переключиться на ASP.NET MVC фреймворк и прощание с этими проблемами навсегда, вот что я планирую сделать, даже если столкнусь с некоторыми другими проблемами. ;)
С первым вы ничего не можете поделать - я ловлю такие исключения и отправляю пользователя на страницу ошибок с сообщением типа " страница, на которой Вы были, просрочена. Обычно это происходит, когда вы пытаетесь вернуться на страницу, где уже были введены данные."
Последнее я вижу чаще всего на довольно больших страницах, использующих панели обновления. Я думаю, что это когда пользователь отправляет ответ (или, возможно, перезванивает) до того, как страница закончила загрузку, поэтому не все javascript, которые помечаются в конце страницы еще не пробежал.
Опять же, вы мало что можете сделать с ними, кроме как показать соответствующее дружелюбное сообщение на странице ошибок.
У меня было такое исключение, которое было брошено в мои журналы и имело очень отличную причину от других, перечисленных здесь. У меня было очень большое состояние просмотра, что является частью проблемы. Но это сочеталось с другой проблемой, чтобы вызвать эти исключения (и, возможно, случайные плохие ответы от IIS).
В кодовой базе, над которой я работаю, есть какой-то необычный код, чтобы избежать двойных кликов, и как часть этого он добавляет некоторые вещи в javascript события щелчка каждой кнопки, которые отключают кнопка после первого клика, а затем делает обычную обратную передачу. Но вызов обратной связи таким образом был проблемой, потому что некоторые из моих кнопок уже имели обратный вызов, генерируемый .NET автоматически. Таким образом, я заканчивал с двойными обратными ссылками, одна из которых имела недопустимое состояние просмотра. Удаление дополнительной обратной связи остановило исключения для меня.
Я знаю, что мне действительно следует резко уменьшить размер ViewState, но это большая устаревшая кодовая база, и подобное изменение было бы будьте очень агрессивны.
Недопустимое состояние представления не имеет никакого значения для вашего регистратора или для пользователей или для вашего веб-сайта, конечные пользователи никогда не видят эти ошибки. чтобы избежать этой ошибки, попробуйте добавить следующее В Global.ascx :
void Application_Error(object sender, EventArgs e) { if (ex is HttpException && ex.InnerException is ViewStateException) { Response.Redirect(Request.Url.AbsoluteUri); return; } }
Для получения дополнительной информации проверьте следующую ссылку:
Https://www.karpach.com/viewstateexception-invalid-viewstate.htm
Вероятно, не стоит игнорировать эту ошибку. В дополнение ко всем вышеперечисленным ответам вы можете рассмотреть вопрос о том, насколько велико ваше состояние просмотра. Большое состояние просмотра может быть усечено прокси-сервером.
Если ваше состояние представления велико, то может быть хорошей идеей использовать ASP.net трассировка, чтобы увидеть, какие элементы управления используют viewstate,и где вы можете отключить это.
Согласно Уэйну Уолтеру Берри в этом блоге другой виновник может использовать XHTML doctype в IE8 без наличия XHTML-совместимой разметки на странице. Это может привести к тому, что IE8 будет отправлять скремблированные параметры в scriptresource.axd и бросить недопустимое исключение viewstate.
Он рекомендует убедиться, что все блоки javascript обернуты с помощью// <![CDATA[]]>
или просто изменить doctype (что может вызвать другие проблемы css/styling на Вашей странице).
Обновление: Microsoft объявила, что следующее исправление ошибки для IE 8 исправляет это problem:
http://blogs.msdn.com/ieinternals/archive/2010/04/01/IE8-Lookahead-Downloader-Fixed.aspx