🚀 go-pugleaf

[ciach]
> Poprawność danych to niezupełnie to samo co bezpieczeństwo systemu. Jak w
> formularzu jest obowiązkowe pole i user przypadkiem go nie wypełni, to
chyba
> lepiej jak wyleci alert z informacją, niż każdorazowo w takiej sytuacji
> serwer miałby generowac na przykład błąd "cannot insert null into...",
> nieprawdaż? Oczywiste, że obejście JavaScriptowych zabezpieczeń jest
możliwe
> i względnie proste, ale dlaczego ich nie stosować (oprócz poważniejszych
> zabezpieczeń, oczywiście)? Sprawdzenie poprawności danych to dokładnie
jedno
> z podstawowych zadań JS, znacznie gorzej z DHTML-em, jeżeli strona ma być
> czytelna pod różnymi przeglądarkami.

Witam...

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. Ja natomiast pisalem o
dublowaniu kontroli poprawnosci danych celem unikniecia nadmiarowego ruchu w
sieci i jednoczesnie spelnieniu wymogow bezpieczenstwa.
Piszesz, ze poprawnosc danych to nie to samo co bezpieczenstwo serwera.
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.
Zgadzam sie, ze kontrola poprawnosci danych to wazne zastosowanie JS,
niemniej jest jeszcze kilka innych ciekawych zastosowan nie koniecznie
dotyczacych DHTML-a (rozumianego jako manipulacja grafika).
Osobiscie JS bardzo mi sie przydal przy pisaniu wysoce modularnych stron z
czesto powielanymi partiami kodu. Zamiast generowac po stronie serwera
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
Alladynorobcow :) ).

Pozdro...:)
TeNciN