W dniu 2012-12-09 20:46, HARY pisze:
> On Sun, 09 Dec 2012 19:50:42 +0100, Cezary Tomczyk wrote:
>> W dniu 2012-12-07 08:35, HARY pisze:
>>> 2. Na serwerze szyfrowanie jednokierunkowe i przekierowanie GET (do
>>> adresu URL/?arg=hash).
>> To przypomina mi rozwiązanie z użyciem Proxy :-)
>
> To klasyka poprawnie zrealizowanego POST. Tzw. Get-after-post.
>> 1. <form> type POST -> serwer Proxy.
>> 2. Proxy przesyła dalej dane do docelowego serwera.
>> Pytanie tylko jak odebrać odpowiedź od serwera docelowego?
>
> Tak jak pierwotny użytkownik, gdyby się do niego odwołał bezpośrednio.
>
> Pewnie jakiś szczegół mi umyka...

Chyba tak. Przekierowanie Get-after-post niczego specjalnie mi nie
rozwiązuje a jeszcze bardziej komplikuje. Po stronie serwera robię
przekierowanie, ale:

1. Ewentualnie dane, jakie chciałbym przesłać do przeglądarki z powrotem
w ramach odpowiedzi z serwera, są w URL-u, bo to GET.
2. Rozumiem, że wówczas callback będzie, powiedzmy, kiedy strona się
załaduje po przekierowaniu a ja sprawdzę czy w URL-u są odpowiednie dane
z serwera.

To, co ja chcę zrobić, to wysłanie dane nie GET-em, ale POST-em i nie
mogę użyć XHR-a do tego w przeglądarkach, które nie wspierają CORS-u.
Robię to za pomocą JSNOP, ale jest z tym trochę problemów odnośnie
bezpieczeństwa, a których to wcześniej pisałem.

Mi nie chodzi o zabezpieczenie się przed wielokrotnym submitem, ale o
przesłanie danych POST-em po SSL-u lub użycie czegoś, co nie będzie
GET-em. Tak bym to ujął.

--
Cezary Tomczyk
http://www.ctomczyk.pl/