View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006450 | Taler | merchant backend | public | 2020-07-30 09:27 | 2024-01-12 13:04 |
| Reporter | Florian Dold | Assigned To | jonathanbuchanan | 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 | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Target Version | 0.8 | Fixed in Version | 0.8 | ||
| Summary | 0006450: merchant lib should parse taler_payto_uri, should be used in test cases | ||||
| Description | It looks like right now the taler_payto_uri is only used by the wallet, not by the merchant's own test cases. This makes it hard to tell if changes break anything. | ||||
| Tags | No tags attached. | ||||
| How should the merchant parse `taler_pay_uri`? Should I add a function that extracts all the parameters from the URI? | |
| I think this has two parts: (1) Implementing a function that parses a taler://pay URI into its components (same will also be needed for taler://refund) (2) Make the test cases use the taler://pay URI to execute the payment. TALER_TESTING_cmd_merchant_pay_order currently uses the order_id directly. Instead it should take the order_id (and the claim token and session id) from the taler://pay URI, just like the wallet does! (Right now the test cases would pass even if the merchant screws up the taler://pay URI generation.) | |
| I added a spec for these methods in b791a14..5560527. | |
| I'm working on implementing it and I noticed that there can be certain situations where there is no way to distinguish between order_id and session_id according to the spec in https://docs.taler.net/core/taler-uri.html Suppose there is no claim token or ssid. If there is a segment seperated by '/' from the last segment, then the last segment could be a session_id or an order_id with the segments preceding it being part of merchant_prefix_path. On a related note, what happens to 'c' and 'ssid' if there isn't a 'session_id'? It would make sense to omit the slash and append them to the order id. | |
| Let's look at the definition: taler://pay/{merchant_host}{/merchant_prefix_path*}/{order_id}/{session_id}{?c}{#ssid} Effectively, the session_id is always present. But it can be the empty string, and in that case the path component of the URI ends with a slash! To get the session ID and order ID, you need to count from the back, as the merchant_prefix_path can consist of an arbitrary number of path segments. The syntax follows the generic URI syntax: https://tools.ietf.org/html/rfc3986 (see Section 3. Syntax Components). You can get the claim token (c) from the query string, which is simply between the first "?" and the fragment delimiter "#". Same for the ssid, which is just the whole fragment (if present) Here's how the wallet does this parsing: https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-core/src/util/taleruri.ts#n138 | |
| Ok, thanks for explaining! | |
| Parser for pay URIs implemented in ef6fed1..119de8d (merchant.git). | |
| Should the claim token always be returned with the pay_uri, or only when it the order is unclaimed? It currently does the latter. On similar note, would it make sense to define a 'taler://claim' action and return that URI when the order is unclaimed? | |
| Parser for refund URIs implemented in 119de8d..280bbb5 (merchant.git). | |
| Just given the URI, I don't see how the URI-parser can tell if the order is claimed or not. You should return the claim token if it is given in the URI (given that it is optional). | |
| Parse/test refund URIs in 8d172853c1c7b1ca8d9dc31194c4e73e79499a80. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-07-30 09:27 | Florian Dold | New Issue | |
| 2020-07-30 09:27 | Florian Dold | Status | new => assigned |
| 2020-07-30 09:27 | Florian Dold | Assigned To | => jonathanbuchanan |
| 2020-08-04 20:04 | jonathanbuchanan | Note Added: 0016560 | |
| 2020-08-06 13:37 | Florian Dold | Note Added: 0016563 | |
| 2020-08-07 01:35 | jonathanbuchanan | Note Added: 0016569 | |
| 2020-08-08 07:58 | jonathanbuchanan | Note Added: 0016572 | |
| 2020-08-08 09:39 | Florian Dold | Note Added: 0016573 | |
| 2020-08-08 19:51 | jonathanbuchanan | Note Added: 0016574 | |
| 2020-08-10 03:36 | jonathanbuchanan | Note Added: 0016578 | |
| 2020-08-10 18:52 | jonathanbuchanan | Note Added: 0016585 | |
| 2020-08-10 20:18 | jonathanbuchanan | Note Added: 0016586 | |
| 2020-08-14 07:36 | Christian Grothoff | Note Added: 0016604 | |
| 2020-08-20 05:12 | jonathanbuchanan | Status | assigned => informing |
| 2020-08-20 05:12 | jonathanbuchanan | Resolution | open => fixed |
| 2020-08-20 05:12 | jonathanbuchanan | Note Added: 0016668 | |
| 2020-10-03 12:09 | Christian Grothoff | Fixed in Version | => 0.8 |
| 2021-08-24 14:23 | Christian Grothoff | Status | informing => closed |
| 2024-01-12 13:04 | Christian Grothoff | Category | merchant backend API (C) => mechant backend |
| 2025-03-22 13:09 | Christian Grothoff | Category | mechant backend => merchant backend |