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)

defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE
Tracking Status
b2g-v2.0 --- affected
b2g-v2.1 --- affected

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.
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)
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).
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.
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)
If I remember properly, I used to see "Mozilla@" as the sender of the SMS before Christmas break.
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)
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.
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).
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)
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)
Flags: needinfo?(alexis+bugs)
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?
> Could this be an encoding an issue? Yes it looks like it is, we could remove the @ from the string as a start.
Attached file Link to GitHub PR. (obsolete) —
Attachment #8549453 - Flags: review?(dwilson)
I've applied this config to production for testing.
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)
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)
Attached file Link to Github PR — #1035. (obsolete) —
Attachment #8550339 - Flags: review?(dwilson)
Attachment #8549453 - Flags: review?(dwilson)
Attachment #8549453 - Attachment description: Link to GitHub Documentation PR. → Link to GitHub PR.
Attachment #8549453 - Attachment is obsolete: true
Dean, Rémy, let me know when you want me to test it again. Thanks a lot!
Flags: needinfo?(rhubscher)
Flags: needinfo?(dwilson)
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)
Thanks a lot! Let me know when the correct version is deployed
Attachment #8550339 - Flags: review?(dwilson) → review+
Should be fine now.
Flags: needinfo?(rhubscher)
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)
This should have remained fixed in production. :natim ping me when you're about and we can double check the prod configs.
Flags: needinfo?(alexis+bugs)
We double checked the configuration and it looks good. I am checking what's going on with Nexmo.
Flags: needinfo?(rhubscher)
Could you provide me the spanish number you are using for the test please?
Flags: needinfo?(oteo)
Already provided via IRC so remiving the NI
Flags: needinfo?(oteo)
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)
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)
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)
> 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)
Attachment #8550339 - Attachment is obsolete: true
Attachment #8557920 - Flags: review?(dwilson)
Attachment #8557920 - Flags: feedback?(oteo)
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+
Attachment #8557920 - Flags: review?(dwilson) → review+
Now, all is working fine. Rémy, can we close the bug or, is there anything pending?
Flags: needinfo?(rhubscher)
If it works for you, it works for me.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Flags: needinfo?(rhubscher)
Resolution: --- → FIXED
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 → ---
: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" } },
> 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)
Should be fixed. Hope it doesn't change again like so every weeks.
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
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 → ---
clearing the ni, as I think it was for me. Already commented in the IRC
Flags: needinfo?(marioalv.mozilla)
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.
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 ago7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: