TempData: è sicuro?

Question

Sto utilizzando lo TempData per conservare il mio modello quando si utilizza uno RedirectToAction. Funziona bene, ma ho la sensazione fastidiosa che potrebbe non essere la cosa giusta da fare. Cerco davvero di evitare l'uso dei dati di sessione, e ho letto che TempData utilizza la sessione. è sicuro da usare? Ci sono problemi che potrebbero sorgere nell'usarlo in un ambiente con bilanciamento del carico?

Domanda trivia: "È sicuro?", Nome del film.

Answer 1

Sì, TempData è supportato dall'archiviazione della sessione, quindi se ci si trova in un ambiente con carico bilanciato occorre prestare particolare attenzione quando lo si utilizza (sessioni permanenti, stato sessione persistente, ecc.).

TempData è stata la scelta di fatto quando si utilizza il modello PRG, ed è ciò per cui è stato progettato.

Se è la cosa giusta da fare ... dipende dal tuo caso d'uso!

PS Marathon Man.

Answer 2

Ho limitato l'utilizzo di TempData per passare il messaggio di convalida dell'oggetto modello tra viste e azione. Non ho esaminato l'utilizzo di Tempdata dal punto di vista della sicurezza, ma il seguente thread SO discute lo stesso: HttpContext.Items with ASP.NET MVC. Vedi gli ultimi commenti sui thread e discussioni correlate.

Answer 3

Vorrei andare, quando possibile, per un approccio completamente apolidi. È più scalabile e non è influenzato dai problemi con i singoli server. In genere, è sufficiente utilizzare un cookie (protetto adeguatamente contro la manomissione) per identificare l'utente e prelevare i dati dal database ogni volta.

Oltre a ciò, suggerisco anche di valutare se è possibile utilizzare View anziché RedirectToAction. Questo:

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

può essere sostituito con:

return View("SomeAction", model); 

Naturalmente assumendo "SomeAction" è una vista valido che è accessibile dal regolatore di corrente (è sia una vista nella stessa CTRL o una definita in Shared) e che non è solo un'azione intermedia che reindirizza a un altro.

Answer 4

Beh, direi che dipende. Se gestisci molto traffico con load balancer e server front-end multipli, gli oggetti di sessione sono qualcosa da evitare perché potrebbero degradare le prestazioni e rendere difficile il ridimensionamento in modalità hotizontal (la richiesta di farm non arriva sempre allo stesso server web).

TempData è di breve durata, e se non ci metti molti oggetti lì e ci pensi due volte sull'intera architettura, penso che sia sicuro. Ci sono molti siti che lo usano estensivamente e non hanno problemi con esso (ho lavorato su siti host condivisi e dedicati fino a circa 50-70k visitatori/giorno che utilizzano la sessione, spesso con web e db sullo stesso server).

Answer 5

stato di sessione può funzionare in un ambiente cluster, a condizione che una delle due cose accade

1. tuo bilanciamento del carico supporta "sticky" sessions (cioètutte le richieste in una determinata sessione vengono instradati alla stessa macchina)
2. Si configura il provider sessione di utilizzare un fuori fornitore sessione di processo, è possibile utilizzare il ASP.NET State Service o SQL Session State Provider

La questione se si dovrebbe usare tempdata o no è una domanda completamente diversa. Direi che di solito c'è un modo per aggirarlo. Se si sta tentando di evitare un hit nel database per ricaricare un oggetto già caricato da un'azione, cercare invece di utilizzare una cache.