2011-11-23 20 views
19

Estoy usando el TempData para preservar mi modelo cuando uso un RedirectToAction. Funciona bien, pero tengo una sensación persistente de que podría no ser lo correcto. Realmente trato de evitar el uso de datos de la sesión, y he leído que TempData usa la sesión. ¿Es seguro de usar? ¿Hay problemas que puedan surgir al usarlo en un entorno de carga equilibrada?TempData: ¿Es seguro?

Trivia Pregunta: "¿Es seguro?": Asígnele el nombre a la película.

+3

¿Es secreto? ¿Es seguro? – Dismissile

Respuesta

21

Sí, TempData está respaldado por el almacenamiento de la sesión, por lo que si se encuentra en un entorno con equilibrio de carga se debe tener especial cuidado al usarlo (sesiones fijas, estado de sesión persistente, etc.).

TempData ha sido la elección de facto al usar el patrón PRG, y es para lo que fue diseñado.

En cuanto a si es lo correcto ... ¡depende de su caso de uso!

PS Marathon Hombre.

+2

buena captura en maratón hombre-- buena película. –

1

He limitado el uso de TempData para pasar el mensaje de validación de objeto de modelo entre las vistas y la acción. No he estudiado el uso de Tempdata desde la perspectiva de la seguridad, pero siguiendo el hilo SO analizo lo mismo: HttpContext.Items with ASP.NET MVC. Vea los últimos comentarios de hilos y discusiones relacionadas.

2

Iría, siempre que sea posible, por un enfoque totalmente sin estado. Es más escalable y no se ve afectado por problemas con servidores individuales. Por lo general, puede usar una cookie (protegida adecuadamente contra manipulación) para identificar al usuario y extraer los datos de la base de datos en todo momento.

Además de eso, también sugiero que evalúe si puede usar View en lugar de RedirectToAction. Este:

TempData["model"] = model; 
return RedirectToAction("SomeAction"); 

pueden ser reemplazados con:

return View("SomeAction", model); 

Por supuesto asumiendo "algunaAccion" es una vista válido que es accesible desde el controlador de corriente (es cualquiera una vista en la misma ctrl o uno define en Compartido) y que no es solo una acción intermedia que redirige a otra.

+4

un problema que tengo con la vista de retorno() es que si la acción era una publicación, entonces una actualización en el navegador muestra un mensaje molesto-- cuando sea posible me gustaría terminar con get. Tal vez eso es un poco tonto. De nuevo, los datos temporales se pierden en la actualización de todos modos, así que tal vez sea un punto discutible. –

+0

Bueno, pero en realidad debería seguir los principios de RESP. Si una acción es leer datos, debería (normalmente) ser un GET. Si la acción está modificando datos, debe ser un POST (y * nunca * un GET). –

+0

@DarioSolera Aún puede hacer eso y finalizar con un GET. Digamos que tengo una acción que modifica los datos. Está en un método de acción POST. Si la validación (en el lado del servidor) de la acción falla, puede meter todo en TempData y redireccionar a la página GET para que muestre todos los errores de validación de su modelo, etc. y si actualiza la página simplemente se borrará la página en lugar de obtener el mensaje de re-publicación. – Dismissile

5

Bueno, yo diría que depende. Si maneja gran cantidad de tráfico con balanceadores de carga y múltiples servidores front-end, entonces los objetos de sesión son algo que debe evitarse porque podría degradar el rendimiento y dificultar el escalamiento horizontal (la solicitud en la granja no siempre llega al mismo servidor web).

TempData tiene una vida corta, y si no colocas muchos objetos allí y lo piensas dos veces sobre toda la arquitectura, entonces creo que es seguro. Hay muchos sitios que lo usan extensamente y no tienen problemas con él (trabajé en sitios alojados compartidos y dedicados con hasta 50-70k visitantes/día que usan sesión, a menudo con web y db en el mismo servidor).

+0

que fue útil para escuchar ... ¡gracias! –

2

estado de sesión puede trabajar en un entorno agrupado, siempre que una de dos cosas sucede

  1. su equilibrador de carga soporta "sticky" sessions (es decir,todas las peticiones en un determinado período de sesiones se dirigen a la misma máquina)
  2. Se configura el proveedor de sesión para usar un proveedor fuera de la sesión de proceso, se puede utilizar el ASP.NET State Service o la SQL Session State Provider

La cuestión de si se debería usar tempdata o no es una pregunta diferente por completo. Yo diría que generalmente hay una forma de evitarlo. Si está tratando de evitar un golpe en la base de datos para volver a cargar un objeto que una acción ya ha cargado, mire usando una memoria caché.