View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009174 | Taler | exchange | public | 2024-09-05 21:20 | 2024-09-17 16:29 |
| Reporter | Florian Dold | Assigned To | Christian Grothoff | ||
| Priority | high | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Target Version | 0.14 | Fixed in Version | 0.14 | ||
| Summary | 0009174: operation_type=deposit rule gets triggered, but subsequent kyc-check returns 200 | ||||
| Description | $ taler-harness run-integrationtests kyc-deposit-deposit The /batch-deposit returns 451, as expected. However, the subsequent request to /kyc-check returns 200, wrongly indicating that no mandatory KYC is necessary. | ||||
| Additional Information | The following rules etc. are configured: [KYC-RULE-R1] OPERATION_TYPE = deposit ENABLED = yes EXPOSED = yes IS_AND_COMBINATOR = yes THRESHOLD = TESTKUDOS:5 TIMEFRAME = 1d NEXT_MEASURES = M1 [KYC-MEASURE-M1] CHECK_NAME = C1 CONTEXT = {} PROGRAM = P1 [AML-PROGRAM-P1] COMMAND = /bin/true ENABLED = true DESCRIPTION = this does nothing FALLBACK = M1 [KYC-CHECK-C1] TYPE = INFO DESCRIPTION = my check! FALLBACK = M1 | ||||
| Tags | No tags attached. | ||||
| child of | 0008977 | resolved | Florian Dold | check debit/credit restriction configured in exchange is being used in wallet-core [4hs] |
|
|
Eh, the KYC measure is not enabled because the merchant_pub from the batch-deposit is not associated with the account (and thus we don't know if this deposit actually was made by the account owner!) --- and you have a zero_limit for deposits. So here you MUST first do the KYC auth transfer with the merchant_pub, and only then we will even fully consider applying KYC rules for your account. Otherwise, I could just do a (batch) deposit into your bank account over a billion dollars to trigger some KYC logic on your account and have the deposit fail -- so I'd be scotch free (costs me nothing) and you have exceeded deposit limits. So we only even process KYC requirements *after* KYC auth transfers for the respective merchant_pub have been done. |
|
|
Oh, I somehow did not realize that they have to match in the context of wallet deposits. But I would expect a completely different response on that case -- some 4xx, definitely not a 200 response. Otherwise, completely impossible to diagnose. |
|
|
Eh, you do get: bad_kyc_auth: true (in the original deposit), that's your diagnostic here. As we don't commit anything to the DB, kyc-check cannot really say anything but 200. |
|
|
Ah, but bad_kyc_auth is not documented anywhere:-( I still don't like that the kyc-check returns 200, when clearly the request doesn't make sense in the first place. Clearly a conflict or bad request IMO. |
|
|
But the kyc-check request *makes* sense. It gives the client its access token, right? Especially with voluntary KYC, that's a totally normal thing to request. |
|
|
Okay, I now think that this indeed makes sense. However, there are still two problems: * when I use the reserve_pub from a withdrawal as the merchant_pub and account_pub for a deposit (to the same account!), the exchange still claims bad_kyc_auth: true * when I then want to do a KYC auth, the long-poller (like http://localhost:8081/kyc-check/M31RX584ZKVDCJR7VE03YTQSSA4FZARPP8V4Y60ES2FXSKRN67Y0?await_auth=YES&timeout_ms=30000), it immediately returns with status 200, but the subsequent /deposit still returns 451 with bad_kyc_auth: true So the original issue is still kinda there: The exchange returns 200 even though it should not. |
|
|
await_auth is now gone, you need to do lpt=1, see https://docs.taler.net/core/api-exchange.html#get--kyc-check-$H_PAYTO |
|
|
Oh, and do you have a reproducer? |
|
|
Ran it, one of the streams shows first a 451 for batch deposit, where bad_kyc_auth is true *but* requirement row is 0 (!). A subsequent request to /kyc-check indeed returns 200 OK and *no limits* (!). |
|
|
All 3 legitimization_*-tables are empty at this point. |
|
|
KYC default rules are: trigger on deposit of 5 TESTKUDOS (the actual deposit is 10 TESTKUDOS), for a measure M1 with KYC check of type "INFO" that falls back to itself and an AML program of /bin/true. |
|
|
Relevant exchange logs: 2024-09-11T09:44:50.044107+0200 taler-exchange-httpd-8941(QF601508CWPDKGHR5605HPY0NG) INFO Handling request (POST) for URL '/batch-deposit' 2024-09-11T09:44:50.044121+0200 taler-exchange-httpd-8941(QF601508CWPDKGHR5605HPY0NG) INFO Handling request (POST) for URL '/batch-deposit' 2024-09-11T09:44:50.044898+0200 taler-exchange-httpd-8941(QF601508CWPDKGHR5605HPY0NG) INFO KYC: merchant_pub given but no target_pub known! 2024-09-11T09:44:50.044925+0200 taler-exchange-httpd-8941(QF601508CWPDKGHR5605HPY0NG) INFO Testing 1 KYC rules for trigger 2 2024-09-11T09:44:50.044937+0200 taler-exchange-httpd-8941(QF601508CWPDKGHR5605HPY0NG) INFO Matched rule 0 with timeframe 1 day 2024-09-11T09:44:50.044953+0200 taler-exchange-httpd-8941(QF601508CWPDKGHR5605HPY0NG) INFO KYC: Checking amounts until Tue Sep 10 09:44:50 2024 2024-09-11T09:44:50.044966+0200 taler-exchange-httpd-8941(QF601508CWPDKGHR5605HPY0NG) INFO KYC: Mismatch between merchant_pub and target_pub is relevant! 2024-09-11T09:44:50.044980+0200 taler-exchange-httpd-8941(QF601508CWPDKGHR5605HPY0NG) INFO Signaling amount TESTKUDOS:9.8 for KYC check during deposit 2024-09-11T09:44:50.044998+0200 taler-exchange-httpd-8941(QF601508CWPDKGHR5605HPY0NG) INFO KYC checking transaction amount TESTKUDOS:9.8 from Wed Sep 11 09:44:50 2024 against 1 rules 2024-09-11T09:44:50.045012+0200 taler-exchange-httpd-8941(QF601508CWPDKGHR5605HPY0NG) INFO Remembering rule R1 as triggered 2024-09-11T09:44:50.045825+0200 taler-exchange-httpd-8941(QF601508CWPDKGHR5605HPY0NG) INFO Got 0 additional transactions for this deposit and limit 1725954290044947 2024-09-11T09:44:50.045854+0200 taler-exchange-httpd-8941(QF601508CWPDKGHR5605HPY0NG) INFO Triggered rule is R1 2024-09-11T09:44:50.045891+0200 taler-exchange-httpd-8941(QF601508CWPDKGHR5605HPY0NG) INFO Handling request (POST) for URL '/batch-deposit' 2024-09-11T09:44:50.045923+0200 taler-exchange-httpd-8941(QF601508CWPDKGHR5605HPY0NG) INFO Do deposit 0 = BFP5W6DP 2024-09-11T09:44:50.046264+0200 taler-exchange-httpd-8941(QF601508CWPDKGHR5605HPY0NG) INFO Request for `/batch-deposit' completed with HTTP status 451 (0) |
|
|
Consider: INFO KYC: Mismatch between merchant_pub and target_pub is relevant! (what does this mean again?). Also, if it says "Remembering rule R1 as triggered", should we not find something in the database? Was there a rollback? Why is the requirement_row 0? |
|
|
reserve_pub is now correctly checked and /kyc-check returns 202. But test still fails. Bouncing back to Florian... |
|
|
The exchange still claims bad_kyc_auth, even though the key used for the deposit and for the kyc auth signature is the same that has been used for the withdrawal reserve. |
|
|
Latest code fixes the bad_kyc_auth, but test *still* fails :-). |
|
|
It passes after a fix in wallet-core and the test :-) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-09-05 21:20 | Florian Dold | New Issue | |
| 2024-09-05 21:20 | Florian Dold | Status | new => assigned |
| 2024-09-05 21:20 | Florian Dold | Assigned To | => Christian Grothoff |
| 2024-09-05 21:40 | Christian Grothoff | Note Added: 0023192 | |
| 2024-09-05 21:40 | Christian Grothoff | Assigned To | Christian Grothoff => Florian Dold |
| 2024-09-05 21:40 | Christian Grothoff | Status | assigned => feedback |
| 2024-09-05 22:03 | Florian Dold | Note Added: 0023194 | |
| 2024-09-05 22:03 | Florian Dold | Assigned To | Florian Dold => Christian Grothoff |
| 2024-09-05 22:07 | Christian Grothoff | Note Added: 0023195 | |
| 2024-09-05 22:08 | Christian Grothoff | Note Edited: 0023195 | |
| 2024-09-05 22:15 | Florian Dold | Note Added: 0023196 | |
| 2024-09-05 22:15 | Florian Dold | Status | feedback => assigned |
| 2024-09-06 00:47 | Christian Grothoff | Note Added: 0023197 | |
| 2024-09-06 15:47 | Christian Grothoff | Assigned To | Christian Grothoff => Florian Dold |
| 2024-09-06 15:47 | Christian Grothoff | Status | assigned => feedback |
| 2024-09-09 11:25 | Florian Dold | Note Added: 0023213 | |
| 2024-09-09 11:27 | Florian Dold | Assigned To | Florian Dold => Christian Grothoff |
| 2024-09-09 11:27 | Florian Dold | Status | feedback => assigned |
| 2024-09-09 11:31 | Florian Dold | Relationship added | child of 0008977 |
| 2024-09-10 16:31 | Christian Grothoff | Note Added: 0023229 | |
| 2024-09-10 16:45 | Christian Grothoff | Note Added: 0023230 | |
| 2024-09-10 16:45 | Christian Grothoff | Assigned To | Christian Grothoff => Florian Dold |
| 2024-09-10 16:45 | Christian Grothoff | Status | assigned => feedback |
| 2024-09-11 09:52 | Christian Grothoff | Note Added: 0023234 | |
| 2024-09-11 09:53 | Christian Grothoff | Assigned To | Florian Dold => Christian Grothoff |
| 2024-09-11 09:53 | Christian Grothoff | Status | feedback => assigned |
| 2024-09-11 09:53 | Christian Grothoff | Note Added: 0023235 | |
| 2024-09-11 09:56 | Christian Grothoff | Note Added: 0023236 | |
| 2024-09-11 09:58 | Christian Grothoff | Note Added: 0023237 | |
| 2024-09-11 09:59 | Christian Grothoff | Note Added: 0023238 | |
| 2024-09-11 20:15 | Christian Grothoff | Assigned To | Christian Grothoff => Florian Dold |
| 2024-09-11 20:15 | Christian Grothoff | Note Added: 0023253 | |
| 2024-09-11 21:47 | Florian Dold | Note Added: 0023255 | |
| 2024-09-11 21:47 | Florian Dold | Assigned To | Florian Dold => Christian Grothoff |
| 2024-09-11 22:58 | Christian Grothoff | Assigned To | Christian Grothoff => Florian Dold |
| 2024-09-11 22:58 | Christian Grothoff | Note Added: 0023257 | |
| 2024-09-12 02:31 | Florian Dold | Assigned To | Florian Dold => Christian Grothoff |
| 2024-09-12 02:31 | Florian Dold | Status | assigned => resolved |
| 2024-09-12 02:31 | Florian Dold | Resolution | open => fixed |
| 2024-09-12 02:31 | Florian Dold | Note Added: 0023259 | |
| 2024-09-14 01:08 | Christian Grothoff | Fixed in Version | => 0.14 |
| 2024-09-17 16:29 | Christian Grothoff | Status | resolved => closed |
