Недопустимый аргумент обратной передачи или обратного вызова

Ответ 1

Это может произойти, если вы публикуете то, что, по-видимому, является злонамеренным; например текстовое поле с html в нем, но не кодируется до обратной передачи. Если вы предоставляете html или script для отправки, вам необходимо закодировать его так, чтобы символы, такие как <, передавались как и lt..

Ответ 2

Описание проблемы:  Это одна из распространенных проблем, с которыми сталкиваются многие начинающие ASP.NET, почта и спрашивают. Как правило, они публикуют сообщение об ошибке, как показано ниже, и добиваются разрешения без совместного использования того, что они пытались сделать.

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

Хотя сама трассировка стека ошибок предполагает быстрое разрешение, отключив eventvalidation, это не рекомендуемое решение, так как оно открывает дыру в безопасности. Всегда хорошо знать, почему это произошло и как решить/решить эту проблему.

Оценка:  Проверка событий выполняется для проверки того, является ли происхождение события связанным визуализированным элементом управления (а не с некоторым кросс-сайтом script или около того). Поскольку управление регистрирует его события во время рендеринга, события могут быть проверены во время обратной передачи или обратного вызова (через аргументы __doPostBack). Это уменьшает риск несанкционированных или вредоносных обратных запросов и обратных вызовов.

См.: MSDN: свойство Page.EnableEventValidation

Исходя из вышеизложенного, возможные сценарии, с которыми я столкнулся или слышал, которые поднимают проблему в обсуждении, следующие:  Случай №1: Если в данных запроса есть скобки angular, похоже, что тег script передается серверу.

Возможное решение:  HTML кодирует скобки angular с помощью JavaScript перед отправкой формы, т.е. Заменяет "<" с "<" и " > " с " > "

function HTMLEncodeAngularBrackets(someString)
{
var modifiedString = someString.replace("<","&lt;");
modifiedString = modifiedString.replace(">","&gt;");
return modifiedString;
}

Случай №2: если мы пишем клиент script, который изменяет элемент управления в клиенте во время выполнения, у нас может быть событие свисания. Примером может быть встроенный элемент управления, где внутренний контроль регистрируется для обратной передачи, но скрыт во время выполнения из-за операции, выполняемой при внешнем управлении. Это я прочитал в блоге MSDN, написанном Карло, при поиске той же проблемы из-за нескольких тегов формы.

Возможное решение:  Вручную зарегистрируйте элемент управления для проверки событий в методе Render страницы.

protected override void Render(HtmlTextWriter writer)
{
ClientScript.RegisterForEventValidation(myButton.UniqueID.ToString());
base.Render(writer);
}

Как сказано, один из других распространенных сценариев (который выглядит как попадание в эту же категорию) создает страницу, где один тег формы встроен в другой тег формы, который выполняется на сервере. Удаление одного из них исправляет поток и устраняет проблему.

Случай №3: Если мы повторно определяем/создаем элементы управления или команды во время выполнения при каждой обратной передаче, соответствующие/связанные события могут идти за броском. Простым примером может быть повторная привязка datagrid к каждой pageload (включая обратную передачу). Поскольку при повторной обработке все элементы управления в сетке будут иметь новый идентификатор во время события, инициированного элементом управления datagrid, при обратной передаче идентификаторы элементов управления будут изменены, и, таким образом, событие может не подключиться к правильному управлению, поднимая проблему.

Возможное решение:  Это можно просто решить, убедившись, что элементы управления не создаются повторно при каждом обратном вызове (переподключение здесь). Использование свойства страницы IsPostback может легко справиться с этим. Если вы хотите создать элемент управления при каждой обратной передаче, необходимо убедиться, что идентификаторы не изменены.

protected void Page_Load(object sender, EventArgs e)
{
if(!Page.IsPostback)
{
// Create controls
// Bind Grid
}
}

Вывод:  Как сказано, легкое/прямое решение может добавлять enableEventValidation = "false" в директиву страницы или файл Web.config, но не рекомендуется. Основываясь на реализации и причине, найдите основную причину и примените разрешение соответственно.

Ответ 3

Кажется, что данные/элементы управления на странице изменяются, когда происходит обратная передача. Что произойдет, если вы отключите проверку событий в директиве страницы.

<%@ Page ... EnableEventValidation = "false" />

Ответ 4

Я только когда-либо получаю это, когда у меня есть вложенные теги <form> на моих страницах. IE6 будет рассматривать вложенные теги формы и попытаться опубликовать значения в этих формах, а также основную форму ASP.NET, вызывая ошибку. Другие браузеры не публикуют вложенные формы (поскольку это недействительный HTML) и не получают ошибку.

Вы можете решить эту проблему, выполнив EnableEventValidation = "false", но это может означать проблемы для ваших опубликованных значений и viewstate. Лучше сначала отсеять вложенные теги <form>.

Есть другие места, где это может возникнуть, например, значения HTML-esque в полях формы, но я думаю, что сообщения об ошибках для них были более конкретными. На общей обратной передаче, которая бросает это, я просто проверил бы сделанную страницу для дополнительных тегов <form>.

Ответ 5

У меня было что-то подобное, когда у меня был ListBox, который отлично работал, когда я вводил текст вручную, но когда я ввел данные, основанные на SQL-запросе, последний элемент в списке выкинул бы это исключение. Я искал все Q & A, и ничто не соответствовало моей проблеме.

В моем случае проблема заключалась в том, что в данных SQL был непечатаемый символ (\ r). Я предполагаю, что сервер создал хеш-код, основанный на существовании непечатаемого символа, но он был удален из строки, которая действительно появилась в ListBox, поэтому второй хеш не совпал с первым. Очистка строки и удаление непечатаемых символов перед тем, как поместить ее в ListBox, исправили мою проблему.

Это, вероятно, супер-край, но я хотел добавить это только для того, чтобы быть полным (и, надеюсь, помочь кому-то еще не тратить 2 дня на смену).