ugrás a tartalomhoz

Archívum - Május 6, 2009

JavaScript Sandbox tesztelése

zzrek · 2009. Május. 6. (Sze), 21.09
Sziasztok!

Nem teljesen megbízható forrásból származó javascript kódot kell futtatnom, ezért csináltam egy homokozó-szerűséget.

A lényege, hogy a beküldött kódot (ami egy függvény lehet) leellenőrzöm, kiveszem belőle a veszélyes elemeket (pl. eval), megnézem hogy milyen lokális változókat akar a kódbeküldő használni, és csupán egy golbális objektumhoz (a neve "arc"), ennek adataihoz és metódusaihoz engedem hozzáférni a kódot, a DOM-hoz, más külső forrásokhoz nem.

Azt hiszem jól kigondoltam az eljárást, de minden javaslatot szívesen fogadok (a szerver oldali ellenőrző algoritmussal, PHP nyelvvel kapcsolatban, de főleg hogy JS oldalon mit kellene még engedélyezni vagy milyen biztonsági rést hagytam meg, stb; illetve hogy egyes böngészők esetleg olyan egyedi JS metódusokat engednek, ami még veszélyes lehet stb stb.)

Ha valakinek van kedve, tesztelheti a homokozót, ezen a linken:
homokozó teszt

Ezen a linken megtalálhatjátok a szerver oldali forráskódot is.

A teszt lehet egy kis játék is:
A baloldalon szerkeszthető és "beküldhető" függvénnyel ha valakinek sikerült kijönnie a homokozóból, úgy mutathatná be, hogy hozzáfér a DOM-hoz, hogy az input2-ként megjelölt mezőbe beleír valamit.

Köszönöm a segítséget és a javaslatokat!
 

Tiltott fejlesztések (a webappok 10 éves problémája)

vbence · 2009. Május. 6. (Sze), 11.04
Nemrég volt blogmarkolva a W3C Widgets ajánlása. A témával kapcsolatban felmerült a Google Gears is… Úgy tűnik szánt szándékkal kerülgetik azt az egyetlen problémát, ami a webalkalmazások nagykorúságát gátolja, mégpedig a fájlátvitelt. Hatalmas csalódás volt Google Gears-szel kapcsolatban, amikor kipróbáltam a YouTube új multi-feltöltőjét. Letöltöm a Gearst, elindul az applet… az első kérdés: engedélyezed-e a youtube.com-nak a teljes hozzáférést a HD tartalához? Ez volt, amit utáltam a Java appletekben még 10 éve. Ennyire tellett a guglitól?

Wolfram Alpha

eashlon · 2009. Május. 6. (Sze), 08.03
Magyar összefoglalása „a legintelligensebb kereső” projekt jelenlegi állapotának
 

PHP-ből Excel Smarty-val

Török Gábor · 2009. Május. 6. (Sze), 07.54
XML alapú Excel generálása PHP-vel
 

A validálás miért nem előre kompatibilis?

eashlon · 2009. Május. 6. (Sze), 03.32
Tudom, sokadrangú kérdés, de most gondolkodtam el rajta, és egyedül kevés vagyok.
Volt már ilyen téma feszegetve Mennyire fontos az érvényes HTML kód? de én egy kicsit másfelől közelítenék.
Miért nem lehet ezt a szabványosítási - mellesleg szerintem nagyon időszerű, sőt kicsit megkésett - mizériát előremutatóbban szervezni?

Mondom mire gondolok: CSS, opacity. "Error: Property opacity doesn't exist in CSS level 2.1 but exists in [css3] : 0.4 "

Miért nem lehet az ilyen szituációkat lefokozni minimum "warning"-ra? Hogyha a jelentős piacrészes böngészők már boldogulnak a történettel miért ne használjam? Egyáltalán ér nekem annyit a valid css, ha pont egy ilyen megoldás a legegyszerűbb, leghatékonyabb, leginkább oda illő? Elfogasható érv az invalid kód mellett, h túlmutat rajta (mármint ha valóban ez a helyzet)?

(Persze tudom, opacityt pont ki lehet váltani png-s megoldásokkal, de az újabb mizériákat vet fel általában... tud még valaki hasonló játékost?)