View Issue Details

IDProjectCategoryView StatusLast Update
0010427Talermerchant backoffice SPApublic2025-10-02 20:47
Reportersebasjm Assigned Tosebasjm  
PrioritynormalSeverityminorReproducibilityhave not tried
Status resolvedResolutionfixed 
Product Version1.0 
Target Version1.1 
Summary0010427: 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 ... "
TagsNo tags attached.
Attached Files
image(9).png (96,562 bytes)   
image(9).png (96,562 bytes)   

Relationships

related to 0010469 resolvedChristian Grothoff cors problem 
child of 0010224 confirmedFlorian Dold merchant backend self-provisioning [meta] [01sept] 

Activities

Christian Grothoff

2025-09-21 14:39

manager   ~0025953

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

sebasjm

2025-09-28 17:26

developer   ~0026051

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.

Christian Grothoff

2025-09-28 22:17

manager   ~0026059

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.

sebasjm

2025-10-02 20:47

developer   ~0026081

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

Issue History

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