View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006522 | Taler | specification | public | 2020-08-24 06:41 | 2021-08-24 14:23 |
| Reporter | Florian Dold | Assigned To | Florian Dold | 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 | 0006522: issues with taler://fulfillment-success URIs | ||||
| Description | We introduced the taler://fulfillment-success URIs as a hack for orders that don't have a meaningful http(s) fulfillment URL, such as the snack machine orders. However, there are two issues with it: 1. It is not i18n-friendly 2. The /orders/{order_id} page doesn't deal well with it (it will redirect the browser to the taler:// URI, which most browsers don't like) For scenarios like the snack machine, we have various options: (a) don't show any customized fulfillment URL message (b) include the fulfillment success message in the original contract terms, as an i18n-ized field. (c) return the i18n-ized message as part of both the /pay response and the order status, once the order is paid. The storefront would then set this message when doing POST /private/orders, but it would *not* be part of the order. | ||||
| Tags | No tags attached. | ||||
| I like (b). | |
| Agreed. However, we need to make it clear that with this approach, the fulfillment success message may not contain secret data. If it really turns out somebody needs it, we can implement (c) post-1.0, as it allows purchasing a secret without using a browser. | |
| I think putting secret data into the fulfillment-message was never exactly the idea, and I don't have a good use case for that right now. So indeed, IF there is a good use case, we can do it post 1.0. Let me know what fieldname you want to use in the contract, and I'll update taler-mdb. | |
| I'd suggest fulfillment_message (and of course fulfillment_message_i18n). | |
| Ok. | |
| Implemented in taler-mdb in 5e31cfb..e2dccbd | |
| Implemented in wallet-core and updated wallet docs as well. Android implementation separately tracked here: 0006528 | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-08-24 06:41 | Florian Dold | New Issue | |
| 2020-08-24 06:41 | Florian Dold | Status | new => assigned |
| 2020-08-24 06:41 | Florian Dold | Assigned To | => Christian Grothoff |
| 2020-08-24 07:29 | Christian Grothoff | Note Added: 0016729 | |
| 2020-08-24 07:51 | Florian Dold | Note Added: 0016730 | |
| 2020-08-24 10:49 | Christian Grothoff | Note Added: 0016732 | |
| 2020-08-24 10:51 | Florian Dold | Note Added: 0016733 | |
| 2020-08-24 11:04 | Christian Grothoff | Note Added: 0016734 | |
| 2020-08-24 12:22 | Christian Grothoff | Note Added: 0016741 | |
| 2020-08-24 12:30 | Christian Grothoff | Assigned To | Christian Grothoff => Florian Dold |
| 2020-08-24 14:51 | Florian Dold | Status | assigned => informing |
| 2020-08-24 14:51 | Florian Dold | Resolution | open => fixed |
| 2020-08-24 14:51 | Florian Dold | Note Added: 0016749 | |
| 2020-10-03 12:09 | Christian Grothoff | Fixed in Version | => 0.8 |
| 2020-10-03 12:10 | Christian Grothoff | Target Version | => 0.8 |
| 2021-08-24 14:23 | Christian Grothoff | Status | informing => closed |
| 2024-01-12 13:02 | Christian Grothoff | Category | merchant backend API (HTTP specification) => specification |