Назначение для <pages enableEventValidation = "false" >

Я использовал следующее в web.config

<pages enableEventValidation="false">

Это исправляет проблему, с которой мы столкнулись с Ajax.

У нас есть веб-страница, которая, если вы перейдете к прямому использованию стандартной гиперссылки HTML, отлично работает.

Если вы перейдете на страницу с другой страницы по ссылке внутри gridview и response.redirecting в событии RowCommand на страницу, передающую идентификатор в строке запроса. Страница выдает ошибки из элементов управления внутри панели с указанием

"Недопустимый аргумент обратной передачи или обратного вызова. Проверка событий активируется с использованием в конфигурации или <% @Page EnableEventValidation =" true "% > на странице. В целях безопасности эта функция проверяет, что аргументы для событий обратной передачи или обратного вызова происходят из серверный элемент управления, который их первоначально визуализировал. Если данные действительны и ожидаются, используйте метод ClientScriptManager.RegisterForEventValidation, чтобы зарегистрировать данные обратной передачи или обратного вызова для проверки."

Я рад оставить проверку страницы ложной, поскольку она, похоже, не имела другого эффекта.

Любые идеи, что происходит?

Ответ 1

Прочитайте документацию .

РЕДАКТИРОВАТЬ. По соображениям безопасности, вероятно, лучше оставить его равным true, где бы вы ни находились.

Поэтому я рекомендую вам установить его на false только на отдельных страницах AJAX, где он вызывает проблемы, оставив его true в web.config.

Ответ 2

От здесь

Неверная ошибка аргумента PostBack или CallBack в основном повышается из-за функции проверки событий. Функция EventValidation является новой функцией в ASP.NET 2.0 и обеспечивает дополнительный уровень проверок, чтобы проверить, что обратная передача из элемента управления на клиенте выполняется именно из этого элемента управления, а не от кого-то, злонамеренного, используя что-то вроде кросс-сайта script инъекции, чтобы попытаться манипулировать вещами. Это часть нашей общей стратегии по увеличению уровня безопасности на уровне глубины до модели программирования, поэтому разработчики могут быть защищены по умолчанию, даже если они забывают добавлять собственные проверки безопасности.

Теперь Неверная ошибка аргумента PostBack или CallBack может возникать, когда вы запускаете событие click, и объект пересоединяется, или его свойства изменяются в событии Page_Load, или кто-то пытается взломать вашу систему с помощью межсайтового скриптинга. Каждый раз .Net Framework визуализирует страницу, тогда он связывает уникальный Guid для всех элементов управления. При привязке gridview или ретранслятора в каждой структуре привязки привязки будет привязан новый указатель для contorl. Поэтому каждый раз, когда вы запускаете событие, убедитесь, что событие Page_Load не меняет элемент управления, потому что, если элемент управления изменился, у него будет другой Guid, который резко активировал событие для обратной передачи. Вот несколько сценариев с этой ошибкой.

1) Недопустимый аргумент обратной передачи или обратного вызова в GridView. Проблема может заключаться в следующем: вы связываете данные в событии Page_Load с объектным источником данных или ручным привязкой с вызовом функции. Это позволит привязать данные GridView к каждому событию любого элемента управления. Когда вы запускаете команду GridView с помощью OnRowCommand, перед запуском RowCommand ваш GridView будет перегруппирован, и весь элемент управления внутри него будет назначен новому идентификатору. Поэтому RowCommand не смог получить элемент, который уволил событие. Решение для неверного аргумента обратной связи или обратного вызова в GridView: вы можете привязывать свои данные в этом случае, если условие

   if (!IsPostBack)

   {

          //Your code for Bind data 

   }

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

Ответ 3

Здесь стоит добавить одну вещь: если вы хотите отключить проверку событий для определенного элемента управления, а не на всей странице, есть обходное решение, задокументированное здесь и здесь (и теперь ссылается на соответствующее предложение Connect):

Просто подкласс соответствующего класса WebControl и не устанавливайте атрибут SupportsEventValidation в подклассе. Подкласс будет освобожден от проверки событий.