Исправлена ​​ошибка с недопустимым представлением в приложении .NET.

Кажется, я получаю "недопустимое представление" каждый раз в окне просмотра событий для приложения ASP.NET.

Большинство из них (95%), похоже, ссылаются на ScriptResource.axd (приложение использует библиотеку ASP.NET AJAX). Я не могу удалить библиотеку Ajax либо как Ajax используется везде.

Как я могу уменьшить эти ошибки? Я получаю ~ 100-200 ошибок в день, и я понятия не имею, как их исправить! Они поступают из разных браузеров, разных IP-адресов и географических местоположений.

Мне трудно воспроизвести проблему, потому что это едва ли случилось со мной, это случилось только со мной в 3-4 раза из-за синего.

Ошибка:

Process information: 
    Process ID: 4004 
    Process name: w3wp.exe 
    Account name: NT AUTHORITY\NETWORK SERVICE 

Exception information: 
    Exception type: HttpException 
    Exception message: Invalid viewstate. 

Request information: 
    Request URL: http://domainnamehere/ScriptResource.axd?d=W1R6x9VzZ2C9SKnIkOmX9VRLhSjJ3nOF1GSQvPwKS3html 
    Request path: /ScriptResource.axd 
    User host address: 124.177.170.75 
    User:  
    Is authenticated: False 
    Authentication Type:  
    Thread account name: NT AUTHORITY\NETWORK SERVICE 

Thread information: 
    Thread ID: 1 
    Thread account name: NT AUTHORITY\NETWORK SERVICE 
    Is impersonating: False 
    Stack trace:    at System.Web.UI.Page.DecryptStringWithIV(String s, IVType ivType)
   at System.Web.UI.Page.DecryptString(String s)
   at System.Web.Handlers.ScriptResourceHandler.DecryptParameter(NameValueCollection queryString)
   at System.Web.Handlers.ScriptResourceHandler.ProcessRequestInternal(HttpResponse response, NameValueCollection queryString, VirtualFileReader fileReader)
   at System.Web.Handlers.ScriptResourceHandler.ProcessRequest(HttpContext context)
   at System.Web.Handlers.ScriptResourceHandler.System.Web.IHttpHandler.ProcessRequest(HttpContext context)
   at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)


Custom event details: 

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

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

Exception raised in GLOBAL.ASAX.Application_Error(): 'Padding is invalid and cannot be removed.' at System.Security.Cryptography.RijndaelManagedTransform.DecryptData(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount, Byte[]& outputBuffer, Int32 outputOffset, PaddingMode paddingMode, Boolean fLast)
   at System.Security.Cryptography.RijndaelManagedTransform.TransformFinalBlock(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount)
   at System.Security.Cryptography.CryptoStream.FlushFinalBlock()
   at System.Web.Configuration.MachineKeySection.EncryptOrDecryptData(Boolean fEncrypt, Byte[] buf, Byte[] modifier, Int32 start, Int32 length, IVType ivType, Boolean useValidationSymAlgo)
   at System.Web.UI.ObjectStateFormatter.Deserialize(String inputString)

ОТВЕТЫ

Ответ 1

Это, похоже, та же проблема IE8, что и у многих людей. Что-то похожее на то, что IE8 (как в режиме рендеринга IE8, так и в режиме совместимости с IE7) потеряет 4096 байтов из середины HTML-документа, и эти отсутствующие данные приводят к этому исключению (обычно вы видите это в вызове ScriptResource или WebResource).

Вот отчет об ошибке Microsoft по этому вопросу: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=434997

Также есть много сообщений в форуме, блоге и т.д. по этой проблеме:

Microsoft ответила на эту проблему:

Примечание - ошибка в Internet Explorer 8. Команда Internet Explorer изучает эту проблему.

Влияние. До сих пор мы считаем, что проблема не влияет на опыт конечного пользователя в веб-приложении; единственным отрицательным эффектом являются ложные/искаженные запросы, отправленные механизмом спекулятивной загрузки JavaScript. Когда script действительно нужен парсеру, он будет правильно загружен и использован в это время.

Обстоятельства: ложный запрос появляется только в определенных ситуациях синхронизации, только когда в документе появляется тег META HTTP-EQUIV, содержащий Content-Type с директивой CHARSET, и только тогда, когда URL-адрес JavaScript SRC охватывает 4096-й байт тела ответа HTTP.

Обходной путь: Следовательно, в настоящее время мы полагаем, что эта проблема может быть уменьшена путем объявления CHARSET страницы с использованием заголовка HTTP Content-Type, а не указания его на странице.

Итак, вместо размещения

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">

В своем теге head вместо этого отправьте следующий заголовок ответа HTTP:

Content-Type: text/html; charset=utf-8

Обратите внимание, что спецификация кодировки в HTTP-заголовке приводит к повышению производительности во всех браузерах, поскольку анализаторам браузера не нужно перезапускать синтаксический анализ с самого начала при встрече с объявлением набора символов. Кроме того, использование заголовка HTTP помогает смягчить некоторые векторы атаки XSS.

ПРИМЕЧАНИЕ. Появились сообщения о том, что эта проблема все еще происходит, когда META HTTP-EQUIV отсутствует на странице. Мы будем обновлять этот комментарий, когда у нас будет больше исследований.

Отправлено Microsoft от 30.06.2009 в 12:25.

Изменить: Иногда я вижу это исключение, но эта ошибка сообщается как фиксированная: http://blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader-fixed.aspx

Ответ 2

Я предполагаю, что вы используете ASP.NET AJAX. У меня та же проблема. Спорадически я бы нашел это исключение в своем журнале событий, а запрошенный путь - ВСЕГДА ScriptResource.axd.

Использование фиксированного validationKey и decryptionKey в machineKey не устранило проблему для меня.

Основываясь на том, что я смог собрать, я склонен полагать, что эта ошибка не имеет ничего общего с ViewState; моя теория заключается в том, что по некоторым причинам некоторые УА каким-то образом испортили параметр "d" ScriptResource.axd. Проблема легко реплицируется путем запроса пути нарушения вручную. Это дает исключение "Invalid ViewState", хотя ViewState здесь даже не применяется.

Копаясь в моих журналах, я нашел, например:

Этот запрос обслуживается ОК (200): /ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_33Y_9Dq6i10g9Q1NRCY1n0_DNg1nE6-DDbsD6r4EiuwoeDzp9mjDDfBNLb1k1&t=41df03cc

Этот немного другой запрос также подан OK (200): /ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_33Y_9Dq6i10g9Q1NR5ijsxQts4AfbJdACRwmQ8sHt6UAzui3spEnooPneTz01&t=41df03cc

Этот запрос не выполняется с ответом 500 и исключением Invalid ViewState: /ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_3 products$ctl00$AddToCart1$id

Если вы внимательно присмотритесь, первые несколько символов по всем трем запросам совпадают, но последние несколько символов последнего запроса (выделены полужирным шрифтом) явно являются идентификаторами Control ID "products $ctl00 $AddToCart1 $id" (у меня есть контролирует названные продукты и AddToCart). Я не знаю, как этот идентификатор попал туда, но в моем случае это то, что вызывает все эти исключения Invalid ViewState.

Я не уверен, что это тот же случай, что и OP или нет, но я заметил, что URL-адрес Мартин-запроса заканчивается в "html", что является совпадением для параметра, который должен быть ключом...

У меня уже есть головная боль благодаря этой проблеме. И до сих пор самая проницательная запись, с которой я столкнулся, - это http://bytes.com/topic/asp-net/answers/861764-invalid-viewstate-system-string-decryptstringwithiv

Любые идеи?

Ответ 3

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

  • Я бы сказал, что сказал Фредди Риос в потоке уже. Убедиться что вы жестко закодировали машину ключ. Это решит большинство из этих вопросов. важная вещь о Ссылка ScriptResource заключается в том, что она должен иметь параметр d и t параметр в запросе. Если оно ничего другого не делает!

  • Не позволяйте пользователю возвращать ваш сделанный. Вы, вероятно, могли бы сделать это с javascript и немного CSS. Из памяти, я думаю, есть способ сделать это с помощью метатега, но это может быть только IE.

  • Я бы посмотрел, это ответ рано. Я бы подумал после менеджером script было бы лучше. Но вам, возможно, придется экспериментировать бит.

  • Если ваш viewstate выглядит раздутым, включите сжатие GZip в IIS.

  • Если ваше viewstate стало действительно раздутый, и вы не можете получить GZip сжатие включено/или оно имеет нежелательные побочные эффекты. Тогда ты можешь сжимать и распаковывать ViewState. http://www.codeproject.com/KB/viewstate/ViewStateCompression.aspx

  • Если это все еще оставляет вас раздутый вид, вы можете посмотреть на сохраняя локальную область просмотра. http://blog.arctus.co.uk/articles/2007/04/23/advanced-asp-net-storing-viewstate-in-a-database/ является хорошей отправной точкой.

Ответ 4

Используйте фиксированный машинный ключ (даже при выполнении одного сервера).

Проблема возникает при использовании автоматической конфигурации для машинного ключа, вы получаете новый каждый раз, когда домен приложения перерабатывается. Это влияет на валидацию видовых представлений, дешифрование строки запроса динамических ресурсов и аутентификационные билеты [вставить другие варианты использования машинного ключа].

Ответ 5

Я видел такие проблемы, когда Viewstate слишком велик. Я видел, как это произошло из-за проблемы, о которой описывает Фредди.

Мне вообще не нравится идея использования Viewstate. Вы можете полностью отключить ViewState?

Ответ 6

У меня также есть эта проблема, и я пробовал все, что упоминалось во всех найденных блогах (фиксированный машинный ключ, размер представления и т.д.). 99% времени, когда ошибка регистрируется в запросах ScriptResource.axd. Я использую .net 3.5 SP1, на сервере Win 2003. Приложение размещено на двух параллельных одинаковых серверах, сбалансированных 50/50. Каждый сервер имеет один и тот же машинный ключ.

Обычно эта ошибка не касается меня много, однако в течение 3-месячного периода тенденция к возникновению событий идет вверх.

Кто-нибудь думает, что эта ошибка связана с тем, что ViewState не правильно используется UrlEncoded/HtmlEncoded или UrlDecoded. Возможно, есть подмножество символов в представлении, которое некоторые браузеры заменяют некоторым кодированным значением. Я не уверен, что это даже имеет смысл.

Ответ 7

Я думаю, вы должны использовать на странице aspx:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

Это решает мою проблему

Ответ 8

Работаете ли вы на не-английской операционной системе?

По некоторым причинам имя учетной записи "Служба NT/Network Service" локализовано на других языках.
К сожалению, многие программы имеют имя учетной записи, жестко закодированное по английскому имени, и не будут находить Сетевую службу при работе в чужих версиях Windows, что приведет к появлению всех ошибок в журнале событий.

Ответ 9

Я только что сузил эту проблему для пользователя с антивирусом Trend Micro, и ошибки только начали возникать после того, как он обновил свое микропрограммное программное обеспечение на 5/21/2009. Нет ошибок до этой даты.

Ответ 10

Проблема выглядит как загрузчик в IE8.

Кажется, это влияет только на IE8 в довольно неясном множестве обстоятельств. Одной из причин, почему это может остаться незамеченным, является то, что 4k кусок данных, добавленных к URL-адресу, часто отбрасывается сервером. Одна из вещей, которая, похоже, делает ее более вероятной, - медленное сетевое соединение. Кто-то из одного из нижеперечисленных ресурсов отметил, что у него был только вопрос со своими клиентами в Новой Зеландии.

Множество людей объясняют две отдельные проблемы, одна из которых описана в вопросе выше (неверные URL-адреса, отправленные на сервер):

http://connect.microsoft.com/VisualStudio/feedback/details/434997/invalid-webresource-axd-parameters-being-generated

Статья, поясняющая, что исправленный загрузчик исправлен:

http://blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader-fixed.aspx

KB980182. Накопительное обновление, в котором проблема исправлена:

http://support.microsoft.com/kb/980182

ПРИМЕЧАНИЕ.. Поскольку script автоматически повторно загружается, если он не может быть загружен загрузчиком lookahead, должно быть возможно вернуться в старый режим проверки, в котором были .axd файлы не проверяется на достоверность и устраняет симптомы проблемы:

<httpRuntime requestValidationMode="2.0" />