View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004601 | Taler | other | public | 2016-07-08 16:51 | 2016-10-11 17:28 |
| Reporter | Marcello Stanisci | Assigned To | Florian Dold | ||
| Priority | normal | Severity | tweak | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | 0.0 | ||||
| Target Version | 0.1 | Fixed in Version | 0.1 | ||
| Summary | 0004601: JS-less alternative | ||||
| Description | As of now, the JS-less version of merchants work by embedding anything needed by the wallet in a 'data-taler-*' attribute. We could also use HTTP headers for that, like X-Taler-*. The point is that sometimes the user does not get HTML, so the data-taler-* approach would not work. Other comments? | ||||
| Tags | No tags attached. | ||||
|
|
It makes sense to eventually allow the use HTTP headers for handling payments. But right now is too early. For a first version of JS-less payments it is easier to use HTML data attributes, since we can polyfill the translation to DOM events outside of the wallet. Handling headers requires more effort and additional signaling between components in the wallet, and there might be some unexpected difficulties in how the webRequest in WebExtensions (which is needed to get header information for requests) works. |
|
|
I disagree, I think we should use HTTP headers soon, especially as we cannot be sure that the body will be HTML. I think you were the one pointing this out, Florian. So we should transition to HTTP headers ASAP, likely just when we use 402 for signaling. |
|
|
Are you saying that we should completely move to HTTP headers, or should we also support a JavaScript API for payments? Note that at least the initial fulfillment page (before we have the cookie to get the actual resource) *MUST* generally be HTML (or something that is put in a DOM by the browser), otherwise the payment is not implementable with WebExtensions. With WebExtensions we can *inspect* HTTP headers, but we can't modify responses. Thus if we want to purchase https://example.com/happy_birthday.mp3, we must first get an HTML response so that the wallet can act on headers (otherwise the content script won't be injected). If there are confusions around this, we should discuss it offline before we make a decision. W3C is doing both, BTW. But for HTTP Payments, they assume that they're completely automated, they don't spec the browser interaction / user interaction part at all. Which is kind of bad. |
|
|
We keep supporting the JavaScript signal API, but for the JS-less version, I think we should signal via 204/402 and HTTP headers. I don't quite think you're right about the mp3 example, and yes, I think an mp3 should be a valid fulfillment page. Naturally, that's for the 200 OK, not for the payment required (402). As for the content script having to be injected, that would already not work with my envisioned 204-handling for the bank. But who says we _must_ do this via JS injection? Can't the extension simply take over given the right status code and headers? |
|
|
Could you please explain what you mean by "my envisioned 204-handling for the bank"? Otherwise I can't really respond properly without that context ;-) And no, unfortunately the extension can't simply take over given the right status code and headers. For session state (cookies) to be set properly, the deposit permission must be HTTP POST-ed from the same origin as the fulfillment page. In order to do that, we need the 402 to be HTML (so that a page with a DOM is created and the content script is injected, which will then do the POST). This is a restriction of WebExtensions that I believe we discussed in detail already. But this is not a bad thing, since for browsers without a wallet we want the 402 to contain HTML anyway. And of course, an mp3 can be a valid fulfillment page (after completed payment), I never said that it wasn't. Anyway, I'm happy with 402 and headers, but at least for browsers I don't see any advantage. Yeah, you could do the optimization with the contract inlined in the header. But considering that Apache and nginx limit headers to 8KB, this is not a good idea anyway. Some proxy might generate a 414 (Request-URI Too Large), we don't want that. |
|
|
1) I had discussed with Marcello what an appropriate way to do a JavaScript-less triggering of the wallet from the bank. If we, just like with the merchant, want to trigger on a status code, we should use one that is not too common. Also, as there is then not really a body, 204 is appropriate. So the idea was that the wallet would get a 204 status code from the bank to initiate withdrawal, again with headers providing the necessary banking details. 2) Ah, the cookie issue. Yeah, I guess we can require the 402 page to be in HTML, still, I think it's cleaner to go with headers. As for the header limit, my discussion with Marcello was to have two headers, one with a URI (dear wallet, download contract from here) and one with an inline JSON contract. So basically it'd be up to the merchant to decide: extra RTT vs. possibly wasted bandwidth. So for short contracts, x-taler-contract-json would be a good choice, and for big ones X-taler-contract-uri would be better. 3) I wonder if the 204 is a bad idea for the cookie-reason, maybe we'll need to revisit that choice as 204 replies must not have _any_ body. |
|
|
Regarding (2) I like that proposal. Don't we need the contract information also in the HTML? If not, enabling/installing the extension after the page has loaded won't work, headers can only be captured on page load. Or do we not consider this use case? The WPWG Payments HTTP API has not decided yet whether they want to link to the contract in the location header of 402, or to have the contract (=PaymentRequest in their terminology) in the body. The latter wouldn't be implementable with WebExtensions, AFAIK. |
|
|
At least for the merchant, it's implemented and documented (in the paper). Payments are triggered with 402. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-07-08 16:51 | Marcello Stanisci | New Issue | |
| 2016-07-08 21:17 | Florian Dold | Note Added: 0010980 | |
| 2016-07-09 17:22 | Christian Grothoff | Assigned To | => Marcello Stanisci |
| 2016-07-09 17:22 | Christian Grothoff | Severity | minor => tweak |
| 2016-07-09 17:22 | Christian Grothoff | Status | new => assigned |
| 2016-07-09 17:22 | Christian Grothoff | Product Version | => 0.0 |
| 2016-07-09 17:22 | Christian Grothoff | Target Version | => 0.2 |
| 2016-07-09 17:24 | Christian Grothoff | Note Added: 0010982 | |
| 2016-07-09 17:24 | Christian Grothoff | Assigned To | Marcello Stanisci => Florian Dold |
| 2016-07-09 17:35 | Florian Dold | Note Added: 0010984 | |
| 2016-07-09 19:47 | Christian Grothoff | Note Added: 0010985 | |
| 2016-07-09 21:17 | Florian Dold | Note Added: 0010986 | |
| 2016-07-09 22:52 | Christian Grothoff | Note Added: 0010987 | |
| 2016-07-09 23:25 | Florian Dold | Note Added: 0010988 | |
| 2016-09-12 23:52 | Florian Dold | Note Added: 0011111 | |
| 2016-09-12 23:52 | Florian Dold | Status | assigned => resolved |
| 2016-09-12 23:52 | Florian Dold | Resolution | open => fixed |
| 2016-09-19 00:51 | Christian Grothoff | Fixed in Version | => 0.1 |
| 2016-09-19 00:51 | Christian Grothoff | Target Version | 0.2 => 0.1 |
| 2016-10-11 17:28 | Christian Grothoff | Status | resolved => closed |
