1043266 - Tokbox SDK url should be configurable

Status: RESOLVED FIXED

(Hello (Loop) :: Client, defect)

Description

[Alexis Metaireau (:alexis)]

At least in order to test staging environment, we need a way to change the url of the tokbox sdk (anvil.opentok.com) to a different URL.

Apparently, Nico told me the only way to do that is to touch the conversation.html file to override window.OTProperties.apiURLSSL

It would be helpful to have that behind a pref.

Comment 1

[James Bonacci [:jbonacci]]

Yea. We can limit this to special cases and urgent tests.
Otherwise holding Stage as is would be preferred for normal QA load, size, scale, and perf testing.

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

This seems like to be useful for functional testing as well.

Comment 3

[Adam Roach [:abr]]

This has been a feature of the OpenTok library for several versions now. You can set the following attributes on the "window.OTProperties" object (taking care to create it if it doesn't yet exist): cdnURL, assetURL, configURL, and cssURL.

Closing.

Comment 4

[Nicolas Perriault (:NiKo`) — needinfo me if you need my attention]

I think what's wanted here is to expose this value through a pref, to ease switching the value for testing. Updating the HTML files by hand is definitely possible, but we could probably improve developer & tester experience a bit here.

Comment 5

[u279076]

James, you originally set this to qa+. Is there anything left to verify here?

Comment 6

[James Bonacci [:jbonacci]]

:ashughes
For the server-side we are good. But based on Commment 4, I can't really tell if this is done or not.

Comment 7

[u279076]

(In reply to James Bonacci [:jbonacci] from comment #6)
> :ashughes
> For the server-side we are good. But based on Commment 4, I can't really
> tell if this is done or not.

Niko, can you please confirm if all the testing you need is done here?

Comment 8

[Nicolas Perriault (:NiKo`) — needinfo me if you need my attention]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #7)
> (In reply to James Bonacci [:jbonacci] from comment #6)
> > :ashughes
> > For the server-side we are good. But based on Commment 4, I can't really
> > tell if this is done or not.
> 
> Niko, can you please confirm if all the testing you need is done here?

This was just a suggestion, I think we implicetely decided not to implement the pref thing; so we're good to go I guess.

Comment 9

[Alexis Metaireau (:alexis)]

What Niko says is correct, we need a way to expose that at the browser level. I'm reopening.


This starts to be blocking since we don't have any way to test staging with a real browser so far.

Comment 10

[Alexis Metaireau (:alexis)]

I don't understand: what's the way to deal with this if we don't have a pref?

Comment 11

[Nicolas Perriault (:NiKo`) — needinfo me if you need my attention]

I remember an IRC conversation with :abr about this, but I don't quite remember its outcome. NI :abr here.

I personally agree this is still a good idea though.

Comment 12

[Adam Roach [:abr]]

(In reply to Alexis Metaireau (:alexis) from comment #10)
> I don't understand: what's the way to deal with this if we don't have a pref?

To make sure I understand what you're proposing -- are you planning to mock out the unpublished, unstable, proprietary, undocumented, internal, http-and-wss API that is used between the TokBox SDK and their back-end infrastructure? The one they didn't want us touching because it changes with every library release?

That may be inadvisable.

Comment 13

[Alexis Metaireau (:alexis)]

We need a way to have a firefox client able to talk with the tokbox staging infrastructure, in order to test everything is working as expected without using the production settings (that's part of the QA workflow, and why :jbo is in cc here).

The way we're currently doing that (server-side) is to generate the session tokens with the staging environment and to have the work okay on a firefox client.

In order to do that we would need a way to change the URL they're using to talk with the server (because this is not the prod server but their stage server).

Comment 14

[Adam Roach [:abr]]

Okay, I have an email in to TB engineering asking how they want us to configure the client to point at the staging server.

To be clear, the SDK configuration parameter that we need to change is "apiURLSSL", which is not in the list of five configuration parameters we currently have the ability to change.

Comment 15

[Rob Hainer]

A little clarification about what you are trying to achieve would be helpful. If you are looking to do some end to end testing or performance testing, is there a reason not to use the 44667562 apiKey and have the sessions hosted by the Tokbox environment that is designed to host the Nightly and Aurora traffic? If you really want to use a separate set of server(s) for this testing we could create a new apiKey and create a "staging" environment that maps to that apiKey.

Comment 16

[Adam Roach [:abr]]

ni? to Alexis for Rob's question.

Comment 17

[James Bonacci [:jbonacci]]

Hmmmm I just talked to TokBox QA rep about this. I said we use (will continue to use) Prod.
I am unclear why Loop Staging to TokBox Staging for client and/or E2E is needed...

Comment 18

[Alexis Metaireau (:alexis)]

What we are trying to achieve is to do an end to end testing using our staging environment, which is configured to use tokbox's staging servers (Anvil).

We currently don't rely on tokbox production for our staging environment (but use tokbox staging as well).

The solutions we have here are:

1. Use tokbox production for our staging environment (we don't want that since that would generate load on tokbox's servers);
2. Have tokbox production accept tokens generated by their staging;
3. Have a way to configure the tokbox client to use a different server than prod.

Comment 19

[Adam Roach [:abr]]

TL;DR: we're going with option 2 from Comment 18.

After a discussion this morning, the conclusion is: (a) We will continue to use anvil.tokbox.com as the client's first point of contact for the API (anvil serves as a redirector, and can dispatch clients to different clusters based on the API key in use); (b) TokBox will add the API key we've been using on the staging server to the production cluster, so that we can use staging tokens via the client API on the production servers.

Consequently, no action is required on the Loop client, so I'm closing this bug. Marking [qa-] because there's no code change to test. (James/Anthony -- let me know if I'm misunderstanding how this flag is to be used).

Comment 20

[James Bonacci [:jbonacci]]

That sounds correct to me. No testing needed.
FYI: my [qa-] is now being replaced by the flag "qe-verify" with a value of "-"

Comment 21

[Adam Roach [:abr]]

(In reply to James Bonacci [:jbonacci] from comment #20)
> That sounds correct to me. No testing needed.
> FYI: my [qa-] is now being replaced by the flag "qe-verify" with a value of
> "-"

Aha! Thanks for pointing that out. Fixing. :)

Comment 22

[Rob Hainer]

Just to be clear, our recommended approach is that you use the 44667562 key for all testing but we will also make the 347819 key work for more than just sessionId creation. Either way, as Adam mentions, there is no need for any action in the Loop client.