Názory k článku
Post-Redirect-Get (nejen) v ASP.NET MVC

Používáme Post-Redirect-Get ve všech aplikacích tak asi 10 let a nemáme jediný problém s duplicitou odeslaných dat. Neznám ani framework s podporou jedinečných klíčů. To je pro změnu můj názor za léta programování pro web.

IMHO pán architekt měl na mysli situaci, kdy se uživatel po regulérním odeslání formuláře vrátí na předchozí stránku s formulářem a znovu klikne na „Odeslat“. To opravdu redirect after POST nevyřeší.

Což pravda nic nemění na tom, že redirect after POST je naprosto základní technika, která by se měla aplikovat vždy a všude :-)

Jde o to, že po tom použití tlačítka zpět uživatel znovu odešle formulář. Typicky stránka (skript) která formulář zpracuje je v pořádku (všechny data se zpracovaly v pořádku) a až na té přesměrované se něco „pokazí“ (nenačte se správně, internal server error, atp.). Když dá uživatel F5, nic se nestane, protože to řeší PRG. Ale spousta (většina) uživatelů F5 nezná/nepoužívá, dají místo toho zpět a pošlou formulář znovu.

Mimochodem s tím jedinečným klíčem ve formuláři se dá pořešit i situace, kdy dojde k neočekávané chybě už během zpracovávání dat z formuláře. Né vždy může celé zpracování probíhat jako transakce, která když se nedokončí, tak se nic nestane. Po opětovném odeslání formuláře uživatelem může aplikace ověřit/dokončit předchozí pokus o zpracování dat.

Jasně, ale je tu jeden zásadní rozdíl: při Post-Redirect-Get je jediná možnost, jak může uživatel formulář odeslat ta, že vyvolá explicitní odeslání formuláře (tj. např. siskne tlačítko ve formuláří, nebo odentruje pole ve formuláři). Nikdy se to nestane mimoděk (např. tlačítkem zpět, apod.).

Opakované odeslání klávesou F5 to neřeší, pokud F5 stiskneme ještě v době, kde se zpracovává první stránka (tedy ta, která zpracovává přijmutá data a následně odesílá redirect).

Ale jinak samozřejmě je základní technika, i když ji nelze použít pro zabránění odeslání formuláře vícekrát.

Dík za moc pěkný článek, jen bych PRG rozhodně nenazval návrhovým vzorem.

Zdravim,

PRG je nahodou celkem pekne reseni (asi otazka nazoru). Rad bych ale nadhodil k diskuzi, jak resit vetsnou uzivatelu ocekavanou zpravu o uspesnosti / neuspesnosti pozadavku.

situace rekneme pridani uzivatele v nejakem foru: GET /user/add
- uzivatel vyplni formular POST /user/add
- server zpracuje pozadavek a uzivatele do DB prida, posle 303 na /user/list GET /user/list
- uzivatel vidi seznam jiz existujicich uzivatelu

ovsem u tohoto seznamu urcite nechce hledat sveho uzivatele, zda byl pridan nebo ne. Tedy rad by videl krasnou zdlenou hlasku „uzivatel uspesne pridan“

jedno reseni, ktere me napada je poslat si zpravu jako get parametr, napriklad /user/list?msg=us­pesne%20pridan

toto reseni ma ale tu nevyhodu, ze ted kdyz uzivatel provede reload, uvidi zpravu znovu a zdesi se, ze uzivatel byl pridan znovu. Jine reseni me napada pridat si treba hlavicku do HTTP, kterou pak parsuji napr. javascriptem a na zaklade ni uzivateli zobrazim zpravu. Ale to mi zase neprijde moc koser vuci HTTP

jak toto resite vy?

Vida, do session si ukladat veci, o kterych pri nejblizsi prilezitosti informovat … proc me to nenapadlo driv :)

Dobry napad, dik

A jak řešíte situace kdy není jednoznačné kam chce dále uživatel pokračovat, například nechce zobrazit seznam, ale přímo záznam vytvořeného uživatele, nebo chce ten seznam, nebo dokonce zůstat na stránce a přidat dalšího uživatele, atd…? Na straně serveru při zpracování post vyberete ten správný redirect, pokud ano, dává Vám to smysl? ;)

Redirekty a různé sofistikované ochrany před XSRF jsou pěkná věc, ale jen do chvíle, než opravdu potřebujete nějakou akci udělat 10× a místo 10-ti zmáčknutí F5 musíte 10× vyplňovat tatáž data. Proto mám raději po vyplnění formuláře stránku, na které je jen a pouze výsledek operace a bez redirektu (automatického).