variable validacion tutorial sesion programando programacion peticiones paso net mvc español desde asp asp.net asp.net-mvc redirect tempdata

validacion - ¿Hay una posible "condición de carrera" cuando se usa Asp.Net MVC TempData en un redireccionamiento?



validacion en asp net mvc (4)

Cuando uso TempData, entiendo que mantendrá todo lo que ponga en él para una sola solicitud. Por lo tanto, 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 ingrese al servidor entre la respuesta que envía la redirección y la navegador del usuario que solicita la página redireccionada? En cuyo caso, el 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 todo eso imposible. ¿En 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 publicación
  2. En la Pestaña 2 el usuario navega hacia otra página en el sitio que hace retrollamadas 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 envía de vuelta una respuesta de redirección
  5. En la pestaña 2, ocurre la devolución de llamada ajax programada, enviando una solicitud GET al servidor. El TempData se elimina de la sesión
  6. En la pestaña 1, el navegador recibe el redireccionamiento y emite una solicitud GET
  7. El servidor procesa la solicitud GET y busca TempData, pero ya no está allí

Bueno, la exploración del 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í, que podría encontrarse en una condición de carrera en la que una solicitud de una pestaña diferente del navegador (tiene 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 se ejecute una a la vez. En realidad, no harán eso, sin embargo, lo limitarán al máximo, lo que es (creo) 5 solicitudes concurrentes al mismo servidor.

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


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


Es completamente posible tener una condición de carrera cuando se usa TempData. Sin embargo, tendrías que ser "desafortunado" para experimentarlo bajo el uso normal. Para entrar en la condición de carrera, todo lo siguiente debe ser cierto:

  1. Tienes que estar usando TempData para comenzar.
  2. Debe tener múltiples ventanas / pestañas / elementos de navegación abiertos y compartir la misma sesión del navegador.
  3. Una solicitud desde la segunda pestaña del navegador tiene que "infiltrarse" entre la solicitud y la respuesta de la primera pestaña del navegador.

Tenga en cuenta que el elemento n.º 2 depende en gran medida del navegador que esté utilizando. Dependiendo de cómo haya configurado IE, el hecho de que tenga varias ventanas abiertas no significa que compartan cookies del navegador y, por lo tanto, no necesariamente comparten sesiones (que se basan en cookies).

Sin embargo, no hay una condición de carrera en el sentido de que algo explote si te tropiezas con ella. Eso podría ser a lo que Haacked se refiere. Pero puede alcanzar una condición de carrera en el sentido de que configuró TempData en una solicitud y luego no la volvió a obtener en la siguiente solicitud en la que pensó que la iba a obtener. Estará vacío.

Gracias, Eilon


Creo que nunca sucederá, aunque al principio tengo la misma confusión. Piénselo si ejecuta su aplicación web mvc en modo de depuración, establece un punto de interrupción en una acción de redireccionamiento. Y le da un valor a la temperatura, entonces obtendrá la tempdate en redirigir viewResult y en la otra vista, encontrará que la otra solicitud nunca responderá hasta que se complete la acción de redireccionamiento. Entonces, ¿qué significa eso? Dijo que la aplicación mvc se ejecuta en modo de subproceso único, puede procesar un solicitud única al mismo tiempo. Por lo tanto, el escenario anterior mencionado nunca puede suceder.