Services/Mobile-ID
From MozillaWiki
< Services
Contents
Overview
The Mobile-ID service provides a global mobile number validation system that can be used to authenticate a user's device. It interacts with SMS gateways to send and receive SMS messages.
More Info:
- https://wiki.mozilla.org/Loop/Architecture#MSISDN_.28Phone_Number.29_Verification
- https://bugzilla.mozilla.org/show_bug.cgi?id=988469#c5
Contacts
- Dev Team
- Tarek Ziadé <tarek@mozilla.com>
- Alexis Metaireau <alexis@mozilla.com>
- Rémy Hubscher <natim@mozilla.com>
- Ops
- Dean Wilson <dwilson@mozilla.com>
- Bob Micheletto <bobm@mozilla.com>
- QA
- Richard Pappalardo <rpappalardo@mozilla.com>
- Karl Thiessen <kthiessen@mozilla.com
Deployment Environments
Summary
There are 4 deployed environments.
Environment | URL | Endpoint Used | Usage |
DEV | http://msisdn-dev.stage.mozaws.net | Nexmo | Development and integration |
STAGE | http://msisdn.stage.mozaws.net | Nexmo | End-2-End (client-side) testing |
STAGE-LOADTEST | http://msisdn-loadtest.stage.mozaws.net | Omxen | Load (server-side) testing |
PRODUCTION | http://msisdn.services.mozilla.com | Nexmo | Production apps |
DEV
Description
- Host: https://msisdn-dev.stage.mozaws.net/
- Maintainer: Dev Team
- SMS Gateway: Nexmo
- Usage: Development and integration
Notes
- This environment is updated with the master branch by devs on a regular basis - or upon request.
- you can get the version by displaying the root URL of the server.
- This environment provides a Mobile number validation for the countries listed below
Client Country | Provider | MCC | Server Number |
USA | Nexmo | 302 - 310 - 311 - 312 - 313 - 314 - 315 - 316 - 332 - 544 | XXXX |
France | Nexmo | 208 - 308 - 340 - 543 - 546 - 547 - 647 - 742 | XXXX |
Spain | Nexmo | 214 | XXXX |
Others | Nexmo | XXX |
STAGE (E2E-TEST)
Description
- Host: https://msisdn.stage.mozaws.net/
- Maintainer: Ops Team
- SMS Gateway: NEXMO (feal endpoint)
- Usage: End-2-End Test (client-side testing against a real endpoint: Nexmo)
Notes
- This environment is used for end-to-end testing of the service once it hits the stable channel.
- This server is a perfect mirror of the production environment, updated with the tag of the upcoming release
- ATTENTION!: - This uses is a real endpoint!
- We pay for each text message so DO NOT loadtest against it!!
STAGE (LOADTEST)
Description
- Host: https://msisdn-loadtest.stage.mozaws.net/
- Maintainer: Ops Team
- SMS Gateway: OMXEN (fake endpoint)
- Usage: Loadtesting (server-side and testing)
Notes
- This environment is used by QA and dev teams for load tests.
- The goal is to measure how many connections can be handled by the server and anticipate errors that might happen on high load.
- SMS are not sent for real - they are collected by a fake SMS Gateway: OMXEN.
- Load tests can interact with OMXEN to check what SMS messages are sent out of the system.
- You can verify that an SMS message has been received by OMXEN through your browser:
- http://omxen.dev.mozaws.net/receive?to=<DEVICE PHONE NUMBER>
PRODUCTION
Description
- Host: https://msisdn.services.mozilla.com/
- Maintainer: Ops Team
- SMS Gateway: Nexmo
- Usage: Production apps
Notes
- This environment is used for production and is the default server for Firefox Nightly.
- The prod environment provide a Mobile number validation for the countries listed below
Client Country | Provider | MCC | Server Number |
USA | Nexmo | 302 - 310 - 311 - 312 - 313 - 314 - 315 - 316 - 332 - 544 | XXXX |
More to come |
Release Cycle
- The service is continuously pushed into the DEV server where client developers can test it.
- The service is released in: STAGE, STAGE-LOADTEST then PRODUCTION every other week (or asap if we discover a security breach)
Branches and bugfix deployments
In case of a bugfix:
- A commit will with the fix will be pushed to master.
- A new branch will be created on the github repository with the versions that needs the patch, and the fixes will be applied there (backported).
- A new tag will be created with the new version (the patch version will be updated) and a deployment request will be filled.
For instance, in case the 0.9.0 release contains a bug that needs to be fixed:
- Fix the code in master;
- Backport (cherrypick) the commit in the 0.9.x branch (create it if needed);
- Tag a new minor release: 0.9.1 and fill a new deployment request.