🚀 go-pugleaf

> Uparcie robisz na opak :)
>
> Formularz kontaktowy _powinien_ używać POST, bo ma efekt uboczny - 
> wysłanie e-maila.

Więc nie robię na opak :-) Ponadto chyba każdy submit formularza ma na celu 
mieć efekt uboczny? Po to się to robi aby wysłać email, dodać do koszyka 
(bazy danych) noiwą pozycję zamówienia, zaktualizować w bazie danych ilości 
zamawianych produktów itp. W żadnym z tych przypadków akcja POST nie może 
się powtórzyć przy np. odświeżeniu.

> Dlatego należy robić walidację danych!

Mam walidację lecz to za mało. Nie wolno np. pola nazwać "email" bo boty 
spamowe wiedzą wtedy co tam wpisać. Pole powinno nazwyać się "dupa" lub coś 
w tym stylu. Pozostałem pola to imię, nazwisko, treść - więc nie ma czego 
walidować.

> Nie rób bezbronnych aplikacji (security by obscurity) polegając na tym jak 
> bardzo komuś się (nie)chce. Zrób to porządnie tak, żeby nie było 
> oczywistych dziur w użyciu danych POST, GET, cookies i innych.

Nie robię - nawet robię sporo więcej: stosuję ID transakcji a w skrajnych 
przypadkach - generowanie wartości pola przez JS.

> Powiedziałem dobrym botom. Te złe i tak będą ci łaziły po wszystkich 
> formularzach - GET (harvestery) i POST (spamboty).

Hmmm... założyłem, że się przejęzyczyłeś. A co to zmieni jeśli złe i tak 
będą spamowały - jak sam napisałeś? Dobre przecież nie są źródłem spamu.


> Nie rozumiem o czym mówisz. Wyszukiwarka = GET. Koszyk = POST. 
> Wyszukiwarka != koszyk.

Ok... może przykład. Jestem na karcie produktu. Dodaję produkt do koszyka 
(np. POST), w koszyku aktualizuję ilość (POST) klikam wstecz i co dostaję? Z 
pewnością nie stronę produktową lecz komunikat o próbie submitu formularza. 
W "moim" podejściu te dwa POSTy nie są widoczne dla przeglądarki i wstecz 
przenosi tam gdzie user oczekuje - do produktu.

> Przeglądarka wysyła POST. Obrabiasz dane, wysyłasz status 303 i nagłówek 
> Location. Przeglądarka załaduje nową stronę używając GET. Wracanie działa 
> tak, jak zawsze powinno.

Hmm.. ciekawe. Poeksperymentuję bo faktycznie nie pomyślałem o takim 
podejściu. Mam jednakże pewną wątpliwość... a co jeśli naszą intencją jest 
pozostanie na tej samej stronie? Przykładowo taki przypadek ma miejsce przy 
aktualizacji ilości w koszyku albo akceptacji kryteriów w wyszukiwarce.

> To jest mniejwięcej to, co opisałeś na początku wątku. Sęk w tym, żeby to 
> stosować tylko wtedy, gdy potrzeba POST (czyli nie przy wyszukiwaniu) i 
> żeby URL podany w Location zawierał coś unikalnego zależnego od danych z 
> POST, jeśli ma z nimi jakiś związek (jeśli wyświetlasz tylko stronę z 
> "dziękujemy za wysłanie formularza", to nie musi być unikalny. Jeśli 
> wyświetlasz "dodałeś czajnik do koszyka", to powinien być unikalny, żeby 
> po dodaniu czegoś innego do koszyka użytkownik na pewno nie dostał strony 
> o czajniku).

Tak, ja nawet dołączam ID transakcji - nie tylko jest wtedy unikalny lecz 
nie pozwala na celowe powtórzenie operacji. Każdy moduł programowy CMS'a, 
który przetwarza dane z formularzy bada zgodność ID transakcji z formularza 
z poprzednio obowiązującym i dopiero wtedy traktuje dane jako 
uwierzytelnione. Każde przeładowanie = nowy ID.

> Jeśli masz w aplikacji choć odrobinę abstrakcji, to powinno dać się używać 
> GET na początku i bezboleśnie przerobić na POST, jeżeli ilość pól urośnie 
> do niebezpiecznego rozmiaru.

Ja dmucham na zimne i POST stosuję wszędzie :-) Szczerze mówiąc tylko przy 
wyszukiwarce widziałbym uzasadnienie stosowania GET ale to też obarczone 
byłoby ryzykiem. Nie chciałem wdawać się w szczegóły lecz widzę, że 
powinienem. Otóż w swoim CMSie udostępniam możliwość konfigurowania 
wyszukiwarki z poziomu sekcji redakcyjnej. Właściciel sklepu / portalu / 
prostej strony WWW sam decyduje jakie kryteria i w jakich wyszukiwarkach w 
systemie mają być dostępne. Mało tego - sam określa jakie cechy posiada dany 
dokument / produkt. Wszystkie z nich mogą stanowić kryteria wyszukiwania - 
to kwestia kliknięcia tylko. Tak więc chcąc uniknąć niespodzianek związanych 
z przekroczeniem długości GET - stosuję POST.

> W praktyce jednak z tym się nie spotykam. Formularz, który ma kilkaset pól 
> albo opcji do zaznaczenia w <select> najczęściej jest też zbyt 
> skomplikowany dla użytkowników i robi zbyt wiele rzeczy na raz. Taki 
> formularz dzielę na mniejsze (coś a'la wizard) albo wybór spośród setek 
> indywidualnych opcji zamieniam na coś innego - np. wybór całych 
> grup/kategorii albo wg. tagów/słów kluczowych.

Takie wielopolowe formularze mają zastosowanie np. przy ręcznym 
aktualizowaniu cen produktów. Wtedy dobrze jest wykorzystać listę produktów 
i pól cenowych. Natomiast w wielu pozostałych przypadkach wystarczy jedno 
pole aby przepełnić możliwości GET. Takim polem jest np. "treść wiadomości" 
w formularzu kontaktowym lub "uwagi do zamówienia" w koszyku. Nie 
ogranicznam ilości znaków bo nie powinienem.