Ошибка декодирования ViewState, когда клиент подключается через несколько IP-адресов на запрос
У нас есть немного странная проблема с нашим сайтом.
Соответственно, от 1 анонимного * пользователя возникает следующая ошибка:
Exception type: System.FormatException
Exception message: Invalid length for a Base-64 char array.
После некоторого расследования выяснилось, что пользователь использует некоторую форму брандмауэра с балансировкой нагрузки, поскольку журналы IIS показывают запросы, исходящие от 2 разных (но последовательных) IP-адресов.
Насколько я могу судить, отключение ViewStateMAC должно решить эту проблему.
Однако я не уверен, и, не имея возможности проверить это с пользователем, я немного не хочу продолжать это делать.
Кто-нибудь испытывал подобные проблемы? Как вы с ними справились?
Детали сервера:
Один сервер (Win2003), работающий с одного IP.
Обновлять:
Насколько я могу судить, ViewStateMAC предназначен только для серверной части. Моя проблема связана с тем, что клиент отправляет обратно одну страницу с несколькими IP-адресами.
* Но с тех же двух IP-адресов, как определено из журналов IIS. Пользователь тоже не злонамеренный.
@JohannesH: Нет, и в этом не было необходимости, 18 месяцев назад меня уволили из этого проекта.
Ответы 2
Отключение viewstatemac не решит проблему; Сбои ViewStateMac происходят, когда у вас несколько веб-серверов, нет, когда пользователь приходит с нескольких IP-адресов.
Вы случайно не используете viewstateuserkey? Даже в этом случае это маловероятно, поскольку вы получите другое исключение.
Я был бы соблазнен, если бы пользователь мог воссоздать его на постоянной основе, чтобы они установили скрипач и регистрировали запросы, пока это не произойдет, а затем они отправят их вам. Затем воспроизведите их со своей стороны и посмотрите, возникает ли ошибка.
Они ведь не используют IE на Mac? Это портит long viewstate из-за ошибки в длине полей формы.
Проблема в том, чтобы воссоздать его ... И без использования ViewStateUserKey. Пользователь использует FF 2.0.0.9. К сожалению, я не могу использовать Fiddler на сервере :(. Но спасибо.
Также пользователь анонимен. Мы собрали информацию из журналов IIS и увидели для той же обратной передачи, что клиент исходит с разных IP-адресов, но с тем же именем хоста (путем разрешения IP).
Привет, мы наблюдаем необычное количество этих ошибок в приложении, которое - из-за требований клиента и отсутствия указаний по ним - использует чрезмерное количество элементов управления и, в частности, GridView на каждой странице.
Очевидным виновником была длина состояния просмотра, которая в некоторых крайних случаях составляла +50 тыс. Символов. Поскольку это административное приложение используется только ограниченным кругом пользователей, мы изначально полностью решили эту проблему, переместив состояние просмотра в сеанс с использованием адаптированной версии решения, описанного в этой превосходной (слегка устаревшей) статье: http://msdn.microsoft.com/en-us/magazine/cc163577.aspx Однако из-за этого у нас возникли проблемы с людьми, использующими кнопку «Назад» и / или просмотр с вкладками.
Затем мы добавили дополнительный код ведения журнала - и подтвердили, что проблема действительно заключалась в том, о чем говорилось в ошибке - строки в кодировке base-64 должны иметь длину, которая делится на 4 - и когда мы получили эту ошибку, этого никогда не было. Предполагалось, что некоторые прокси и / или брандмауэры в какой-то момент просто обрезают строку состояния просмотра. Затем мы использовали ViewStateChunking ASP.NET для разделения поля на несколько скрытых полей - мы все еще отслеживаем это решение.
Однако - недавно я получил ошибку в поле состояния просмотра, которое имело допустимую длину - однако длина поля __EVENTVALIDATION была недопустимой для этого.
На странице, где это произошло, у нас есть поля, в которых есть знаки "+" (телефонные коды) - в настоящее время я изучаю, не вызвано ли все это неправильной кодировкой исходных строк (поскольку знаки + имеют особое значение в базе -64 строки с эндодированием).
Вы когда-нибудь находили решение?