Hi!
>Az ECMAscript interpreter egy masik nagy program. Nem vadolok senkit, de
>az elkepzelhetetlen hogy egy nagyobb programban idovel ne deruljon feny
>design problemakra, buffer overflowokra, integer of-ra, signal handling
>vulnerabilityre vagy akarmire ami eppen abban az evben vezeti a
>toplistat. Ha letiltod, ezzel *potencialis* veszelyektol kimeled meg magad.
Ez teljesen okes dolog, csak neha kisebb a veszely, mint az a lehetoseg,
amit a scripteles kinal. Ha ez nem igy lenne, akkor rovid tavon kihalna a
technologia. Ezert elfogadom, hogy teljesen idegen oldalakat eloszor a
scriptek letiltasaval latogatunk meg, de ha mar megneztuk, es ugy dontunk,
hogy megbizunk benne, akkor folosleges utana szidni, hogy nem mukodik
script nelkul, inkabb probaljuk ki, mit kinal azzal.
Egyebkent ha egy informacio fontos, akkor annyi aldozatot meger, hogy
akar csak ideiglenesen engedelyezzuk a scriptek futtatasat, ha meg nem
fontos, akkor folosleges szidni, majd szol, akinek fontos es nem tudja
megoldani az elereset (ha van ilyen).
>Rendszeres levelezesre tessek hasznalni levelezot.
En is azt hasznalok, es nagyon sokan hasznalnak, de pont az atlag es az
alatti userek, akiket elbuvolnek a csicsas scriptes oldalak meg a
csodafunkciok, altalaban meggyozhetetlenek a levelezoprogram hasznalatarol,
mert "jo nekik a freemail is", azt meg mar meg sem probaljak megerteni,
hogy megy a jo oreg freemail POP3/SMTP alapon is.
>Csinalsz egy formot es HTTP POST-tal elkuldod a tartalmat. Vagy en nem
>ertek valamit? Igy a problema delegalodik a kliensoldalra ie. hogyan
>kerul bele az attach doc a formba.
Es eppen ezt a reszet szoktak a felhasznalok kenyelme erdekeben
script-tel megoldani. :) Igy aztan lathatatlan mezobe kerulhet, amitol nem
lesz rosszul az atlag user, es szepen gombokkal meg tallozhatja is a
file-jait. :)
>Nope. Teljesen mindegy hogy a site 10 vagy 20 GiB helyet foglal el.
Tenyleg mindegy, bar az adatbazis meg a generalo kod talan kevesebb, mint
a felet foglalhatja, mint rengeteg statikus oldal a design informaciok
tobbezerszeres megismetlesevel (persze, ott a css, de annyit nem segit).
Bar meg ez is mindegy. Csak egyszeruen kenyelmesebb serveroldalon aktivan
generalni/feldolgozni az oldakat (formot maskepp nehez is lenne
feldolgozni), es folosleges bonyolitas elore legyartani a sok statikus
oldalt. Manapsag mar eleg sok a gyakran valtozo tartalom, nem is kell
bonyolultabbra gondolni, mint egy sima forum vagy vendegkonyv. Szerintem ez
ellen folosleges kuzdeni, veszelyt sem jelent, kulonosebb erofeszites
nelkul cache-elheto is, es "rohano vilagunkban" nem hatrany, ha
napra/percrekesz infot kapunk.
> > kezelni), es tudomasul veszi, hogy az ido mulik, es bizonyos kodokat
> > tamogatni kell...
>
>Inkabb ugy fogalmaznek hogy "meg kell adni a lehetoseget".
Szerintem a tamogatas pont a lehetoseg megadasarol szol, attol meg nem
kotelezo hasznalni. :)
> > Azt azert belathatod, hogy a Netscape 3 nagyon elavult, es bizony a
> > Netscape 4.5 sem mostanaban keszult.
>
>Security szemponbol mar ne is beszeljunk rola.
Akkor tehat folosleges startersnek biztonsagi megfontolasbol ezeket
hasznalni, mert scriptet letiltva is sebezhetobbek lehetnek, mint egy uj
azt engedelyezve.
>A bemutatott fuggvenyek a Windows API reszei (es a cikk nem tert ki olyan
>fontos dolgokra mint az idozites pontossaga, de ebbol a szempontbol mindegy).
Tenyleg hianyolhatok a technikai reszletek, de a cikk inkabb csak az API
fuggveny C# implementalasarol szol.
De teljesen mindegy, honnan nezzuk, 86-ban Windows API sem volt, tehat
orulunk, hogy volt mar futasido mero rutin akkor is (volt sokkal regebben
is, en Commodore-on is hasznaltam nullazhato timereket ilyen celbol), csak
ennek semmi koze a cikkhez, igy nem kimondottan ertelmes kritikai eszrevetel.
Peterson
|