|
|
This is not yet actionable since there is no spec documented. I found this example in the Taler POS " taler-pos://backend.demo.taler.net/#/username=<username>&password=<password> " which uses an unusual fragment to separate the params from url and access token is not supported. |
|
|
I have created this draft implementation to check how PoS creates the config but no look with the POS app image.png (90,320 bytes) image-2.png (29,091 bytes) image-3.png (61,311 bytes) |
|
|
5949a356a..a2fe54a89 only visible on expert mode |
|
|
Firstly, about the #, yes, a bit not standard, but I guess this was a move to make sure that backend logs do not contain usernames and passwords. From what I see, the QR code you have sent is recognized by pos, the only problem in my case was the fact that the merchant.taler is not found :(((( Otherwise, absolutely valid point about access tokens, I will try to make a DD for this in the next couple of days, just for the matter of structure, quite sure it will be "taler-pos://backend.demo.taler.net/#/username=<username>&access_token=<token>" |
|
|
For taler:// URIs we have this https://lsd.gnunet.org/lsd0006/ I'm not sure that a DD is the best way to define it. Please check with CG The taler-pos:// doesn't have an `action` section so are we going to use this for only one purpose? We also have the bank/merchant integration ( a merchant can setup it's instance with a bank user&password for auto-reconciliation) which lacks of an good URI for the same mechanism so I don't think this only belongs to pos. > but I guess this was a move to make sure that backend logs do not contain usernames and passwords. Password should never be in the URI and not exposed as QR code. The access_token has ha `secret-token:` prefix for that purpose. So the # makes no sense. Please make it consistent like others URIs Last, if the merchant portal print the QR code on screen but another person scan it first we should have a way for the user to know that is it's own device. This is bad because it will allow to sell product at lower price. IMO we need a flow of 1) print qr code on screen with a temp access_token (we can do this with a low duration) 2) pos app scans it, and generate a NEW access_token with refreshable property and high duration 3) merchant portal automatically switchs to a view with a confirmation "is this your device?" with buttons "yes" and "no, try again" similar to the taler://withdraw PD: the current backend API doesn't expose information to correlate the temp access_token generated in (1) with the new access token generated at (3) so now it will poll for any new tokens. @gc |
|
|
I suggest: taler-pos://backend.demo.taler.net/instances/username#accesstoken -- limits accidental logging, doesn't expose password. If missing, PoS app can ask for password. |
- Anonymous
