View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007473 | Taler | wallet (Android App) | public | 2022-11-17 18:20 | 2023-11-29 01:30 |
| Reporter | sebasjm | Assigned To | Christian Grothoff | ||
| Priority | high | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | git (master) | ||||
| Target Version | 0.9.3 | Fixed in Version | 0.9.3 | ||
| Summary | 0007473: The app should navigate to the article after payment: (I need manually go back) | ||||
| Description | Current behavior: 1.- open shop.test.taler.net on mobile browser 2.- go to an article 3.- pay it with wallet expected: the user wanted to see the article behavior: the user is redirected to the transaction list proposal: * redirect the user to the article (which webex does but controversial) * show the the transaction details with a clear indication of the fulfillment url (it should be obvious that this is the next step that the user need to take) worth mention that this issues was reported by email and there is a video that explain the situation | ||||
| 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. |
|
|
I have updated the description and since the original video was reported to android, I moving this issue to android but it should also be considered for iOS |
|
|
iOS has the same problem as Android: it cannot detect whether the user tapped on a link in Mobile Safari (on the phone) or used the built-in camera app (not its own Scan QR Dialog) to scan the QR code and pass the decoded link to the app. In both cases, the app only gets a taler:// URI to open. Only if the user taps the app's own Scan QR button it is clear that the user is scanning another device, and wouldn't want to open the fullfillment URI on the iPhone after payment. However, if the user tapped the link on the phone to switch from Safari to our app, then iOS itself shows a very small button in the top left corner reading "Safari", which brings the user right back to the web page where the link was tapped. And every iOS user knows this... Thus, this is a non-issue for iOS. Either the fullfillment is on another device, or the user can tap the small "Safari" button in the top left corner to go back to the merchant website where the payment link originated. |
|
|
I had my 15year old nephew here last week to try the iOS app for the very first time. He had absolutely no problems switching between a) bank and wallet app after having solved the math puzzle on the bank website and b) wallet app and shop after payment finished. He saw that the payment sheet vanished and the balance updated, and immediately switched to the shop to notice he could now read the paid article. So I won't show a fulfillment button on iOS - it's not necessary. Users know how to switch back to the browser where they started the payment process. |
|
|
I just tested the current situation on Android, and it works OK. If Marc is happy enough on iOS (and it does work nicely in browsers already), I think we can consider this done. |
| 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 | |
| 2023-07-05 15:16 | sebasjm | Description Updated | |
| 2023-07-05 15:16 | sebasjm | Assigned To | sebasjm => grote |
| 2023-07-05 15:17 | sebasjm | Note Added: 0020339 | |
| 2023-07-05 15:17 | sebasjm | Status | feedback => assigned |
| 2023-07-08 13:28 | MarcS | Note Added: 0020346 | |
| 2023-07-08 13:39 | MarcS | Note Added: 0020347 | |
| 2023-07-26 18:27 | Christian Grothoff | Assigned To | grote => Christian Grothoff |
| 2023-09-23 15:00 | Christian Grothoff | Priority | normal => high |
| 2023-09-23 15:00 | Christian Grothoff | Target Version | 0.9.3 => 0.9.4 |
| 2023-11-22 15:56 | Christian Grothoff | Status | assigned => resolved |
| 2023-11-22 15:56 | Christian Grothoff | Resolution | open => fixed |
| 2023-11-22 15:56 | Christian Grothoff | Fixed in Version | => 0.9.4 |
| 2023-11-22 15:56 | Christian Grothoff | Note Added: 0020656 | |
| 2023-11-29 01:28 | Christian Grothoff | Target Version | 0.9.4 => 0.9.3 |
| 2023-11-29 01:29 | Christian Grothoff | Fixed in Version | 0.9.4 => 0.9.3 |
| 2023-11-29 01:30 | Christian Grothoff | Status | resolved => closed |
