Marek pisze:
> To nie o submit() chodzi lecz o fałszowaną zawartość action. To się
> dzieje nawet w tych miejscach, gdzie submitu nie stosuję.

Modyfikowanie action jest tak samo nieciekawe, jak używanie submit().
Równie dobrze możesz zacząć wysyłać zawartość formularzy ajaxem (nie
sprawdzi się tylko z input type=file).

artur

do góry

> Modyfikowanie action jest tak samo nieciekawe, jak używanie submit().
> Równie dobrze możesz zacząć wysyłać zawartość formularzy ajaxem (nie
> sprawdzi się tylko z input type=file).

Tak, wiem... jednakże czasem potrzebna jest interakcja z użytkownikiem zanim
formularz zostanie wysłany. Trudno to przeskoczyć w rozsądny sposób. Za
pomocą JS doklejam identyfikator sesji do URL zawartego w action jeśli ktoś
cookies ma wyłączone i tą drogą nie będzie możliwe jego podtrzymywanie.
Czasem też trzeba zmodyfikować przesyłane parametry będące następstwem np.
ustawienia czegoś we Flashu przez użytkownika itp. Zło konieczne lub
konsekwencja rozwoju technologii...

do góry

On Tue, 09 Jun 2009 18:31:04 +0100, Marek <m...@s...interia.pl>
wrote:

>> Modyfikowanie action jest tak samo nieciekawe, jak używanie submit().
>> Równie dobrze możesz zacząć wysyłać zawartość formularzy ajaxem (nie
>> sprawdzi się tylko z input type=file).
>
> Tak, wiem... jednakże czasem potrzebna jest interakcja z użytkownikiem
> zanim formularz zostanie wysłany. Trudno to przeskoczyć w rozsądny
> sposób. Za pomocą JS doklejam identyfikator sesji do URL zawartego w
> action jeśli ktoś cookies ma wyłączone

Po prostu zawsze wrzucaj pole typu hidden. Przy okazji to będzie dobrym
zabezpieczeniem przed CSRF, jeśli przy odbieraniu formularzy będziesz
odczytywać ID sesji tylko z danych formuarza, a nie z cookies.

Poza tym i na serwerze możesz stwierdzić, czy użytkowik obsługuje cookies
i nie musisz generować JS do tego.

> Czasem też trzeba zmodyfikować przesyłane parametry będące następstwem
> np. ustawienia czegoś we Flashu przez użytkownika itp. Zło konieczne lub
> konsekwencja rozwoju technologii...

Nawet nie czepiając się Flash, to *jest* zła implementacja.

Tego typu dane powinny być trzymane w <input type=hidden> i powinny być
ustawiane od razu jak się zmienią albo w <form onsubmit>. Modyfikowanie
action albo submit() to jak wbijanie gwoździ trzonkiem młotka (też się
da...)

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

do góry

> Po prostu zawsze wrzucaj pole typu hidden. Przy okazji to będzie dobrym
> zabezpieczeniem przed CSRF, jeśli przy odbieraniu formularzy będziesz
> odczytywać ID sesji tylko z danych formuarza, a nie z cookies.

Sprawa dotyczy zzęść administracyjnej CMS, która jest dość wiekowa i
chroniona. Przeróbka 100 formularzy zabiłaby mnie :-) W częściach
publicznych zwykle nie ma potrzeby uciekania się do takich patentów więc
minimalny nakład pracy ma priorytet no i stąd ten wątek.

A co do przekazywania ID w hidden to nie załatwi (chyba) sprawy bo PHP jeśli
nie ma sesji w cookies to szuka jej w GET z tego co pamiętam.

> Poza tym i na serwerze możesz stwierdzić, czy użytkowik obsługuje cookies
> i nie musisz generować JS do tego.

Zgadza się, ale co dalej jeśli nie obsługuje? Nie chciałbym pożegnać
użytkownika.

> Nawet nie czepiając się Flash, to *jest* zła implementacja.

Taaa... tylko jak przedstawić np. interaktywny rzut 3D centrum handlowego w
HTML? Czy nam się podoba czy nie to nie możemy klientowi powiedzieć, że nie
zrobimy tego bo Flash jest beee. Dlatego właśnie napisałem, że trzeba jakoś
egzystować w warunkach jakie nam stworzono.

> Tego typu dane powinny być trzymane w <input type=hidden> i powinny być
> ustawiane od razu jak się zmienią albo w <form onsubmit>. Modyfikowanie
> action albo submit() to jak wbijanie gwoździ trzonkiem młotka (też się
> da...)

A to już prawie plagiat :-) Też tego porównania gdzieś użyłem.
Wracając do wątku: jak napisałem wcześniej - dostosowuję stary projekt aby
działał z IE8. Tak już w nim jest, że skrypty reagują na GET a nie na POST.
Kiedyś to przerobię pewnie...

do góry

P.S.
Jak sobie radzisz z metodą pól hidden gdy akcja użytkownika generuje
nieprzewidywalną ilość zmiennych (oczywiście w rozsądnych granicach) ?
a) dynamicznie generujesz pola hidden gdy zajdzie taka potrzeba ?
czy
b) od razu nadmiarowo dajesz tyle pól aby mogły przekazać POSTem wszystkie
możliwe warianty akcji użytkownika (godząc się z tym, że część z pól będzie
pusta i niepotrzebnie przekazywana)?

do góry

On Wed, 10 Jun 2009 00:01:32 +0100, Marek <m...@s...interia.pl>
wrote:

> Sprawa dotyczy zzęść administracyjnej CMS, która jest dość wiekowa i
> chroniona. Przeróbka 100 formularzy zabiłaby mnie :-)

Find'n'replace? :)

> A co do przekazywania ID w hidden to nie załatwi (chyba) sprawy bo PHP
> jeśli nie ma sesji w cookies to szuka jej w GET z tego co pamiętam.

Owszem, trzeba by samemu podać do session_id() przed wykonaniem
session_start().

>> Poza tym i na serwerze możesz stwierdzić, czy użytkowik obsługuje
>> cookies i nie musisz generować JS do tego.
>
> Zgadza się, ale co dalej jeśli nie obsługuje? Nie chciałbym pożegnać
> użytkownika.

Na serwerze sprawdzasz, czy dostałeś cookie i jak nie, to generujesz
alternatywny kod (z ID wsadzanym w formularze i linki). Generalnie to
samo, co robisz w JS, tylko na serwerze.

Jak wspomniałem wcześniej, w przypadku formularzy (POST) najlepiej z góry
wszystkich traktować jakby nie mieli cookies.

W pozostałych przypadkach to nie jest taki dobry pomysł - ID w URL są
paskudne i niezbyt bezpieczne, ale jeśli chcesz sesje dla użytkowników
kompletnie bez cookies, to w PHP masz gotowca do tego - trans_sid.

>> Tego typu dane powinny być trzymane w <input type=hidden> i powinny być
>> ustawiane od razu jak się zmienią albo w <form onsubmit>. Modyfikowanie
>> action albo submit() to jak wbijanie gwoździ trzonkiem młotka (też się
>> da...)
>
> A to już prawie plagiat :-) Też tego porównania gdzieś użyłem.
> Wracając do wątku: jak napisałem wcześniej - dostosowuję stary projekt
> aby działał z IE8. Tak już w nim jest, że skrypty reagują na GET a nie
> na POST. Kiedyś to przerobię pewnie...

type=hidden i onsubmit działają identycznie dla GET i POST.

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

do góry

On Wed, 10 Jun 2009 00:36:02 +0100, Marek <m...@s...interia.pl>
wrote:

> P.S.
> Jak sobie radzisz z metodą pól hidden gdy akcja użytkownika generuje
> nieprzewidywalną ilość zmiennych (oczywiście w rozsądnych granicach) ?
> a) dynamicznie generujesz pola hidden gdy zajdzie taka potrzeba ?
> czy
> b) od razu nadmiarowo dajesz tyle pól aby mogły przekazać POSTem
> wszystkie możliwe warianty akcji użytkownika (godząc się z tym, że część
> z pól będzie pusta i niepotrzebnie przekazywana)?

Zależy. Zazwyczaj generuję elementy JSem, a dla bezJSowców mam przycisk
"dodaj więcej". Czasem da się użyć textarea z jednym wpisem na linię.

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

do góry

> Find'n'replace? :)

Chciałbym aby to było tak proste :-)

> Na serwerze sprawdzasz, czy dostałeś cookie i jak nie, to generujesz
> alternatywny kod (z ID wsadzanym w formularze i linki). Generalnie to
> samo, co robisz w JS, tylko na serwerze.

Tak jak robi to PHP w jakimś trybie. Tak, znam tą technikę. Trochę to
uciążliwe w implementacji, nieładne, psujące pozycjonowanie i średnio
bezpieczne. Stąd pomysł z JS, który sam w razie potrzeby czynił takie
zabiegi - zawsze kolejna przeszkoda więcej no i nie wpływa na
pozycjonowanie. Takie podejście możliwe jest w/g mnie do zastosowania w
niepublicznych częściach CMSów.

> Jak wspomniałem wcześniej, w przypadku formularzy (POST) najlepiej z góry
> wszystkich traktować jakby nie mieli cookies.

Wtedy linki nam się rozrastają i mamy konsekwencje j/w.

> W pozostałych przypadkach to nie jest taki dobry pomysł - ID w URL są
> paskudne i niezbyt bezpieczne, ale jeśli chcesz sesje dla użytkowników
> kompletnie bez cookies, to w PHP masz gotowca do tego - trans_sid.

Hehe ... właśnie o tym wspomniałem na początku. Jednakże

> type=hidden i onsubmit działają identycznie dla GET i POST.

Tak wiem, ale dane z formularza czytane są POSTEm a polecenia co z nimi
zrobić - GET'em. Mam albo związane ręce albo sporo pracy przed sobą, za
którą nikt nie zapłaci.

do góry