Neplatny podpis v chybovej odpovedi s 200/OK responsem

[rootpd]

V pripade, ze oneclick/init volanie nevrati nainicializovanu platbu s payId, vyzera odpoved napr. takto:

{
    "resultCode": 700,
    "resultMessage": "Oneclick template not found",
    "paymentStatus": 0,
    "dttm": "20221104083936",
    "signature": "**REDACTED**"
}

Toto je v rozpore s https://github.com/csob/paymentgateway/wiki/Methods-for-OneClick-Payment#return-values--1, kde dokumentacia oznacuje ako povinne polia v odpovedi:

• payId (chyba)
• dttm
• resultCode
• resultMessage
• signature

Kvoli tomuto rozporu nie je mozne spravne overit podpis odpovede, pretoze nami generovany podpis je iny, ako podpis obdrzany z API.

Pri debugovani sme zistili, ze nas base podpisu je iny a lisi sa prave v pouziti payId:

• Nas kod ho berie ako povinny a zahrnie ho do text baseu:

  |20221104083936|700|Oneclick template not found|0
  

• Ked sme payId v odpovedi brali ako nepovinny parameter, system vygeneroval rovnaky podpis, aky prisiel zo serveru. Text base bol takyto:

  20221104083936|700|Oneclick template not found|0
  

Prvy krat sme problemy pri overovani podpisu zo servera zaznamenali 17.10. Z nasho pohladu momentalne potrebujeme dospecifikovat, ci je payId v odpovedi oneclick/init povinny alebo nie.

• Ak povinny je, ocakavali by sme ho aj v chybovych odpovediach volania.
• A ak povinny nie je, tak je potrebne upravit dokumentaciu aby nebol "boldom" a my si na zaklade toho upravime fieldy na generovanie text base pre podpisy.

Dakujem za pomoc.

[jgrmelova]

Dobrý den,

parametr PayID je sice uveden jako povinný, pokud se však při provolání API nepodaří transakci (s přiděleným PayID) vytvořit, není možné PayID vrátit. Pokud je parametr vyplněný, tak se pole doplní a oddělí oddělovačem |, pokud však vyplněný není vypouští se pole i oddělovač.

Správný řetězec k podpisu je tedy v tomto případě: 20221104083936|700|Oneclick template not found|0

Hezký den.

[janbrasna]

@rootpd Chybove odpovedi maji jiny vycet povinnych hodnot; u odpovedi bez podpisu (401, 403 aj., 500+) je to jasne viz wiki, u odpovedi za pritomnosti dttm+signature mrknu zda je to dostatecne zadokumentovane…

[rootpd]

Vdaka. V podstate mi chyba nieco "uchopitelne", podla coho by sme jednoznacne vedeli povedat, co sa ma pri 2XX chybovej odpovedi pouzit na vygenerovanie podpisu. Ta zmena API medzi verziami nie je zanedbatelna.

Pridavam rozdiely, ktore pozorujeme pri pouziti noveho API. Pri requeste sa snazime nainicalizovat platbu neexistujuceho (uz expirovaneho) oneclick templatu. Tento scenar nie je u nas uplne okrajovy.

Toto su odpovede (obe s HTTP statusom 200):

// 1.8

{
    "dttm": "20221128103103",
    "signature": "**REDACTED**",
    "payId": "foo",
    "resultCode": 180,
    "resultMessage": "orig payment not found",
    "paymentStatus": 6
}

// 1.9

{
    "resultCode": 700,
    "resultMessage": "Oneclick template not found",
    "paymentStatus": 0,
    "dttm": "20221128105931",
    "signature": "**REDACTED**"
}

Cize:

• Zmenil sa resultCode
• Zmenil sa paymentStatus
• Stratil sa payId z odpovede

Prebehol som este raz aj https://github.com/csob/paymentgateway/wiki/Request-Signing-and-Response-Signature-Validation aj https://github.com/csob/paymentgateway/wiki/Methods-for-OneClick-Payment a naozaj nevidim, ako sa pri kontrole podpisu k takemuto niecomu zachovat.

[janbrasna]

@rootpd Pokud to je casty scenar, tak si idealne volejte oneclick/echo pro overeni sablony nez budete platbu initovat (=vubec oneclick nabizet klientovi, a pripadne rovnou nabidnout ulozit cerstvou kartu), ta je pro to urcena.

Odpoved v1.8 obsahuje bug #562 kdy i pro neexistujici sablonu zaklada transakci kterou hned zamita (proto muze vratit payId a paymentStatus) — kvuli historickym integracim se uz v1.8 neopravovala bez odverzovani pro zabraneni polamani interfejsu, fixovane je to az od v1.9 aby to odpovidalo specifikaci i jinym opracim, a timpadem se takova transakce ani nezaklada a rovnou zamita. Proto payload odpovida chybovemu, kde povinna pole z odpovedi puvodni operace nehraji roli a jsou povinne pouze minimalni chybove hodnoty (resulty ap.).

Nicmene mi prijde ze i tak to chovani neni uplne spravne, jeste to necham overit. (Bud by se jako drive mela platba zalozit a hned zamitnout, timpadem mit svoje ID aj., a/nebo chybi specifikace co se vraci v pripade nezalozeni platby, na jakykoliv init, pro 200/OK a paymentStatus:0, kdy neexistuji identifikatory — ve specifikaci to nevidim…)