I have a webhook set up with Twilio to respond to incoming SMS requests, and the number sent by Twilio includes the country code; e.g., "+16175551234". However, the number is stored in the sms_user table without the country code, so sms_user_get_uid() always fails for me.

It seems the way to fix this is to first check for the number as is. If that fails to find a user, sms_user_get_uid() should try again, taking the country code into account (I see that, for Twilio at least, the gateway column stores the country).

The other, lazier option is to add query tags to the db_select query so that it can be altered.

I've done the latter locally but would be willing to help with the former if the patch will be released.

Comments

venutip created an issue.

almaudoh’s picture

almaudoh CreditAttribution: almaudoh commented

Do you have a patch that can demonstrate the issue better? The sms_user number is not processed in any way before storage in the sms_user table.

venutip’s picture

venutip CreditAttribution: venutip commented

Hi almaudoh,

I'm not sure I can provide a patch that demonstrates the problem but I'll try to explain the problem in more detail. Imagine that a user sends a STOP or START request. When Twilio gets that request, a webhook sees that and sends a POST request to our callback URL with data like the following:

Array
(
    [ToCountry] => US
    [ToState] => District Of Columbia
    [SmsMessageSid] => xxx
    [NumMedia] => 0
    [ToCity] => 
    [FromZip] => 02703
    [SmsSid] => xxx
    [FromState] => MA
    [SmsStatus] => received
    [FromCity] => CAMBRIDGE
    [Body] => STOP
    [FromCountry] => US
    [To] => +12025551234
    [ToZip] => 
    [NumSegments] => 1
    [MessageSid] => xxx
    [AccountSid] => xxx
    [From] => +16175551234
    [ApiVersion] => 2010-04-01
)

It's the [From] line that's the problem:

[From] => +16175551234

Because the number has that "+1" country code prefix, when my sms_incoming rule fires, it never finds a user because the number is stored as 6175551234.

Does that make sense?

almaudoh’s picture

almaudoh CreditAttribution: almaudoh commented

Because the number has that "+1" country code prefix, when my sms_incoming rule fires, it never finds a user because the number is stored as 6175551234.

What I don't get is how your number gets stored as 6175551234. It is whatever you type in at registration that gets saved. The number is not modified before storage. If 6175551234 is saved to sms_user table, that's what was entered by the user.

venutip’s picture

venutip CreditAttribution: venutip commented

I'm not saying that sms_user is changing it before it is stored. I'm saying that when it comes in from Twilio it has a +1 prepended. That's the array I pasted – data from Twilio.

almaudoh’s picture

almaudoh CreditAttribution: almaudoh commented

I'd suggest then that you store your number in international format. What Twilio is doing is correct. Alternatively, you can write some code to strip out the +1 from the Twilio data - but that would be the wrong way of doing it.