Názory k článku Manipulace se strukturovanými daty: úskalí naivních metod a jejich dopady

Možná jsem to jen nepochopil, třeba je potřeba víc článků, ale já nějak nevím, o co autorovi vlastně jde. Vymyslel jeden print, ke kterému potom tvoří filosofickou úvahu, není to na článek trochu málo?

No nevím, školy nemám...
Ale tohle mi příjde jako hodně hypotetický příklad. Není chyba spíš v nedostatečné kontrole vstupních dat? Jméno obsahující uvozovky by měl systém odmítnout s poukazem na zakázané znaky, nebo uvozovky automaticky smazat nebo alespoň nahradit apostrofy, pokud je jistota, že se tím popisované problémy vyřeší.
Mimochodem já jako skalní zastánce pascalu bych takový print nikdy nenapsal. :-)

Je chyba se snažit sanovat vstupní data předem, s ohledem na to, že obsahují něco potenciálně vadného. Jednak nevíte, kam všude data vstoupí, a jestli to tedy stačilo. Druhak ta data změníte, což taky nemusí být žádoucí.

Správný přístup je data escapovat až ve chvíli, kdy vstupují do nového subsystému, podle pravidel onoho subsystému. Tedy ve chvíli kdy z nich skládáte JSON. Nejlépe nějakou knihovnou na to určenou, nevynalézat znovu kolo.

Presne naopak ... vadny je pristup, kdy v kazdem systemu jsou jina data, protoze se resi prave az na jeho vstupu a kazdy si to (ne)resi nejak jinak a po svem.

Spravny pristup je analyzou (ja vim sproste slovo) urcit prunik a data omezit prave na vstupu tak, aby vyhovela vsem systemum a nemusela se nijak dal upravovat.

Znovuvynalezani kola je pak sam json.

Spravny pristup je na zaklade 1) poziadaviek 2) existujucich systemov a ich obmedzeni a 3) vysledkov analyzy rozhodnut sa, ktora metoda alebo ich kombinacia je najvhodnejsia.

Vzdy urcovat prienik je rovnako nespravne ako vzdy sanovat len pre konkretny system. Napriklad ak niektory system nezvlada diakritiku a specialne znaky ale iny system na zaklade rovnakych dat tlaci nejaku zmluvu tak nemozeme zo zmluvy len ak zmazat diakritiku a specialne znaky.

Chyba! Kdybyste provedl tu analýzu, zjistil byste, že na vstupu jsou správná data. Chyba není v datech, ale v tom, jak se s nimi pracuje. A eskejpovat je předem pro json nejde, protože nevíte kam všude ty data doputují a jak bude potřeba je eskejpovat na jiných místech. Ten, na koho reagujete, měl pravdu.

V Pascalu by zase nastal problém se stringem délky nad 255 znaků. ;oD

Nevšiml jsem si, ale je fakt, že je třeba upřesnit - nevšiml jsem si ve svém Freepascalu s UnicodeString :-)

V příkladu, o kterém se zatím bavíme, jde o zadání jména. Kolik lidí omezí 255 znaků? Ale jak jsem řekl, školy nemám. U dnešních Widestring s UTF-8 to nejspíš bude jinak.

Na tom přeci nezáleží, kolik lidí má jméno delší než 255 znaků. Záleží na tom, kolik lidí se pokusí nabourat systém skrz chybnou práci s daty.

print mu zde slouzi jen jako emulator vsech moznych systemu kde se zpracovava, validuje vstup dat.

Dnes mají snad všechny jazyky nativní JSON enkodéry a dekodéry. Takže pokud chci odněkud někam poslat validní JSON, použiji těchto funkcí a nemusím pak řešit co by kdyby...

Optimistický odhad je, že k takovému závěru se autor chce časem dobrat. Nebo je to spíš jediný předpoklad, za kterého ten článek dává aspoň trochu smysl.

Pokud to má být ukázka, že nemáme používat C-like jazyk a v něm přístupy k serializaci dat staré 30 let, docela se to povedlo. Každopádně jsem zvědavý, kam to bude pokračovat.

Taková variace na SQL injection.
A ano, stále se s tím v praxi setkávám. A s hard creating json taky.

Pravidlo programatora 37: Kazdy datovy format ma nejake 'escape' znaky. Od shell-u cez JSON, YAML, XML az po CSV a SQL.
Pravidlo programatora 38: Ak si myslite ze viete ktore a ako ich vsetky osetrit tak je lepsie pouzit specializovanu kniznicu.