View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011192 | Taler | merchant backoffice SPA | public | 2026-03-04 20:09 | 2026-03-04 21:56 |
| Reporter | sebasjm | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | have not tried |
| Status | acknowledged | Resolution | open | ||
| Target Version | post-2.0 | ||||
| Summary | 0011192: dd 89: no enough info to distinguish between two emails if they come togheter | ||||
| Description | My email server had a big delay sending email and some emails reached at the same time. I left the SPA open waiting for the email to enter the code but when I tried both code failed (maybe it was a third one that never reached, didn't test) There should be a unique information in the email for the user to match the correct email with the verification the backend is waiting. One way I thought this could be is instead of sending 1234-5678 we send ABC-1234-5678 (3 random upper cased letters in addition to the 8 random numbers). We can achieve this by 2 ways: 1) extending the protocol by adding a new fiend in the response of https://docs.taler.net/core/api-merchant.html#post-[-instances-$INSTANCE]-challenge-$CHALLENGE_ID interface ChallengeRequestResponse { ... // The characters sent additionally as a TAN code prefix. // The client should show this in the UI so the user only needs to input the other 8 numbers tan_id: String; } 2) Using the last 3 characters of the challenge id for this purpose. We don't modify the protocol but this id will be the send on "resend". | ||||
| Tags | No tags attached. | ||||
|
|
Eh, the latest version of the backend includes the instance name, expiration date, and the purpose of the TAN. How is that not sufficient? |
|
|
The only piece of info that is unique to the tan code is the expiration date but we don't show it in the MFA screen, we show the remaining time if is close to be expired. So no. it's not a matter of sending more information, more also means that is more confusing (specially plain text email, or sms). Adding 3 letter as a prefix of the code doesn't require parse the full email and the SPA should very prominently asking Verification code: A F G - [ ][ ][ ][ ] - [ ][ ][ ][ ] |
|
|
I don't think we should do this, this is uncommon, we need to make sure e-mails are delivered quickly anyway, and having some strange prefix can lead to bad results. Just imagine the random prefix being FCK-1234 for some sensitive user. Nobody else does it, and it also is not good for auto-detection of TANs in SMS by mobile OSes for easy copy & paste. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-03-04 20:09 | sebasjm | New Issue | |
| 2026-03-04 20:09 | sebasjm | Status | new => assigned |
| 2026-03-04 20:09 | sebasjm | Assigned To | => Christian Grothoff |
| 2026-03-04 20:35 | Christian Grothoff | Note Added: 0027985 | |
| 2026-03-04 20:36 | Christian Grothoff | Assigned To | Christian Grothoff => sebasjm |
| 2026-03-04 20:36 | Christian Grothoff | Status | assigned => feedback |
| 2026-03-04 20:48 | sebasjm | Note Added: 0027986 | |
| 2026-03-04 20:48 | sebasjm | Assigned To | sebasjm => Christian Grothoff |
| 2026-03-04 21:55 | Christian Grothoff | Note Added: 0027987 | |
| 2026-03-04 21:56 | Christian Grothoff | Status | feedback => acknowledged |
| 2026-03-04 21:56 | Christian Grothoff | Target Version | => post-2.0 |
| 2026-03-04 21:56 | Christian Grothoff | Assigned To | Christian Grothoff => |
| 2026-03-04 21:56 | Christian Grothoff | Severity | minor => feature |
