2010-05-06 41 views
12

Ocasionalmente recibo este error durante el uso normal, y no he encontrado una forma de detenerlo sin eliminar el atributo que requiere el token, que prefiero no usar.Error intermitente lanzado, "No se proporcionó un token antifalsificación requerido o no fue válido".

He obtenido este error durante mis propias pruebas (pero aparentemente al azar) y sé por mi registro que los usuarios que realmente han iniciado sesión también lo están obteniendo.

¿Alguien sabe lo que causaría la ruptura del sistema antiforgerytoken (que no sea un ataque real), y cómo podría solucionarlo sin abrir un agujero de seguridad en mis formularios?

Gracias!

+0

No está familiarizado con MVC2, pero si se trata de una rara vez, sospecho que el token está por caducar entre el momento en que el usuario carga la página y envía el formulario. Marca – mpen

+0

- creo que realmente podría ser. deberías publicar eso como una respuesta en caso de que resulte ser la respuesta. no es una solución, pero podría ser el problema. ¿Cómo podría manejar un token que expira? ¿cuánto tiempo tarda en caducar? –

+0

La cookie __RequestVerificationToken_Lw__ caduca al final de la sesión cuando se prueba usando MVC3 y Firefox. Me gustaría encontrar una forma de forzar una recarga de página para actualizar la cookie en lugar de expulsar un error. –

Respuesta

1

lea la sección sobre las limitaciones aquí

prevent cross site request forgery

+0

No, todo está configurado correctamente. El error ocurre raramente, una vez a la semana más o menos y ocasionalmente durante pruebas intensas. –

+0

Gracias Jason, voy a leerlo. –

+0

el único pensamiento que vi allí que es diferente de lo que he implementado es, muestran esto: <% usando (Html.Form ("UserProfile", "SubmitUpdate")) {%> <% = Html .AntiForgeryToken()%> <- resto del formulario va aquí -> <% } %> mientras comúnmente implementado este: <% usando (Html.Form ("PerfilUsuario", "SubmitUpdate")) {% > <% = Html.AntiForgeryToken()%> <% } %> ya que este es un formulario de envío, yo no creía que fuera a la materia, y todavía don' t. pero en este punto cambiaré cualquier cosa para que funcione. –

0

Asegúrese que su ~/Web.config tiene una sección > < machineKey y que se está configurando la clave dentro de esa sección. El sistema anti-XSRF requiere que esto esté presente.

+0

Ya he hecho esto durante mi último intento de solucionar este problema. No ayudó, pero teóricamente era un paso necesario. Gracias –

+0

Si tiene acceso al registro de eventos de su máquina, ¿puede verificar si hay entradas que estén ocurriendo más o menos al mismo tiempo que la excepción inválida anti-XSRF? Por ejemplo, ¿esto ocurre inmediatamente después de reiniciar AppDomain, etc.? – Levi

+1

Voy a ver este Levi, otro pensamiento interesante. No estoy seguro de si es la caducidad de la sesión o el reinicio del dominio de aplicación en este punto; ambas sugerencias parecen plausibles. ¡gracias de nuevo! –

1

No estoy seguro si esto ayudará pero encontré que al usar Internet Explorer obtendría este error cada vez que hubiera un guión bajo '_' dentro del subdominio ... pero no en Firefox.

Sigue buscando una solución o razonamiento.

+0

Gracias ioSamurai! Nunca pensé que era el culpable. – Warren

4

Una cosa para asegurarse es have the same machine key token for all requests. Si no tiene esto y su grupo de aplicaciones se recicla, los POST subsiguientes con cookies antiguas causan este error.

Otra causa es cuando alguien tiene la configuración de privacidad muy alta y bloquea las cookies. Por ejemplo, en Internet Explorer desde la pestaña Privacidad si la configuración está configurada en Alto o Bloquea todas las cookies, se obtendría este error.

+0

Estaba recibiendo el problema en Firefox. No se pudo averiguar por qué, resulta que todas las cookies fueron deshabilitadas por alguna razón. Mi teoría es que los tuve desactivados en Firebug (que luego desinstalé), y esta configuración se mantuvo. –

8

Aquí hay una parte de mi respuesta a a similar question:

Clave del equipo y Cookies: este problema es feo, fácil de detectar (hace excepciones), pero no es muy intuitiva. Las cookies y tokens de validación se codifican y decodifican utilizando una "clave de máquina" única. Esto significa que si tiene una granja de servidores o cambia su servidor, su cookie ya no será válida. Cerrar el navegador soluciona el problema (porque la cookie es una cookie de sesión). Sin embargo, algunas personas dejan las ventanas de su navegador abiertas en el fondo durante mucho tiempo.
La solución es establecer una "clave de máquina" en su archivo de configuración. Esto le indicará a MVC que use la misma clave en todos los servidores, asegurando que la cookie se pueda descifrar en cualquier lugar.

Tenga en cuenta: si un usuario mantiene abierta cualquier ventana del navegador, incluso DESPUÉS de que cambie su clave de máquina , continuarán recibiendo estos mensajes de error. DEBEN cerrar la ventana (para borrar la cookie de sesión) para poder acceder nuevamente a su sitio web.

+1

Este es el mismo escenario que tengo, pero ya estoy usando la clave del equipo en mi web.config. La otra idea que tengo es que el usuario tiene una cookie para la función "Recordarme" que no expira. ¿Es posible que esta cookie que no está expirando esté ligada a la cookie antifalsificación/verificación de solicitud, cuando esa está caducando, siendo diferente de la cookie "Recordarme"? – ganders

0

Como dijo mpen en el comentario sobre la respuesta, veo esto todo el tiempo cuando los usuarios abandonan la página permanecen allí más de 20 minutos (el tiempo de sesión predeterminado) y el token expira.

Puede desencadenar o forzar este error (si está tratando de poner a prueba la captura de él) mediante la apertura de las herramientas de desarrollo del navegador y borrar el campo oculto __RequestVerificationToken:

<input name="__RequestVerificationToken" type="hidden" value="AqJL/+e9tGCSCXdurrXDRefVL/TAdOAG9Hjrx0oMPg6sVZY3xv099OSYlH1qI8uZyu4x2xFj9eiNVSH2BGsSfJCQAqzxfQtIKoHXNkkW2FJTkxzsNRkwZo1SJUzYGvcEJ/OJ0AouiUWh98qyIzgN2ZkKP7k="> 
Cuestiones relacionadas