View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0010427 | Taler | merchant backoffice SPA | public | 2025-09-19 13:32 | 2025-10-02 20:47 |
Reporter | sebasjm | Assigned To | sebasjm | ||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | resolved | Resolution | fixed | ||
Product Version | 1.0 | ||||
Target Version | 1.1 | ||||
Summary | 0010427: better error details when the code is send too soon | ||||
Description | > very weird error message > "A code was just sent. Please wait before requesting another one." > If possible, add countdown until possibility to request new code reported by vlada This requires more information from the backend, so I'm creating this issue in the backend first and checking with CG also. https://docs.taler.net/core/api-merchant.html#post-[-instances-$INSTANCE]-challenge-$CHALLENGE_ID IMO Instead of returning 204 No Content on the success we can return a duration and a hint: interface ChallengeStarted { // text that was sent with the code to identify between more than one message hint: string; // time until this challenge can be solved solve_expiration: Timestamp; // time while this tan channel is blocked for retry retry_expiration: Timestamp; } This information is not saved in SPA session and a reload (or using same account from another browser) can still get 429 Too many requests. It would be nice to have the same response so the SPA can render "you should already have one with hit xxx or you can try again at ... " | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
related to | 0010469 | resolved | Christian Grothoff | cors problem |
child of | 0010224 | confirmed | Florian Dold | merchant backend self-provisioning [meta] [01sept] |
|
Eh, you already got the hint when you were given the list of challenges! So use the data from the 202 accepted, see https://docs.taler.net/core/api-merchant.html#tsref-type-Challenge |
|
That information is being used in the image, is what you see as "the phone starting with... XXX" where XXX is the hint (or tan_info in the protocol). (which by the way, i'm not sure 'starting with' is ok since the protocol doesn't say what that the hint is) This issue here highlight the fact that there is no enough information on 'too many request' error. > The client should wait how long? That why i propose the `ChallengeStarted` response when the challenge is sent: * `hint` (not the same as tan_info) is to allow the user to distinguish the message sent between 2 or 3 that already have. * `solve_expiration` time until this challenge is solvable (is this forever now?) after this time the SPA should request new challenge * `retry_expiration` time until this challenge is blocked for sending new TAN. Maybe the last two can be returned on 202 Accepted, but it should be duration instead of abs time. |
|
Ok, added a 200 OK with: interface ChallengeRequestResponse { // How long does the client have to solve the // challenge. solve_expiration: Timestamp; // What is the earlist time at which the client // may request a new challenge to be transmitted? earliest_retransmission: Timestamp; } We don't right now have something that would make a meaningful hint. |
|
57ab7532f..aa90a7ded adds the information but in order to see this in test environment we need 0010469 i was able to test it locally with a reverse proxy script to fix the headers from the merchant backend |
Date Modified | Username | Field | Change |
---|---|---|---|
2025-09-19 13:32 | sebasjm | New Issue | |
2025-09-19 13:32 | sebasjm | File Added: image(9).png | |
2025-09-21 14:39 | Christian Grothoff | Note Added: 0025953 | |
2025-09-21 14:40 | Christian Grothoff | Status | new => confirmed |
2025-09-21 14:40 | Christian Grothoff | Product Version | => 1.0 |
2025-09-21 14:40 | Christian Grothoff | Target Version | => 1.1 |
2025-09-27 21:28 | Christian Grothoff | Relationship added | child of 0010224 |
2025-09-27 21:29 | Christian Grothoff | Assigned To | => sebasjm |
2025-09-27 21:29 | Christian Grothoff | Status | confirmed => assigned |
2025-09-28 17:26 | sebasjm | Note Added: 0026051 | |
2025-09-28 17:27 | sebasjm | Assigned To | sebasjm => Christian Grothoff |
2025-09-28 17:27 | sebasjm | Status | assigned => feedback |
2025-09-28 22:17 | Christian Grothoff | Note Added: 0026059 | |
2025-09-28 22:17 | Christian Grothoff | Assigned To | Christian Grothoff => sebasjm |
2025-09-28 22:17 | Christian Grothoff | Status | feedback => assigned |
2025-10-02 20:47 | sebasjm | Note Added: 0026081 | |
2025-10-02 20:47 | sebasjm | Relationship added | related to 0010469 |
2025-10-02 20:47 | sebasjm | Status | assigned => resolved |
2025-10-02 20:47 | sebasjm | Resolution | open => fixed |