Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect signature verification in the response of unsuccessful oneclick/init call #46

Closed
rootpd opened this issue Nov 14, 2022 · 2 comments

Comments

@rootpd
Copy link
Contributor

rootpd commented Nov 14, 2022

We've encountered issue with the signature verification of failed oneclick/init responses. The failure was usually caused by expired oneclick templates, but that's irrelevant for now. (it might help you to verify the issue)

We've debugged the issue and found out, that the signature base used for signature generated by the library is different than the signature base used for signature generated by the CSOB backend. I've discussed this with CSOB, please check the linked issue and the example - csob/paymentgateway#648.

The code in Client.php seems valid and in the compliance with the documentation:
https://github.com/ondrakoupil/csob/blob/master/src/Client.php#L897

However based on the bank's developer response, the payId doesn't seem to be required parameter of the response if it wasn't a successful request.

That means that the library needs to adapt to the fact, that payId is only required for "OK" responses and not for the rest, and generate different signature base.

@rootpd rootpd changed the title Signature verification in the oneclick/init response Incorrect signature verification in the response of unsuccessful oneclick/init call Nov 14, 2022
@janbrasna
Copy link
Contributor

Honestly this should either pass as 200/OK with auto-declined payment with full metadata as in previous API versions; or fail as 400/Bad Request with only minimal error response as not being able to init such payment.

Bumping that internally, watch the linked @csob issue for any progress whether the behavior is indeed as intended (and just missing proper spec; but this is not how it was originally designed…), or a change in the response is in the cards anyway.

@ondrakoupil
Copy link
Owner

OK, for that case let's make payId an optional value in response. The Client->paymentOneClickInit method will throw anyway, but with relevant exception message.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants