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");