> No cóż, jak dla mnie, to o wiele za szczegółowe.

Dla mnie również. Dlatego trzeba uprościć temat bo nie ma idealnego
rozwiązania.

>. Wyszukiwarka równie
> dobrze może być zupełnie wyłączona z hierarchii serwisu,

:-)))))))
Zacytuję moje słowa 2 wątki wyżej:
"Nie zawsze.W przypadku funkcjonalnych sekcji serwisu WWW nie będących
dokumentem pojęcie kategorii nie istnieje więc nie można np. wyszukiwarki
czy modułu newsów umieścić na jakimkolwiek poziomie hierarchii."

Po tym poprosiłeś mnie o rozwinięcia a następnie piszesz to samo lecz już
jako autor powyższej kwestii. :-D

> a jeśli równoległych
> hierarchii da się wydzielić kilka -- ale jednoznacznych -- to relatywnie
> niewielkim wysiłkiem można treść sklasyfikować na kilka sposobów, dając
> możliwość przeglądania w kilku hierarchiach (jakieś przyciski w menu
> z opisami choćby "według kształtu", "według przeznaczenia", "według
> pochodzenia" i po ich wybraniu chodzenie po kategorii z breadcrumbsami
> odzwierciedlającymi daną hierarchię). Jeśli nie da się jednoznacznie
> klasyfikować, lepsze są jednak tagi.

Tak to właśnie ująłem również w którymś z wątków. Streściłbym to tak:
- "wstecz" niech robi przeglądarka
- przedstawiamy tylko lokalizację dokumentu w hierarchii
- jeśli hierarchii jest kilka to możemy w różnych aspektach ten sam dokument
prezentować

Co do ostatniego punktu to miałbym zastrzeżenie -może okazać się, że lista
ścieżek prowadzących do produktu będzie większa niż jego opis :-)

do góry

On Sat, 07 Mar 2009 19:01:51 -0000, Marek <m...@s...interia.pl> wrote:

>> Ale POST wcale nie jest bezpieczniejszy niż GET! W obu przypadkach
>> każdy ma możliwość przesłania ci dowolnych danych.
>
> Ja nie mówiłem o bezpieczeństwie wcale lecz o utrudnieniu ingerencji.
> Powiem na przykładzie: był kiedyś formularz kontaktowy na jakimś
> serwisie wykorzystujący GET.

Uparcie robisz na opak :)

Formularz kontaktowy _powinien_ używać POST, bo ma efekt uboczny - wysłanie e-maila.

> POST ruch natychmiast ustał. Dodatkowo dorzuciłem jeszcze w ukrytym polu
> ID transakcji aby jeszcze bardziej ograniczyć działalność botów
> spamerskich.

Spam to jest osobna sprawa i spambotom wcale nie jest trudniej wysłać dane przez POST
niż GET (co dobrze wiem po przeanalizowaniu parunastu milionów spamów na sblam.com)

> Ale to już wymaga znacznie większej ilości pracy. Niewiele osób ma
> ochotę grzebać aż tak głęboko. GET wypełnią nawet nudzące się dzieci.

Dlatego należy robić walidację danych! 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.

>> POST przyciąga spamerskie boty znacznie bardziej niż GET, a dobrym
>> botom można zakazać GET w robots.txt.
>
> Sęk w tym, że identyfikacja takiego bota jest żadna. Przypadkowy IP,
> podszywanie się pod przeglądarkę itp. Nie ma jak zakazać.

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

>> OK, ale proponuję to robić dodatkowo, a nie zamiast tworzenia
>> niezawodnych URL-i.
>
> No dobrze, a po co w serwisie dwie wyszukiwarki oferujące to samo tyle
> tylko, że jedna pracująca w trybie GET i nie pozwalająca na łatwy
> powrót do niej gdy w łąńcuszku zdarzeń jakiś POST się przytrafił?

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

>> To nie ma związku z wyszukiwarką, szczególnie jakbyś prawidłowo użył GET.
>
> Akurat to ma związek m.in. z wyszukiwarką i każdym innym formularzem w serwisie.

Nie musisz robić wszystkich formularzy tą samą metodą! Wręcz odwrotnie - bardzo ważne
jest użyć odpowiedniej metody do odpowiedniego rodzaju formularza.

>> Kiedy potrzeba użyć POST, to ten bug obchodzi się wysyłając status 303
>> i przekierowanie.
>
> Nie zaskoczyłem? Co można w ten sposób zyskać i jak miałoby to działać?
> Jeśli możesz to przedstaw mi krok po kroku wypełnienie formularza i
> wpływ tej medody na problem "wstecz".

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.

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

>> Tego się nie czepiam. Czepiam się, że używasz POST zamiast GET tam,
>> gdzie się nie powinno.
>
> POST tak czy owak muszę stosować choćby z uwagi na limit danych GET.

No, ok. Jeśli masz tyle danych, że nie mieszczą się w GET to nie ma wyjścia.

> zamkniętych rozwiązań typu wyszukiwarka Google. Gdy co jakiś czas musisz
> dodawać nowe funkcje, bo klient tak sobie życzy, to zrobisz sobie
> krzywdę prędzej czy później bazując na GET.

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.

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.

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

do góry

On 07.03.2009, Marek <m...@s...interia.pl> wroted:

>> Tagi to po prostu rodzaj etykiet. Termin "słowa kluczowe" może być mylący,
>> bo jest bardziej ogólny (np. stosowany dla terminów wyszukiwania etc).
>> Chmury to rodzaj wizualizacji, najczęściej tagów "społecznościowych",
>> czyli metadanych dodawanych przez samych użytkowników, ale spotyka się
>> też np. tagi stosowane przez autorów serwisu, z możliwością użycia np.
>> przy wyszukiwaniu.
>
> Chmury stosuje np. Empik... Jednakże nadal nie bardzo wiem jak po stronie
> wizualnej te tagi miałyby występować. Jak klienci mieliby operować nimi
> podczas wyszukiwania jeśli nie są to słowa kluczowe, które gdzieś wpisać
> można?

To zależy, widywałem serwisy (cholera, jak trzeba, to nie mogę znaleźć)
w których tagi były do wyboru w formularzu. W prostej postaci jest to
dość popularne w różnych CMSach, kiedy wchodzisz do wyszukiwarki, masz
opcje szukania: wszystko, artykuły, nowości, ogłoszenia, sondaże itd.
Decydujesz co przeszukasz na podstawie ogólnej klasyfikacji typu treści.
Zdarzają się też bardziej rozbudowane. Zaznaczasz po prostu jakimiś
buttonami z etykietami co Cię interesuje.

GS
--
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Nocturnal Infiltration and Accurate Killing

do góry

On 07.03.2009, Marek <m...@s...interia.pl> wroted:

>>. Wyszukiwarka równie
>> dobrze może być zupełnie wyłączona z hierarchii serwisu,
>
>:-)))))))
> Zacytuję moje słowa 2 wątki wyżej:
> "Nie zawsze.W przypadku funkcjonalnych sekcji serwisu WWW nie będących
> dokumentem pojęcie kategorii nie istnieje więc nie można np. wyszukiwarki
> czy modułu newsów umieścić na jakimkolwiek poziomie hierarchii."
>
> Po tym poprosiłeś mnie o rozwinięcia a następnie piszesz to samo lecz już
> jako autor powyższej kwestii. :-D

Hm, widomy znak tego, że za pierwszym razem czegoś nie dorozumiałem.

>> a jeśli równoległych
>> hierarchii da się wydzielić kilka -- ale jednoznacznych -- to relatywnie
>> niewielkim wysiłkiem można treść sklasyfikować na kilka sposobów, dając
>> możliwość przeglądania w kilku hierarchiach (jakieś przyciski w menu
>> z opisami choćby "według kształtu", "według przeznaczenia", "według
>> pochodzenia" i po ich wybraniu chodzenie po kategorii z breadcrumbsami
>> odzwierciedlającymi daną hierarchię). Jeśli nie da się jednoznacznie
>> klasyfikować, lepsze są jednak tagi.
>
> Tak to właśnie ująłem również w którymś z wątków. Streściłbym to tak:
> - "wstecz" niech robi przeglądarka
> - przedstawiamy tylko lokalizację dokumentu w hierarchii
> - jeśli hierarchii jest kilka to możemy w różnych aspektach ten sam dokument
> prezentować
>
> Co do ostatniego punktu to miałbym zastrzeżenie -może okazać się, że lista
> ścieżek prowadzących do produktu będzie większa niż jego opis :-)

No tak, umiar trzeba zachowywać. To, że się _da_ zastosować siedem
równoległych hierarchii nie znaczy że _trzeba_ to robić.

GS
--
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Nocturnal Infiltration and Accurate Killing

do góry

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

do góry

> To zależy, widywałem serwisy (cholera, jak trzeba, to nie mogę znaleźć)

Nie wiedziałeś w końcu, że będziemy gadać o tym :-)

> w których tagi były do wyboru w formularzu. W prostej postaci jest to
> dość popularne w różnych CMSach, kiedy wchodzisz do wyszukiwarki, masz
> opcje szukania: wszystko, artykuły, nowości, ogłoszenia, sondaże itd.

We wspomnianym Empiku masz wyszukiwanie np. w muzyce, filach, książkach itp.
Jednakże ja to nazywam bardzo konkretnie: wyborem kategorii produktu /
dokumentu. Nie nazwałbym tego tajemniczo brzmiącym "tagiem".

> Decydujesz co przeszukasz na podstawie ogólnej klasyfikacji typu treści.
> Zdarzają się też bardziej rozbudowane. Zaznaczasz po prostu jakimiś
> buttonami z etykietami co Cię interesuje.

A to również jest dość proste w realizacji.Ja takie rzeczy buduję z
wykorzystaniem alternatywnych drzew kategorii. Jeden produkt może należeć do
kilku kategorii. Każdy z tych zestawów kategorii może stanowić kryterium w
wyszukiwarce.

do góry

> Hm, widomy znak tego, że za pierwszym razem czegoś nie dorozumiałem.

Nie ma problemu :-) Ale za plagiat i tak odpowiesz :-))))

do góry

On 09.03.2009, Marek <m...@s...interia.pl> wroted:

>> w których tagi były do wyboru w formularzu. W prostej postaci jest to
>> dość popularne w różnych CMSach, kiedy wchodzisz do wyszukiwarki, masz
>> opcje szukania: wszystko, artykuły, nowości, ogłoszenia, sondaże itd.
>
> We wspomnianym Empiku masz wyszukiwanie np. w muzyce, filach, książkach itp.
> Jednakże ja to nazywam bardzo konkretnie: wyborem kategorii produktu /
> dokumentu. Nie nazwałbym tego tajemniczo brzmiącym "tagiem".

Bo to jest prosty przypadek, pokrywający się z kategorią w serwisie. Ale
bodajże jakieś TikiWiki ma już takie dowolnie definiowane "cross-kategorie",
gdzie możesz np. książkę i film opatrzyć tagiem "dokumentalny" i szukać
tylko w obrębie takich dodatkowych, luźnych kategorii bez budowania
oddzielnej hierarchii.

>> Decydujesz co przeszukasz na podstawie ogólnej klasyfikacji typu treści.
>> Zdarzają się też bardziej rozbudowane. Zaznaczasz po prostu jakimiś
>> buttonami z etykietami co Cię interesuje.
>
> A to również jest dość proste w realizacji.Ja takie rzeczy buduję z
> wykorzystaniem alternatywnych drzew kategorii. Jeden produkt może należeć do
> kilku kategorii. Każdy z tych zestawów kategorii może stanowić kryterium w
> wyszukiwarce.

Owszem, to alternatywa, jeśli da się ładnie ułożyć kolejne drzewko
klasyfikacji.

GS
--
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Nocturnal Infiltration and Accurate Killing

do góry

On Mon, 09 Mar 2009 10:58:31 -0000, Marek <m...@s...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");

do góry

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

do góry