Vlákno názorů k článku Jak EET vidí ajťák aneb Draze zaplacená vražda uživatelské přívětivosti od anonym - O vytvoření ukázkových kódů jsem GFŘ žádal, ale...
-
Pazu (neregistrovaný)
Tak se to jeví jen v rámci tvojeho technologického světa. Napříč to nechodí, protože specifikace jako WS-* obsahují příliš stupňů volnosti - jsou nedokonalé. A ufoni u jiných světů to prostě pochopili jinak. Asn.1 trpí v reálu stejným problémem, jak soap i json, a to je význam aplikačních dat. Ale to by snad u přenosu jedné částky v korunách neměl být takový problém?! Pak určitě zvolit nejjednodušší protokol, třeba řádky oddělené crlf. A v ústavě přikázat, že ministerstvo musí k specifikaci přidat funkční oss klienty pro 90% zařízení na trhu, ono je to bájení o IBM přejde.
-
Který z použitých algoritmů?
Podle https://www.keylength.com/en/8/ jsou sice některé na hraně, ale v souladu s aktuálními doporučeními.
-
Já to znám, nebojte. Ale máte pravdu, že jsem to mohl rozvést, slovo „pomocí“ by se dalo chápat i tak, že tam ta data zapíšu tak jak jsou, ale tak to myšleno nebylo. Ostatně, je to CDATA, ne BDATA.
Takže ještě jednou a lépe: binární data je možné do XML kódovat mnohem efektivněji, než je hexadecimální zápis nebo base64.
-
Pavel (neregistrovaný)
Binární data jdou do XML vložit pomocí sekce CDATA.
Ano, už jsem videl hodně pomýlenců, co si toto mysleli, a pak koukali jak tele na nová vrata, že ono to ne a ne a nefunguje.
Pro začátek doporučuji XML Standard a v něm věnujte pozornost odstavci 2.2.
-
Problém ASN.1 je v tom, že nabízí příliš mnoho možností serializace, přičemž některé ani nejsou samopopisné (musíte znát schéma, abyste je dekódoval). V XML je tohle ve formě entit a defaultních hodnot ve schématu, které se ale v praxi nepoužívají (DTD mělo být už dávno z XML vyhozeno aby standard pokrýval to,co se v praxi používá, celý standard by se tím také výrazně zjednodušil).
Binární data jdou do XML vložit pomocí sekce CDATA.
&se vkládá tak, jako do jakéhokoli jiného HTML nebo XML – & escapujete jako&a za to napíšeteamp;, ve výsledku tedy napíšete&. -
P2010 (neregistrovaný)
Ano, je to jen o tom, zda to vedet chteji.
Embedded aplikace, tam nemam vubec predstavu, moznosti tech dnesnich hw pro IoT me prijdou pro to dostatecne. Nakonec i ta XML zprava je jen shluk bytu, ktery podepisete. Idealni by asi bylo poskytnout EET rozhrani v obou technologiich, ale to by stalo dalsi stamiliony :-)
Na neco takoveho kde jde nakonec o penize bych se to Android neodvazil pouzit. Tam mi neni jasne, jak chce dodavatel poskytovat nejakou zaruku funkce, zvlaste opakovani odeslani zpravy pri vypadku (Android se mezitim 20x zadre a bude treba restart, zprava se neulozi). To je proste technologicky odpad s nulovou spolehlivosti a bezpecnosti, vyrazne horsi moznost nez ty jednoucelove embedded aplikace.
-
Často tomu tak může být. Napadají mě dvě výjimky.
Vyspělé vývojové nástroje, které složitost skryjí pod jednoduchou fasádu a fungují automagicky, vedou k tomu, že uživatelé/vývojáři mnohdy nevědí, čeho činí. V tomto příépadě je to možné dávat za vinu nedoukovi uživateli.
Ale co se EET týká, zde mi složitost vadí zejména proto, že se dá čekat vývoj nejen pro plnohodnotná "tučná" prostředí, ale také embedded aplikace. Dovedu si představit, že ze zařízení založeného na ESP8266 celkem pohodlně provolám REST API včetně kryptografie v HTTPS a elektornickém podpisu. XML Signaturu už do toho čipu nenacpu.
I v dnes již celkem ztučnělém Androidu je sada standardů pro EET API docela oříšek.
-
P2010 (neregistrovaný)
Neni spis problem jinde ? Pouzitim normalniho vyvojoveho nastroje prece nemusim tohle vubec resit (coz neznamena, ze nemam o te technologii neco vedet). Zkratka naimportuji WSDL, ziskam typove bezpecny klientsky kod (interface, metody, typy), nastavim certifikat a mohu volat sluzbu. O vlastni format a zabezpeceni XML zprav se uz nemusim starat a uz vubec nemusim neco zkouset stylem pokus/omyl.
Prave to je prinos vyspelych a standardnich (a otevrenych) technologii.
-
Každý má své důvody.
Pro ASN.1 vs. JSON/JWS jsou ty moje důvody následující:
Na pochopeni ASN.1 se všemi možným (DER, BER, XER) tu více tu méně jednoznačnými serializacemi té "abstraktní" syntaxe s implicitními/explictiními/kontextově závislými tagy je třeba sestudovat pěkných pár set stran.
K použití JSON/JWS mi stačí pochopit jednoduché kódování znaků, base64 a poměrně triviální syntaxi JSON. Desítky stran specifikací. Plus jako bonus snadného ladění zvládnutelné s textovým editorem a pár skripty.
-
Ogar (neregistrovaný)
Proc se tocit v kruhu XML, JSON, kdyz tady mame radu let proverene ASN1?
V ASN1 je specifikovan/implementovan X509 (cerifikaty, klice), vlasni podpis zprav, cele SSL/TLS, proste vse ...
Navic ASN1 je prefixova notace - nemusim hledat 'parovy' koncovy element - hned na zacarku vim delku. Tudiz odpoda nutnost `escape` sekvenci ala & lt ; & gt ; & amp ; .... Vse je 1:1 :-)
Proc vymyslet neco nove s XML, JSON a pak specifikovat, co vsechno se vlastne podepisuje (hmm, mame string - binarni/UTF8-data, prevedeme to pro podpis do BASE64? nebo HEX? i s BOM? a Unicode ala Micro$oft v little-edianu)? A co `escape` sekvence ala `& amp ;` - ty podepiseme jako `&` nebo jako `& amp ;`?
Hmm, ale vydelek podpisu je binarni vec, kterou do XML nevlozime - take zase prevest na HEX nabo BASE64 .....
P.S. Otazka za 100 bodu - jak vlozit inteligentne do tohoto xml bazmeku & amp; a podobne?
-
P2010 (neregistrovaný)
Ano, CORBA, IDL, DCOM ... masakr.
Kazdy problem lze ale zjednodusovat jen do urcite urovne.
Treba zminene SOAP webove sluzby. Kompletni W3C specifikace je hruza a je v ni plno zbytecnosti jako RPC/Document model atd. Proto vznikl WS-I Basic Profile, ktery vybral podmnozinu rozumnych vlastnosti, na ktere se shodli vsichni. Takze podpora SOAP sluzeb casto neznamena celou specifikaci, ale prave tuto rozumnou podmnozinu, pritom je to stale v souladu s obecnou specifikaci.
Tohle je podle mne lepsi cesta, nez JSON ktery se hodi pro inetrni komunikaci ve webovych aplikacich, ale ne jako obecne API, ke kteremu se dnes zneuziva. Je prilis primitivni a nedospely, prave kvuli neexistenci metadat, ktera vede k jiz zminene implementaci stylem: tak dlouho matlame pokus/omyl, az to domatlame. Tolik zbytecne promarneneho casu ve srovnani s WSDL a jeste chaby vysledek.
-
Svět se točí v kruzích a stále se vymýšlí již vymyšlené a a ta cesta je dlouhá a konveguje k jednoduchosti. Začínal jsem s CORBA komunikací (IDL + C-cko a další low level bindingy). Dodnes se z té složitosti budím opocený hrůzou. - tisíce stran specifikací
Pak přisly krásně jednoduché textové dobře laditelné XML/XSD/WSDL webové služby začaly se obalovat složitostí WS-* (Policy, Security, Routing, ..). - stovky stran specifikací
Dnes roste obliba REST/JSON. A opět se nabaluje JSON Schema, JSON Web Signature, SWAGER. Ale celé je to o řády jednoduušší než předchůdce. - desítky stran specifikací.
Tu poslední inkarnaci už s rozumným úsilím dokážete naimplementovat z ruky od základu, pokud už to někdo neudělal za vás.
Se složitostí systému roste problematičnost jeho údržby, pochopení a správného užití. Proto budoucnost má JSON protože je jednoduchý, snadno kompatibilní.
A co se ladění rozhraní metodou pokus omyl - to není až tak vada technologie jako jejího užití, dokumentace, kázně.
-
P2010 (neregistrovaný)
K tomu, že jsou potřeba JSON schémata, už se dospělo, následovat budou předpokládám jmenné prostory, pak JPath a transformace.
... az nakonec znovu vynaleznou XML a razem bude JSON "slozity" a nahrazen CSV/TXT soubory.
Nestava se to tu casto, ale tentokrat s Vasi odpovedi plne souhlasim :-)
-
REST/JSON sice zvládne každý, ale tak, že tak dlouho upravuje příklady, až to referenční implementace protistrany přijme – a pak už se jen v příkladech vyměňují data kus za kus. Taková implementace pak samozřejmě nepřežije různé netypické situace, a obvykle ani změnu formátování dat (aniž by došlo ke změně specifikace).
SOAP/XML pro tohle má dávno definované a ověřené standardy. Není důvod používat pro to JSON jenom proto, že je módní. Zvlášť když cílem JSONu je evidentně znovu vynalézt to, co se vytvořilo v XML, akorát místo špičatých závorek se použijí kudrnaté. K tomu, že jsou potřeba JSON schémata, už se dospělo, následovat budou předpokládám jmenné prostory, pak JPath a transformace.
-
P2010 (neregistrovaný)
Zverejneni ukazkovych implementaci pro vetsinu beznych vyvojovych nastroju, vcetne celeho procesu opakovani transakce pri chybe komunikace bych povazoval za povinnost. To je samozrejme.
Dalsi vec o ktere se nemluvi je archivace komunikace (na jake ovsem urovni ?) pro pripad sporu s uradem. Platce DPH lze kontrolovat az 10 let zpetne, takze to bude pekny balik dat.
-
Z toho zadani je videt, ze je to pro komercniho bouchace kodu v klasickem middleware (na 99% nad Javou). Za tim se to vsecko veze, neumim posoudit konkretni vhodnost te ci one technologie ci standardu, na to vidim jen male kousky cele skladacky. Kazdopadne REST/JSON zvladne dnes temer kazdy, WSS uz zacina jit do API z vyssi divci a chce to pak rozhodne nenulovou praxi.
S kvalitami koderu v PHP mam take rozporuplne zkusenosti, ale abych byl neutralni: doufejme, ze ministerstvo zverejni i ukazkoveho klienta, protoze by bylo neproduktivni, aby se s tim kazdy potil uplne od nuly.
-
P2010 (neregistrovaný)
Duvod, ze jsou narozdil od JSON a temer nepouzivaneho WADL pouzitelne ? Nevim co s tim ma spolecneho OSS, tam snad neumi implementovat obecne a zcela otevrene standardy jako WS-Security ?
Spis mam pocit, ze se zde narazi na limity znalosti a schopnosti. Ono treba parsovat XML regexem v PHP jako text po radcich ma jiste limity :-)
-
P2010 (neregistrovaný)
Proč nejdeme do ulic proti EET?
To uz je v CR takova tradice, kdyz po 40 letech komunismu to zase ridi stbak. V Brazilii zvysili ceny za MHD o 10% a byl z toho malem prevrat. Ale je to samozrejme asi jedine mozne (zakonne) reseni, podobne jako kdysi nedavno pripomenuta akce Internet proti monopolu.
Otazka je kdo pujde demonstrovat ? Znacna cast zdejsi populace se tesi, jak to "tem podnikatelum/zivnostnikum co se topi v penezich" konecne natrou. Ze budou mezi temi co diky tomu prijdou treba nakonec o praci, to jim dojde az pozdeji.
Dneska se demonstruje jen vykonavanim sql prikazu UPDATE FacebookPages SET Like = Like + 1 WHERE PageID = dalsi zbytecna stranka :-)
-
P2010 (neregistrovaný)
Ano, coz je presne WS-Security. Proc zase vymyslet znova neco co uz je davno vymyslene, standardni, overene, a hlavne v praxi pouzivane.
Takovou cestou slo jedno ministerstvo, to vyzaduje take podani nejakych hlaseni (zemedelstvi) elektronicky a vytvorilo za tim ucelem jakysi proprietalni paskvil, ktery vzdalene pripominal WS-Security.
-
P2010 (neregistrovaný)
Ale tohle neni jednoduche pouziti. Za kazdou ztracenou transakci hrozi pokuta 500 000 Kc, takze radne zabezpeceni je na miste. Zde budou zajimave zaruky dodavatele na ten software, zvlaste na shitiodnich zarizenich typu Android, kde se nic zarucit neda.
Je to i dobry filtr kvality dodavatele, pokud nekdo nezvladne implementovat takto jasne popsany a leta pouzivany standard, mel by jit delat neco jineho.
Daleko horsi je ovsem v clanku zmineny zcela nedomysleny princip opakovani zasilani transakce pri vypadku, kde opet hrozi ona pokuta.
-
P2010 (neregistrovaný)
Souhlasim, JSON by byl navrat o 10 let zpet, protoze REST nema (zadny standardni) popis metadat kontraktu podobny WSDL. V kazdem rozumnem vyvojovem prostredi automaticky vygenerujete z WSDL typovy klientsky kod. Zadne zkouseni stringu pokus/omyl jako v REST/JSON, ktery je obliben hlavne u programatoru kteri maji problem pochopit i XML a jeho schema. Takze vyber WS-Security je prekvapive dobry.
Implementace muze byt komplikovana z jineho duvodu (viz dale), ktery ovsem autor clanku neobjevil :-) Vlastni WS-Security standard v .NETu i Jave by nemel byt problem, SHA-256 implementace je take v poradku (zatim jsem v .NET nemel problem, jde pripadne nahradit vlastnim).
Zrada bude jinde. WS-Security neresi jen zabezpeceni requestu, ale i response. A ta je podepsana jakym certifikatem ? Modri uz vedi :-)
-
Ano, celé by to daleko jednodušeji fungovalo bez certifikátů.
Moje zkušenost z praxe využívání XML Signature mě vede k názoru, že tento velmi komplikovaný standard s mnoha stupni volnosti se málokdy daří na všech komunikujících stranách implementovat bez zádrhelů zejména ve chvíli, kdy se mezi sebou integrují různé implementace (Java vs. .NET) a komunikační protokol specifikují lidé s povrchní znalostí standardu.
Komplexnost standardu není ve většině případů vyvážena přínosem pro typická jednoduchá použití.
SOAP/WS-Security/XML Signatura není obvyklou součástí SW vybavení na mobilních zařízení o embedded platformách nemluvě.
-
Samotné EET a výběrové řízení ponechám bez komentáře.
Osobně si myslím, že technologicky by to šlo celé udělat bez certifikátů, mnohem jednodušeji (implementace) a levněji (nároky na HW).
Nicméně, když už to má být postavené na certifikátech a podpisu, je nesmysl na to používat JSON Web Signature. Nový, nedokončený standard, s malým počtem, praxí neověřených implementací.
XML Signature sice není nic jednoduchého, ale ve většině běžně používaných jazyků jsou na to hotové knihovny. Kde nejsou, jde vždy podepsat externě pomocí xmlsec.