Dotaz: Doporučte vhodné řešení v PHP

[MAN]

Zdravím, chtěl bych se zeptat zdejších zdatných programátorů, jestli by mi neporadili jak řešit takovou situaci v php. Mám nějakou stránku /registration, na této stránce mám formulář pro novou registraci, po odeslání se zpracují případné chyby a pokud je vše v pořádku form se odešle. Teď se chci zeptat jak dál pokračovat. Má se stránka přesměrovat na nějakou jinou? Má se zůstat na původní stránce? Narážím na to, že s každé stránky se lze vrátit v prohlížeči zpět a tudíž user může znova form odeslat, což se mi nelíbí, a to i za situace, že jsem ihned všechny $_POST unsetoval. Header taky nic moc neřeší, jelikož třeba opera dokáže opět vrátit předchozí stránku. Pokud se někdo podělí, budu rád. Děkuji

Odpovědi

[Kit]

Ano, po každém zpracování požadavku POST je dobré stránku ihned přesměrovat. Nejlépe na sebe samu. Je zbytečné generovat výstup, stačí jen poslat header() a hned exit().

[Šangala]

Pomocí header() přesměrovat je dobrý krok (jak psal Kit třeba i na sebe samu).
Zabránit opětovnému odeslání lze jednoduše takto:
Při generování formuláře vygenerovat „ticket“ (něco jako md5(time() . $salt));), tento „ticket“ si uložit na serveru (třeba jako session proměnnou) a současne ji dát do hidden input-u.
Po odeslání jako první na straně serveru kontrolovat jestli „ticket“ ve formuláři je totožný s tím v uloženým na serveru (session proměnné, zde je první potřeba ověřit existenci a pak srovnat), jako druhý krok (nezapomenout!) smazat „ticket“ ze serveru (odstranit session proměnnou).
No a pak přesměrovat pomocí header() na OK nebo i Chyba stránku.
Takto můžete jednoduše i informovat uživatele, že to odesílá znovu a pod., ale také můžete hidden input změnit za text input a vygenerovat obrázek „captcha“ (nebo dočasně jen text) k opsání.

Také můžete zaměnit odstranit session proměnnou za pomocí jiné proměnné (její exitence nebo pravdivostní hodnoty) mít informaci, že TENTO formulář (podle ticket-u) již byl odeslán. (Při opětovném vstupu na stránu s formulářem se tato informace ztratí, protože vygeneruje druhý ticket)

PS: Obecně unset-ovat něco z $_POST nemá obvykle význam, a ve vašem případě vůbec žádný, tyto proměnné jsou vytvořeny z uživatelem odeslaných dat a existují jen po dobu běhu skriptu (při opětovném odeslání jsou samozřejmě opět vytvořeny).

[jos]

pošli registraci ajaxem, odpověď ze serveru pak bude buď chybová hláška, nebo url na kterou se má pokračovat

oproti Šangalovo řešení s ticketama je to IMHO implementačně jednodušší, ale jen do tý doby, než se budeš pokoušet ošetřit i lidi co maj vypnutej javascript

[Jendа]

pošli registraci ajaxem

Aneb jak zavést JavaScript tam, kde HTML nabízí už 15 let jednoduché řešení.

odpověď ze serveru pak bude buď chybová hláška, nebo url na kterou se má pokračovat

No ale k tomu není potřeba Ajax, stačí normálně odeslat formulář a server vrátí buď chybu nebo redirect.

Šangala podle mě JS nepotřebuje.

Jinak pokud by to autor nepsal v čistém PHP, ale použil nějaký framework (pro začátek alespoň Nette Forms), tak si ušetří dost času s ověřováním, generováním chybových hlášek, vracením formuláře atd.

[jos]

to jednoduchý řešení tazateli ale nevyhovuje, jestli nejsem úplně mimo, tak prohlížeč i když dostal redirect stejně na zmáčknutí tlačítka zpět bude chtít postovat informace znovu

takže jestli si ještě nerozumíme - nevim o tom, že by se prohlížeč libovolným způsobem pokoušel postnout data který šly ajaxem

[George O.]

Ajax je docela nebezpecna dvousecna zbran. Nedokazu si predstavit, co je praktickeho na pouziti ajaxu prave na registraci. Ajax se hodi mozna na nejake chaty a jine widgety, kde neni zivotne dulezity pristup indexacnich robotu, ale jinak to zavani ubitim serveru

[jos]

co je praktickeho na pouziti ajaxu prave na registraci

třeba že to řeší tazatelovo problém?

zavani ubitim serveru

ubitím serveru pak ale zavání nasazení čehokoliv na ten server ;)

[George O.]

Tazateluv problem resi redirect sam na sebe nebo na jinou stranku po zpracovani requestu, jak je tomu u vsech webovych aplikaci napsanymi profesionaly

A jinak ubiti normalnim http requestem neni tak realne, protoze si drzi po nejakou dobu aktivni connection (keep-Alive), narozdil od ajaxu, kdy se pri kazdem requestu vytvari spojeni nove a je tam tim padem mnohem vetsi potencial k ubiti serveru

[jos]

Tazateluv problem resi redirect sam na sebe nebo na jinou stranku po zpracovani requestu, jak je tomu u vsech webovych aplikaci napsanymi profesionaly

talk is cheap, show me the code

pomocí header() se mi problém s tlačítkem zpět vyřešit nepodařilo, firefox se sice brání, ale nakonec ty data klidně postne znova; rád se přiučim (bez ironie)

ad keep-alive - nad tim sem nepřemejšlel, ale dle prvních pár hitů v googlu nemluvíš pravdu, ono by od výrobců prohlížečů bylo dost hloupý nerecyklovat spojení v případě ajaxu

[George O.]

Tak ciste logicky, pokud mas registraci a chces znovu odeslat post data, pak ti stejne pokus o registraci selze, protoze dany user s loginID uz v databazi je... Jinak bohate staci do header() pridat code 303: header('Location: nekam', true, 303);

A jinak k tomu connection, nejde o to, co si drzi prohlizec, ale co drzi web server. Server uzavre asynchronni connection hned po odeslani Ajax response. Takze posles treba ajax 5 pozadavku (napr. v praxi suggestion) a muzou se ti vratit response v jinem poradi, protoze nejdou ve fronte, ale pro kazdy ajax request se otevre nove spojeni

[jos]

Tak ciste logicky, pokud mas registraci ....

selhat může a nemusí, už sme to řešili o kus níž http://www.abclinuxu.cz/poradna/programovani/show/365331#6

Jinak bohate staci ...

nestačí, muj prohlížeč se chová furt stejně blbě

k tomu zbytku - zní to docela rozumně, ale nevěřim že se takhle chovají všechny kombinace prohlížeč vs. webserver; kromě toho IMHO webserver nic nedrží, webserver dostává hlavičky z klienta a ten mu může nabullshitit cokoliv

[Šangala]

Tím se problém jen skryje, ne odstraní.

[jos]

to nechápu, pokud je uživatel opravdu schonej zmáčknout odesílací čudlík formuláře dvakrát, tak to nepovažuju za problém aplikace

[Šangala]

Vyřeší to to, že běžný uživatel v běžném prohlížeči neprovede dvojí odeslání stiskem tlačítka zpět, ale odeslat stejný formulář vícekrát stále lze, tedy to problém neřeší jen skrývá.

pokud je uživatel opravdu schonej zmáčknout odesílací čudlík formuláře dvakrát, tak to nepovažuju za problém aplikace

pokud toto aplikace nezpracuje korektně, tak to jednoznačně problém aplikace je.

[jos]

jo takhle, jasný, v případě registrace (snad oprávněně) předpokládam, že uživatel dodal nějakej identifikátor, takže pokud to opravdu pošle dvakrát, tak ho (obvykle) server pošle do někam, že takovej identifikátor už existuje

na druhou stranu když uživatel dá zpět, pozmění identifikátor, odešle, tak v mým řešení se zaregistuje podruhý s různejma údajema, v tvým řešení bude čučet jak puk co že se to stalo (a pak si přečte chybovou hlášku a odnaviguje se jinak)

[Šangala]

bude čučet jak puk co že se to stalo (a pak si přečte chybovou hlášku a odnaviguje se jinak)

Ano bude pukem. Otázkou je jestli to je nebo není žádané. V kombinaci s přesměrováním, je kladena překážka na to dát „zpět“, takže je naznačeno „tudy ne“ a pokud se dozví „si puk, bo jsi neposlechl“ není nic špatného. Pokud je vhodné opakovaně zadávat, tak je daleko snazší, na stránce potvrzení, nabídnou “zadat další“.
Jinak je jasné, že pokud existuje jednoznačný identifikátor a je vhodné/možné ho tak použít (tedy i je povolené informovat o jeho existenci) tak je to snazší. Ale spousta formulářů i registračních takový identifikátor nemá.

[jos]

souhlas v plným rozsahu

[George O.]

IMHO resite blbosti, pridanim 303 code do funkce header() se problem resi.

[Josef Kufner]

To, co hledáš, se nazývá Redirect After Post. Jednoduše řečeno, po úspěšném zpracování Post požadavku pomocí header() řekneš prohlížeči, ať udělá Get (který pak bude mít prohlížeč v historii).

Druhou věcí, kterou chceš, je obrana proti útoku Cross-site request forgery. To spočívá ve vytvoření náhodného tokenu při předání formuláře uživateli, a jeho následném zneplatnění po zpracování formuláře. Každá instance formuláře je tedy použitelná nanejvýš jednou. Tím se vyřeší i obrana proti double clicku na odesílací tlačítko formuláře na nepříliš svižném připojení. Vhodné chování v případě neplatného tokenu je opětovné zobrazení formuláře stejně, jako by uživatel nevyplnil povinné pole.

Dále si pak přečti něco o REST, pomůže ti to s designem aplikace.