🚀 go-pugleaf

On Mon, 09 Mar 2009 10:58:31 -0000, Marek <marek1967@spam.interia.pl> wrote:

> Więc nie robię na opak :-) Ponadto chyba każdy submit formularza ma na  
> celu mieć efekt uboczny? 

Zazwyczaj tak. Wyjątkiem jest wyszukiwanie, zmiana widoku (jeśli masz pole wyboru z kryteriami sortowania albo ilością elementów na stronie), wybieranie opcji przy ściąganiu programów (np. radio buttony z wersją językową programu), itp.

> 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ć.

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

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.

>> 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.

No właśnie nic nie zmieni. Wcześniej pisałeś, że spam dyktuje twój wybór GET/POST. Tłumaczę, że przed spamem i nadużyciami trzeba się bronić w obu przypadkach, więc nie powinno to być czynnikiem w wyborze między GET/POST.

> 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 przeglądarkach obsługujących HTTP poprawnie dostajesz poprzednią stronę bez pytania i bez ponownego POST :)

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

> 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.

Wyszukiwarka nie powinna używać POST. Do wyszukiwarki używaj GET. Wtedy niedoróbka IE/FF nie przeszkadza.

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

> 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.

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

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.

-- 
http://pornel.net
this.author = new Geek("porneL");