🚀 go-pugleaf

witam ponownie :)

> Przeczytaj jeszcze raz to co napisalem ja i moj przedmowca. On pisal
> wyraznie o sprawdzaniu danych z poziomu JS jako jedynym zastosowanym
> zabezpieczeniu i z tym sie wlasnie nie zgadzam.

no chyba niezupełnie... napisał bowiem
<cytat>
zgadza sie - i tutaj [tutaj czyli w sprawdzaniu poprawnosci danych jeszcze
przed submitem formularza- pf]
widze glowne zastosowanie skryptow.
Ale widzialem juz przypadki, gdzie goscie zrzucali na przegladarke
sprawdzanie poprawnosci formularza, a CGI juz nic w tym temacie
nie robilo....
</cytat>

jak widzisz zaznaczył wyraźnie, że sama kontrola danych po stronie klienta
to za mało

> Niestety nie zawsze jest tak wesolo. Jesli w przytoczonym przez Ciebie
> przykladzie komunikatu bledu - "cannot insert null into..." - masz na
mysli
> komunikat generowany przez skrypt ktory sam przechwycil taki blad i
> odpowiednio go obsluzyl, to wszytko jest OK. Jesli natomiast komunikat
jest
> wynikiem bledu zwroconego przez baze danych, to mozna przypuszczac, ze
> projektant aplikacji wysyla do bazy dane bez sprawdzenia ich zawartosci, a
> to juz smierdzi naruszeniem zasad bezpieczenstwa.

obojętne, czy błąd został obsłuzony przez skrypt, czy przez wychwycony
dopiero przez bazę (oczywiście w tym ostatnim przypadku nie najlepiej to
świadczy o programiście...), istotny jest fakt, że zupełnie niepotrzebnie
zostały zajęte zasoby serwera i sieci.

> bezposrednio HTML, mozna przeciez wygenerowac wywolanie funkcji JS z
> dopowiednimi parametrami i pozwolic jej na budowanie po stronie klienta
np.
> sporych fragmentow skomplikowanych tabel wraz z zawartoscia. Taki kod
wykona
> kazda przegladarka potrafiaca interpretowac JS, w koncu podstawowa funkcja
w
> nim uzyta to zwykle print(). Efektem ujemnym jest oczywiscie kod
nieczytelny
> dla przegladarek bez JS (chyba ze wylapiesz je po stronie serwera i
> odpowiednio potraktujesz). Efektem dodatnim jest kod zajmujacy 20-30%
> objetosci w stosunku do HTML-a w ktory rozwinie sie dopiero u klienta.
> Jak wiec widac, nie tylko kontrola danych. Co do DHTML-a, to nie bede sie
> wypowiadal, bo nie jestem tu najbardziej kompetentny (pozdrowienia dla

hmm, a czy to nie jest właśnie DHTML? Modyfikujesz stronę u klienta -
obojętne, czy wykorzystujesz JS do zmiany liczby komórek w tabeli czy
ogólnie do "wypluwania" HTML-a (funkcja print). Istnieje jeszcze jedna,
ujemna niestety, strona takiego rozwiązania - jest ono wolniejsze niż zwykły
HTML. Objętościowo trzeba przesłać nie mniej danych niz przy zwykłym HTML-u,
a zazwyczaj nawet więcej, bo dochodzą skrypty, więc obciążenie sieci i
serwera nie maleje. Dodatkowo jest narzut czasu na wyrenederowanie strony u
klienta, a to niestety trwa...

--
pozdrawiam
Paweł Filipiak
pfilipiak@poczta.fm
icq 65223699; gg 1165099