View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010003 | Taler | exchange | public | 2025-05-22 00:36 | 2025-08-31 17:09 |
| Reporter | Florian Dold | Assigned To | Christian Grothoff | Resolution deadline | |
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | urgent | Severity | block | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Target Version | 1.0 stretch goals | Fixed in Version | 1.0 stretch goals | ||
| Summary | 0010003: exchange KYC auth does not work when non-normalized payto URI differs between withdrawal and KYC auth | ||||
| Description | There will be two entries in exchange.wire_targets with the same normalized payto URI, but only one will have the target_pub set properly when doing a KYC auth. | ||||
| Steps To Reproduce | * Withdraw into wallet using bank account X (with receiver name "Florian Dold") * Set up merchant instance, using bank account X * Do KYC auth transafer, but somehow the bank capitalizes the receiver-name to "FLORIAN DOLD" => Boom, KYC auth transfer never succeeds, merchant hangs forever in KYC auth required. | ||||
| Tags | No tags attached. | ||||
| Relevant SQL that leads to this problem: -- Find the access token and the current account public key. SELECT access_token ,target_pub ,payto_uri INTO my_wtrec FROM wire_targets WHERE h_normalized_payto=in_h_normalized_payto; | |
| Ok, so superficially here the problem is that the h_normalized_payto is in the above assumed to be UNIQUE, while it is not. So we either should make h_normalized_payto UNIQUE (with a constraint!) and handle on INSERT the case that we already have a wire target with a "similar" payto_uri (how? not insert again? update payto_uri?) __or__ we don't assume UNIQUEness and need to handle the case here. First feeling: make UNIQUE. | |
| It's more complicated, I think we need to split up the table... | |
| Fixed in c887cfd76734ea1896bbe844f81bd29962aab7f7 | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-05-22 00:36 | Florian Dold | New Issue | |
| 2025-05-22 00:36 | Florian Dold | Status | new => assigned |
| 2025-05-22 00:36 | Florian Dold | Assigned To | => Christian Grothoff |
| 2025-05-22 00:37 | Florian Dold | Note Added: 0024965 | |
| 2025-05-22 05:24 | Christian Grothoff | Note Added: 0024966 | |
| 2025-05-22 09:01 | Christian Grothoff | Note Added: 0024967 | |
| 2025-05-24 20:24 | Christian Grothoff | Status | assigned => informing |
| 2025-05-24 20:24 | Christian Grothoff | Resolution | open => fixed |
| 2025-05-24 20:24 | Christian Grothoff | Fixed in Version | => 1.0 stretch goals |
| 2025-05-24 20:24 | Christian Grothoff | Note Added: 0024978 | |
| 2025-08-31 17:09 | Christian Grothoff | Status | informing => closed |