FormHelper miért konvertál?
Sziasztok!
A kovetkezo problemat a cakephp magyar foruman is felvetettem, de valaszt nem kaptam. Gondoltam hatha itt nagyobb sikerrel jarok.
Mielott eltarolok valamit az adatbazisban, raeresztem a sanitize clean() metodust a bejovo adatokra. Igy az adatbazisban pl. a < jel < alakban tarolódik el.Megjeleniteskor nincs is baj, viszont ha a tartalmat egy input mezobe rakom, akkor az elejen levo & konvertalodik & -ra, es az eredmeny a html forrasban &lt; , vagyis az oldalon nem alakul at < jelle, hanem a kodjat latom.
Ha nem a metodust hasznalom, hanem hagyomanyosan alakban, akkor mukodik.
Nem ertem, hogy ha mar van Sanitize::clean(), akkor kiirasnal miert nem ugy mukodik a dolog, ahogy elvarna az ember. A kerdesem: mas ezt hogy oldja meg?
■ A kovetkezo problemat a cakephp magyar foruman is felvetettem, de valaszt nem kaptam. Gondoltam hatha itt nagyobb sikerrel jarok.
Mielott eltarolok valamit az adatbazisban, raeresztem a sanitize clean() metodust a bejovo adatokra. Igy az adatbazisban pl. a < jel < alakban tarolódik el.
$this->data = $sanitize->clean($this->data);Ha nem a
$form->input()echo '<input type="text" value="'.$value.'" />'Nem ertem, hogy ha mar van Sanitize::clean(), akkor kiirasnal miert nem ugy mukodik a dolog, ahogy elvarna az ember. A kerdesem: mas ezt hogy oldja meg?
Ennek így is kell mennie
Milyen Cake verziót használsz?
En is ezt a verziot
Tegnap elkovettem ezt: link. De nem ertem, mit akar, mit csinaljak.
Meg mindig nem ertem
Nem hiszem el, hogy ezt csak ilyen ganyul lehet megcsinalni :/
escape opció
Ahogy ott olvasható, kicsy jól sejtette (apiban nincs benne), van egy 'escape' nevű opciója az inputnak, ami alapból true. Nekem azért volt jó, mert textareás inputtal néztem, ott meg valamiért nincs eszképelés.
A ticketben phpnut szerintem azt akarja mondani, hogy általában nem az inputot kell szűrni, hanem az outputot, de nem tudom, hogy a core-ral kapcsolatosan pontosan mire hivatkozik, hiszen spec. karaktereket (magától értetődően) minden további nélkül be lehet rakni az adatbázisba. Tehát jogos a kérdésed, csak a ticket nem alkalmas arra, hogy ilyeneket részletesen megbeszéljetek. nate utána leírja, hogy szűrsz mindkét irányba, de a konkrét megoldást nem említi :)
A sanitize-t (meg a core komponenseket) egyébként nem kell példányosítani: Sanitize::clean()
A htmlentities-re van egy h() shorthand.
Es igeeeeeen!
Nem tudom, miert nem talaltam ra az altalad linkelt oldalra, ha 40 keresest nem inditottam, akkor egyet se. Igazabol par dolgot nem ertek. Nem tul bonyolult a problema, hogyhogy nem futott meg bele senki (eltekintve a google groupse-os linktol)? Ugyanis ha valahogy el akarjuk tarolni a spec. karaktereket, akkor elojon a problema. Akarhogy taroljuk adatbazisban, kesobb vagy kiirasnal, vagy formos megjelenitesnel szivunk.
A masik, hogy mit nem ertettek ott a ticketben? Szerintem vilagosan leirtam :) De komolyan. Ok irjak a core-t, benne vannak nyakig.
Van meg egy bugom, de az nem tulsagosan erdekel, es ezek utan nem is fogom venni a faradsagot, hogy utanajarjak, ticketeljem. Leirom ide, jo kedvem lett, hala neked! :)
Sanitize::clean()-nek megadhatunk egy options tombot. Csakhogy ha a tisztazando valtozonk egy tomb, akkor a clean() a rekurziv hivasoknal nem az egesz options-t adja at, hanem csak a connection-t. Igy tombok eseten nem erunk semmit pl. egy 'encode' => false -sal.
(ez meg ugye akkor jon elo, ha pl sql safe adatokat akarunk, viszont a html karaktereket ugy, ahogy vannak, el akarjuk tarolni)
U.i.: Egyebkent ha az outputot akarom szurni, akkor minden view-ban minden valtozot h()-val irjak ki? Vicc.
nincs különösebb furcsaság
Én nem látok furcsaságot abban, hogy ennyi találat van. A GGroups cake nyitóoldaláról kerestem rá a "sanitize"-ra (4. találat). Ezer ugyanilyen probléma van, ugyanilyen publicitással. Én pl. még nem használtam a sanitize-t (igaz, közösségi oldalt se írtam cake-ben).
Értették, mit akarsz. phpnut leírta, hogy nincs okod az inputot megszűrni. A manuálban is output-ra használják a sanitize-t. Persze ezen lehet vitatkozni, csak nem egy ticketben. A form inputok mindenesetre sql biztosak, nem kell őket szűrni, ezt is leírta. Te megszűrted a bemenetet, de a kimenetben nem kapcsoltad ki a default escape-et, tehát kétszer szűrtél, ezt meg – kicsit szűkszavúan – nate írta le. Ehhez hozzájön még, hogy a ticketed alapvetően egy invalid bugjelzés volt.
Viszont amit az options paraméterrel kapcsolatban írsz, az tényleg bugnak látszik (úgyhogy ha nem te ticketeled, akkor én fogom :)) Nincs hozzá teszt sem, és a logból kiderül, hogy miért maradhatott benn: korábban csak a connection volt ott paraméterként, azt wrappelték be az options-be, tehát el lehetett nézni.
Ez az, ami egy száraz keretrendszerben fel sem merülhet. Model::afterFind(), Controller::beforeRender() stb.
fixed
Biztos ilyen egyszeru?
Kovezz meg, de szerintem ezekkel se egyszeru. Tegyuk fel, van egy User modelled. Adatok: nev, kor, mai_motto
Az oldalad fooldalan meg akarod jeleniteni az utolso 5 olyan user adatait, akik legutobb valtoztattak meg a mai_mottot.
Minden user a users/mai_motto_mod oldalon megvaltoztathatja a mai_motto-jat (text field), valamint fel van tuntetve a neve es a kora (echo).
Tfh. az adatok 'nyersen' vannak tarolva, nincsenek szurve. Kiiras elott akarom rajuk engedni a Sanitize::clean()-t
Hogy ered el, hogy a view-oknak atadott tomb a fooldalon teljesen szurt legyen, viszont a users/mai_motto_mod oldalon a $user['User']['mai_motto'] _ne_ legyen.
Model::afterFind()-ot nem hasznaltam meg, de ha jol sejtem, tudnod kellene, hogy melyik view lesz megjelenitve, mert ugye a $user['User']['mai_motto']-t valamikor szurni kell, valamikor nem.
Megintcsak, ha mindent szurhetnel, mindegy lenne, hogy az inputot szurod, vagy az outputot (azert hozzateszem, hogy outputot szurni 'draga', mivel tobbszor kernek le adatot, mint modositanak). De ha figyeled azokat a tombelemeket is, amelyek form-ba mennek, akkor ott egye meg a fene. Egy automatikus funkcio miatt kodoljak 10-20 sorokat pluszba?
Egy szavam nem lenne, ha az 'escape' ott lenne az api-ban. De meg akkor se szolnek, ha a kerdesem utan elarultak volna.
Szoval ha van egy kis idod, melazz el ezen, es aruld el, mire jutottal :)
Igen
A tickettel és az escape-pel kapcsolatban félig igazat adok neked: a ticketedet máshol is így kezelnék le. A dokumentáció meg hírhedten hiányos, ezt a cake-kel kapcsolatban egyelőre el kell tudni fogadni. (Az én szerénytelen mazochizmusomnak ez valahogy még tetszik is, rákényszerít, hogy kicsit mélyebb szinten is magamévá tegyem a frameworköt, de fejet hajtok előtte, ha emiatt éri kritika.)
Talán érthető, ha az escape nem kerül gyakran előtérbe: ugyanis az edit formokat érinti (add-okat, tehát üres formokat nem, mint pl. egy fórum hozzászólásmezője), ott meg általában adminról van szó, ahol nem (olyan) szükséges a védekezés. És nyilván sokan rátalálnak arra a ggroups topikra, prominens helyen van, csak a "sanitize" szót kell beírni a keresőmezőbe.
Tanulsag
Csak ne ment volna ra 2 napom erre a hulyesegre.