1034538 - Need to have different API Keys for Loop mobile and desktop

Status: RESOLVED WONTFIX

(Hello (Loop) :: General, defect)

Description

[Daniel Coloma:dcoloma]

Product Team wants to monitor and route the various environments a bit more, and as a result they want FFOS to have its own API key.

A possible solution would be the server using the UserAgent header of the HTTP request to decide which APIKey should be used (this would require only changes on the Loop server) but I assume there might be other alternatives. 

Filing this bug on Loop::General component until a solution is proposed.

Comment 1

[Romain Testard [:RT]]

Please have a look at https://bugzilla.mozilla.org/show_bug.cgi?id=1033032
The plan described by Adam is that there will be only _one_ API key in use per call, selected by the _server_ based on the release channel of the _calling_ party.

If the calling party is a Web UI client (shared for a call-back to a desktop client or a FFOS client) and the callee is a FFOS device this means the Web UI client will set the API key.

Comment 2

[Daniel Coloma:dcoloma]

(In reply to Romain Testard [:RT] from comment #1)
> Please have a look at https://bugzilla.mozilla.org/show_bug.cgi?id=1033032
> The plan described by Adam is that there will be only _one_ API key in use
> per call, selected by the _server_ based on the release channel of the
> _calling_ party.
> 

What I was suggesting is exactly the same, the _server_ decides the API Key to use based on the User Agent included in the HTTP Request of the _calling_ party. Adam, any reason why the User Agent sniffing was not considered as an option here?

If Adam believes we should follow the same approach for FFOS than for release channels, I think we should simply add a new possible value for ffos to the channel attribute described in https://wiki.mozilla.org/Loop/Architecture/MVP#POST_.2Fcalls.


> If the calling party is a Web UI client (shared for a call-back to a desktop
> client or a FFOS client) and the callee is a FFOS device this means the Web
> UI client will set the API key.

Yep, that is the current behaviour, but based on https://bugzilla.mozilla.org/show_bug.cgi?id=1033032#c3 "elected by the _server_ based on the release channel of the _calling_ party" it's not clear to me if the calling party is the one generating the URL or the one clicking on it. 

ni on Adam to clarify both aspects.

Comment 3

[Adam Roach [:abr]]

(In reply to Daniel Coloma:dcoloma from comment #2)
> What I was suggesting is exactly the same, the _server_ decides the API Key
> to use based on the User Agent included in the HTTP Request of the _calling_
> party. Adam, any reason why the User Agent sniffing was not considered as an
> option here?

Mostly because we want the decision to be based on the release channel itself, which isn't part of the UA string. In theory, we could have the server make this distinction based on version number, which would probably be close enough; but this imposes a burden on the server to track which version is in which channel at any given moment.

There's also a bit of monkey-training (see http://proliberty.com/observer/20080703.htm) that goes on any time UA sniffing is mentioned, even when the reasons to avoid it don't apply.

> If Adam believes we should follow the same approach for FFOS than for
> release channels, I think we should simply add a new possible value for ffos
> to the channel attribute described in
> https://wiki.mozilla.org/Loop/Architecture/MVP#POST_.2Fcalls.

I'm not opposed to adding a new value, but it's not clear why we couldn't simply use "release" for the mobile client.

> > If the calling party is a Web UI client (shared for a call-back to a desktop
> > client or a FFOS client) and the callee is a FFOS device this means the Web
> > UI client will set the API key.
> 
> Yep, that is the current behaviour, but based on
> https://bugzilla.mozilla.org/show_bug.cgi?id=1033032#c3 "elected by the
> _server_ based on the release channel of the _calling_ party" it's not clear
> to me if the calling party is the one generating the URL or the one clicking
> on it. 
> 
> ni on Adam to clarify both aspects.

The caller is the link clicker -- basically, it has to be whoever causes the Loop server to retrieve the tokens from the TokBox server, since that's the point in time that the API key is used. I'm currently waiting to hear back from TokBox about which key they want us to use for the link clicker, but this shouldn't have any impact on the mobile implementation.

Comment 4

[Daniel Coloma:dcoloma]

(In reply to Adam Roach [:abr] from comment #3)
> (In reply to Daniel Coloma:dcoloma from comment #2)
 
> > If Adam believes we should follow the same approach for FFOS than for
> > release channels, I think we should simply add a new possible value for ffos
> > to the channel attribute described in
> > https://wiki.mozilla.org/Loop/Architecture/MVP#POST_.2Fcalls.
> 
> I'm not opposed to adding a new value, but it's not clear why we couldn't
> simply use "release" for the mobile client.
> 
There is a request to use different API Keys for FFOS and Desktop, I think that requires a FFOS specific value separated from the Firefox Destkop "release" value. 

> > > If the calling party is a Web UI client (shared for a call-back to a desktop
> > > client or a FFOS client) and the callee is a FFOS device this means the Web
> > > UI client will set the API key.
> > 
> > Yep, that is the current behaviour, but based on
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1033032#c3 "elected by the
> > _server_ based on the release channel of the _calling_ party" it's not clear
> > to me if the calling party is the one generating the URL or the one clicking
> > on it. 
> > 
> > ni on Adam to clarify both aspects.
> 
> The caller is the link clicker -- basically, it has to be whoever causes the
> Loop server to retrieve the tokens from the TokBox server, since that's the
> point in time that the API key is used. I'm currently waiting to hear back
> from TokBox about which key they want us to use for the link clicker, but
> this shouldn't have any impact on the mobile implementation.

Yep, agreed there is no impact on the mobile client, but just wanted to clarify what the expectations are as this is kind of "strange" case. Glad to hear it's already being discussed.

Comment 5

[Adam Roach [:abr]]

(In reply to Daniel Coloma:dcoloma from comment #4)
> There is a request to use different API Keys for FFOS and Desktop, I think
> that requires a FFOS specific value separated from the Firefox Destkop
> "release" value. 

Melih did send out message on July 3rd with this request, but he sent out a follow-up email about 45 minutes later:

> Let me take this one back.
> 
> There are some complexities introduced by this approach, and we'll find a different method to solve
> routing and monitoring.

So, for the time being, I think we're expected to use the same API key for the mobile client as we do for the release channel Firefox browser.

Melih: Can you confirm that this is your team's current expectation?

Comment 6

[Melih Onvural]

As far as production versions go, let's please use the same API key across all endpoints for this project. Sorry for the delay in response. The Bugzilla messages didn't bubble up into "important and unread", and so I've now fixed that

Comment 7

[Mark Banner (:standard8)]

Adam, given comment 6, do you think we can close this as wontfix for now?

Comment 8

[Adam Roach [:abr]]

(In reply to Mark Banner (:standard8) from comment #7)
> Adam, given comment 6, do you think we can close this as wontfix for now?

I think so, yes. If we decide that we need to rework the channels in the future, we can open a new bug to handle it.