View Issue Details

IDProjectCategoryView StatusLast Update
0006699Talermerchant backendpublic2021-09-02 16:23
ReporterFlorian Dold Assigned ToChristian Grothoff Resolution deadline
ImplementerReviewer 
Release signed byDeployed by 
VerifierCommunicator 
Data protection authority notification requiredNo  
CSIRT notification requiredNo  
Estimated effort (hours)Actual effort (hours)0 
Fast-trackNo
Work packagenone
PriorityhighSeveritymajorReproducibilityhave not tried
Status closedResolutionfixed 
Product Versiongit (master) 
Target Version0.8Fixed in Version0.8 
Summary0006699: merchant falsely claims that denomination isn't audited
DescriptionThis issue can be reliably reproduced with a wallet integration test. It occurs when the URL for the trusted exchange configured in the merchant configuration differs from the exchange base URL used by in the wallet (and thus sent in the /pay request).

The underlying issue is likely *not* the different base URL, but that the merchant requests the exchange's /keys information *during* the /pay request, as opposed to during startup.

The merchant gives the following response to the wallet's /pay request:

{
        "hint": "The denomination key used for payment is not audited by an auditor approved by the merchant.",
        "code": 2152,
        "h_denom_pub": "6B70V0DFPJ9ZTNZEQV6CYYBM4TZ0EFF744D731N5632QSHKV4WZ8K8Z4FYPQS6BNAX1YQENWDN0GPGHHP6DCPXHZEDAS1T4RFQG8QVG"
}

Note that the exchange_keys field is missing.

What's wrong here is that:
1. The error message claims that the *auditing* is the problem, when exchange trust is the problem
2. The merchant claims that the denomination is "bad", when it didn't even finish obtaining the keys from the exchange yet.
Steps To Reproduce$ taler-wallet-cli testing run-integrationtests merchant-exchange-confusion
TagsNo tags attached.

Required notifications

Address or linkRemarkAdded byNotifiedActions

Activities

Florian Dold

2021-01-14 01:00

manager   ~0017344

This *looks* like a weird corner case, but it means in practice that the merchant will respond with an HTTP 400 (i.e. a permanent error) each time it's seeing a new exchange (or the same exchange via a different base URL).

Christian Grothoff

2021-01-15 11:40

manager   ~0017352

4a5eb61..4bbb29f forces a re-download of /keys also if the auditor DK check fails. Alas, this does NOT fix the issue. But I don't understand the report yet.

Christian Grothoff

2021-01-15 12:58

manager   ~0017353

The real issue here is that the exchange /keys reply is bogus/fails, and the merchant blames the wallet (400) instead of the exchange (502). So we need to check the status code of /keys and generate the right http code.

Christian Grothoff

2021-01-16 13:25

manager   ~0017357

The _real_ real issue is that the merchant doesn't like the base URL being different due to the proxy, even though it explicitly trusts the master_pub.

Christian Grothoff

2021-01-16 17:38

manager   ~0017358

Fixed in 4bbb29f..2c5a245

Christian Grothoff

2021-09-02 16:23

manager   ~0018363

Fix committed to master branch.

Issue History

Date ModifiedUsernameFieldChange
2021-01-14 00:57Florian DoldNew Issue
2021-01-14 00:57Florian DoldStatusnew => assigned
2021-01-14 00:57Florian DoldAssigned To => Christian Grothoff
2021-01-14 01:00Florian DoldNote Added: 0017344
2021-01-15 11:40Christian GrothoffNote Added: 0017352
2021-01-15 12:58Christian GrothoffNote Added: 0017353
2021-01-16 13:25Christian GrothoffNote Added: 0017357
2021-01-16 17:38Christian GrothoffStatusassigned => informing
2021-01-16 17:38Christian GrothoffResolutionopen => fixed
2021-01-16 17:38Christian GrothoffFixed in Version => 0.9
2021-01-16 17:38Christian GrothoffNote Added: 0017358
2021-01-16 17:38Christian GrothoffProduct Version => git (master)
2021-01-16 17:38Christian GrothoffTarget Version => 0.9
2021-07-30 11:57Christian GrothoffFixed in Version0.9 => 0.8.1
2021-07-30 11:59Christian GrothoffTarget Version0.9 => 0.8.1
2021-07-30 12:02Christian GrothoffFixed in Version0.8.1 => 0.8
2021-07-30 12:02Christian GrothoffTarget Version0.8.1 => 0.8
2021-08-24 14:23Christian GrothoffStatusinforming => closed
2021-09-02 16:22Christian Grothoff
2021-09-02 16:23Christian GrothoffNote Added: 0018363
2025-03-22 13:09Christian GrothoffCategorymechant backend => merchant backend