| 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. | |
| Implemented at Taler POS (since 1.5.0), waiting for implementation at MerchantPortal, for further testing | |
| have you tried merchant portal in master branch? I don't remember when I implemented so I can't tell which version already has it. image-4.png (22,345 bytes) image-5.png (24,873 bytes) image-6.png (40,955 bytes) | |
| seems like scope order-pos is incorrectly set at backend side curl -v -H "Authorization: Bearer secret-token:X9CS5WBYD56FX2WWZAP1ZM99ETBHZR58SGE8A0P9769M63QXC3X0" https://my.taler-ops.ch/instances/bfhcafeteria/private/pos * Host my.taler-ops.ch:443 was resolved. * IPv6: 2a01:4f8:1c1b:b857::1 * IPv4: 167.235.152.145 * Trying [2a01:4f8:1c1b:b857::1]:443... * Connected to my.taler-ops.ch (2a01:4f8:1c1b:b857::1) port 443 * ALPN: curl offers h2,http/1.1 * (304) (OUT), TLS handshake, Client hello (1): * CAfile: /etc/ssl/cert.pem * CApath: none * (304) (IN), TLS handshake, Server hello (2): * (304) (IN), TLS handshake, Unknown (8): * (304) (IN), TLS handshake, Certificate (11): * (304) (IN), TLS handshake, CERT verify (15): * (304) (IN), TLS handshake, Finished (20): * (304) (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256 / [blank] / UNDEF * ALPN: server accepted http/1.1 * Server certificate: * subject: CN=my.taler-ops.ch * start date: Jun 16 15:03:37 2026 GMT * expire date: Sep 14 15:03:36 2026 GMT * subjectAltName: host "my.taler-ops.ch" matched cert's "my.taler-ops.ch" * issuer: C=US; O=Let's Encrypt; CN=YE1 * SSL certificate verify ok. * using HTTP/1.x > GET /instances/bfhcafeteria/private/pos HTTP/1.1 > Host: my.taler-ops.ch > User-Agent: curl/8.7.1 > Accept: */* > Authorization: Bearer secret-token:X9CS5WBYD56FX2WWZAP1ZM99ETBHZR58SGE8A0P9769M63QXC3X0 > * Request completely sent off < HTTP/1.1 401 Unauthorized < Server: nginx < Date: Mon, 29 Jun 2026 09:30:14 GMT < Content-Type: application/json < Content-Length: 153 < Connection: keep-alive < Access-Control-Allow-Origin: * < Access-Control-Expose-Headers: * < Cache-Control: no-store < { "code": 2015, "hint": "The merchant refused the request due to lack of authorization.", "detail": "Check credentials in 'Authorization' header" * Connection #0 to host my.taler-ops.ch left intact }% for some reason pos scoped token, doesn't give access to pos endpoint... | |
| Okay, this is crazy, no surprise it was not working... The scope of pos token has to be redefined at the backend. image-7.png (48,651 bytes) image-8.png (19,264 bytes) | |
| 76f41e95..a1fbb0de should fix the backend issue. | |
- Anonymous