View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010811 | Taler | exchange | public | 2025-12-19 01:37 | 2026-03-20 23:55 |
| Reporter | vecirex | 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 | major | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | 1.3 | ||||
| Target Version | 1.5 | Fixed in Version | 1.5 | ||
| Summary | 0010811: Test case: try to not use an IBAN anymore, deleting a bank account or the whole instance; can IBAN be reclaimed? [20min] | ||||
| Description | It's not tested in recent merchant versions (we will test v1.2.6+) if an IBAN can be reclaimed (as in: if an IBAN can be added to be KYCed again) by either deleting the bank account only or even deleting the instance. As on talver.hacktivism.ch (TOPS/CHF testing) there are enough KYCed IBANs, both test cases can easily be covered. | ||||
| Steps To Reproduce | 1. Login to a merchant instance which has a KYCed IBAN. Delete the IBAN under the bank account menu entry; try to readd it. 2. Login again. Say to delete the instance; try now to add the IBAN again. (3. Dito. Say this time to purge the instance; dito.) As what concerns 2. vs. 3.: 3. is the more radical approach, because it effectively deletes all the instance's data. Going for 3. makes sense if even 2. doesn't work, let's not expect this! :) | ||||
| Tags | customer | ||||
| related to | 0010810 | closed | Florian Dold | Test case: use an IBAN twice (context: TOPS/CHF) |
| related to | 0010974 | closed | Florian Dold | test needed for behavior of multiple KYC auth transfers [2h] |
| related to | 0010703 | closed | Florian Dold | Test reusing same IBAN on new taler-merchant installation |
| related to | 0011069 | closed | Florian Dold | need test & fix for multiple instances with same IBAN and KYC [2h] |
| Assigning to myself, then assigning to Florian (cf. ticket 0010810 for similar approach). | |
| @CG: Please relate this ticket to the other test case, so that we can test & close this (together), if this is the same issue as trying to use the very same IBAN twice for two different instances. | |
| I need a reproducer first. | |
| $ taler-harness run-integrationtests merchant-kyc-auth-multi This currently fails due to an unexpected 204 No content response. Once that's fixed, the test should succeed though. | |
| After 780e0606b..9ab71001b the test *still* fails. To be investigated. | |
| The last response we see in the test is indeed a 204: GET /instances/minst1/private/kyc?timeout_ms=30000&lpt=1 HTTP/1.1 Accept: application/json Authorization: Bearer secret-token:NJ6EQYNR4AWDGKCAADDWM41PYKQBBR8K3ZQHJR9YHXT8GDA36KRG Host: localhost:8083 Connection: keep-alive HTTP/1.1 204 No Content Date: Thu, 26 Feb 2026 12:08:43 GMT Access-Control-Allow-Origin: * Access-Control-Expose-Headers: * Cache-Control: no-store ETag: 0000000000000000000000000000000000000000000000000000 | |
| The reason for the 204 is pretty clear from this sequence earlier: GET /instances/minst1/private/accounts HTTP/1.1 Accept: application/json Authorization: Bearer secret-token:NJ6EQYNR4AWDGKCAADDWM41PYKQBBR8K3ZQHJR9YHXT8GDA36KRG Host: localhost:8083 Connection: keep-alive HTTP/1.1 200 OK Date: Thu, 26 Feb 2026 12:08:43 GMT Access-Control-Allow-Origin: * Access-Control-Expose-Headers: * Cache-Control: no-store Content-Type: application/json Content-Length: 260 { "accounts": [ { "active": true, "payto_uri": "payto://x-taler-bank/localhost/minst1?receiver-name=minst1", "h_wire": "RQBZ243D9M70BW3T7Z1QV02HRQ3D5J8DV96XQEB85Z2YWSS4A0CZ8XDH875AG52D68XQR76KDGSCX7YPZ5WJPWRGSF887RWQHRJNMB0" } ] } DELETE /instances/minst1/private/accounts/RQBZ243D9M70BW3T7Z1QV02HRQ3D5J8DV96XQEB85Z2YWSS4A0CZ8XDH875AG52D68XQR76KDGSCX7YPZ5WJPWRGSF887RWQHRJNMB0 HTTP/1.1 Accept: application/json Authorization: Bearer secret-token:NJ6EQYNR4AWDGKCAADDWM41PYKQBBR8K3ZQHJR9YHXT8GDA36KRG Host: localhost:8083 Connection: keep-alive HTTP/1.1 204 No Content Date: Thu, 26 Feb 2026 12:08:43 GMT Access-Control-Allow-Origin: * Access-Control-Expose-Headers: * GET /instances/minst1/private/accounts HTTP/1.1 Accept: application/json Authorization: Bearer secret-token:NJ6EQYNR4AWDGKCAADDWM41PYKQBBR8K3ZQHJR9YHXT8GDA36KRG Host: localhost:8083 Connection: keep-alive HTTP/1.1 200 OK Date: Thu, 26 Feb 2026 12:08:43 GMT Access-Control-Allow-Origin: * Access-Control-Expose-Headers: * Cache-Control: no-store Content-Type: application/json Content-Length: 261 { "accounts": [ { "active": false, "payto_uri": "payto://x-taler-bank/localhost/minst1?receiver-name=minst1", "h_wire": "RQBZ243D9M70BW3T7Z1QV02HRQ3D5J8DV96XQEB85Z2YWSS4A0CZ8XDH875AG52D68XQR76KDGSCX7YPZ5WJPWRGSF887RWQHRJNMB0" } ] } Basically, the only account is DELETEd, leaving zero available accounts for that instance for any exchange. Hence 204 is the correct answer. | |
| Eh, the problem is actually something else: The test (1) adds (2) removes and then (3) re-adds the bank account. Thus it correctly expects a non-empty /kyc response after (3). However, the merchant: * Returns an *undocumented* 204 response for "POST /.../private/accounts" * Subsequently seems to *not* re-activate the bank account (still listed as "active: false") This looks wrong, since it means a merchant can trivially/accidentally break their merchant instance *forever* w.r.t. being able to use that particular bank account. | |
| Fixed in 477831b8..40fcdf6f. Test passes now. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-12-19 01:37 | vecirex | New Issue | |
| 2025-12-19 01:39 | vecirex | Steps to Reproduce Updated | |
| 2025-12-19 01:40 | vecirex | Assigned To | => vecirex |
| 2025-12-19 01:40 | vecirex | Status | new => assigned |
| 2025-12-19 01:40 | vecirex | Note Added: 0027119 | |
| 2025-12-19 01:41 | vecirex | Note Edited: 0027119 | |
| 2025-12-19 01:44 | vecirex | Summary | test case: try to not use an IBAN anymore, deleting a bank account or the whole instance; can IBAN be reclaimed? => Test case: try to not use an IBAN anymore, deleting a bank account or the whole instance; can IBAN be reclaimed? |
| 2026-01-26 06:34 | Christian Grothoff | Target Version | => post-1.0 |
| 2026-02-14 17:59 | Florian Dold | Summary | Test case: try to not use an IBAN anymore, deleting a bank account or the whole instance; can IBAN be reclaimed? => Test case: try to not use an IBAN anymore, deleting a bank account or the whole instance; can IBAN be reclaimed? [20min] |
| 2026-02-15 09:23 | vecirex | Assigned To | vecirex => Christian Grothoff |
| 2026-02-15 09:23 | vecirex | Note Added: 0027731 | |
| 2026-02-15 09:24 | vecirex | Note Edited: 0027731 | |
| 2026-02-16 22:23 | Christian Grothoff | Product Version | => 1.3 |
| 2026-02-16 22:23 | Christian Grothoff | Target Version | post-1.0 => 1.5 |
| 2026-02-16 22:34 | Christian Grothoff | Relationship added | parent of 0010810 |
| 2026-02-16 22:35 | Christian Grothoff | Note Added: 0027765 | |
| 2026-02-16 22:35 | Christian Grothoff | Tag Attached: vivy | |
| 2026-02-16 22:35 | Christian Grothoff | Priority | high => urgent |
| 2026-02-16 22:35 | Christian Grothoff | Status | assigned => implementing |
| 2026-02-16 22:53 | Christian Grothoff | Relationship added | related to 0010703 |
| 2026-02-17 20:32 | Christian Grothoff | Assigned To | Christian Grothoff => Florian Dold |
| 2026-02-17 20:32 | Christian Grothoff | Status | implementing => assigned |
| 2026-02-17 20:41 | Christian Grothoff | Tag Detached: vivy | |
| 2026-02-22 14:34 | Christian Grothoff | Relationship added | related to 0011069 |
| 2026-02-22 14:38 | Christian Grothoff | Relationship replaced | related to 0010810 |
| 2026-02-22 14:39 | Christian Grothoff | Relationship added | related to 0010974 |
| 2026-02-23 11:24 | Christian Grothoff | Tag Attached: customer | |
| 2026-02-23 19:49 | Florian Dold | Note Added: 0027871 | |
| 2026-02-25 17:50 | Florian Dold | Status | assigned => feedback |
| 2026-02-26 12:08 | Christian Grothoff | Note Added: 0027909 | |
| 2026-02-26 12:09 | Christian Grothoff | Note Added: 0027910 | |
| 2026-02-26 12:37 | Christian Grothoff | Note Added: 0027911 | |
| 2026-02-26 21:57 | Florian Dold | Note Added: 0027914 | |
| 2026-02-26 21:57 | Florian Dold | Assigned To | Florian Dold => Christian Grothoff |
| 2026-02-26 22:40 | Christian Grothoff | Note Added: 0027915 | |
| 2026-02-26 22:40 | Christian Grothoff | Status | feedback => informing |
| 2026-02-26 22:40 | Christian Grothoff | Resolution | open => fixed |
| 2026-02-26 22:40 | Christian Grothoff | Fixed in Version | => 1.5 |
| 2026-03-20 23:55 | Christian Grothoff | Status | informing => closed |