View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010806 | Taler | specification | public | 2025-12-18 17:47 | 2026-07-31 11:58 |
| Reporter | Christian Grothoff | 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 | normal | Severity | feature | Reproducibility | N/A |
| Status | informing | Resolution | fixed | ||
| Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
| Product Version | git (master) | ||||
| Target Version | 1.6 | Fixed in Version | 1.6 | ||
| Summary | 0010806: need support for session-bound payments using templates | ||||
| Description | Paivana and other paywalls cannot easily afford to create an order object *before* the customer scans the QR code. So we should make templates where the wallet supplies the session and the template then initializes the session ID in the order a feature of the merchant backend. | ||||
| Tags | No tags attached. | ||||
| For me the main question is: How will the browser get the cookie? There needs to be *some* request in the same origin that returns the cookie header. For paivana, the idea was to reverse-proxy to the protected content via paivana, thus paivana and the protected content are served on the same domain. Paivana can simply set the cookie header and also check it. Does this also work for other use cases, or is there something fundamentally different about the design? IMO we should also not reuse session_id, as that already has (quite involved) semantics, and overloading this term will cause confusion. | |
| aeaca65e..f5cd9e43 expands the merchant REST API spec with a new /sessions/ endpoint and updates DD76 accordingly. | |
| Implementation is basically done, needs testing! | |
| Rudimentary test is there, but see FIXME with "discuss with Florian" in GET /private/orders/$ID handler of the merchant. To be discussed with Florian. | |
| Not sure what's left to be done there, paivana templates seem to be implemented. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-12-18 17:47 | Christian Grothoff | New Issue | |
| 2025-12-18 17:47 | Christian Grothoff | Status | new => assigned |
| 2025-12-18 17:47 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2025-12-18 17:47 | Christian Grothoff | Category | merchant backend => specification |
| 2025-12-18 18:00 | Florian Dold | Note Added: 0027103 | |
| 2026-01-04 20:32 | Christian Grothoff | Note Added: 0027198 | |
| 2026-01-20 11:45 | Christian Grothoff | Note Added: 0027291 | |
| 2026-01-23 14:41 | Christian Grothoff | Note Added: 0027323 | |
| 2026-01-23 14:41 | Christian Grothoff | Assigned To | Christian Grothoff => Florian Dold |
| 2026-01-23 14:41 | Christian Grothoff | Status | assigned => feedback |
| 2026-02-07 17:12 | Christian Grothoff | Tag Attached: vivy | |
| 2026-02-17 08:52 | Christian Grothoff | Target Version | 1.5 => 1.7 |
| 2026-02-17 20:41 | Christian Grothoff | Tag Detached: vivy | |
| 2026-07-24 14:15 | Florian Dold | Assigned To | Florian Dold => Christian Grothoff |
| 2026-07-24 14:15 | Florian Dold | Note Added: 0029214 | |
| 2026-07-31 11:58 | Christian Grothoff | Status | feedback => informing |
| 2026-07-31 11:58 | Christian Grothoff | Resolution | open => fixed |
| 2026-07-31 11:58 | Christian Grothoff | Fixed in Version | => 1.6 |
| 2026-07-31 11:58 | Christian Grothoff | Target Version | 1.7 => 1.6 |