asp.net - true - <%@ page... enableeventvalidation="false"... %>

No válido postback o argumento de devolución de llamada

Question

Tengo una aplicación ASP.net que funciona bien en el entorno de desarrollo pero en el entorno de producción arroja la siguiente excepción al hacer clic en un enlace que realiza una devolución de datos. ¿Algunas ideas?

No válido postback o argumento de devolución de llamada. La validación de eventos se habilita mediante la configuración o <% @ Page EnableEventValidation = "true"%> en una página. Por motivos de seguridad, esta función verifica que los argumentos para la devolución de datos o los eventos de devolución de llamada se originan en el control del servidor que los generó originalmente. Si los datos son válidos y esperados, utilice el método ClientScriptManager.RegisterForEventValidation para registrar la devolución de datos o los datos de devolución de llamada para la validación.

Editar: Esto parece estar sucediendo solo cuando se ve con IE6 pero no con IE7, ¿alguna idea?

Answer 1

Esto puede suceder si está publicando lo que parecen ser cosas posiblemente maliciosas; como un cuadro de texto que tiene html, pero no está codificado antes de la devolución de datos. Si permite que se envíe html o script, debe codificarlo para que los caracteres, como <, se pasen como & lt ;.

Answer 2

Parece que los datos / controles en la página se cambian cuando se produce la devolución de datos. ¿Qué sucede si desactiva la validación del evento en la directiva de la página?

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

Answer 3

Solo recibo esto cuando he anidado etiquetas <form> en mis páginas. IE6 examinará las etiquetas de formulario anidado e intentará publicar los valores en esos formularios, así como el formulario principal de ASP.NET, causando el error. Otros navegadores no publican los formularios anidados (ya que no es HTML válido) y no obtienen el error.

Ciertamente puede resolver esto haciendo una EnableEventValidation = "false" , pero eso puede significar problemas para sus valores publicados y viewstate. Es mejor descartar primero las etiquetas <form> anidadas.

Hay otros lugares donde esto puede aparecer, como valores HTML-esque en los campos de formulario, pero creo que los mensajes de error fueron más específicos. En una devolución de datos genérica que arroja esto, simplemente verificaría que la página representada contiene etiquetas <form> adicionales.

Answer 4

Descripción del problema: Este es uno de los problemas comunes que muchos principiantes de ASP.NET enfrentan, publican y preguntan. Normalmente, publican el mensaje de error como se muestra a continuación y buscan una solución sin compartir mucho sobre lo que intentaban hacer.

[ArgumentException: devolución de datos inválida o argumento de devolución de llamada. La validación de eventos se habilita mediante la configuración o <% @ Page EnableEventValidation = "true"%> en una página. Por motivos de seguridad, esta función verifica que los argumentos para la devolución de datos o los eventos de devolución de llamada se originan en el control del servidor que los generó originalmente. Si los datos son válidos y esperados, utilice el método ClientScriptManager.RegisterForEventValidation para registrar la devolución de datos o los datos de devolución de llamada para la validación.

Sin embargo, el seguimiento de la pila de errores sugiere una resolución rápida al desactivar la opción de validación de eventos, no es una solución recomendada ya que abre un agujero de seguridad. Siempre es bueno saber por qué sucedió y cómo resolver / manejar ese problema de raíz.

Evaluación: la validación de eventos se realiza para validar si el origen del evento es el control representado relacionado (y no algún script entre sitios, más o menos). Como el control registra sus eventos durante el procesamiento, los eventos se pueden validar durante la devolución de datos o la devolución de llamada (a través de los argumentos de __doPostBack). Esto reduce el riesgo de solicitudes y devoluciones de devolución de datos no autorizadas o maliciosas.

Consulte: MSDN: propiedad Page.EnableEventValidation

En base a lo anterior, los posibles escenarios que he enfrentado o escuchado que plantean el problema en discusión son: Caso # 1: si tenemos corchetes angulares en los datos de solicitud, parece que alguna etiqueta de script se está pasando al servidor.

Solución posible: HTML codifica los corchetes angulares con ayuda de JavaScript antes de enviar el formulario, es decir, reemplace "<" por "<" y ">" por ">"

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

Caso n. ° 2: si escribimos el script del cliente que cambia un control en el cliente en tiempo de ejecución, podríamos tener un evento colgante. Un ejemplo podría ser tener controles incrustados donde un control interno se registra para la devolución, pero está oculto en el tiempo de ejecución debido a una operación realizada en el control externo. Esto lo leí en el blog de MSDN escrito por Carlo, al buscar el mismo problema debido a las múltiples etiquetas de formulario.

Posible solución: registrar manualmente el control para la validación de eventos dentro del método Render de la página.

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

Como se dijo, uno de los otros escenarios comunes reportados (que parece estar en la misma categoría) es construir una página donde una etiqueta de formulario está incrustada en otra etiqueta de formulario que se ejecuta en el servidor. Eliminar uno de ellos corrige el flujo y resuelve el problema.

Caso n. ° 3: si redefinimos / instanciamos controles o comandos en el tiempo de ejecución en cada devolución, los eventos respectivos / relacionados pueden ser lanzados. Un ejemplo simple podría ser volver a vincular una cuadrícula de datos en cada carga de página (incluidas las devoluciones). Dado que, al volver a enlazar, todos los controles de la cuadrícula tendrán una nueva ID, durante un evento desencadenado por control de cuadrícula de datos, en la devolución se cambiarán las ID de control y, por lo tanto, el evento podría no conectarse al control correcto al plantear el problema.

Solución posible: esto se puede resolver simplemente asegurándose de que los controles no se vuelvan a crear en cada devolución de datos (vuelva a enlazar aquí). El uso de la propiedad de página IsPostback puede manejarlo fácilmente. Si desea crear un control en cada devolución de datos, entonces es necesario asegurarse de que los ID no se modifiquen.

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

Conclusión: Como se dijo, una solución fácil / directa puede agregar enableEventValidation = "false" en la directiva de la página o en el archivo Web.config, pero no es recomendable. En función de la implementación y la causa, encuentre la causa raíz y aplique la resolución en consecuencia.

Answer 5

Sucedí algo similar cuando tenía un ListBox que funcionaba bien cuando ingresaba el texto manualmente, pero cuando ingresaba datos basados ​​en una consulta SQL, el último elemento de la lista emitía esta excepción. Busqué todas las preguntas y respuestas y no hubo ningún problema con mi problema.

En mi caso, el problema era que había un carácter no imprimible (/ r) en los datos de SQL. Supongo que el servidor creó un código hash basado en la existencia del carácter no imprimible, pero se eliminó de la cadena que realmente apareció en el ListBox, por lo que el segundo hash no coincidió con el primero. Limpiar la cadena y eliminar los caracteres no imprimibles antes de ponerlo en el ListBox solucionó mi problema.

Este es probablemente un caso súper útil, pero quería agregar esto solo para estar completo (y espero ayudar a alguien más a no pasar 2 días enloqueciendo).