ASP.NET Viewstate с Safari 5.x

Question

У меня есть веб-приложение ASP.net 3.5 sp1, которое работает на IIS6, и в веб-конфигурации установлены ключи компьютера и проверки. Приложение работает корректно во всех браузерах, кроме Safari.

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

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

Я нашел другие сообщения в Stackoverflow, но ни одна из них не помогла решить проблему.

Это известная проблема с сафари или кто-то еще сталкивался с этой проблемой?

Answer 1

Если на OSX, попробуйте убедиться, что переключатель «Block Cookies: Always» установлен , а не .Вы можете найти его на вкладке Конфиденциальность Настройки ...

Answer 2

Подобная проблема возникла у нас 12 марта 2012 года, когда был выпущен Safari 5.1.4.Проблема возникает и в Safari 5.1.5.Это происходит как в Windows, так и в Mac-версиях Safari.

В нашем случае состояние представления, отправляемое Safari, было полным состоянием представления, к сожалению, это было для предыдущей страницы, а не для публикуемой страницы.

Чтобы проверить это

1. Сначала перед отправкой проверьте состояние просмотра, просмотрев источник на странице, где возникла проблема.Обычно это кодируется base64 и может быть зашифрован.Если на вашем сайте он зашифрован, возможно, вам придется отключить его, чтобы проверить состояние просмотра.Вы можете найти в Интернете декодер Base 64. Существует несколько сайтов, в которые можно вставить строку __Viewstate и декодировать ее.
2. Отправьте страницу и получите ошибку.Если вы получите пользовательскую ошибку в браузере, она покажет вам значение viewstate, полученное сервером.Если нет, перейдите в журнал событий приложений на сервере и найдите зарегистрированное сообщение об ошибке.Декодируйте состояние просмотра в сообщении так же, как вы делали это на шаге 1.
3. Изучите содержимое обоих состояний просмотра. Обычно по данным вы сможете определить, принадлежит ли состояние просмотра к странице, на которой размещается сообщение.или на какой-либо другой странице.

Так что, если вы обнаружите, что они отличаются, возможно, вы столкнулись с проблемой, с которой мы столкнулись.

В нашем случае код-нарушитель, вызвавший проблему, действительно былна предыдущей странице.В PageOne мы подключили событие window.onload и вызывали форму [0] .submit.Сервер ответил перенаправлением 302 на PageTwo.aspx.Браузер правильно ответил, выполнив GET из Page2.aspx.Когда пользователь нажимает кнопку отправки на PageTwo.aspx, возникает ошибка проверки, в нашем случае safari отправляет значение viewstate для предыдущей страницы, pageone.aspx

В нашем случае мы обошли проблемувызов setTimeout ("DoWork ()", 10);в событии window.onload.Затем поместите наш код в функцию DoWork ().

Мы отправили отчет об ошибке в Apple.

Надеюсь, это поможет.

Answer 3

Во-первых, это анти-паттерн для создания большого состояния просмотра (то есть, пусть страница обрабатывает состояние при обратной передаче).Когда есть проблема MAC состояния представления, это имеет отношение к неспособности дешифровать возвращенное состояние представления.Не уверен, что Safari для WIndows делает это (вероятно, как я мог бы предположить, что это та же самая база кода), но состояние просмотра на Mac составляет 1/4 размера viewstate в ориентированных на ПК браузерах (1K против 4k).

Ограничение размера конфигурации viewstatein будет работать только в том случае, если вы действительно можете ограничить размер и при этом сохранить работу своего приложения.И вы должны ограничить в пределах окна 1K (обратите внимание, что это не означает viewstate == 1K, так как, вероятно, есть другие вещи, отправленные обратно).

Лучшее решение - выяснить, что у вас есть в viewstate.и определите, можете ли вы выполнить повторное связывание на стороне сервера, а не полагаться на представление состояния для автоматического повторного связывания.Существует SessionPageStatePersister, который можно использовать.

Краткий ответ: вам придется немного перестроить архитектуру, чтобы пройти это.