Closed
Bug 1120713
Opened 10 years ago
Closed 7 years ago
SMS Code is not intercepted by MobileID implementation
Categories
(Core :: DOM: Device Interfaces, defect)
Core
DOM: Device Interfaces
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: oteo, Unassigned)
Details
Attachments
(1 file, 2 obsolete files)
PRECONDITIONS:
- Loop installed in the device
STR:
- Launch Loop
- Select register with your mobile phone
- Enter the phone number corresponding to the inserted SIM Card
ACTUAL RESULT
- The SMS is received in the device
- User needs to enter manually the code received in the SMS to complete the registration process.
EXPECTED RESULT
- The SMS with the code is received and intercepted by the MobileID implementation so the user does not need to enter it manually.
Reporter | ||
Comment 1•10 years ago
|
||
Fernando, I tested the Mobile ID flow again just before Christmas and was working fine. No more changes have been uplifted to 2.0 recently (only bug 1101444 last week) but I have been tested with older 2.0 builds and the issue is happening too.
I suspect that it could be a change in the Loop server configuration... could you help us and have a look at it, please? Thanks a lot!
Flags: needinfo?(ferjmoreno)
Reporter | ||
Updated•10 years ago
|
status-b2g-v2.0:
--- → affected
status-b2g-v2.1:
--- → affected
Comment 2•10 years ago
|
||
Dunno if it's related, since I haven't actually checked the code yet, but the received message comes from the number 'Mozilla¡' (yep, with the Spanish opening exclamation mark symbol). Since I'm assuming MobileID filters by the sending number, maybe that's the problem (that the sending number changed for some reason).
Comment 3•10 years ago
|
||
Ok, I added a trace to MobileIdentityClient (_request) and effectively, the configured number doesn't include a '¡', but a '@':
MobileIdentityClient: Got: {"verificationMethods":["sms/mt"],"verificationDetails":{"sms/mt":{"mtSender":"Mozilla@","url":"https://msisdn.services.mozilla.com/sms/mt/verify"}}}
Dunno if that's a misconfiguration on the server or a misconfiguration on the SMS carrier.
Comment 4•10 years ago
|
||
Thanks Antonio :)
IIRC this is on the SMS carrier side. We simply listen for messages coming from what the mtSender value says. Rémy, could you take a look at this, please? Thanks!
Flags: needinfo?(ferjmoreno) → needinfo?(rhubscher)
Reporter | ||
Comment 5•10 years ago
|
||
If I remember properly, I used to see "Mozilla@" as the sender of the SMS before Christmas break.
Comment 6•10 years ago
|
||
For which country do you see this problem? From which number do you receive the SMS instead of Mozilla@?
It could be a carrier modification. What we can do is to change the MSISDN server configuration to send from a country number instead of a text sender.
Flags: needinfo?(rhubscher)
Comment 7•10 years ago
|
||
For Spain, and we receive the SMS from Mozilla¡ instead of Mozilla@. I've sent the SMS to an iPhone also and it also shows Mozilla¡ as the sender.
Comment 8•10 years ago
|
||
I've also tried sending the SMS to a different carrier (in Spain) and it also shows Mozilla¡, so the number/name seems to come incorrectly from the originating carrier (it doesn't seem to be replaced by the receiving carrier).
Reporter | ||
Comment 9•10 years ago
|
||
Based on Antonio's comment, Alexis, Rémy, can you please verify on your side if the SMS is being sent from "Mozilla¡" instead of the expected "Mozilla@"?
Flags: needinfo?(rhubscher)
Flags: needinfo?(alexis+bugs)
Comment 10•10 years ago
|
||
I tried to buy Spanish number but I didn't succeed to send SMS to them so far.
I will ask for a configuration change about this in the MSISDN server.
Flags: needinfo?(rhubscher)
Updated•10 years ago
|
Flags: needinfo?(alexis+bugs)
Comment 11•10 years ago
|
||
We've tested this in O2 Network in UK and the SMS is received from "Mozilla@" when using a O2 UK number and from "Mozilla¡" when using a Movistar Spanish number (which kinds of make sense as the SMS-C used is the Home Network one).
Could this be an encoding an issue?
Comment 12•10 years ago
|
||
> Could this be an encoding an issue?
Yes it looks like it is, we could remove the @ from the string as a start.
Comment 13•10 years ago
|
||
Attachment #8549453 -
Flags: review?(dwilson)
Comment 14•10 years ago
|
||
I've applied this config to production for testing.
Reporter | ||
Comment 15•10 years ago
|
||
Humm... this is very weird, we received in the Mobile ID client that the SMS should be coming from "Mozilla":
I/Gecko (23049): 1421344137743 MobileId DEBUG MobileIdentityClient -> responseText {"verificationMethods":["sms/mt"],"verificationDetails":{"sms/mt":{"mtSender":"Mozilla","url":"https://msisdn.services.mozilla.com/sms/mt/verify"}}}
... but the SMS is now being received from "Mozilla@". Remy, any idea about what could be going on?
Flags: needinfo?(rhubscher)
Comment 16•10 years ago
|
||
Yes it is the reason why we were providing the @ in the first place.
What we will do is the same thing as for french number, we will provide the spanish number as mtSender. I will take care of it tomorrow.
Flags: needinfo?(rhubscher)
Comment 17•10 years ago
|
||
Attachment #8550339 -
Flags: review?(dwilson)
Updated•10 years ago
|
Attachment #8549453 -
Flags: review?(dwilson)
Updated•10 years ago
|
Attachment #8549453 -
Attachment description: Link to GitHub Documentation PR. → Link to GitHub PR.
Attachment #8549453 -
Attachment is obsolete: true
Reporter | ||
Comment 18•10 years ago
|
||
Dean, Rémy, let me know when you want me to test it again. Thanks a lot!
Flags: needinfo?(rhubscher)
Flags: needinfo?(dwilson)
Comment 19•10 years ago
|
||
This change has been made and works on production. We need to do a new release to stage and prod to ensure the new correct version gets deployed on autoscaling actions.
Status: NEW → ASSIGNED
Flags: needinfo?(dwilson)
Reporter | ||
Comment 20•10 years ago
|
||
Thanks a lot! Let me know when the correct version is deployed
Updated•10 years ago
|
Attachment #8550339 -
Flags: review?(dwilson) → review+
Reporter | ||
Comment 22•10 years ago
|
||
Unfortunately this is happening again in production.
Mobile ID Server is telling the device it should expect the SMS Authentication code coming from "+34911067087".
I/Gecko ( 8235): 1422607570655 MobileId DEBUG Discover result {"verificationMethods":["sms/mt"],"verificationDetails":{"sms/mt":{"mtSender":"+34911067087","url":"https://msisdn.services.mozilla.com/sms/mt/verify" }}}
But the message in the device is received from the number without the plus symbol: "34911067087"
I have tested pointing to Development Server and the message is received from "Mozilla¡" but expected from "Mozilla@" ("mtSender":"Mozilla@").
Alexis, Remy, could you please have a look?
Flags: needinfo?(rhubscher)
Flags: needinfo?(alexis+bugs)
Comment 23•10 years ago
|
||
This should have remained fixed in production. :natim ping me when you're about and we can double check the prod configs.
Updated•10 years ago
|
Flags: needinfo?(alexis+bugs)
Comment 24•10 years ago
|
||
We double checked the configuration and it looks good. I am checking what's going on with Nexmo.
Flags: needinfo?(rhubscher)
Comment 25•10 years ago
|
||
Could you provide me the spanish number you are using for the test please?
Flags: needinfo?(oteo)
Reporter | ||
Comment 26•10 years ago
|
||
Already provided via IRC so remiving the NI
Flags: needinfo?(oteo)
Comment 27•10 years ago
|
||
Thank you Maria.
According to https://help.nexmo.com/hc/en-us/articles/204014613-Originator-From-field-parameter-encoding we are doing the right thing in both cases.
Mozilla is in [a-zA-Z0-9]{1,11} and we are sending messages from 34911067087 which is a international number starting directly with the country code as described.
Maria do you think it could be possible to wait for messages coming from the number starting with one of 0034.. +34.. and 34..?
Is it possible that because the number is not recognized as a mobile number but as a landline number; it is considered as a string instead of a valid number? Does this problem can come from Firefox OS?
Flags: needinfo?(oteo)
Reporter | ||
Comment 28•10 years ago
|
||
Umm, I doubt we can handle different origins... but I am not sure, I prefer Antonio or Fernando to answer these questions.
Be aware also that we are very late to include more changes in 2.0 FxOS release, that is the target release for the current Firefox Hello mobile client.
Flags: needinfo?(oteo) → needinfo?(amac.bug)
Comment 29•10 years ago
|
||
No, the current MobileID implementation only allows to silently receive SMS from a single number. What I don't get is why, if you're sending 34xxxx as the "from" number to nexmo you have configured a +34xxxx number on the server (since I suppose that's configuration on the MobileID server). If you configure the same number that you're actually using (without the +) it should work.
Oh, and Mozilla is [a-zA-Z0-9]{1,11}, but neither Mozilla¡ nor Mozilla@ are.
Flags: needinfo?(amac.bug) → needinfo?(rhubscher)
Comment 30•10 years ago
|
||
> What I don't get is why, if you're sending 34xxxx as the "from" number to nexmo you have configured a +34xxxx number on the server (since I suppose that's configuration on the MobileID server).
We can definitely configure it like so for Spain but we should be sure it happens with all operator there. In France we are sending the number with any leading + but we receive it with one.
> Oh, and Mozilla is [a-zA-Z0-9]{1,11}, but neither Mozilla¡ nor Mozilla@ are.
Yes, I don't get why it is modified like so. When sending Mozilla it is received with Mozilla@, when sending Mozilla@ it is received with Mozilla¡
Flags: needinfo?(rhubscher)
Updated•10 years ago
|
Attachment #8550339 -
Attachment is obsolete: true
Comment 31•10 years ago
|
||
Attachment #8557920 -
Flags: review?(dwilson)
Attachment #8557920 -
Flags: feedback?(oteo)
Reporter | ||
Comment 32•10 years ago
|
||
Comment on attachment 8557920 [details] [review]
Link to Github PR — #1057.
Now, pointing to Production is working fine.
I don't have to enter manually the PIN code when user verifies the number already included in his SIM.
Attachment #8557920 -
Flags: feedback?(oteo) → feedback+
Updated•10 years ago
|
Attachment #8557920 -
Flags: review?(dwilson) → review+
Reporter | ||
Comment 33•10 years ago
|
||
Now, all is working fine.
Rémy, can we close the bug or, is there anything pending?
Flags: needinfo?(rhubscher)
Comment 34•10 years ago
|
||
If it works for you, it works for me.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Flags: needinfo?(rhubscher)
Resolution: --- → FIXED
Reporter | ||
Comment 35•10 years ago
|
||
Reopening because today it's failing again... and this morning was working, I promise!
Although the SMS that includes the PIN is sent from "+34911067087" (with the"+"), now we have to enter manually to verify the Mobile ID.
Antonio has got some traces:
I/Gecko ( 1571): AMAC: verificationOptions: {"origin":"app://loop.services.mozilla.com","msisdn":"+34669501762","mcc":"214","external":true,"mtSender":"34911067087"}
As you can see in "mtSernder" the "+" is not included...
Status: RESOLVED → REOPENED
Flags: needinfo?(rhubscher)
Resolution: FIXED → ---
Comment 36•10 years ago
|
||
:rhubscher - config from prod.
"smsMapping": {
"mtSender": "Mozilla",
"mtSenderMapping": {
"208": "+33644639987",
"214": "34911067087",
"302": "+12182967993",
"308": "+33644639987",
"310": "+12182967993",
"311": "+12182967993",
"312": "+12182967993",
"313": "+12182967993",
"314": "+12182967993",
"315": "+12182967993",
"316": "+12182967993",
"332": "+12182967993",
"340": "+33644639987",
"543": "+33644639987",
"544": "+12182967993",
"546": "+33644639987",
"547": "+33644639987",
"647": "+33644639987",
"742": "+33644639987"
}
},
Comment 37•10 years ago
|
||
> As you can see in "mtSernder" the "+" is not included...
Yes it is exactly the fix we did before in https://bugzilla.mozilla.org/attachment.cgi?id=8557920
Nexmo told me they did some changes to fix the +problem we had before.
We will revert and see if it works.
Flags: needinfo?(rhubscher)
Comment 38•10 years ago
|
||
Should be fixed. Hope it doesn't change again like so every weeks.
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
Comment 39•10 years ago
|
||
Apparently it depends on the operator. We will need to get down to the MNC.
Could you give us the MNC of the operator getting it with the '+' and the one which get it without the '+'?
Status: RESOLVED → REOPENED
Flags: needinfo?(marioalv.mozilla)
Resolution: FIXED → ---
Reporter | ||
Comment 40•10 years ago
|
||
clearing the ni, as I think it was for me.
Already commented in the IRC
Flags: needinfo?(marioalv.mozilla)
Comment 41•10 years ago
|
||
Thanks Maria.
I have contacted Nexmo about this. There is not much we can do on the server side since we are sending the exact same request and you are receiving on the same operator messages from different senders.
I will keep you posted.
Comment 42•7 years ago
|
||
Cleaning up Device Interfaces component, and mass-marking old FxOS bugs as incomplete.
If any of these bugs are still valid, please let me know.
Status: REOPENED → RESOLVED
Closed: 10 years ago → 7 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•