Closed Vitexus closed 3 years ago
Dobrý den,
Váš požadavek byl zaevidován a předán k řešení. O dalším průběhu Vás bude informovat odpovědný servisní technik.
S pozdravem
Milan Spisar 1st level support - Team Leader
Dobrý den,
v čase zpracování vaší transakce jsem našel v logu chybu, kterou nedokážu v tuto chvíli objasnit. Zkonzultuji s kolegou a poté napíšu výsledek.
S pozdravem,
Daniel Komárek IT application specialist
Dobrý den pane Komárku. Ano, to uznávám že jsem tam dělal strašný věci. Nicméně jsem se snažil nevymýšlet kolo, takže jsem použil knihovnu https://github.com/ondrakoupil/csob a zkoušel jí různě krmit aby vyplodila korektní požadavek na zahájení platby. Stalo se tam uplně všechno co mohlo. Použitím expirovaných klíčů počínaje a opakovanými odmítnutými requesty končě. Vývojový proces jsme navíc s kolegou @SimonFormanek pojali spíše jako párty a tak jsme při tom všem nebyli ani trošičku střízliví. I to mohlo zapříčinit použití testovací platební brány jiným způsobem než bylo předpokládáno jejími tvůrci.
Dobrý den,
dostal jsem vyjádření od kolegy z vývojového oddělení k mnou nalezené chybě:
v payment/init byl parametr returnUrl poslany jako objekt, musi to byt string ... aplikace pouziva knihovnu na parsovani vstupu, proto to vrati 500 error, protoze se nepodari vyparsovat ten vstup ...
Tedy jak to chápu já, tak aplikace si neporadila s parsováním dat, protože jste to tam poslal v rámci své "párty" jako objekt. Na to opravdu nejsme připraveni :-)
S pozdravem,
Daniel Komárek IT application specialist
Děkuji za ujasnění a ticket uzavírám.
@Vitexus Diky za barvity scenar k reprodukci chyby, vetsinou tak detailni kontext ke zopakovani nemame k dispozici… (:) Chapu nicmene ze nejde o dany problem formatu, je od zacatku jasne ze to jste spravne identifikovali — ale ze otazka zni proc neni vysledna chybova hlaska napomocnejsi, a presne neidentifikuje ktery parametr nema spravny format, jak sama API spec responsu rika. Ano, mel bych uplne stejnou otazku.
Aktualne jsou ruzne "severity" vstupnich validaci, ktere bud konci konkretni odpovedi, a nebo rekneme z bezpecnostnich duvodu prilis neukazuji na duvod, proc se brane pozadavek nelibi, a vrati se ruzne genericke 900-stovky. Tenhle pripad taky ale vidim na 400 Bad Request jako vysity, takze si to beru jako feedback dal, mame podobne meta-tema (pro vylozene explicitne prazdne a nullish hodnoty), a pridam tam tento case jako jednu z ukazek, kdy by mozna byla potreba vyvojare lepe informovat.
Neslibim zda se s tim v soucasne v1.x epose eAPI neco stane, protoze takovyto objekt vstupuje do algoritmu podpisu, a chyba vychazi primarne z nemoznosti "rozbalit" tu obalku zpravy pro porovnani s podpisem, ale davam dal jako podnet ke zlepseni zaclenenim do podobne skupinky spatnych typu k nullish/falsy hodnotam, kde je podobna situace s nemoznosti overovani podpisu, a uvidime.
Diky za report! ^H.
Dobrý den,
Už se to tu sice řešilo např. v rámci #550 ale jistě nejsem sám komu to na chvíi zamotalo hlavu.
Protože jsem omylem poslal prázdnou návratovou hodnotu
platební brána hlásí chybu 900 s error kódem 500
Pro mne jako vývojáře by bylo méně matoucí pokud by jste poslali kód 400 a pak resultCode 110 aby bylo jasné kde problém vzniká.
Nebo je záměna typu parametru už takový problém aby se mnou API uplně odmítlo bavit ?
Celý požadavek:
Ve wiki k tomu není nic bližšího uvedeno.
Děkuji za vaší reakci