TempData No está borrando

Estoy trabajando en una aplicación Web ASP.NET MVC 3, donde uso TempData para almacenar un objeto del modelo, en el escenario en el que el usuario no se registra enTempData No está borrando

aquí está el flujo.:

Utilice el formulario de envío.
Código (filtro de acción especial) agrega modelo a TempData, redirige a la página de inicio de sesión.
usuario redirigida hacia atrás para conseguir una actuación, que dice TempData y llama acción POST directamente

Después del paso 3, tendría que TempData pensamos que sería limpiado?

Aquí está el código:

[HttpGet] 
public ActionResult Foo() 
{ 
    var prefilled = TempData["xxxx"] as MyModel; 
    if (prefilled != null) 
    { 
     return Foo(prefilled); 
    } 
} 

[HttpPost] 
[StatefulAuthorize] // handles the tempdata storage and redirect to logon page 
public ActionResult Foo(MyModel model) 
{ 
    // saves to db.. etc 
}

He encontrado this article que establece:

Los productos que sólo se dan de TempData al final de una solicitud si han sido marcados para su eliminación.
Los elementos solo se etiquetan para su eliminación cuando se leen.
Los artículos no tienen etiqueta llamando a TempData.Keep (clave).
RedirectResult y RedirectToRouteResult siempre llama a TempData.Keep().

Bueno, leyéndolo con TempData["xxx"] ¿no es una "lectura" y por lo tanto deben etiquetarse para su eliminación?

Y la última me preocupa un poco, ya que estoy haciendo una redirección después del POST (P-R-G). Pero esto no se puede evitar.

¿Hay alguna manera en que pueda decir "abandonar este elemento". TempData.Remove? ¿O estoy haciendo esto mal?

Fuente

2011-10-03 RPM1984

Debe realizar una redirección completa y no devolver un segundo método de acción. Es por eso que no está funcionando. – Buildstarted

@BuildStarted - pero el método POST * does * do un redirect después de que haya terminado. No puede hacer una redirección a un método POST, ¿no será eso un GET? – RPM1984

Bueno, por lo que estoy leyendo basándome en los datos limitados es que estás haciendo un get y una redirección * en el código * a una publicación: no se llamará a 'StatefulAuthorize'. – Buildstarted

Se corrigió añadiendo TempData.Remove justo después de que lo leí.

No estoy contento con esto. Pensé que el objetivo de TempData era que yo no lo hice tengo que hacer esto.

También se puede utilizar la sesión directamente.

Fuente

2011-10-03 03:05:17 RPM1984

Esa no es la forma de despejarlo. Podrías haber usado Session en lugar de TempData. La única ventaja con TempData es que administra los datos por sí mismo. Como lo había respondido anteriormente, el valor solo se borra cuando la acción da como resultado 200 (como ViewResult/ContentResult/JsonResult) en todos los demás escenarios, precisamente cualquier acción resultante del código de estado Http de 302 (como RedirectAction) retendrá el datos en TempData. Lea todo lo siguiente para obtener más información http://stackoverflow.com/questions/32571599/asp-net-tempdata-isnt-cleared-even-after-reading-it –

Hay 2 GET HTTP peticiones que participan aquí:

La primera petición es enviada por el cliente y es el que almacena algo en TempData
Al final de la primera solicitud del cliente envía una segunda solicitud HTTP para recuperar la página de inicio de sesión.

No hay una solicitud POST involucrada en su situación. El hecho de que a partir de su acción GET Foo invoque la acción POST Foo no significa que se está realizando una solicitud por separado (todavía se encuentra en el contexto de la solicitud GET inicial). Es solo una llamada al método C#, no una solicitud por separado.

Almacena algo en TempData durante la primera solicitud y este TempData estará disponible para el segundo. Por lo tanto, estará disponible en la acción del controlador que representa la página de inicio de sesión.

Por lo tanto, debe leer de TempData en acción, presentando la página de inicio de sesión si desea que se elimine TempData.

Fuente

2011-10-03 06:02:44

Su derecho. Pero no me importa en la página de inicio de sesión. Intento hacer una "publicación automática" cuando inician sesión, para que no tengan que volver a enviar el formulario. Es por eso que estoy "llamando" mi acción POST directamente (sé que no es una solicitud separada). Así que supongo que no debería estar usando TempData, ya que son 2 solicitudes posteriores para las cuales necesito los datos, no el siguiente. – RPM1984

A continuación se detallan algunos de los puntos clave a tener en cuenta cuando se utilizan datos de temperatura.

1) Un acceso de lectura a datos temporales no elimina elementos del diccionario inmediatamente, sino solo marcas para su eliminación.

2) Los datos de temperatura no siempre eliminarán el elemento al que se ha accedido. Solo elimina el elemento cuando una acción da como resultado un código de estado Http 200 (ViewResult/JsonResult/ContentResult, etc.).

3) En el caso de acciones que dan como resultado un Http 302 (como cualquier acción de redirección), los datos se conservan en el almacenamiento incluso cuando se tiene acceso a ellos.

Fuente

2015-05-16 01:22:59

Respuesta

Cuestiones relacionadas