 Hozzászólások  A témához csak regisztrált és bejelentkezett látogatók szólhatnak hozzá!Bejelentkezéshez klikk ide
(Regisztráció a fórum nyitóoldalán)
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!" |
Beidézhetted volna a továbbiakat is, és akkor ilyen népi "bölcsességeket" nem tudtál volna elsütni.
|
""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.
|
Nana, a perlt csak nem bántani 
A nyúl egy igazi jellem. Ott ül a fűben, de akkor sem szívja!
|
ha úgy gondolod, hogy a php-t csak divatból használják a webprogramozók, akkor használj csak perlt :P
"I am a leaf in the wind!
Watch how i soar..." Wash from Serenity
|
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)?
|
A példád tipikus csúsztatás. A leíró részeket miért nem számolod bele?
|
"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.
|
Tipikus szolgáltatói hozzáállás. Észt nem osztottál, mert nem volt mit. Abban viszont igazad van, hogy feleslegesen irkaFirkáltál :)
|
"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? :))))
Ha már kivan a faszod az idióta szignókkal csinálj te is egyet.
|
"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.
If your site has a hosting plan with a limit on free bandwidth usage, smaller documents will reduce costs - provided traffic doesn’t increase.
456 Berea street - Ten reasons to learn and use web standards
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 :)
Ha már kivan a faszod az idióta szignókkal csinálj te is egyet.
|
"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>...
|
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.
C2D E8400 ~4.4ghz+GeminII / P5B Deluxe / 2*2Gb Kingmax DDR2-1066 / Powercolor ATI 4890 / Acer AL1916W / 400+320GB Samsung / G15 / Razer D.Back / Creative Audigy 2
|
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
Van egy kék tó a fák alatt,
Ha belet eszem, lehűti a lábamat.
|
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.
|
Na ja, nem beszelve arrol, hogy az egesz web 2.0 javascriptre epul...
|
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.
|
|
Nyomtatás
Elküldés e-mailben
Microsoft: 4-5 év alatt megtörhető az iPod
Új német kampány az illegális másolók ellen
