asp.net mvc - tutorial - TempData: ¿Es seguro?

install asp net core linux

Question

Estoy usando TempData para conservar mi modelo cuando TempData un RedirectToAction . Funciona bien, pero tengo la molesta sensación de que podría no ser lo correcto. Realmente trato de evitar el uso de datos de 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?

Pregunta de trivia: "¿Es seguro?": Nombre la película.

Answer 1

Bueno, yo diría que depende. Si maneja gran parte del tráfico con balanceadores de carga y varios servidores front-end, entonces los objetos de sesión son algo que se debe evitar porque podría degradar el rendimiento y dificultar el escalado hotizontal (en la solicitud de granja de servidores no siempre llega al mismo servidor web).

TempData es de corta duración, y si no pones muchos objetos allí y piensas dos veces en toda la arquitectura, creo que es seguro. Hay muchos sitios que lo utilizan ampliamente y no tienen problemas con él (trabajé en sitios alojados compartidos y dedicados con un promedio de 50 a 70.000 visitantes por día que usan sesión, a menudo con web y DB en el mismo servidor).

Answer 2

El estado de sesión puede funcionar en un entorno agrupado, siempre que ocurra una de estas dos cosas

1. Su equilibrador de carga admite sesiones "pegajosas" (es decir, todas las solicitudes en una sesión determinada se enrutan a la misma máquina)
2. Configura el proveedor de sesión para usar un proveedor de sesión fuera de proceso, puede usar el servicio de estado de ASP.NET o el proveedor de estado de sesión de SQL

La pregunta de si debes usar tempdata o no es una pregunta completamente diferente. Yo diría que generalmente hay una manera de evitarlo. Si está tratando de evitar un impacto en la base de datos para recargar un objeto que una acción ya ha cargado, busque en su lugar usar un caché.

Answer 3

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

Answer 4

Iría, siempre que sea posible, para un enfoque completamente apátrida. Es más escalable y no se ve afectado por problemas con servidores individuales. Por lo general, solo puede usar una cookie (debidamente protegida contra manipulación) para identificar al usuario y extraer los datos de la base de datos cada vez.

Además de eso, también le sugiero que evalúe si puede utilizar View lugar de RedirectToAction . Esta:

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

Puede ser reemplazado con:

return View("SomeAction", model);

Por supuesto, asumiendo que "SomeAction" es una vista válida a la que se puede acceder desde el controlador actual (es una vista en el mismo ctrl o una definida en Compartido) y que no es solo una acción intermedia que redirige a otra.

Answer 5

Sí, TempData está respaldado por el almacenamiento de sesión, por lo que si se encuentra en un entorno de carga equilibrada, se debe tener mucho cuidado al usarlo (sesiones persistentes, 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 o no ... ¡depende de su caso de uso!

PS Marathon Man.