¿Existe una posible & # 8220; condición de carrera & # 8221; ¿Cuándo se usa Asp.Net MVC TempData en una redirección?

Question

Al usar TempData, mi entendimiento es que mantendrá todo lo que pones en él solo por una solicitud. Entonces, al usar TempData para retener datos a través de una redirección (para usar el patrón Post-Request-Get), ¿no es posible que alguna otra solicitud del usuario pueda ingresar al servidor entre la respuesta que envía la redirección y la ¿El navegador del usuario solicita la página a redirigida? En cuyo caso, get ya no tendría TempData disponible, ¿correcto?

Ahora, entiendo que algo así sucedería sería muy raro, pero teniendo en cuenta que el usuario podría tener otra página abierta en otra pestaña, y podría haber solicitudes de devolución de llamada ajax o temporizadas en esa página, de repente No me parece tan imposible. ¿Por lo general, se considera demasiado remoto como para preocuparse o estoy malinterpretando algo?

Editar: para ser más específico sobre el escenario que estaba preguntando.

1. En la pestaña 1, el usuario navega a una página. con un formulario de correo
2. En la pestaña 2, el usuario navega a otra página del sitio que sí lo hace. devoluciones de llamada ajax en un temporizador
3. En la pestaña 1, el usuario publica el formulario en el servidor
4. Cuando el servidor recibe la publicación, guarda algunos datos en TempData y devuelve una respuesta de redireccionamiento
5. En la pestaña 2, se produce la devolución de llamada ajax temporizada, enviando una solicitud GET al servidor. El TempData se elimina de la sesión
6. En la pestaña 1, el navegador recibe la redirección y emite una solicitud GET
7. El servidor procesa la solicitud GET y busca el TempData, pero ya no está allí

Answer 1

Bueno, navegar por el código ASP.NET MVC muestra que mientras TempData se almacena en la sesión, se elimina de la sesión cuando se carga. Y se carga en el método ExecuteCore () del controlador.

Así que creo que eso significaría que sí, podrías correr completamente en una condición de carrera donde una solicitud desde una pestaña diferente del navegador (tenías un buen ejemplo) podría causar este problema. Pero eso dependería del modelo de cada navegador para manejar las solicitudes. Un navegador puede serializar todas las solicitudes al mismo servidor para que solo una se ejecute a la vez. En realidad, no lo harán, sin embargo, lo limitarán al máximo, que son (creo) 5 solicitudes simultáneas al mismo servidor.

Dado que un sitio ASP.NET MVC podría ser una solicitud de servicios a cualquier navegador (es la web, después de todo :)) es un escenario real, aunque probablemente sea raro, como dijiste.

Answer 2

Es completamente posible tener una condición de carrera al usar TempData. Sin embargo, tendrías que, por supuesto, ser "desafortunado" experimentarlo bajo uso normal. Para correr en la condición de carrera, todo lo siguiente debe ser verdadero:

1. Para empezar, debes usar TempData.
2. Tienes que tener varias ventanas / pestañas / whatevers del navegador abiertas y compartiendo la misma sesión del navegador.
3. Una solicitud desde la segunda pestaña del navegador debe " infiltrarse en " entre la solicitud y la respuesta de la primera pestaña del navegador.

Tenga en cuenta que el elemento # 2 depende mucho del navegador que esté usando. Dependiendo de cómo haya configurado IE, solo porque tiene varias ventanas abiertas no significa que compartan las cookies del navegador y, por lo tanto, no necesariamente compartan sesiones (que se basan en cookies).

Sin embargo, no hay una condición de carrera en el sentido de que algo explota si te topas con él. Eso podría ser a lo que se refiere Haacked. Pero usted puede alcanzar una condición de carrera en el sentido de que establece algunos TempData en una solicitud y luego no la recuperó en la siguiente solicitud donde pensó que iba a ir para conseguirlo. Simplemente estará vacío.

Gracias Eilon

Answer 3

TempData utiliza el objeto Session, que no sufre este problema, AFAIK. ¿Te has encontrado con un problema específico con esto?

Answer 4

Creo que nunca sucederá, aunque al principio tengo la misma confusión. Piense en eso si ejecuta su aplicación web mvc en modo de depuración, entonces establece un punto de interrupción en una acción de redireccionamiento. valor, entonces obtendrá la fecha de temp en redirect viewResult y la otra vista, encontrará que la otra solicitud nunca será respondida hasta que se complete la acción de redireccionamiento. Entonces, ¿qué significa? Dijo que la aplicación mvc se ejecuta en modo de subproceso único. puede procesar una sola solicitud de una sola vez. Por lo tanto, el escenario que mencionó anteriormente nunca puede suceder.