View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007473 | Taler | wallet (Android App) | public | 2022-11-17 18:20 | 2023-04-05 17:35 |
| Reporter | sebasjm | Assigned To | sebasjm | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | feedback | Resolution | open | ||
| Product Version | git (master) | ||||
| Target Version | 0.9.3 | ||||
| Summary | 0007473: The app should navigate to the article after payment: (I need manually go back) | ||||
| Description | If the user is using mobile to read the articles on demo and tries to read one the wallet opens with the payment dialog. After the payment is completed, the user should be redirected to the article again. From an email > Yes, open fulfillment URL in browser. However, there is a small issue: > if I scanned the QR code from a desktop-browser, we'd open the URL in a > different browser (and the session-bound payment is bound to the browser > on my desktop!). So we shouldn't auto-navigate here at all, and merely > go to the page with the order details where the user can click on a > button to open the page. | ||||
| Tags | No tags attached. | ||||
|
|
I am not sure I understand. The quoted text says "we shouldn't auto-navigate here at all", but you want to auto-navigate after payment? |
|
|
The comment is describing a scenario when the QR code is scanned from the android wallet but the article is going to be read in the desktop. So, from the desktop: - go the shop - try to read an article - the qr code is shown - pay it with the mobile wallet - after being paid the wallet should show the tx is completed - the shop in the desktop browser should detect that the order has been pay and render the article Here the article is not shown in the mobile browser. Alternative scenario is when the article is being accessed from the mobile browser, pay and the the wallet should redirect again to the article. |
|
|
So you want after all payments that the Android wallet opens the fullfillment Uri without asking? |
|
|
You mean like "you are going to be redirected to" type of question? Maybe, I'm not sure. In the first scenario (when the redirect needs to be made, reading from mobile and paying with the same device) the user is coming FROM the article to the wallet to pay. It sounds reasonable that the user will want to go back to the article and the fulfillment url will redirect the user to that. |
|
|
OK, but how do we reliably detect that the user is coming from an article they want to go back to? On Android, we don't get informed by the browser where the user is coming from, so we only see the taler:// Uri. Maybe there's something in that Uri that indicates the desire to auto-go-back to fulfillment? Btw. a feature like this could have security implications as you can force the user to visit a certain site. |
|
|
I see. Yes, I guess we should add an argument to the taler://-URI that tells the mobile phone that it scanned a QR code on an 'external' system and thus should not navigate back itself. Something like "?nav=yes" would do, right? The QR code is where we need things to be compact, so there I would leave it out. I think the merchant can easily be modified to append such an argument when offering a link for clicking. All agree? |
|
|
I prefer not to add an extra parameter in QR more, there should be a default behavior that cover both use cases in a good enough experience. My suggestion: * after payment is done we add a successful payment screen with -- "ok" button (go back to the wallet) -- "close" (close the wallet) -- "continue to" (follow the fulfillment url) That I think solve what grote raise as security issue (we are not redirecting without user consent) Also, in the use-desktop-pay-with-mobile scenario the user will see the successful screen, the browser will reload showing the article, and can use the "close" button (since the wallet is just being summoned for the payment) If the scenario is navigating-with-mobile-and-payment, the "continue to" button or link will redirect to the article using the fulfillment url The "ok" button there if the user want to check balance before closing. What about that? (main idea: convention over configuration) |
|
|
Not good, as 'continue to' would be shown but would NOT work! The payment is session bound, so the browser would open but shown an error. So telling the wallet that the payment is for an article on another device (media-break) is an important hint to drive the right UX. I'm not sure the redirecting without user consent is an issue. The user consented to actually spend money already. If I can get you to do that, it's probably OK if I can ask you to open a web page ;-). Now, the really funky case is where the user opened in a browser, paid by mobile, and then _later_ wants to go back to the article on the mobile. Here, we'll need to open the browser, the browser will trigger the wallet, and then the wallet's repurchase detection has to change the payment in the merchant backend to the new session on the mobile and go back to the browser. Still, with my extra taler://-URI argument, all of this is possible and we don't show the user 'strange' paths that don't work. |
|
|
> Not good, as 'continue to' would be shown but would NOT work! The payment is session bound, so the browser would open but shown an error. Well, this is bad. AFAIK the merchant front-office has a volatile session that is used to bound the payment with the article, if that session is lost the user will need to pay again? If I ever payed for an article I would like to go back again even if I lost the session, isn't? That would mean that fulfillment URL should work in any setup. Like carrying the orderId and a prove of ownership in the request params (session-less) > Now, the really funky case is where the user opened in a browser, paid by mobile, and then _later_ wants to go back to the article on the mobile. This seems equal to the "continue to" plus a delay before clicking. > I'm not sure the redirecting without user consent is an issue. The user consented to actually spend money already. If I can get you to do that, it's probably OK if I can ask you to open a web page ;-) Sending a user to another app or external site (other than the wallet) should be warned. Merchant input should be considered untrusted from the wallet perspective and this lead to open-redirect issues https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html > repurchase detection has to change the payment in the merchant backend to the new session on the mobile and go back to the browser I don't have very clear how the repurchase work. Is this some missing feature what you are describing? |
|
|
Repurchase detection is exactly the feature you are looking for, and is implemented. Basically, if you did already pay for an article, but in a different session, you are first asked to pay again. But once you try, the wallet detects that you did already pay before, and simply proves to the merchant that you paid before, and asks the merchant to change the session ID on the purchase to the current session. BUT what this means is that if the user switches devices, they will get asked to pay again first, and have to scan the QR code with the wallet (or see some jumping around if the browser can auto-trigger the wallet) to allow the wallet to see the repurchase and rebind the session. |
|
|
I don't think that Christian's approach can work. How would the merchant decide whether it is a "media break" or not? When I click on an article in the blog demo, the merchant doesn't know whether I'm gonna pay with the browser wallet or the phone wallet. I'm proposing a different user experience: When going to the fulfillment URL, the merchant checks if there is a session mismatch. If the session matches, the article is rendered. On a mismatch, it offers to instead view the article in this browser. It then shows the QR code page. That's one more step, but it IMHO makes the user experience much clearer. And maybe the wallet can also add additional information to the fulfillment URL to make clear that this is a repurchase. IMHO we need to go back to the drawing board for the blog shop article, because it's currently both horribly complicated *and* not fully working. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2022-11-17 18:20 | sebasjm | New Issue | |
| 2022-11-17 18:20 | sebasjm | Status | new => assigned |
| 2022-11-17 18:20 | sebasjm | Assigned To | => grote |
| 2022-11-17 18:33 | grote | Note Added: 0019435 | |
| 2022-11-17 20:03 | sebasjm | Note Added: 0019438 | |
| 2022-11-17 20:23 | sebasjm | Target Version | git (master) => 0.9.1 |
| 2022-11-17 20:41 | grote | Note Added: 0019440 | |
| 2022-11-18 16:37 | sebasjm | Note Added: 0019443 | |
| 2022-12-20 18:26 | Christian Grothoff | Target Version | 0.9.1 => 0.9.2 |
| 2023-01-05 21:27 | grote | Note Added: 0019583 | |
| 2023-01-05 21:27 | grote | Assigned To | grote => Christian Grothoff |
| 2023-01-05 21:27 | grote | Status | assigned => feedback |
| 2023-01-06 14:58 | Christian Grothoff | Note Added: 0019593 | |
| 2023-01-06 14:59 | Christian Grothoff | Assigned To | Christian Grothoff => sebasjm |
| 2023-01-06 14:59 | Christian Grothoff | Assigned To | sebasjm => Florian Dold |
| 2023-01-07 14:59 | sebasjm | Note Added: 0019605 | |
| 2023-01-07 14:59 | sebasjm | Status | feedback => assigned |
| 2023-01-07 17:24 | Christian Grothoff | Note Added: 0019606 | |
| 2023-01-07 22:35 | sebasjm | Note Added: 0019607 | |
| 2023-01-07 23:01 | Christian Grothoff | Note Added: 0019608 | |
| 2023-02-19 14:27 | Florian Dold | Target Version | 0.9.2 => 0.9.3 |
| 2023-04-05 17:35 | Florian Dold | Assigned To | Florian Dold => sebasjm |
| 2023-04-05 17:35 | Florian Dold | Status | assigned => feedback |
| 2023-04-05 17:35 | Florian Dold | Note Added: 0020025 |
