Create a dashboard to configure MOMT numbers routing wrt MNC/MCC and MSISDN

VERIFIED FIXED

Status

Cloud Services
MobileID
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: natim, Assigned: natim)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [qa?])

Attachments

(1 attachment)

(Assignee)

Description

4 years ago
We have deployed MSISDN in production at https://msisdn.services.mozilla.com/

Today it only works in the US.
In order to make it works at a global scale and/or add country in production, we need to create a protected dashboard to help configure the routing.
Whiteboard: [qa?]
(Assignee)

Comment 1

4 years ago
Created attachment 8471723 [details] [review]
Link to github PR
Attachment #8471723 - Flags: review?(alexis+bugs)
(Assignee)

Comment 2

4 years ago
We now have a working interface that can be plugged using redis.
How do we plan to deploy it so that only authorized people can access it and that both the server and the administration interface access the same elasticcache server.
Flags: needinfo?(bwong)
We can run it behind a persona login and limit it to a whitelist of users. 

Why is this better than just having it as a static configuration? 
Does routing change that often?
Flags: needinfo?(bwong) → needinfo?(rhubscher)
(Assignee)

Comment 4

4 years ago
For now it doesn't change a lot (slower than the code update) but for the moVerifierMapping it will change after each operator contract (when they can guarantee that the message will be free for their user to our number.)

Do you have some instruction for the persona login + whitelist? And example so that I can start hacking around.
Flags: needinfo?(rhubscher)
(Assignee)

Comment 5

4 years ago
A good and reasonable solution would be to use Persona for this using Apache as reverse proxy.

https://github.com/mozilla/mod_authnz_persona/
(Assignee)

Updated

4 years ago
Assignee: nobody → rhubscher
Status: NEW → ASSIGNED
(Assignee)

Comment 6

4 years ago
https://github.com/mozilla-services/msisdn-gateway/commit/1d757730121addc55cc1859499a176a71a27822c
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
(Assignee)

Comment 7

4 years ago
:Tarek propose that we also restrict access to the dashboard to people from the VPN.
Attachment #8471723 - Flags: review?(alexis+bugs) → review+
Wow, that is a significant number of changes/fixes/additions.
Just how does one test this new dashboard?
Do we run the server locally and go to a specific page/port in our browser?
(for testing purposes)

Is this something that is deployed via OPs to some instance that we all potentially have access to?

Does this run in Stage/Prod?
(Assignee)

Comment 9

4 years ago
By default it is still using the configuration file.

If you want to test using the dashboard, we will need to deploy both the dashboard and then configure the server to use configuration from redis.

And yes it can be use both on stage and prod.
Restricting the dashboard to people from the VPN would be the way I think is best.
OK, so configurations and restrictions belong to the OPs team, where they would most likely control things via one of their own repos (preferably during a specific msisdn deployment).

Given that, I can close this out based on the code committed earlier - Comment 6.

Verified in code and through unit tests.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.