Akit erdekel a teljes tanulmany magyarul az megtekintheti itt: http://insecurity.hu
"java appletek nagyon lassuak, legalabbis amiket en lattam, cgi, asp, perl ... megatobbi nem kell." - szerintem nagyon nem vagy képben. A Java applet a gépeden fut (és a Java szerintem is nagyon lassú), a "cgi, asp, perl" pedig a szerveren, aminek az eredménye a képernyõdön megjelenik, de a felhasználónak ebbõl a szempontból lényegtelen, hogy a szerveren mi fut.
"...ami a forma es a tartalom elvalasztasat illeti - hat az adat pl. mysql adatbazisba kerul a format meg lehet varialni" Csak itt a tartalom és a forma szétválasztásáról, nem az az adatbázisban tárolt adat és a felhasználó által böngészhetõ tartalom szétválasztásáról volt szó. Két különbözõ dolog.
"cgi, asp, perl ... megatobbi nem kell." HTML-bõl nem fogod elérni az adatbázist...
"Ami a tablakat illeti - minden bongeszoben egyforman nez ki" 1. Hogy táblázatos oldalszerkezetet használsz, annak az az oka, hogy a HTML nyev eredetileg nem arra lett kitalálva, amire mostanság használják - azaz layout-ok készítésére. Ez menti meg egyedûl a táblázatokat - a régi böngészõk - de szerencsére nem sokáig. 2. Jelenleg arra felé halad a trend, hogy minden egyes taget arra használjanak, amire való. Táblázatot táblázatos adatok megjelenítésére, CSS-t a formázásra. 3. Vajon miért beszélnek egyre inkább szakmai fórumokon (kis hazánkban például a Weblabor) egyre többet a táblázatos oldalszerkezet elhagyásáról? CSS-redesign-ról? Szemantikusságról? Akadálymentességrõl? Miért nem ennek ellenkezõje (igénytelenség, nem-törödömség) a húzóerõ? Miért nem ezekrõl tartanak konferenciát, adnak ki szakkönyveket? Ja, mert a webes nyelvek fejlõdnek!
...ami a forma es a tartalom elvalasztasat illeti - hat az adat pl. mysql adatbazisba kerul a format meg lehet varialni .... gondolom a tartalmat nem text fileokban tartjatok ... ott a Joomla meg a tobbiek. Es ami a server terheltseget illeti, php-ban is lehet optimalizalni a kodot, erre az egyik rossz pelda a Typo3. Ami az internetes vasart illeti, mondjuk ott rendelek, de a fizetest nem ott bonyolitom le. En meg a bankoknak a webes szolgaltatasait se hasznalnam. Az emberkek egy rakas scriptet hasznalnak , de a nagyresze az oldal pofazmanyat befojasolja, vagy felmegoldasokat nyujt ... java appletek nagyon lassuak, legalabbis amiket en lattam, cgi, asp, perl ... megatobbi nem kell. Ami a tablakat illeti - minden bongeszoben egyforman nez ki, a css deklaracios reszerol meg irtak mar elottem ... de az kimaradt h mennyit kell bogozgatni h egy par ablakot/cellat normalisan elhelyezz ... a tablaknal meg minimalis energiaval szep dolgokat lehet kihozni - table bg + cell bg + kep a cellaba, esetleg meg page bg ... es persze minden darabka minden bongeszoben a helyen van. Azzal mondjuk egyetertek h mega-siteoknal/portaloknal nem szamit a design, de a tobbieknel biza sokat nyom a latban.
"Mégis rengetegen fejlesztenek pl. ActiveX-es alkalmazásokat intranetre - ami alapból csak IE-n mûködik" - itt van az igénytelenség remek mintapéldája. Egy webes alkalmazást azért készítenek webesre, mert akkor a kliens oldalon egy gyengébb gép is elegendõ, amin elmegy egy böngészõ. Ez egyben elvileg platformfüggetlenséget is eredményezne. Persze nem úgy, hogy csak szutyok msie-activex-windows alatt mehet, mert azzal csak adtak a szarnak egy pofont.
"Ha sûrûn van használva a Windows Update (ami azért elvárható dolog - mármint az operációs rendszer frissítéseinek rendszeres telepítése), akkor az IE 5-nek is illett volna frissülnie IE 6-ra..." - na persze. Ismerjük a taktikát. Ha egy biztonsági rést egy harmadik cég befoltoz, akkor jön egy update, ami további hibákat eredményez, vagy nemkívánatos dolgokat csempész az ember gépére (lásd az eredetiségvizsgálat árulkodó tevékenységét, amire szerencsére fény derült. És még ki tudja, mennyi ilyen árulkodó van? Pontosabban: lehet tudni egy jópár beépített "kémprogramról". WMP, MSIE, ActiveSync, Outlook, stb.). Köszi, de nem kérek belõle. Ez így egy végtelennek tûnõ mókuskerék, amibõl még idõben ki kell szállni.
"Bûn, de édes bûn." - én inkább keserû pirálának nevezném.
"Mégis rengetegen fejlesztenek pl. ActiveX-es alkalmazásokat" - Egy klasszikus mondás erre: "Többmilliárd légy nem tévedhet! Együnk szart!"
""A fejlesztõ cég felmérte/megkapta-e, hogy a cég milyen verziójú szoftvereket használ?" - minek azt tudni?" Azért hogy ne kerüljön a fejlesztõ/a felhasználó zûrös helyzetbe. Például más-más motor kell egy lemezjátszóba és egy porszívóba. Mindkettõ elektromos motor, mégis más elvárások vannak velük szemben.
" biztos a legfrissebb Mozilla volt rajta. Szóval mennie kellett volna, ha a kritérium a "legfrissebb"." Ha sûrûn van használva a Windows Update (ami azért elvárható dolog - mármint az operációs rendszer frissítéseinek rendszeres telepítése), akkor az IE 5-nek is illett volna frissülnie IE 6-ra...
"Egy ilyen böngészõre fejleszteni a legnagyobb felelõtlenség. Én azonnali hatállyal világgá zavartam volna azt, aki olyan webes alkalmazást készít, ami csak a szutyok msie alatt megy." Mégis rengetegen fejlesztenek pl. ActiveX-es alkalmazásokat intranetre - ami alapból csak IE-n mûködik. Miért? Mert egyszerûen integrálható a Windowsos alkalmazásokhoz.
"de bûn olyan alkalmazást készíteni, ami csak egy meghatározott böngészõvel megy." Bûn, de édes bûn. Lásd az ActiveX-re tett megjegyzésem.
"És mivel ez egy céges/oktatási intézményes alkalmazás lehetett, elvárható lett volna a webböngészõ legfrissebb változatának használata (biztonsági frissítésekkel egyetemben)." - biztos a legfrissebb Mozilla volt rajta. Szóval mennie kellett volna, ha a kritérium a "legfrissebb". Mellékesen megjegyezném, hogy pont a mikrofos volt az, ami - különbözõ biztonsági problémák miatt - állandóan azt javasolta a felhasználóknak, hogy ezt, meg azt a funkciót kapcsolják ki, bizonyos dolgokat ne engedélyezzenek, stb. Nos, ha ezt az ember megtette, akkor egy olyan nulla tudású böngészõje maradt, ami gyakorlatilag semmire sem volt alkalmas. Egy ilyen böngészõre fejleszteni a legnagyobb felelõtlenség. Én azonnali hatállyal világgá zavartam volna azt, aki olyan webes alkalmazást készít, ami csak a szutyok msie alatt megy. A hozzá nem értés magasiskolája.
"A fejlesztõ cég felmérte/megkapta-e, hogy a cég milyen verziójú szoftvereket használ?" - minek azt tudni? Olyat kell csinálni, ami minden elterjedt böngészõvel megy. Az elterjedtséget úgy határoznám meg, hogy ami (ha csak magyarországi felhasználóknak készül) Magyarországon 1%-osnál nagyobb "piaci részesedéssel" rendelkezik. Persze lehet vitatkozni a százalékon, de bûn olyan alkalmazást készíteni, ami csak egy meghatározott böngészõvel megy.
"van rajta egy ie5, mire a válasz, ja azzal sem megy 6.0 xxxx kell neki!" Valószínûleg akkor már létezett az IE 6-os változata. És mivel ez egy céges/oktatási intézményes alkalmazás lehetett, elvárható lett volna a webböngészõ legfrissebb változatának használata (biztonsági frissítésekkel egyetemben).
"Na ennyit a javaról meg a kompatibilitásról." Ez most javas, vagy javascriptes alkalmazás volt? A fejlesztõ cég felmérte/megkapta-e, hogy a cég milyen verziójú szoftvereket használ?
A java-t és java scriptet is utálom mint a szart! Hoztak egy webes alkalmazást, és mondták, hogy csak ie-vel megy, mozilával nem. Na mondom mekkora egy rakás szar, mindegy alapban van rajta egy ie5, mire a válasz, ja azzal sem megy 6.0 xxxx kell neki! Na ennyit a javaról meg a kompatibilitásról. A sebességról már nem is beszélek! Érdekes nekem interaktív flash mozik mennek php-vel, egy árva majmoknak való java sincs benne, és nem lassú. stargateszink.uw.hu pl.
Lehet, hogy érthetetlen lesz számodra, de én kb. 1 hónapig használtam WYSIWYG szerkesztõt annak idején, hogy egyáltalán megtanuljam a HTML-t, azóta ha valamit csinálok (statikus oldal), akkor csak és kizárólag Ultraedit-et használok. Dinamikus oldalaknál meg ugye úgyis legeneráltatja az ember az oldalt, de itt is törekszem a pure HTML-re, mert azt a legprimitívebb browser is tudja értelmezni. És úgy látszik én nem követem a divatot, mert nem PHP-t használok, hanem Perl-t :)
" A leíró részeket miért nem számolod bele?" Mert nem a HTML része, hanem a CSS-é. Tartalom/design különválasztása.
"Nem akarlak gyõzködni, látom, hogy reménytelen. Megkajáltad te is "az újabb mindig jobb" maszlagot." Szerinted nem jobb egy összeszedettebb XHTML+CSS páros mint egy non-valid (xyz WYSIWYG szerkesztõvel összeberhált) táblázatos/spacer gif-es kialakítás? Szerinted nincs értelme egy mindenki számára normálisan elérhetõ tartalomnak (ami igényesen van összerakva)?
"Lehet csak a weblap megtekintése után dönti el a termék boltban történõ megvásárlását" - oké, így már jobban hangzik. De hát ez szerintem édeskevés, mert semmivel sem ad sokkal több _hasznos_ infót, mint egy reklámújság. Viszont felhasználói vélemények és tapasztalatok egyes fórumokon sokat nyomnak a latban. Persze ezeket a véleményeket is szûrni kell, de ezek mennyisége nem összemérhetõ egy termék bemutatkozó oldalával. Nem akarlak gyõzködni, látom, hogy reménytelen. Megkajáltad te is "az újabb mindig jobb" maszlagot. Pedig az állítás nem minden esetben igaz. Tipikusan az objektumorientált programozási szemlélet hozadéka, de mint tudjuk, nem ez eredményezi a kis méretet, most pedig errõl volt szó.
"ez csak akkor igaz, ha külsõ file-ra hivatkozik." Márpediglen a tartalom és a design különválasztásának ez a legjobb módja.
"De az mennyivel rövidebb, mint a font?" <p class="piros">Ez egy piros bekezdés</p> <p><font color="red">Ez egy piros bekezdés</font></p>
"Annak meg eltörném a kezét, aki spacert használ." Magyarországon ez még bevett szokás. De reméljük nem sokáig... Validság? Minek? Igényesség? Ugyan már! Akadálymentesség? Az vicc!
"De mivel a CSS-kód újrafelhasználható (több oldal is használhatja ugyanazt a CSS állományt;" - ez csak akkor igaz, ha külsõ file-ra hivatkozik. "lásd: például class attribútum" - látom, látom. De az mennyivel rövidebb, mint a font? Annak meg eltörném a kezét, aki spacert használ.
"Ha kifogytál a szakmai érvekbõl, személyeskedsz..." - nem én kezdtem...
"internetes vásárlásra gondoltál? Nekem ilyen soha eszembe sem jutna, hogy így vásároljak." Nem feltétlenûl internetes vásárlásra. Lehet csak a weblap megtekintése után dönti el a termék boltban történõ megvásárlását. És az már potenciális vásárló.
"ezt sem merném így kijelenteni, akárhány "megmagyarázó" linket és szöveget emelsz be." De mivel a CSS-kód újrafelhasználható (több oldal is használhatja ugyanazt a CSS állományt; és csak egyszer kell letölteni), illetve egy adott CSS deklarációt több elem is használhat egyszerre (lásd: például class attribútum), ezért a CSS mérete mégiscsak kisebb, mint egy újra- és újradeklerált <font> tag, vagy spacer gif.
"Tipikus szolgáltatói hozzáállás. Észt nem osztottál, mert nem volt mit. Abban viszont igazad van, hogy feleslegesen irkaFirkáltál :)" Ha kifogytál a szakmai érvekbõl, személyeskedsz...
"mindegyik lehet potenciális vásárló" - internetes vásárlásra gondoltál? Nekem ilyen soha eszembe sem jutna, hogy így vásároljak.
"Nem a dialup user a lényeg, hogy neki hamar meglegyen az oldal." Hanem mindegyik (mindegyik lehet potenciális vásárló!). Olvasgassatok egy kis Jakob Nielsen-t (õ foglalkozik a webergonómiával).
"minden script veszélyes, aminek az adott platformon az implementációja el van szva." Épp ez az, hogy elvileg a Javascript-nek alapból nem kellene veszélyesnek lennie, de elszúrják az implementálását.
"ez egy komoly szakmai fórum :DD" Ugye te ezt viccnek szántad? ;) A Weblabor ebbõl a szempontból az lenne... ...bár a fórumon ott is vannak érdekes anonymous-ok.
"Amúgy meg a flash nem rosz dolog, csak a legtöbb helyen kb az animált gif helyett használják." Ahol animációra (gif-hez hasonlítani - ami csak 256 szines - kissé túlzás), mozgásra, pixelpontos grafikára, különbözõ betûtípusokra van szükség ott kiválóan alkalmas.
minden script veszélyes, aminek az adott platformon az implementációja el van szva. Amig a stackben hoz létre valami adatokat, és azokon szarul implementált függvényeket (strcpy) hív, addig bármi (script, kép, stb) veszélyes. Olvassatok már el egy-egy security bulletint légyszives. A microsoft hetente átlag kettõt ad ki :)
Amúgy Faustus: Nem a dialup user a lényeg, hogy neki hamar meglegyen az oldal. _Nekem_ nem mindegy szerver oldalon, hogy mennyi adatot kell cache-ben tartanom, és mennyi idõ alatt nyomom ki a csövön.
Az aki azt gondolja, hogy a szervernek kell minden megcsinálnia az nagyon nem ért hozzá (Wanek) és még életében nem látott WAN-ra irt alkalmazást, aminek x millió user-t kell kiszolgálnia. Nézz utána légyszi a near cache fogalmának, mondjuk indulásnak. Örülök, hogy segithettem... És ha tájékozatlan vagy AJAX-ban, akkor inkább ne írjál le semmit. Az XMLHTTPRequest-nek annyi köze van az ActiveX-hez, hogy az egyik böngészõ esetében egy activex component, de a többi esetben (pl mozilla szoftverek) már nincs is activex-ed :))) FYI: var req = new ActiveXObject("Microsoft.XMLHTTP"); var req = new XMLHttpRequest(); ugye...
Amúgy tegye fel a kezét, aki clusterezett itt már LAMP-ot. Köszi. Gondoltam. A PHP-vel meg ne viccelõdjünk itt, ez egy komoly szakmai fórum :DD
Amúgy meg a flash nem rosz dolog, csak a legtöbb helyen kb az animált gif helyett használják. Van egy pár profi oldal a neten, ahol mesterien megirt flash van. Az igaz, hogy nem volt olcsó :))) És a reprezentáció - ugye - nem keverendõ össze az adattal és a business layer-el. Ha jól irtad meg, akkor xml-ben kiszolgálhatsz flash-t, vagy egy ajax-os oldalt, vagy direktben egy kliens programot.
Hé. Minek osztom itt az észt? Aki felfogja, az vagy nálunk, vagy a konkurenciánál dolgozik, a többinek meg minek? :))))
"De ha van lehetõség arra, hogy egyes feladatokat levegyünk a szerver válláról - akkor miért ne?" - azért, mert õ szolgáltat, nem én. Vagy innentõl kezdve én is a szolgáltató része vagyok? Mert akkor kérem a részesedésemet!
"Normális esetben nem szabadna. Sajnos hogy egy böngészõben van/volt ilyen exploit az más tészta." - exploit minden böngészöben volt már. Jellemzõen a legtöbb a msie-ben.
"Másrészt a HTML kód mérete éppenhogy kisebb lesz" - ezt sem merném így kijelenteni, akárhány "megmagyarázó" linket és szöveget emelsz be. Csak a CSS definíciós része akár nagyobb is lehet, mint a hasznos tartalom. Sok ilyet láttam már. És ezekre ugyanúgy hivatkozni kell, mint pl. a <font>-ra.
A poénkodó szövegedre nem tudok hasonló stílusban válaszolni, érdemben meg így minek?
"ez a szolgáltatói oldal feladata. Gondoskodjon róla, ha akar valamit. " De ha van lehetõség arra, hogy egyes feladatokat levegyünk a szerver válláról - akkor miért ne?
"De memóriatartalom is kiolvastatható, stb, de ebbe ne menjünk bele." Normális esetben nem szabadna. Sajnos hogy egy böngészõben van/volt ilyen exploit az más tészta.
"szerintem meg nem. Ettõl nõ meg igazán a méret. És a veszély is így sokkal nagyobb." Hol "nagyobb" a veszély? A CSS-nél (megeszi a gépedet vacsorára egy gonosz border-top tulajdonság)? Az XHTML-nél (a nagybetûk - akik nem szerepelhetnek a tagekben - fellázadnak és elhagyják a gépedet, és nem tudsz ZSUZSI SZERETLEK-jellegû kiabálásokat produkálni a csevgõcsatornákon)? A diszkrét Javascriptnél (maximum a HTML forrásban kevésbé észrevehetõ kód miatt nagyobb az eredetileg is veszélyes Javascript)?
Másrészt a HTML kód mérete éppenhogy kisebb lesz például egy táblázatos oldalkialakítás lecserélésénél CSS-re (sok spacer gif elhagyása, sok <tr>/<td>/</tr>/<td> elem lecserélése); a <font> elemek elhagyása; az újrafelhasználható kód (mind CSS-nél, mind Javascriptnél, illetve a jövõbeni XML+XSLT technológiáknál) miatt. Persze ehhez ésszerû használat szükséges.
Idézet egy szakoldalról: Well-structured markup that separates structure and content from presentation is generally much more compact than table-and-spacer-image-based tag soup. Documents will be smaller and faster for visitors to download. Like it or not, there are still many, many people connecting to the Internet through dialup.
Egy másik: Reduction in File Size: I reduced the file size of the SitePoint page from 34,353 bytes to 18,585 bytes. It would be smaller again if it wasn't for all those rounded corners! One file controls the whole site design: OK you've heard this before - it is part of the beauty of CSS in general. Should you decide to add Geneva to your font family because you're becoming Mac friendly then modify your style sheet and the changes will be reflected across your whole site. Sitepoint - HTML Utopia! Design Websites Without Tables - Parts 1 and 2
"De nem annyira, hogy más felhasználóktól vegyük el a rá esõ feldolgozási idõt." - ez a szolgáltatói oldal feladata. Gondoskodjon róla, ha akar valamit. Az iwiw más miatt veszélyes. Olyan adatokhoz és kapcsolati rendszerekhez lehet hozzájutni, ami még csak véletlenül sem a felhasználó érdekeit szolgálja. Én pl. soha nem használnám. Mint ahogy a telefonos közvéleménykutatóknak sem mondok soha semmit (ingyen). Az információ érték, és ezt az adatgyûjtõk rendesen pénzre is váltják. Az adatot szolgáltatót pedig mindig elfelejtik díjazni...
"A javascripttel keveset tudsz kutakodni - szerencsére." - ez majdnem így van, de nem is a javasriptre gondoltam. Egyébként az általad felsoroltakon kívül nagyon kellemetlen meglepetés érhet valakit a cookie-k miatt is, és mellesleg azt is javascripttel lehet írni-olvasni. De memóriatartalom is kiolvastatható, stb, de ebbe ne menjünk bele.
"Ezért jó a XHTML+CSS+diszkrét Javascript alapú weboldalkészítés." - szerintem meg nem. Ettõl nõ meg igazán a méret. És a veszély is így sokkal nagyobb.
Nem azzal van bajom, ha valami elegánsan van megoldva. De rettenetesen sok a sallang, így az ember a NoScript mellett kénytelen Adblock-ot is használni :) Így elérhetõ, hogy a képernyõre tényleg csak a valós hasznos tartalom kerüljön, a hirdetések, a különbözõ felhasználói szokásokat gyûjtõ javascriptek és egyéb sallangok nálam meg sem jelennek. :)
"A szervernek az a dolga, hogy dolgozzon." De nem annyira, hogy más felhasználóktól vegyük el a rá esõ feldolgozási idõt. Lásd pl: iwiw.
"Akkor pedig elég visszatetszõ, ha olyan technikákat próbálnak erõltetni, ami a kliens gépen tud a felhasználó tudta nélkül kutakodni." A javascripttel keveset tudsz kutakodni - szerencsére. IP-cím, felbontás, használt pluginek, cookie-k - de felhasználói file-ok, privát adatok nem kerülhetnek a felhasználó tudta nélkül illetéktelen kezekbe.
"Ma már nagyon sok mobil támogatja a flash-t (persze nem a low-end kategóriában)" Flashlite néven van rá megoldás - de a Flash-ben elterjedt izgõ-mozgó-animálódó dolgok mennyire hatékonyak egy szimplán tartalmat kívánó alkalmazás esetén? Mert játéknál, mozibemutatónál, csak-csak...
"Sajnálatos módon manapság egy oldalnak a kódja szükségtelenül nagy. Sok esetben tizedakkora méretben is megoldható lenne valami, simán html tag-ekkel." Ezért jó a XHTML+CSS+diszkrét Javascript alapú weboldalkészítés. Az XHTML-be csak a tartalom és a struktúra kerül, a CSS-be csak a design, a diszkrét javascriptbe csak a viselkedés. Ha valamelyikre nincs szükség, kiiktatható.
"Valóban a tartalom érdekli a felhasználókat, ehhez pedig a sok csilivili csicsa érdemben nem tud hozzátenni." Természetesen az igényes design (nem a csilivili) kellemes hatással lehet a látogatóra, de ezzel óvatosnak kell lenni.
A szervernek az a dolga, hogy dolgozzon. És persze nem egy árva gép van általában beállítva, hanem az igényeknek megfelelõen szerverpark. Ez a kliens-szerver megoldás eléggé vitatható hatékonyságú. Akkor pedig elég visszatetszõ, ha olyan technikákat próbálnak erõltetni, ami a kliens gépen tud a felhasználó tudta nélkül kutakodni. Persze ez a céljuk, de ezt nem kell megengedni. Csak a birkákat lehet a vágóhídra terelni...
Sajnálatos módon manapság egy oldalnak a kódja szükségtelenül nagy. Sok esetben tizedakkora méretben is megoldható lenne valami, simán html tag-ekkel.
Ma már nagyon sok mobil támogatja a flash-t (persze nem a low-end kategóriában), a wap pedig már induláskor is halott ötlet volt, mára tulajdonképpen le is áldozott.
Valóban a tartalom érdekli a felhasználókat, ehhez pedig a sok csilivili csicsa érdemben nem tud hozzátenni.
"...es mondjatok h miert/mire nem jou a php?" Mert jobban terheli a szervert, mintha Javascript-tel tehermentesíted. Például: elküldöd a termékek listáját PHP segítségével, és Javascripttel rendezed sorba.
"Mi a fenenek kell osszekavarni mindenfelet. CSS, jscript, ajax megatobbi." A tartalom ((X)HTML), a forma (CSS), és a viselkedés (Javascript) szétválasztására (hogy ne egy nyelvbe legyen sûrítve minden). Ha majd közbelép a tartalom (XML) és a struktúra (XST) különválasztása akkor még inkább részekre lesz bontva az egész (ami a jobb struktúráltság szempontjából eléggé elõnyös).
"meg flash elmegy" A Flasht nem lehet tökéletesen mobilplatformra vinni (például wap-ra), nem kezelik a felolvasószoftverek, a keresõk sem szeretik, és nem kifejezetten a web központi "nyelve".
"a pofazmany nagyreszet ugyis a Photoshop vegzi" És ez érdekli a mobilplatformot használókat? A keresõket? A felolvasószoftvereket használókat? Nem, õket (mint általában mindenkit) elsõsorban a tartalom érdekli.
...es mondjatok h miert/mire nem jou a php? Mi a fenenek kell osszekavarni mindenfelet. CSS, jscript, ajax megatobbi... minimalis jscript meg flash elmegy, a pofazmany nagyreszet ugyis a Photoshop vegzi, akinel meg nem, az majd rajon idovel. Ha fizetosdirol van szo akkor meg egyszerubb megadni egy bank kontot, mint gateway-t belekavarni, egy normalis vasarlonak mindenkepp nagyobb a bizalma, legalabbis en biztos nem fogom weboldalra beirni az adataimat.
Mióta mondom, hogy a webes alkalmazásokat megbszhatjátok...
Szenvedsz egy csomót, a végén meg vagy csak explorerben megy, vagy van annyi javascripted, hogy öröm maintainelni :)
"Szerintem a jó öreg HTML ben mindent meglehet oldani ami egy normális böngészéshez kell, nekem nem kell a flash meg a többi brandwith evô cucc ami "elméletileg" szebbé teszi a környezetet... megaztán álltalában minden egyes újítással egyre kevesebb levegôje van a kliensnek, azaz annál több a megkötés." Vissza a HTML 2.0-hoz... Nincs <script>, nincs <style>, nincs <object>, nincs <embed>...
1. Egy árva XMLHTTPRequest (se M$-os megfelelõje: XMLHTTP) nincs se az adott oldalon, se az oldalról elérhetõ Javascript szkriptben. 2. Nem ActiveX-et használ, mert mûködik Firefox alatt is, amiben alapból nincs ActiveX-támogatás (bár van hozzá ActiveX kiterjesztés...). 3. Az XMLHTTPRequest nem mûködik megfelelõen külsõ domainen. Lásd itt: http://www.sitepoint.com/forums/showthread.php?t=277942.
személyszerint kikapcsolom a scripteket (még egy pár apróságon kívül) böngészésnél, csak ha éppen igényeli az oldal (és persze én is, mert látni akarom az oldal tartalmát, vagy egy két speciális funkciót) akkor lövöm be. álltalában amelyek oldalok erôsen vannak scriptelve azoktól túl sok jóra sem lehet számítan, sôt mondhatni, hogy egyenesen rosszindulatúak a kliensel szemben. Agresszív "de én telepíteni akarom a gépedre" utasítások, pop-up ok, ilyen-olyan átvezetések különbözô oldalkra mind az engedélyen kívül stb, stb nagy a lehetôségek listája, és nem szégyenlik kihasználni ôket egy kicsit sem :). Szerintem a jó öreg HTML ben mindent meglehet oldani ami egy normális böngészéshez kell, nekem nem kell a flash meg a többi brandwith evô cucc ami "elméletileg" szebbé teszi a környezetet... megaztán álltalában minden egyes újítással egyre kevesebb levegôje van a kliensnek, azaz annál több a megkötés.
Ez is az activex-et baszkurálja, ami egyébként is potenciális veszélyforrás. Nem kell msie-t használni.
Bár nem próbáltam ki, de elképzelhetõnek tartom, hogy XMLHTTPRequest-ek felhasználásával ilyesmit csináljon egy JavaScript. Adatot fogadni biztosan tud, (legalábbis HTTP-lal), rossz esetben akár még küldeni is.
Egy lehetséges módja a probléma orvoslásának az lenne, ha egy adott domainrõl származó script csak az adott domain-en belül használhatna HTTPRequest-eket. Például ha letölöm, és elhelyezem a saját lapomon a GoogleMaps API-t megvalósító scriptet, akkor ne mûködjön (mivel ugye az én domain-emrõl szeretne kommunikálni a google.com domainnel), de ha csak importálom (src=""), akkor menjen rendesen. Kérdés, hogy ilyenkor saját scriptembõl milyen korlátozásokkal használhatom (szélsõséges esetben - ha a router konfigját például nem védi jelszó, logikai ÉS web2-es felületû, akkor visszajutottunk a kályhához).
Vagy lehet, hogy rosszul értelmezem a problémát, mindegy. Majd megoldódik, a webfejlesztõk meg felkészülhetnek, hogy megint szívnak, mint a torkos borz, ha minden böngészõben máshogy fog mûködni. :-S
Megyjegyezném hogy kipróbáltam az említett proof of concept cuccost és hát nem gyõzött meg :) Beírtam neki hogy milyen tartományban vannak a gépeink, és azon kívül hogy elõbukkant két hálózati eszköz (egy router és egy switch) jelszóablaka, az égvilágon semmi nem történt (ezeket meg egy http redirect is elõ tudja hozni ha valaki ismeri a belsõ címüket. Arról nem beszélve hogy a jelszóablak tartalmát - pl a router típusát - nem tudom hogy akarja visszajuttatni a támadóhoz). Az összes hálózaton található gép közül egyet sem talált meg, igaz nem futott rajtuk webszerver. Ettõl függetlenül ügyes ötletnek tartom.
"létezik uPNP" - valóban. De minden normális router-ben alapból tiltva van. Aki ezt engedélyezi, az már képes arra is, hogy az admin jelszót és az SSID-et átállítsa.
Szerintem fingod sincs arról, amit írtam. 1. A NoScript-et nem ártana megismerned, mielõtt hülyeséget írsz. 2. a cégek milliárdjait magas ívben leszarom. Õk vannak értem, nem én miattuk... 3. A vállalati sw-ek csak a hozzáértést nélkülözõ helyeken mennek úgy.
tök jó hogy ilyeneket megtalálnak és biztosan hamarosan megoldják a szakik hogy mégse lehessen így bejutni a gépekre, de addig könyörgöm, minek kell nagy dobra verni?? hogy a sok lelkes amatõr/haladó hacker akik eddig esetleg nem tudtak errõl a lehetõségrõl, most elkezdhessenek gyakorolni? egyébként meg nem kell minden szar honlapra felmenni
"A jó megoldás: NoScript extension." - ez tényleg jó megoldás fõleg olyan cégek számára akik milliárdokat költöttek olyan szoftverek fejlesztésére amelyek igénylik a scripteket. Olyan megoldás mint hogy kapcsoljuk ki az activex-et osztjóvan. Az hogy a vállalati szoftverek activexel mennek - hát sorry.
mivel a javascript a böngészõdön belül fut, ezért a tûzfal csak egy böngészõ kommunikációt érzékel... létezik uPNP is, lazán nyitogathat portokat a routeren magának, router jelszavát pedig jó ha 10-bõl 2 ember átállítja... sokan még arra sem képesek hogy a default SSID-t átállítsák... nem ITSEC guruból kell kiindulni ilyenkor
"Hoffmann szerint egy ilyen jellegû támadással a behatoló feltérképezheti az áldozat routerét, majd az elküldött utasítások segítségével akár a felhasználó vezetéknélküli internethozzáférését is engedélyezheti, és kikapcsolhat minden védelmet, de belsõ támadásnak látszó külsõ behatolások is indíthatóak egy vállalat szervei ellen." - mi ez? Hári János találkozó? A router admin jelszavát meg csak úgy hiphop kitalálja? Mert anélkül nehéz ilyet megcsinálni. Hogyan megy át a belsõ hálón lévõ gépek sw-es tûzfalán? Lenne még csomó kérdés, de minek? Szerintem az egész csak arra jó, hogy ijesztgessék az embereket, és eladják a majd ezt a "rést betömõ" kémprogramukat. A jó megoldás: NoScript extension.
Informatika és tudomány
