Verify user has received an SMS
How to ensure that a user has received an SMS on their mobile phone using SMS authentication method and/or CustomerID mobile phone number verification process?
Guide
Ubisecure SSO calls the URL listed in the SMS authentication method.
Eg.
http://hostname/sendSMS?id=23uhf3423s&from=+38111&to={mobile}&content={challenge}
The {challenge} message is generated based on the localized SMS_TEXT language key found in the custom uas_XX.properties file.
Ubisecure CustomerID calls the gateway listed in the methods.sms.gateway variable of the eidm2.properties file
methods.sms.gateway = http://smsgw/sendsms?PhoneNumber={mobile}&text={challenge}&etc=123
The actual text sent in the challenge is defined in the setting sms.verification.message of the messages_XX.properties file.
In both cases, the call to the external SMS gateway is done by HTTP GET.
The {mobile} value is derived from the user’s directory mobile attribute.
Use of acknowledgements or read receipts is dependent on SMS gateway capabilities. Every SMS gateway is different and must be checked for compatibility.
If a HTTP status of 200 is received from the URL, it is assumed that the delivery has been successful. The actual output of the returned page HTML content is not read, processed or logged in any way. Ubisecure SSO and Ubisecure CustomerID do not process delivery and read receipts.
By using an intermediate proxy, it is possible to accept the request from Ubisecure SSO or CustomerID and implement a delay until the receipt of delivery is received, and only then return a 200 successful message. Implementation of the delay logic is gateway specific. User interface text should be updated according to warn the user of the delay. Maximum timeout should be implemented in the proxy application to prevent blocking of the user.
An intermediate proxy program can also create its own log of transaction numbers and received return values for diagnostic and possible accounting purposes. Typically operators provide a webservice to list sent messages and statuses.
For example, Orange SMS Gateway service returns a 200 status code even if the sending fails. An intermediate proxy is required to parse the XML response and determine if the message has been sent or not. Message sending can be prevented for example for technical reasons or billing reasons (lack of usage credits).
Orange returns a transaction ID upon successful send request, which can then be used later to call a different REST interface to check for delivery status. A HTTP callback from the SMS gateway is also possible.
As a general rule, user interface text should be modified according to customer requirements to describe what to do if SMS sending fails. ("If the problem persists, please use TUPAS", "If the problem persists, please call support")
If the SMS gateway requires a different format than HTTP GET (WebService, POST, custom API), customer or integrator implementation of a simple proxy application is required.
A sample implementation of a simple proxy for demonstration purposes is available upon request.
Related articles