Come visualizzare i messaggi per l'utente dopo un reindirizzamento POST + HTTP

Question

Sto utilizzando il PRG pattern per evitare l'invio di più moduli. Ha, tuttavia, un grave inconveniente: non è possibile semplicemente il echo messaggio di conferma per l'utente (ovviamente, l'utente non vedrà la pagina, verrà reindirizzato a un altro).

Quali sono le soluzioni a questo problema? Ne conosco due, ma nessuno di loro sembra perfetto.

• Utilizzare un URL di reindirizzamento personalizzato, ad esempio: http://example.com/?msg=data-saved. È senza stato, quindi penso che sia abbastanza affidabile. Ma crea problemi quando l'utente copia il collegamento, lo memorizza, ecc.
• Memorizza una variabile di sessione/cookie e controlla su ogni caricamento di pagina. Se è impostato, cancellarlo e visualizzare il messaggio. Sembra OK, ma non sono sicuro di questo - si basa fortemente sui cookie, è un po 'più complicato.

O forse ci sono altri modi che non conosco? Qualche combinazione di sessioni e parametri URL? Boh.

Qual è il modo migliore secondo te? Quale ha il minimo inconveniente? Quali sono i pro e i contro?

Answer 1

Praticamente ogni sito Web che consente agli utenti di accedere fa affidamento su un cookie. Non è una soluzione perfetta, ma è la migliore che abbiamo.

Anche la gestione delle sessioni è una di quelle cose che un framework di sviluppo web di solito si prende cura di voi.

Answer 2

Uso il metodo della variabile di sessione. Non mi piace davvero incorporare messaggi di errore per la visualizzazione nell'URL, in particolare con i problemi di salvataggio/condivisione degli URL che noti e mi piace che se l'utente ricarica la pagina di destinazione sarà un'istanza pulita.

Answer 3

Dipende dalla piattaforma su cui si sta eseguendo.

Ruby on Rails chiama questo flash [: Avviso] = "è stata eseguita vostra azione", ASP.NET MVC chiama questo TempData [ "avviso"] = "è stata eseguita vostra azione" ...

Fondamentalmente è sufficiente memorizzare i dati in HttpSession solo per un singolo round trip. In questo modo puoi recuperare i dati su un'altra richiesta web.

Answer 4

Ci sono molte altre domande di overflow dello stack che toccano questo argomento, anche se non penso che riassuma il problema in modo così chiaro. Qui ci sono alcuni:

• How do I implement the Post/Redirect/Get pattern in asp.net WebForms?
• Response.Redirect with POST instead of Get?
• Sia HTTP GET with request body e Can an HTTP GET legally contain content? affrontare la questione, e le discussioni sono la pena di leggere.
• How do I maintain ModelState errors when using RedirectToAction?

maggior parte delle soluzioni convenienti sono basata sulla sessione o avere più gravi inconvenienti (come incorporare il messaggio nella querystring).

Se non è possibile garantire la disponibilità delle sessioni, un altro (piuttosto costoso) metodo prevede il reindirizzamento a viste diverse in base al risultato dell'invio del modulo. Ad esempio, potresti reindirizzare a EditWidgetView, EditWidgetSaveSuccessfulView o EditWidgetSaveErrorView (o forse semplicemente non reindirizzare sugli errori). In alcune lingue e framework, questo non è pratico al punto da farti rinunciare a mostrare i messaggi di conferma/errore, ma in altri potrebbe valerne la pena.

Answer 5

Se non si desidera fare affidamento su sessioni per qualsiasi motivo, è possibile utilizzare un URL Get Variabile/personalizzato e, se tale variabile è presente, controllare il riferimento. Se il riferimento è corretto, quindi visualizzare il messaggio. Sì, questo fa affidamento sulla referenza inviata per mostrare il messaggio di conferma, ma altrimenti stai facendo affidamento su sessioni (che pur essendo affidabili, non sono perfette al 100% anche per tutte le soluzioni)

E onestamente, alcune i siti di grandi dimensioni che sono normalmente abbastanza buoni su questo genere di cose semplicemente attaccano un "actiondone = true" nell'URL. (Ho notato Facebook lo fa in alcuni luoghi.)

Answer 6

Venendo molto tardi a questa discussione ..

Si potrebbe utilizzare una combinazione delle due opzioni proposte.

Dopo la richiesta POST il cliente viene reindirizzato (303) per un URL che indica che ci potrebbe essere un messaggio di risposta per questa richiesta:

Client: GET http://example.com/foo.cgi 
Server: 200 Ok 

Client: POST http://example.com/bar.cgi 
Server: 303 http://example.com/foo.cgi?msg=true 

Se l'argomento msg è true il messaggio sarà guardato in la sessione e (se trovati) inclusi nella risposta al cliente.
Se l'argomento msg è ! true (o non presente), il passaggio di ricerca viene saltato.

Con questa soluzione, si impedisce il messaggio effettivo visualizzato nell'URL, l'URL indica solo che potrebbe esserci un messaggio. Inoltre, il messaggio viene visualizzato solo quando necessario (= quando viene trovato nella sessione).

Un altro vantaggio è che questa soluzione consente anche l'inclusione di controlli di cassa adeguati con le risposte HTTP.