paymentgateway
paymentgateway copied to clipboard
csob
Python - špatný podpis požadavku od verze 1.8
Zdravím,
pro komunikaci s API platební brány využíváme jazyk Python (3.6)
Máme vytvořené funkční napojení na API v 1.6. Nyní chceme přejít na API v 1.8, ale máme problémy s podpisem požadavku. Stále se nám vrací {"resultCode":900,"resultMessage":"Invalid signature for merchant A2518nct6P"}
Rozdíl oproti verzi 1.6 by měl být pouze v tom, že se používá hashovací funkce SHA256 namísto SHA1. V kódu jsme tak vyměnili pouze tento modul, ale stejně se nám stále vrací chyba viz výše. Ukázka podpisu v pythonu:
from Crypto.PublicKey import RSA
from Crypto.Signature import pkcs1_15
from Crypto.Hash import SHA256
to_digest = data k podpisu
to_digest = to_digest.encode("utf-8")
to_digest2 = SHA256.new()
to_digest2.update(to_digest)
recipient_key = RSA.import_key(open(key_file,"rb").read())
signature = pkcs1_15.new(recipient_key).sign(to_digest2)
signature = base64.b64encode(signature).decode("utf-8")
Nemáte někdo zkušenosti s rozchození podpisu s modulem SHA256 v jazyce python? Případně zdali vy na straně testovacího API rozhraní z mých požadavků(order number 104888961) nevidíte lépe v čem je problém. Děkuji.
Dobrý den,
v logu, bohužel, vidím pouze informaci "resultCode":900,"resultMessage":"Invalid signature for merchant A2518nct6P".
Váš dotaz jsem proto předala na vývojáře.
Hezký den.
Jana Grmelová
Dobrý den,
obdržela jsem informaci od kolegů z vývoje, že v současné chvíli nejsou příklady v Python podporovány.
Nicméně kolegové se na Vás požadavek dívali, bohužel, se jim však nepodařilo z jejich pohledu odhalit co přesně způsobuje problémy s podpisem požadavku. Bude potřebné aby jste se svým dotazem obrátili na někoho zkušenějšího v oblasti programování v Python.
Tento požadavek v současné chvíli ukončuji. Pokud by jste měl doplňující dotazy je možné požadavek znovu otevřít nebo vytvořit požadavek nový.
Hezký den.
-- Jana Grmelová
Dobrý den,
prosím o znovuotevření požadavku. Provedl jsem ještě ve svém kódu zpětnou verifikaci přes veřejný klíč a tato verifikace souhlasí. Tedy by teoreticky můj podpis měl být správný. Od vás se mi ale stále vrací {"resultCode":900,"resultMessage":"Invalid signature for merchant A2518nct6P"}.
Abych problém mohl dále řešit, tak prosím vaše vývojáře o informaci, který přesně algoritmus pro ověření podpisu používají. Algoritmus by měl být popsán v nějakém RFC standardu. Jedná se o protokol RSASSA-PKCS1-v1_5 popsaný zde? https://datatracker.ietf.org/doc/html/rfc8017#section-8.2 Děkuji. Petr Konvalinka
Dobrý den, brána od v1.8 používá rsa-sha256 (sha256WithRSAEncryption):
md2WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 2 } md5WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 4 } sha1WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 5 } sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 } sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 } sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 }
https://www.rfc-editor.org/rfc/rfc3447#appendix-A.2.3
Dobrý den, v RFC odkazujete na A.2.3 - RSASSA-PSS algoritmus, ale když se kouknu do nějaké dokumentace k javě a na ten algoritmu SHA256withRSA - https://javadoc.iaik.tugraz.at/iaik_jce/current/iaik/security/rsa/Sha256RSASignature.html Tak tam je popsané, že se používá právě ten algoritmus RSASSA-PKCS1-v1_5 jak jsem psal výše, nikoliv ten RSASSA-PSS (https://www.rfc-editor.org/rfc/rfc3447#section-8.1) Nicméně zkoušel jsem zaměnit v kódu ten algoritmus za RSASSA-PSS a stejně stále nefunkční. Asi si budu muset tedy zkusit ty stejné data spustit v PHP, zda mi to dá stejný podpis.
Dobrý den,
tak se mi konečně podařilo po porovnání dat z PHP přijít na problém. Nebylo to ve špatném podpisu, ale v nadbytečném parametru Description, který mi tam zůstal z verze 1.6. Škoda, že jste o smazání tohoto parametru nenapsali alespoň v update logu k verzi 1.8. Dále mi tedy přijde divné vracet z API chybu, že je špatný podpis, když podpis je správný, akorát je obsažen jiný parametr.
Nicméně stále mi úplně korektně nefunguje, nyní na platební bráně obdržím červený text:
**
Platba nemůže být provedena Omlouváme se za nepříjemnosti, ale v platebním požadavku obchodníka se objevila technická chyba. Vraťte se, prosím, na stránky obchodníka a zaplaťte jiným způsobem
**.
Zřejmě v logu vidíte důvod chyby, prosím tedy o prozkoumání. Jedná se stále o ID A2518nct6P Děkuji.
Dobrý den,
pokud podpis není ve správném tvaru, tj. neobsahuje všechny požadované parametry nebo naopak obsahuje parametry, které obsahovat nemá případně pokud nejsou parametry ve správném pořadí, tak je vyhodnocen jako nesprávný.
Co se týče Vašeho dotazu, tak v logu vidím následující:
Aug 1, 2022 @ 14:49:55.049 Invalid paymentProcess signature for merchant A2518nct6P Aug 1, 2022 @ 14:49:55.045 Received paymentProcess request A2518nct6P / 3464402acbe9@HH
--
2022-08-01 14:49:55,049 WARN c.m.m.s.CryptoServiceBase - (Invalid signature, returning false ... exceptions: MipsException: verify failed: > SignatureException: Signature encoding error > IOException: ObjectIdentifier mismatch: 1.3.14.3.2.26 2022-08-01 14:49:55,049 WARN c.m.m.p.PaymentProcessorImpl - Invalid paymentProcess signature for merchant A2518nct6P
Zkontrolujte si, prosím, zda podpis obsahuje všechny parametry a ve správném pořadí. (Podpis požadavku a ověření podpisu odpovědi)
V případě dotazů jsem Vám k dispozici.
Jana Grmelová
@konvalik Sice uz je to starsi verze (tj. update dale v historii), nicmene tato zmena s dopadem na podpis je v changelogu zminena: @csob/platebnibrana CHANGELOG.md#v18-102019 — mozna se podivejte i na dalsi zmeny mezi v1.6–v1.8, treba neco z toho se vaseho volani taky muze tykat. (Obecne je nejlepsi problemy s podpisy zacit zkouset od zakladniho volani operace echo, tzn. sestavit podpis a vzajemnou kryptografii na tom nejtrivialnejsim pozadavku+odpovedi… a az po jeho uspesnem testu pokracovat na dalsi endpointy.)
@jgrmelova Protoze ta zminena cervena chyba (err100) vypada, jako ze podpis na payment/init byl v poradku, a az na payment/process se nepodarilo overit…(?)
@janbrasna Děkuji za info, tohoto changelogu jsem si nevšiml. Díval jsem se pouze do Wiki na funkční změny na začátku návodu.
@jgrmelova Jak píše @janbrasna . Nyní už mám podpis správně (nevrací mi chybu) ale na platební bráně obdržím toto:
Dnes jsem to zkoušel znovu. Nevidíte k tomuto opravdu nic v logu? V požadavku tedy neposílám Dodatečná data o nákupu, ale ty myslím, nejsou povinné, že?
No, tak payment/process by byl jednoduchy, na tom se co mi pamet saha nic nemenilo, a parametry jsou taky jasne — tj. pokud neni problem v nich (opravdu doporucuji znovu zkontrolovat ze nemate nejake hardkodovane ID, neaktualni timestamp atp. ciste pro toto jedno volani s parametry primo v URL) tak vidim jedinou stopu: na rozdil od ostatnich POST+payload/JSON operaci toto byva jedine misto, kde se v integraci pouziva GET+query/params — tj. @konvalik zkuste si overit, ze napr. pote co pro vsechna ostatni POST/PUT volani jste tu zmenu v kryptografii provedli hromadne, tak jen tuto jednu specifickou GET metodu nesestavujete nejak vyjimecne jinak, a treba vam ciste pro ni zbyla jeste nejaka zastarala logika…
Otestovat sestavovani POST i GET pozadavku je mozne na echo operaci, ta podporuje jak JSON payload tak parametry v URL — muzete si upgrade SHA zkusit na ni.
@janbrasna díky objevil jsem chybku v logice process. Už se zdá, že je vše v pořádku. @jgrmelova Můžete tedy požadavek uzavřít.
Dobrý den,
děkuji za informaci. Požadavek ukončuji.
Hezký den.
Jana Grmelová