Archívum - Szep 2, 2012 - Fórum téma
Saját HTML ($_POST) feldolgozó
Sziasztok!
Támadt egy ötletem, nem tudom, jó-e. Egy korábbi fórumtémában, ahol eredetileg SQL injection volt a kérdés, felmerült a HTML-szűrés (XSS, CSRF szempontból) is, ezzel együtt a HTML Purifier. Ez utóbbival egy pár gondom van:
- Kb. akkora (nagyobb), mint a framework, amit használok (CodeIgniter);
- Számomra annyi lehet (időben) rendesen átlátni, mint írni egy jóval egyszerűbbet;
- Elég nehézkes lenne szerintem ebbe a fw-be jól "bepasszítani" (eddig meg sem próbáltam);
- Kb. 100x annyit tud, mint nekem szükséges.
Ezek miatt úgy gondoltam, írok egyet. (A CodeIgniter-nek nincs sajátja, a Typography Class csak "stilizál", de nem szűri pl. a tag-ek attribútumait.)
Amikre gondolok (szempontok és megvalósítás):
- Kicsi (és gyors) legyen, mint a CI többi része is. Ha végére is érek, ez nem lesz gond.
- Megengedő értékelés, mind a tag-ek, mind attribútumaik terén (itt kérdés: így elég jól lehet XSS-t védeni?).
- Ha egy tag nem megengedett, a benne lévő esetleges szöveg ne vesszen el, hanem pl. kerüljön helyette más tag-pár közé.
- Könnyen konfigurálható legyen (pl. az osztály betöltésekor, mint más CI osztályok).
- Fentiek megvalósítására a PHP DOMDocument osztályát használnám, mégpedig úgy, hogy miközben elemenként olvasom a feldolgozandó HTML-t, ezzel "együtt" egy másik példányban gyártom a másikat.
- Ennek hátránya, hogy terjedelmesebb HTML esetén sok memóriát megehet, de nálam nemigen fordul elő, sőt, 100kB-nyi HTML-nél több szinte sehol. (Ebből a 2 DOM szerintem max. 3-4 megán elfér.)
- Még nem tudom, hogy mennyire működőképes ez az "egyiket olvasom, másikat írom" törtnet, de talán egyszerűbb, mint kibontani tömbbe, aztán gyártani abból az újat. Viszont ezzel meg rekurzív fv. kell, akkor azt meg védeni kell max.
Támadt egy ötletem, nem tudom, jó-e. Egy korábbi fórumtémában, ahol eredetileg SQL injection volt a kérdés, felmerült a HTML-szűrés (XSS, CSRF szempontból) is, ezzel együtt a HTML Purifier. Ez utóbbival egy pár gondom van:
- Kb. akkora (nagyobb), mint a framework, amit használok (CodeIgniter);
- Számomra annyi lehet (időben) rendesen átlátni, mint írni egy jóval egyszerűbbet;
- Elég nehézkes lenne szerintem ebbe a fw-be jól "bepasszítani" (eddig meg sem próbáltam);
- Kb. 100x annyit tud, mint nekem szükséges.
Ezek miatt úgy gondoltam, írok egyet. (A CodeIgniter-nek nincs sajátja, a Typography Class csak "stilizál", de nem szűri pl. a tag-ek attribútumait.)
Amikre gondolok (szempontok és megvalósítás):
- Kicsi (és gyors) legyen, mint a CI többi része is. Ha végére is érek, ez nem lesz gond.
- Megengedő értékelés, mind a tag-ek, mind attribútumaik terén (itt kérdés: így elég jól lehet XSS-t védeni?).
- Ha egy tag nem megengedett, a benne lévő esetleges szöveg ne vesszen el, hanem pl. kerüljön helyette más tag-pár közé.
- Könnyen konfigurálható legyen (pl. az osztály betöltésekor, mint más CI osztályok).
- Fentiek megvalósítására a PHP DOMDocument osztályát használnám, mégpedig úgy, hogy miközben elemenként olvasom a feldolgozandó HTML-t, ezzel "együtt" egy másik példányban gyártom a másikat.
- Ennek hátránya, hogy terjedelmesebb HTML esetén sok memóriát megehet, de nálam nemigen fordul elő, sőt, 100kB-nyi HTML-nél több szinte sehol. (Ebből a 2 DOM szerintem max. 3-4 megán elfér.)
- Még nem tudom, hogy mennyire működőképes ez az "egyiket olvasom, másikat írom" törtnet, de talán egyszerűbb, mint kibontani tömbbe, aztán gyártani abból az újat. Viszont ezzel meg rekurzív fv. kell, akkor azt meg védeni kell max.
Mi az a "felülírás" phpmyadminban?
Van egy problémám. Van ismerősömnek egy weboldala, amit én kezelek. Ez egy fórum, amihez évek óta nem lett nyúlva. Időközben megtalálta egy csomó robot, aminek sikerült teleírni rengeteg reklámmal. Ennek az lett az eredménye, hogy az utóbbi két évben több tízezer spam bejegyzést kapott a fórum, így betellett az adatbázis kvóta, ami 100 Mb. Erről kaptam egy értesítést a tárhelyszolgáltatótól, és amelyben az állt, hogy túlléptem a kvótát, és 72 órám van, hogy letöröljek annyi adatot, hogy megint 100 Mb alá menjen a mysql adatbázis tartalma.
Mivel láttam, hogy több tízezer bejegyzésről van szó, ezért a weboldalon való törölgetés szóba sem jöhetett. Beléptem hát a phpmyadmin-ba, és letöröltem egy query-vel vagy 20.000 bejegyzést, és így a bejegyzések száma a két évvel ezelőtti állapotra esett vissza, amennyi biztosan elfér a 100 Mb-ban. Ezen kívül magán az oldalon letiltottam a posztolást, mert már úgy sem használja senki az oldalt. Tehát már nem is lehetett bevinni adatokat a weboldalon keresztül az adatbázisba.
Erre kaptam még egy emailt pár nappal később, hogy az adatbázisba már egyáltalán nem vihetek be adatokat, tehát most már teljesen le lett tiltva az INSERT utasítás, mert úgy vették észre, hogy még mindig 100 Mb felett van, és hogy nem tettem semmit az elmúlt 72 órában, hogy kevesebb legyen. Furcsálltam a dolgot, ezért megnéztem, hogy mi történt az adatbázissal. Hát az történt, hogy azóta valóban nem posztolt senki (mivel letiltottam), viszont ha megnézem egy tábla struktúráját, akkor megjelenik egy olyan sor az tárterületnél, amely eddig nem volt ott. Most így néz ki a statisztika az fórum üzeneteit tároló táblánál:
Adat 93 943.3 KB
Index 381.0 KB
Felülírás 91 567.4 KB
Hatályos 2 756.9 KB
Összes 94 324.3 KB
A vastagított sorok azok, amelyek még nem voltak itt eddig. És a gáz az, hogy ha törlök mondjuk 100 bejegyzést, akkor ezek a sorok növekednek, és összességében nem csökken a foglalt terület.
Mivel láttam, hogy több tízezer bejegyzésről van szó, ezért a weboldalon való törölgetés szóba sem jöhetett. Beléptem hát a phpmyadmin-ba, és letöröltem egy query-vel vagy 20.000 bejegyzést, és így a bejegyzések száma a két évvel ezelőtti állapotra esett vissza, amennyi biztosan elfér a 100 Mb-ban. Ezen kívül magán az oldalon letiltottam a posztolást, mert már úgy sem használja senki az oldalt. Tehát már nem is lehetett bevinni adatokat a weboldalon keresztül az adatbázisba.
Erre kaptam még egy emailt pár nappal később, hogy az adatbázisba már egyáltalán nem vihetek be adatokat, tehát most már teljesen le lett tiltva az INSERT utasítás, mert úgy vették észre, hogy még mindig 100 Mb felett van, és hogy nem tettem semmit az elmúlt 72 órában, hogy kevesebb legyen. Furcsálltam a dolgot, ezért megnéztem, hogy mi történt az adatbázissal. Hát az történt, hogy azóta valóban nem posztolt senki (mivel letiltottam), viszont ha megnézem egy tábla struktúráját, akkor megjelenik egy olyan sor az tárterületnél, amely eddig nem volt ott. Most így néz ki a statisztika az fórum üzeneteit tároló táblánál:
Adat 93 943.3 KB
Index 381.0 KB
Felülírás 91 567.4 KB
Hatályos 2 756.9 KB
Összes 94 324.3 KB
A vastagított sorok azok, amelyek még nem voltak itt eddig. És a gáz az, hogy ha törlök mondjuk 100 bejegyzést, akkor ezek a sorok növekednek, és összességében nem csökken a foglalt terület.
www.objectmentor.com - mit tudtok róla?
Pár hete próbáltam megnézni valamit a www.objectmentor.com-on, de nem sikerült ("Unable to connect...")
Meg is feledkeztem róla, de ma egy google találat kapcsán megint oda akartam menni és megint a fenti üzenet fogadott.
A blog megy, a többi oldal elérhetetlen.
Ami külön érdekes: meg akartam nézni a google-n, hogy utoljára mikor került be valami érdemi infó innen, ezért kipróbáltam egy ilyen kifejezéssel:
site:objectmentor.com -site:blog.objectmentor.com
Egész sok találatot kaptam.
Na jó, akkor szűkítem időben: elmúlt egy év -> nulla találat.
Vissza az időkorlát nélkülire, megnézem a cache-ben lévő adatokat, ott meg a fejlécben az áll, hogy 2012.aug.24-i állapotot látok...
Bugos a google is? :-)
ui: ha valaki nem értené, miért fontos az oldal: ismereteim szerint, Robert C. Martin itt szokott publikálni és elég sok érdekes anyaguk van OOP témában.
■ Meg is feledkeztem róla, de ma egy google találat kapcsán megint oda akartam menni és megint a fenti üzenet fogadott.
A blog megy, a többi oldal elérhetetlen.
Ami külön érdekes: meg akartam nézni a google-n, hogy utoljára mikor került be valami érdemi infó innen, ezért kipróbáltam egy ilyen kifejezéssel:
site:objectmentor.com -site:blog.objectmentor.com
Egész sok találatot kaptam.
Na jó, akkor szűkítem időben: elmúlt egy év -> nulla találat.
Vissza az időkorlát nélkülire, megnézem a cache-ben lévő adatokat, ott meg a fejlécben az áll, hogy 2012.aug.24-i állapotot látok...
Bugos a google is? :-)
ui: ha valaki nem értené, miért fontos az oldal: ismereteim szerint, Robert C. Martin itt szokott publikálni és elég sok érdekes anyaguk van OOP témában.