Dotaz: problém so spracovaním dát ajaxom - z PHP zlé z HTML OK

[adrinko]

Ahojte, prosim o pomoc, netusim preco dochadza k takemuto problemu:

ked nacitam do ajaxu data zo statickeho skriptu index.html vsetko je ok. ale ked mi tie iste data vygeneruje dynamicky php vycitanim ich z db a naslednym echom, tak ajax nezbehne dobre, hlasi chybu (prehliadac).

co je toto za hovadinu?

priklad: index.html vypise "XXX" script.php vypise "XXX" ale vygeneruje to takto: echo $data[0]->var;

viete niekto, v com je problem, preco data z php nie su dobre?

Odpovědi

[Tarmaq]

jakou chybu hlasi prohlizec? je urcite nultym prvkem pole $data instance nejake tridy?

[adrinko]

áno, data je určite ok, lebo to vypíše vporiadku php (keď si otvoriím ten skript priamo v browseri). Prohlížeč IE píše syntax error line 281 character 163 v súbore ttm/canvas.1.03.jgz.

[adrinko]

ešte prikladám ten súbor http://www.freefilehosting.net/canvas103

[Tarmaq]

je velky problem ten soubor uploadnout primo sem?

[Šangala]

Určitě jsou to dva rozdílné výstupy lišící se nějakým netisknutelným znakem…

[adrinko]

a viem to nejako zistiť, ktorý je ten netiskutelný znak?

[Šangala]

Jo, normálně si to stáhnout a pak se podívat/porovnat to třeba hex editorem.

[adrinko]

neviem kde je problém, ale zistil som,že keď jednoducho vyechujem toto:

$from ='05/17/2012 10:15:00';
  $to ='05/17/2012 10:30:00';
  $day ='5/17/2012';
echo '{ "dtstart": "'.$from.'", "dtend": "'.$to.'", "day": "'.$day.'" },';

tak to fičí ok, ale akonáhle pred to dám hocijakú funkciu, tak to ajax nespracuje, napr. toto (prepíšem na konci tie isté premenné čo v prvom skripte, ale aj tak to nejde dobre):

$from= preg_replace('/[\x00-\x1F\x80-\xFF]/', '',$data[0]->time_from);
$to  = preg_replace('/[\x00-\x1F\x80-\xFF]/', '',$data[0]->time_to);
$day = preg_replace('/[\x00-\x1F\x80-\xFF]/', '',$data[0]->day);
$from ='05/17/2012 10:15:00';
  $to ='05/17/2012 10:30:00';
  $day ='5/17/2012';
echo '{ "dtstart": "'.$from.'", "dtend": "'.$to.'", "day": "'.$day.'" },';

[Tarmaq]

hocijaku funkciu? ozaj? orly? neverim.. IMHO je problem nekde v poli $data

[adrinko]

keby bol problém v $data, tak keď naplním znova manuálne tie isté premenné novými hodnotami (ako v ukážke kódu), tak by to malo fungovať, nie? ale mne to ani tak nefunguje.

[Tarmaq]

presne tak, do promennych $from, $to, $date by se mely stejne priradit rucne definovane hodnoty, takze problem bude spise v tom, ze tam dojde k nejake notice/warning nebo tak neco, co pak rozbije ten vystup..

[adrinko]

síce som neprišiel na to, čo tam blbne, ale prerobil som pole na iný tvar a ide to konečne super! diky za navedenie na správnu cestu!

Array(
    [0] => array        (
            [id] => 24
            [time_from] => 05/17/2012 10:15:00
            [time_to] => 05/17/2012 11:30:00
            [day] => 05/17/2012
        )
 
)

[Šangala]

object vs. array?

[adrinko]

áno, presne. ale netuším, prečo to s obejct nefunguje.

[Šangala]

Asi to není všechno, co tady vidíme, a nebo prostě to tam generuje výstup, který je nám zde odpírán.
Třeba tam vyletí nějaký notice či warning…
Toto je to samé:

<?php
class Data{
  public $time_from = '05/17/2012 10:15:00';
  public $time_to ='05/17/2012 10:30:00';
  public $day ='05/17/2012';
};

$data = Array(0 => new Data());

$from= preg_replace('/[\x00-\x1F\x80-\xFF]/', '',$data[0]->time_from);
$to  = preg_replace('/[\x00-\x1F\x80-\xFF]/', '',$data[0]->time_to);
$day = preg_replace('/[\x00-\x1F\x80-\xFF]/', '',$data[0]->day);

echo '{ "dtstart": "'.$from.'", "dtend": "'.$to.'", "day": "'.$day.'" },';

jako byste přímo zapsal toto:
{ "dtstart": "05/17/2012 10:15:00", "dtend": "05/17/2012 10:30:00", "day": "05/17/2012" },

[mess]

Tady vidím potenciální problém - čárka , na konci toho výpisu. Zkusil bych ji dát pryč, co to udělá.

[Šangala]

Jen jsem vysvětloval, že v tom není žádný rozdíl, jestli se to generuje a zavolá se nějaká fce, nebo se to vystřelí přímo - krom toho, že při generování tam můžou být chyby, které se snadno zjistí s vygenerovaného výstupu…
Jak bylo zadání, tak jsem to tam opsal.

[adrinko]

btw $data dava

Array(
    [0] => stdClass Object
        (
            [id] => 24
            [time_from] => 05/17/2012 10:15:00
            [time_to] => 05/17/2012 11:30:00
            [day] => 05/17/2012
        )
 
)

v čom by tam mohol byť do kelu problém?

[Kit]

Co to tam vyvádíš s tím echem? Snad se z toho nepokoušíš vyrobit JSON?

echo json_encode(array("dtstart"=>$from,"dtend"=>$to,"day"=>$day));

[adrinko]

problém s json_encode je ten, že mi z 05/17/2012 spraví 05\/17\/2012

[Kit]

To je snad dobře, ne? Alespoň je ten JSON korektní. To děláš pro Američany?

[adrinko]

:D s tými Američanmi som sa pobavil. nie nie, nerobím to pre nich. je to taká nepodarený library, volá sa yui, ktorá berie len hetak naformátované veci a preto ak sa tam vyskytne spätné lomítko, tak to už nevie spracovať (teda vytiahnuť si dátumy korektne...)

[DK]

tak tam pridej replace do yui ne? :)

[adrinko]

pravda, to by šlo.

[Kit]

Pokud ten JSON budeš dávat do Javascriptu, stačí použít funkci eval(), která si s těmi zpětnými lomítky hravě poradí.

[Filip Jirsák]

A s jiným podstrčeným kódem taky.

[Kit]

Funkce json_encode() přidává uvozovky, podstrčený kód se tedy předá jako řetězec.

[xkucf03]

On spíš myslel, kdyby ze serveru přišel obecně nějaký závadný JSON (ve skutečnosti závadný skript), ale to není až takový problém, protože vlastnímu serveru bys měl věřit (a v případě MITM ti může podvrhnout cokoli jiného, takže už je to jedno).

[xkucf03]

Podle JSONLint validátoru je:

{
    "dtstart": "05/17/201210: 15: 00",
    "dtend": "05/17/201210: 30: 00",
    "day": "05/17/2012"
}

v pořádku. Že by zase nějaká JSON obskurnost?

[Josef Kufner]

Ty zpětná lomítka před normální se tam přidávají, aby náhodou nevznikl uzavírací tag, který by mohl dělat někdy potíže. (Jo, je to úchylárna.)

http://stackoverflow.com/questions/1580647/json-why-are-forward-slashes-escaped

[xkucf03]

Dík, to jsem nevěděl.

Ale jinak OMG: od toho máme přece

<![CDATA[
…
]]>

[Josef Kufner]

Tím jen převedeš problém na zákaz "]]>".

[xkucf03]

No, hlavně odpovědnost za správné escapování nemá mít JSON (ani formát, ani knihovna), ale ten, kdo něco někam vkládá. A escapovat se bude pokaždé jinak podle toho, jestli vkládám do elementu bez CDATA, nebo do CDATA, nebo do atributu, nebo do .js souboru, nebo třeba do zdrojáku LaTeXu nebo jakéhokoli jiného formátu/prostředí… Připomíná mi to PHP Magic Quotes a podobné bastlení.

[Kit]

A proč? Když budu chtít uložit do JSONu binární data, tak nejsem povinen je nijak escapovat. json_encode() si s tím musí umět poradit tak, abych při json_decode() dostal identická data.

Když ukládám data do DB, tak je také nesmím escapovat, abych je měl v DB přesně byte po bytu tak, jak je tam potřebuji mít.

[Josef Kufner]

Tak. A když pak vkládáš JSON do HTML, tak ho musíš taky escapovat.

[Kit]

Ne. Když vkládám JSON do HTML, tak nejprve json_decode() a pak htmlspecialchars(). V HTML nemá JSON co pohledávat.

[Josef Kufner]

Proč decode?

[Kit]

Abych dostal původní datový strom, který jsem si do JSONu uložil a mohl s ním dál pracovat.

[Josef Kufner]

A v čem to pomůže jeho vložení do HTML?

[Šangala]

A zas jindy musím data escapovat, když je vkládám do db, abych je měl v DB přesně byte po bytu tak, jak je tam potřebuji mít.

[xkucf03]

Protože můžu napsat třeba:

<script>
  <?php
    echo json_encode(array("dtstart"=>"<![CDATA[","dtend"=>"05/17/2012 10:15:00"));
  ?>
</script>

nebo

<script>
  <?php
    echo json_encode(array("dtstart"=>"<script>","dtend"=>"05/17/2012 10:15:00"));
  ?>
</script>

což mi rozbije výstup.

Případně když budu vypisovat jinam (atribut, jiný formát), může se tam rozbít něco jiného. Proto je potřeba, aby escapoval ten, kdo ví*, kam se vypisuje. A tudíž je to polovičaté escapování ve funkci json_encode() nadbytečné a povede akorát ke zmatkům a chybám – stejně jako ty PHP Magic Quotes – programátoři se budou spoléhat na to, že můžou jen tak přilepit návratovou hodnotu funkce do výstupu a nebudou ji escapovat a špatně dopadnou.

Ta funkce má i volby – trochu by pomohla JSON_HEX_TAG, která zneškodní ty < >, ale stále tam zbudou & a ty budou dělat neplechu (neexistující entity). Takže je potřeba přidat ještě JSON_HEX_AMP. A už to není tak jednoduché a možná tam jsou i další díry…

Je to takový neunixový přístup, jedna funkce se toho snaží dělat příliš mnoho a nakonec to dělá blbě. Daleko lepší mi přijde to rozdělit – mít jednu spolehlivou funkci na generování JSONu a jinou spolehlivou funkci na escapování (pro různé výstupní formáty) a tyto dvě funkce zřetězit:

$výstup = bezpečněEscapujProDanýVýstupníFormát(generujNějakáData($vstup));

*) což může být programátor, který zavolá patřičnou funkci, nebo třeba nějaký inteligentní šablonovací systém, který zná kontext.

[Josef Kufner]

<script>
  <?php
    echo htmlspecialchars(json_encode(array("dtstart"=>"&<![CDATA[","dtend"=>"05/17/2012 10:15:00")));
  ?>
</script>

[xkucf03]

Ano, tak je to správně* – ostatně to jsem myslel tím bezpečněEscapujProDanýVýstupníFormát(). Jenže pak je nějaké přidávání zpětného lomítka před / zbytečnost a nemá tam co dělat – akorát to někoho svede k chybě.

*) relativně – zase to zbytečně převádí " na &quot;, přestože uvozovky v textových uzlech (uvnitř elementů) klidně být můžou a je potřeba je převádět jen v atributech – a to ještě jen v těch, kde je hodnota zavřená do uvozovek – zatímco v <element atribut='nějaká "hodnota" s uvozovkami'/> klidně být můžou.

[Josef Kufner]

Ale v apostrofech uzavřené hodnoty zas nemohou obsahovat apostrof, takže to escapování uvozovek je celkem dobrý nápad. Ale jinak htmlspecialchars bere jako parametr příznak, zda uvozovky escapovat, či ne.

[xkucf03]

Koukám, že tam jsou příznaky na oboje – ENT_NOQUOTES a ENT_QUOTES – takže se dá dosáhnout celkem precizního výsledku, kdy se neescapuje to, co není potřeba:

• apostrofy ani uvozovky uvnitř elementů
• apostrofy uvnitř atributů zavřených do uvozovek
• uvozovky uvnitř atributů zavřených do apostrofů

ale výchozí chování je takové humpolácké.

[Kit]

Specifikace formátu JSON připouští 2 možnosti ("/", "\/") a to není dobře. Na druhou stranu není možná dvojí interpretace. Shodneme se snad na tom, že při ukládání by nemělo být escapování pokud možno žádné, ale při výstupu je nutné escapovat podle kontextu, ve kterém je generován:

• Javascript v HTML
• čistý Javascript
• čisté HTML
• něco jiného

Pokaždé je potřebné escapovat trochu jinak. Ve chvíli, kdy JSON vytváříme, však teoreticky nemusíme tušit, v jakém formátu bude uskutečněn výstup a proto jsou tyto zmatky.

[xkucf03]

V tom se shodneme.

Nelíbí se mi to, když funkce na generování JSONu tam jako výchozí cpe ty \/, protože pak z toho bude mít někdo pocit, že nemusí escapovat a dojde k chybě. A když naopak escapovat bude, tak jsou tam ty \ nadbytečné – k chybě sice nedojde, ale proč je tam dávat?

[mess]

Ještě bych se zkusil podívat, jaké hlavičky posílá server, když servíruje to HTML a porovnal s tím, když servíruje PHP.