🚀 go-pugleaf

> Miałem na myśli walidację danych (czy pole przeznaczone na e-mail, nawet 
> jak nazywa się dupa, zawiera coś przypominającego e-mail).

No i właśnie o tym również mówię. Jeśli nazwiesz pole email i dasz walidację 
jako email to nawet najgłupszy robot spamowy wklepie tam email, który 
przejdzie walidację.

> Jeśli przejmujesz się tak bardzo spamem, to pola na imie i nazwisko też 
> można sprawdzać pod kątem spamu - nie słyszałem, żeby ktoś miał na 
> nazwisko "http://...", a pewnie niejednego bota podkusi wpakowanie tam 
> linku.

Wiesz... to już byłby przerost formy nad treścią - trzeba szukać złotego 
środka.

> W przeglądarkach obsługujących HTTP poprawnie dostajesz poprzednią stronę 
> bez pytania i bez ponownego POST :)

A jakie to? Pod IE i FF otrzymywałem zawsze zapytanie o zgodę na re-submit i 
to było przyczyną mojej decyzji dot. zastosowania sztuczki z location. Być 
może coś w bieżących wersjach zmienili...

> W tych, które mylą cache z historią musisz użyć sztuczki z POST + status 
> 303, żeby się głupio nie pytały.

Poeksperymentuję i jeśli zadziała to zmienię choć nie bardzo rozumiem 
róznicę pomięcy samym location a location + 303. Z punktu widzenia 
użytkownika zachowanie aplikacji będzie identyczne w przypadku gdy location 
prowadzi pod ten sam URL co formularz. Może w przypadku gdy submit ma 
prowadzić do innej strony to wtedy warto 303 posłać aby powrót działał 
"poprawnie" ? To miałeś na myśli?

> W przypadku koszyka możesz przekierować spowrotem na stronę koszyka, ale 
> pod warunkiem, że strona koszyka jest niecache'owalna (nigdy nie wysyłasz 
> jej bez Cache-Control: no-cache). Alternatywnie możesz przekierować na 
> koszyk?wersja=123456

Już lepiej wyłączyć cache bo cholera wie w jaki sposób user powróci: czy 
"wsteczem", czy linkiem w treści strony, czy z palca wpisze URL.

> Tak na marginesie - obsługujesz jakoś ładnie dwukrotne wysłanie 
> formularza? (tzn. nie wielkim błędem, tylko pokazywaniem wyniku pierwszego 
> wysłania?)

Tak. Wkurzały mnie błędy z tym związane no i przerobiłem CMS aby uniknąć 
wszelkich konsekwencji podwójnego submitu.

> Problem może się zdarzyć jak ktoś dwukliknie submit albo sieć nawali zanim 
> użytkownik dostanie odpowiedź na pierwsze wysłanie formularza i umyślnie 
> wyśle go jeszcze raz. Jeśli po prostu odrzucasz użytą transakcję, to 
> operacja wykona się pomyślnie (za pierwszym razem), ale użytkownik zobaczy 
> błąd (zobaczy tylko drugi raz) i pomyśli, że się nie wykonała.

Jeśli sieć nawali no to nic nie zrobisz - cudów nie ma. Wtedy oczywiście 
user zobaczy niedostępność URL itp.i może tworzyć w głowie różne 
scenariusze - m.in. że submit nie doszedł do skutku. Jeśli natomiast kliknie 
drugi raz bo za pierwszym mu nie zadziałało (bo albo faktycznie tak było 
albo zadziałało lecz odpowiedź jeszcze nie nadeszła) to CMS zaakceptuje 
jedynie pierwszego submita, który do niego dotarł a kolejne ze przetworzonym 
już ID transakcji zignoruje.

W podtekscie pytasz jak to zrobiłem?
Banalnie... jądro systemu generuje wspólny ID dla nowych transakcji dla 
wszystkich modułów programowych, które mają zastosowanie na danej stronie 
WWW. Jeśli te moduły potrzebują formularzy HTML, to każdy z modułów ustawia 
ukryte pole  swojego formularza "id_transakcji_modulu_X". Po przeładowaniu 
każdy z modułów sprawdza czy  jego formularz zwraca wartość tego pola równą 
poprzednio wygenerowanemu ID. Jeśli tak, to przetwarza formularz, jeśli 
nie - to odtwarza tylko poprzednie wartości swojego formularza. Jedną z 
ostanich operacji jest zapamiętanie przez jądro ID_old=ID. Amen.