View Issue Details

IDProjectCategoryView StatusLast Update
0011107Talerchallengerpublic2026-09-04 19:27
Reportervecirex Assigned ToChristian Grothoff Resolution deadline
ImplementerReviewer 
Release signed byDeployed by 
VerifierCommunicator 
Data protection authority notification requiredNo  
CSIRT notification requiredNo  
Estimated effort (hours)Actual effort (hours)0 
Fast-trackNo
Work packagenone
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Versiongit (master) 
Target Version1.6Fixed in Version1.6 
Summary0011107: Backend for sms auth needs fixing for cases where number wrong (e.g., too short, too long, or invalid (like flipped digit))
DescriptionUnfortunately, from our current helper scripts we get status codes like 400 or 404 for the two gateway providers we have, when we do like

+41 79 NNN NN NN K, while K is too much
+41 79 NNN NN N, with a missing digit somewhere (e.g., at the end)
+41 79 NNN NN WN, with a W turning the number invalid (e.g., at the end)

or just any other number which clearly is wrong,
Steps To ReproduceDoing it wrong with a pattern above, the following happens (for both SMS auth providers, telesign and clicksend):

curl: (22) The requested URL returned error: 400
telesign failed.
Polling message status (message_id: 1F10D12F-2AFA-6988-9122-3549D9A5CD0D)...
curl: (22) The requested URL returned error: 404
clicksend failed.
All SMS providers failed.
taler-merchant-httpd@1b0bd36dc346:/usr/local/bin$
Additional InformationOf course this will also happen if it's utterly wrong, like just "+41", which currently even the backoffice SPA lets through.
TagsNo tags attached.

Required notifications

Address or linkRemarkAdded byNotifiedActions

Relationships

related to 0011106 closedvecirex Phone numbers need proper checking 
child of 0011108 implementing Error message when an SMS cannot be delivered (bc of invalid number) should be subtle 

Activities

Christian Grothoff

2026-08-11 12:10

manager   ~0029460

fd977f3..0e60c12 fixes this by making the helpers return more well-defined exit codes depending on the various failure scenarios and parallel commits to challenger/merchant/anastasis map those new exit codes to suitable HTTP status codes and ECs. Note that we cannot easily tell "too short" from "too long" phone numbers, as that depends on the country and would require some rather complex custom code. But, we do now properly report on 'invalid phone number' as obtained by the providers.

vecirex

2026-09-04 19:27

administrator   ~0029871

Old / clearly solved

Issue History

Date ModifiedUsernameFieldChange
2026-02-18 21:45vecirexNew Issue
2026-02-18 21:47vecirexRelationship addedrelated to 0011106
2026-02-19 01:30vecirexDescription Updated
2026-02-19 01:50vecirexRelationship addedrelated to 0011108
2026-02-19 17:42Christian GrothoffRelationship deletedrelated to 0011108
2026-02-19 17:42Christian GrothoffRelationship addedchild of 0011108
2026-02-19 17:43Christian GrothoffPriorityhigh => normal
2026-02-19 17:43Christian GrothoffStatusnew => implementing
2026-02-19 17:43Christian GrothoffTarget Version => 1.8
2026-08-07 20:51Christian GrothoffAssigned To => Christian Grothoff
2026-08-07 20:51Christian GrothoffStatusimplementing => assigned
2026-08-07 20:51Christian GrothoffCategorymerchant backend => challenger
2026-08-07 20:51Christian GrothoffProduct Version => git (master)
2026-08-07 20:51Christian GrothoffStatusassigned => implementing
2026-08-11 12:10Christian GrothoffNote Added: 0029460
2026-08-11 12:10Christian GrothoffStatusimplementing => informing
2026-08-11 12:10Christian GrothoffResolutionopen => fixed
2026-08-11 12:10Christian GrothoffFixed in Version => 1.7
2026-08-11 12:10Christian GrothoffTarget Version1.8 => 1.7
2026-08-17 16:33Christian GrothoffFixed in Version1.7 => 1.6
2026-08-17 16:33Christian GrothoffTarget Version1.7 => 1.6
2026-09-04 19:27vecirexNote Added: 0029871
2026-09-04 19:27vecirexStatusinforming => closed