ugrás a tartalomhoz

Creative Loading Effects

janez · 2013. Okt. 2. (Sze), 14.48
Kreatív betöltő effektek
 ■
1

Elég jó dolgai vannak a

inf · 2013. Okt. 3. (Cs), 06.29
Elég jó dolgai vannak a csajnak, ahogy nézem :D
2

Wow: ez mekkora ötlet:

inf · 2013. Okt. 3. (Cs), 06.41
Wow: ez mekkora ötlet: http://tympanus.net/Tutorials/NaturalLanguageForm/
4

Azt díjazom benne, hogy nem

Hidvégi Gábor · 2013. Okt. 3. (Cs), 12.00
Azt díjazom benne, hogy nem használ jQuery-t.
5

Cserébe viszont IE8-ban is

bamegakapa · 2013. Okt. 3. (Cs), 12.59
Cserébe viszont IE8-ban is már fallback van (ami nem baj).

Amúgy király a cucc.
6

Ez elkerülte a figyelmemet,

Hidvégi Gábor · 2013. Okt. 3. (Cs), 13.04
Ez elkerülte a figyelmemet, milyen fallbackra gondolsz?
7

Amennyire néztem, maga az

bamegakapa · 2013. Okt. 3. (Cs), 13.09
Amennyire néztem, maga az alap select elem, kis stílussal, de én se sok időt töltöttem vele. A kódban addEventListener, querySelectorAll, forEach, stb. bátran van használva.
8

Ja, azokat én is láttam.

Hidvégi Gábor · 2013. Okt. 3. (Cs), 13.17
Ja, azokat én is láttam. Programozni nem tud annyira, mint effektusokat létrehozni, pl. nagyon szépen keveri a DOM függvényeket az innerHTML-lel (szerintem egyszerűbb és gyorsabb lett volna az egészet az utóbbival létrehozni).
12

jQuery - IE8

Pepita · 2013. Okt. 4. (P), 09.41
Pont arra jó a jQuery, hogy helyettünk (többé-kevésbé) megoldja a böngészőkompatibilitást. Persze inkább a régebbi verziók, ott több fantázia kell tőlünk (ami talán még előny is).
DOM függvényeket az innerHTML-lel (szerintem egyszerűbb és gyorsabb lett volna az egészet az utóbbival létrehozni)
Csak erős haladóknak. Én kezdőknek nagyon nem javaslom az innerHTML-t / szöveges HTML írást. Ott követik el a legtöbb hibát, a megfelelő regexp-et sem tudják sokszor megírni. DOM fv-el ez elkerülhető könnyen. De szerveroldali HTML/XML-feldolgozás is ugyanez.
13

Ja, hát a világon a

inf · 2013. Okt. 4. (P), 11.20
Ja, hát a világon a legnagyobb marhaság saját html vagy xml parsert írni, amikor már létezik ilyen és 100x gyorsabb és jobb, mint ami a mi tollunkból jön... Egyedüli kivétel, ha vér profik vagyunk, és hatalmas mennyiségű xml-t szeretnénk feldolgozni, és tudjuk a tutit... :-)
14

Meg biztonságosabb is. Az

tgr · 2013. Okt. 4. (P), 13.16
Meg biztonságosabb is. Az innerHTML az a kategória, mint a mysql_real_escape_stringgel összerakott query: elméletileg lehet biztonságosan csinálni, gyakorlatilag ha nagy mennyiségben használód, előbb-utóbb biztos becsúszik egy sebezhetőség.
15

Milyen sebezhetőségek

Hidvégi Gábor · 2013. Okt. 4. (P), 13.33
Milyen sebezhetőségek csúszhatnak be? Arra célzol, hogy ha az innerHTML-be egy felhasználótól származó karakterlánc kerül?
16

User input

Poetro · 2013. Okt. 4. (P), 13.34
Pl. egy rossz indulatú felhasználó egy script taget állított be a felhasználói nevének, vagy valami más rosszaság. A DOM függvények ettől védenek, ugyanis a document.createTextNode mindig text node-ot hoz létre. Ha valaki ügyeskedik, és az innerHTML-be rakott tartalom nincsen előbb megfelelően validálva és escapelve, az csúnya dolgokat eredményezhet. A DOM függvények ettől a validációtól megkímélnek, ugyanis a böngésző elvégzi a megfelelő escapelést helyetted.
17

Azért egy kérdés...

Pepita · 2013. Okt. 5. (Szo), 01.59
inf3rno, ha én elkövettem azt a "marhaságot", hogy írtam saját BBCodert és Markdown-átalakítót, akkor marha vagyok, vagy vér profi? :)
Szerintem egyik sem, egyszerűen különböztek az igényeim a fellelhető cuccoktól. Persze ez nem DOM/XML.
18

A bbcode és az md nincs

inf · 2013. Okt. 5. (Szo), 02.36
A bbcode és az md nincs beépítve a php-ba semmilyen formában, velük ellentétben az xml-nél ott van a libxml, szóval egyáltalán nem egy kategória a kettő. Ettől függetlenül én inkább meglévő parsert használnék vagy alakítanék át, ha ilyen igényem lenne, feltéve ha nincs benne preg_replace eval sebezhetőség meg hasonló ;-)
19

Ezért nem találtam...

Pepita · 2013. Okt. 5. (Szo), 23.35
én inkább meglévő parsert használnék vagy alakítanék át, ha ilyen igényem lenne, feltéve ha nincs benne preg_replace eval sebezhetőség meg hasonló ;-)
Amit be lehetett volna állítani az én igényeim szerint, az nagyobb volt, mint a framework :), ami meg kicsi, az nem azt, nem úgy, és nem ritkán eval-lal. Nem sokat keresgéltem, megírtam én, amit könnyen át is írok, mindkettő egy-egy kicsi osztály, és 1-2 extrát tud. Így csak azt csinálja, amit akarok, nagyon rövid futásidővel.
Persze, hogy XML-re nem írnék... :)

Szerk.: egyébként mi a gondod a preg_replace eval-al? Ha jól használod (pl. osztályon belüli fv-re), szerintem nem gond. Ha tévednék, kérek szépen "felhomályosítást"! (Így fejből: mintha a MD-ban lenne...)

Szerk2.: Szóval én a szerver oldalról (PHP) beszélek, a kliens másik történet.
20

egyébként mi a gondod a

Poetro · 2013. Okt. 6. (V), 10.05
egyébként mi a gondod a preg_replace eval-al?
$felhasznaloi_adat = '<h1>{${print_r($_SERVER)}}</h1>';

preg_replace('/<h[123][^>]*>(.*?)<\/h[123]>/ie', "strtoupper(\"\n\n\\1\n\n\")", $felhasznaloi_adat);
Array
(
    [HTTP_ACCEPT] => text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
    [HTTP_ACCEPT_CHARSET] => 
    [HTTP_ACCEPT_ENCODING] => gzip, deflate
    [HTTP_ACCEPT_LANGUAGE] => en-GB,en;q=0.8,en-US;q=0.6,hu;q=0.4
    [HTTP_CONNECTION] => keep-alive
...
)
Az exploit rosszindulatú kihasználása innen gyerekjáték.
22

Igen, ha a template-eződben

Pepita · 2013. Okt. 6. (V), 16.17
engedélyezve van a {...}.
Nekem nincs, épp ezért (részben).
De elgondolkodtam így is a módosításon, mert van ilyenem:
$text[$n] = preg_replace('/\[img\="?(.*?)"?\]/ue', '$this->img_check("$1")', $text[$n]);
//...
private function img_check($url) {
//...
  if (mb_strpos($url, $this->base_url) === 0) {
    return '<img src="'.$url.'" />';
  } else {
    return '[ELUTASÍTOTT KÉP]';
  }
}
Ezt pont azért vettem külön fv-be, hogy beállítástól függően tiltani lehessen az idegen URL-ről származó képeket.

Én túl bonyolultnak tartom szűrni a {...}-ket, úgy, hogy mint karaktert lehessen használni (akkor egy nagy szótár kéne, hogy mik nem szerepelhetnek közte, és a tiltó szűrés sem "zsánerem", inkább a megengedőt szeretem, ami abban nincs, az tiltott).
Ezért tiltom a template-ben, így ott csak "valódi" tagek érvényesülhetnek tag-ként (és mivel nem HTML-t várunk, mindjárt &lt; lesz belőle, stb.). Szerintem így nem gond, és nem tudom, hogy a preg_replace_callback mennyivel-mitől lenne jobb ebben az esetben.

Szerk.: bár lehet, hogy a példádat nem egészen értem. ({$...)
23

http://php.net/manual/en/func

inf · 2013. Okt. 6. (V), 17.31
http://php.net/manual/en/function.preg-replace-callback.php

Nem érted a lényeget, felhasználótól származó tartalmat escapelés nélkül hívsz meg php kódként. Gyakorlatilag bármilyen php parancsot meghívhatnak innentől az oldaladon, mondjuk egy általuk feltöltött php fájl includolását, vagy még egy eval-t, amibe már tényleg tetszőleges hosszú kódot írhatnak, stb...
24

Természetesen manuált néztem

Pepita · 2013. Okt. 7. (H), 02.56
felhasználótól származó tartalmat escapelés nélkül hívsz meg php kódként
Na ez az, ami nálam nincs, bár a kódrészletből hiányzik. A felhasználótól jövő adaton elsők közt van (akár BBCode, akár MD) a < cseréje. Ezért írtam a template-re is a "{" tiltást, ezért nem használom (meg a template-ben is nekem jobban átlátható a <?php..., de nem ez a lényeg).

Így a különbséget még mindig nem értem (a preg_replace_callback sem escape-el helyetted), illetve ha korábban már levédtem az inputot, akkor miért ne használhatnám?
Lehet én vagyok értetlen, de még mindig nem tiszta.
25

$text[$n] =

inf · 2013. Okt. 7. (H), 05.45

$text[$n] = preg_replace('/\[img\="?(.*?)"?\]/ue', '$this->img_check("$1")', $text[$n]);
Ez nagyon messze van az escapeléstől, simán lehet küldeni olyan string-et img után, amiben van ", ami kiüti az img_check utáni idézőjelet, és máris injektálható bele php kód. Az eval használata minden esetben életveszélyes, mert csak egyszer felejtesz el szűrni valamire, és máris kész a baj...

A preg_replace callback a $1-et paraméterként adja át, így nem is kell escapelni azt.
26

Köszönöm, átírom

Pepita · 2013. Okt. 7. (H), 10.11
Bár elvileg nem lehet eddigre a $1-ben "<" (és sehol máshol sem a szövegben), az mégis lehet, hogy megkerülhető. Az idézőjel "tette tisztába", köszönöm.
27

Ez ebben a formában nem igaz,

tgr · 2013. Okt. 7. (H), 10.37
Ez ebben a formában nem igaz, az idézőjelnek nem lesz speciális jelentése a $1-ben, de más módon ki lehet használni. A manual elég jól összefoglalja.
28

Itt azt nem értem, hogy

Pepita · 2013. Okt. 8. (K), 15.46
"hogyan lesz" a "{"-ből <?php. De mivel 5.5-től szevasz neki, mindenképp javítanom kell.

Eddig is köszönöm.
29

double quoted strings >

tgr · 2013. Okt. 8. (K), 16.39
double quoted strings > variable parsing > complex syntax
30

Köszönöm szépen!

Pepita · 2013. Okt. 8. (K), 18.37
Ez eddig elkerülte a figyelmemet - nagy hiba.
21

Inkább csináld preg replace

inf · 2013. Okt. 6. (V), 11.21
Inkább csináld preg replace callback-el, az eval-nál nagyon nagy az injektálás veszélye.
9

Ja mondjuk ennek is megvannak

inf · 2013. Okt. 3. (Cs), 18.15
Ja mondjuk ennek is megvannak a korlátai, ha az akadálymentesség, vagy a masszív adatbevitel a szempont, de pl egy ilyen keresőre egy mondat az teljesen okés...
10

Nem értem, az általad

Hidvégi Gábor · 2013. Okt. 4. (P), 07.19
Nem értem, az általad belinkelt megoldás pont akadálymentesen használható.
11

Egyik haver írta, hogy nem,

inf · 2013. Okt. 4. (P), 08.47
Egyik haver írta, hogy nem, én hittem neki, ezek szerint hiba volt :-) Végülis ha belegondol az ember tényleg akadálymentesebb, mint egy össze-vissza label-ezett űrlap, aminek ki tudja hol van a másik fele. A srác még azt is felhozta ellenérvnek, hogy az összetett mondatokat nem mindenki érti meg :D
3

Hasznos

Pepita · 2013. Okt. 3. (Cs), 10.24
Nagyon jó ötletek szerintem.