View Issue Details

IDProjectCategoryView StatusLast Update
0007473Talerwallet (Android App)public2023-04-05 17:35
Reportersebasjm Assigned Tosebasjm  
PrioritynormalSeverityminorReproducibilityalways
Status feedbackResolutionopen 
Product Versiongit (master) 
Target Version0.9.3 
Summary0007473: The app should navigate to the article after payment: (I need manually go back)
DescriptionIf 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.
TagsNo tags attached.

Activities

grote

2022-11-17 18:33

developer   ~0019435

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?

sebasjm

2022-11-17 20:03

developer   ~0019438

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.

grote

2022-11-17 20:41

developer   ~0019440

So you want after all payments that the Android wallet opens the fullfillment Uri without asking?

sebasjm

2022-11-18 16:37

developer   ~0019443

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.

grote

2023-01-05 21:27

developer   ~0019583

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.

Christian Grothoff

2023-01-06 14:58

manager   ~0019593

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?

sebasjm

2023-01-07 14:59

developer   ~0019605

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)

Christian Grothoff

2023-01-07 17:24

manager   ~0019606

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.

sebasjm

2023-01-07 22:35

developer   ~0019607

> 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?

Christian Grothoff

2023-01-07 23:01

manager   ~0019608

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.

Florian Dold

2023-04-05 17:35

manager   ~0020025

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.

Issue History

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