View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010806 | Taler | specification | public | 2025-12-18 18:47 | 2025-12-18 19:00 |
| Reporter | Christian Grothoff | Assigned To | Christian Grothoff | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | assigned | Resolution | open | ||
| Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
| Product Version | git (master) | ||||
| Target Version | 1.5 | ||||
| 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. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-12-18 18:47 | Christian Grothoff | New Issue | |
| 2025-12-18 18:47 | Christian Grothoff | Status | new => assigned |
| 2025-12-18 18:47 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2025-12-18 18:47 | Christian Grothoff | Category | merchant backend => specification |
| 2025-12-18 19:00 | Florian Dold | Note Added: 0027103 |
