View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007656 | Taler | exchange | public | 2023-01-31 19:29 | 2024-01-12 14:05 |
| Reporter | sebasjm | Assigned To | sebasjm | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | git (master) | ||||
| Target Version | 0.9.2 | Fixed in Version | 0.9.2 | ||
| Summary | 0007656: exchange cant find logic when there business and individual defined | ||||
| Description | If a comment out every kyc-legitimization-bus* it works again. [kyc-provider-sauron02] COST = 1 LOGIC = oauth2 USER_TYPE = BUSINESS PROVIDED_CHECKS = sauron_business_withdraw <the rest of the oauth2 config for this provider> [kyc-provider-sauron07] COST = 1 LOGIC = oauth2 USER_TYPE = INDIVIDUAL PROVIDED_CHECKS = sauron_individual_withdraw <the rest of the oauth2 config for this provider> [kyc-legitimization-ind_withdraw] OPERATION_TYPE = WITHDRAW REQUIRED_CHECKS = sauron_individual_withdraw THRESHOLD = ARS:10 TIMEFRAME = 1h [kyc-legitimization-bus_withdraw] OPERATION_TYPE = WITHDRAW REQUIRED_CHECKS = sauron_business_withdraw THRESHOLD = ARS:10 TIMEFRAME = 1h <more legitimization and providers and stuff> curl 'https://exchange-kyc.taler.ar/kyc-check/1/NQXJ7FYSZ1FY021Y8JPRSM6QTG2JAW8ZKB1MHCKHJM1ZP8VZS1YG/individual' { "code": 1932, "hint": "The request requires a logic which is no longer configured at the exchange.", "detail": "sauron_individual_withdraw sauron_business_withdraw" } Something I notice here: https://git.taler.net/exchange.git/tree/src/kyclogic/kyclogic_api.c?id=d7382879539fef81a6870b7535f0ebeb08fb2a2f#n1000 It does not check for the user_type | ||||
| Tags | No tags attached. | ||||
|
|
Eh, please see src/kyclogic/kyclogic_api.c it clearly looks for USER_TYPE there. Also, there is the 'ut' argument for TALER_EXCHANGE_kyc_check(). Finally, note the: ekr->kyc = TALER_EXCHANGE_kyc_check ( eh, ekr->exchange_kyc_serial, &h_payto, /* FIXME: get from settings! */ TALER_KYCLOGIC_KYC_UT_BUSINESS, kc->timeout, &exchange_check_cb, ekr); in taler-merchant-httpd_private-get-instances-ID-kyc.c -- hard-coded to BUSINESS right now. So yes, it's an open issue to get this from the settings ... |
|
|
The error changed in this new version taler-exchange-httpd v0.9.1-git-d7382879 curl https://exchange-kyc.taler.ar/kyc-check/17/4N50F3HKQGH03YRD8P3V974KM5V2ES87BVNB36G9911Q5CGEF360/individual { "code": 1932, "hint": "The request requires a logic which is no longer configured at the exchange.", "detail": "sauron_business_withdraw" } querying for individual, tries to find business |
|
|
This is what the database has in the table legitimization_requirements "legitimization_requirement_serial_id" "h_payto" "required_checks" 1 "binary data" "sauron_individual_withdraw sauron_business_withdraw" 17 "binary data" "sauron_business_withdraw" Looks like both requirements are getting triggered but after completing kyc process just one of them are marked as solved |
|
|
In particular configurations, it is possible that a user may need to finish multiple KYC processes (idea: collecting different data!) before the action is unlocked. Could this be the case here? If you ask, are you now redirected to the 2nd KYC challenge? |
|
|
The http request that I pasted above has a return status code of 500 < HTTP/1.1 500 Internal Server Error < Server: nginx/1.18.0 (Ubuntu) < Date: Thu, 02 Feb 2023 17:09:56 GMT < Content-Type: application/json < Content-Length: 147 < Connection: keep-alive < Access-Control-Allow-Origin: * < Access-Control-Expose-Headers: * < { "code": 1932, "hint": "The request requires a logic which is no longer configured at the exchange.", "detail": "sauron_business_withdraw" } If query to the same kyc-check URL with business instead of individual the exchange give me the kyc url to complete the step. Like this curl https://exchange-kyc.taler.ar/kyc-check/17/4N50F3HKQGH03YRD8P3V974KM5V2ES87BVNB36G9911Q5CGEF360/business But I expected this kyc just to a) require kyc check for individual (not business) b) mark as completed both requirements when doing the first one I think a) is better but the exchange need to know in advance if the payto is business or individual, right? That what I was mentioning in my first comment, this function here > https://git.taler.net/exchange.git/tree/src/kyclogic/kyclogic_api.c?id=d7382879539fef81a6870b7535f0ebeb08fb2a2f#n1000 "TALER_KYCLOGIC_kyc_test_required" add all requirement without checking the user_type of the payto. Maybe all payto can be treated as individual by default (when doing kyc_test_required) with a "upgrade" procedure to mark the account as "business" (with higher threshold) |
|
|
or c) returns another 4xx code implying that kyc for this user_type is OK but the user should check another user_type. That will be enough information for the wallet to know it will be not able to withdraw before doing another kyc step. |
|
|
Oh, I think I see now what is going wrong. You're misunderstanding completely how you are supposed to configure the KYC checks. Let me rewrite your config for you: [kyc-provider-sauron02] COST = 1 LOGIC = oauth2 USER_TYPE = BUSINESS PROVIDED_CHECKS = fullname address phone [kyc-provider-sauron07] COST = 1 LOGIC = oauth2 USER_TYPE = INDIVIDUAL PROVIDED_CHECKS = fullname address [kyc-provider-sauron42] COST = 1 LOGIC = oauth2 USER_TYPE = INDIVIDUAL PROVIDED_CHECKS = phone [kyc-legitimization-ind_withdraw] OPERATION_TYPE = WITHDRAW REQUIRED_CHECKS = fullname THRESHOLD = ARS:10 TIMEFRAME = 1h [kyc-legitimization-bus_withdraw] OPERATION_TYPE = WITHDRAW REQUIRED_CHECKS = address phone THRESHOLD = ARS:100 TIMEFRAME = 1h Is that better? :-) |
|
|
ACK, this worked. So the 500 problem can be solved by adding a start up verification checking gathering all the required_check (in your config address, phone and fullname) and then check that for every one of them exists a kyc-provider that can be used. Am I getting this right? |
|
|
Well, you are right to say that in this case is the 500 is pointing to a *configuration error*. However, it cannot be solved as easily as you say by a start-up check, as we do want to ALLOW some checks to not be defined! That's an open feature for me, which is "hard thresholds": by setting a rule that cannot be satisfied, we can categorically prohibit certain amounts! Plus, even without that it's not this easy, as we may prohibit for individuals but not for businesses. So in the end, yes, we MAY want to change this from a 500 to a special type of 451 unsatisfiable. But as I said, this part is still work-in-progress ;-). |
|
|
good enough for me |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2023-01-31 19:29 | sebasjm | New Issue | |
| 2023-01-31 19:29 | sebasjm | Status | new => assigned |
| 2023-01-31 19:29 | sebasjm | Assigned To | => Christian Grothoff |
| 2023-01-31 20:25 | Christian Grothoff | Note Added: 0019725 | |
| 2023-02-01 13:15 | Christian Grothoff | Assigned To | Christian Grothoff => sebasjm |
| 2023-02-01 13:15 | Christian Grothoff | Status | assigned => feedback |
| 2023-02-02 16:54 | sebasjm | Note Added: 0019735 | |
| 2023-02-02 17:18 | sebasjm | Note Added: 0019736 | |
| 2023-02-02 17:22 | Christian Grothoff | Note Added: 0019737 | |
| 2023-02-02 18:18 | sebasjm | Note Added: 0019738 | |
| 2023-02-02 18:19 | sebasjm | Assigned To | sebasjm => Christian Grothoff |
| 2023-02-02 19:18 | sebasjm | Note Added: 0019739 | |
| 2023-02-02 19:18 | sebasjm | Status | feedback => assigned |
| 2023-02-03 10:48 | Christian Grothoff | Note Added: 0019740 | |
| 2023-02-03 10:49 | Christian Grothoff | Assigned To | Christian Grothoff => sebasjm |
| 2023-02-03 10:49 | Christian Grothoff | Status | assigned => feedback |
| 2023-02-03 14:16 | sebasjm | Note Added: 0019742 | |
| 2023-02-03 14:23 | Christian Grothoff | Note Added: 0019743 | |
| 2023-02-03 14:43 | sebasjm | Status | feedback => resolved |
| 2023-02-03 14:43 | sebasjm | Resolution | open => fixed |
| 2023-02-03 14:43 | sebasjm | Note Added: 0019744 | |
| 2023-02-21 16:39 | Christian Grothoff | Fixed in Version | => 0.9.2 |
| 2023-02-21 16:39 | Christian Grothoff | Status | resolved => closed |
| 2024-01-12 14:05 | Christian Grothoff | Category | exchange API (C) => exchange |
