default webAppUrl in config.js is incorrect

RESOLVED FIXED

Status

Hello (Loop)
Server
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: dmose, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [qa+])

(Reporter)

Description

3 years ago
It currently points to "http://localhost:3000/static/#call/{token}", and really needs to point to ""http://localhost:3000/content/#call/{token}".

Would it be practical to put some automated (functional, I guess?) tests in front of these defaults to keep them from bit rotting?
"...some automated (functional, I guess?) tests..."

That was the idea. I wrote some separate bugs about that:
https://bugzilla.mozilla.org/show_bug.cgi?id=1045964
https://bugzilla.mozilla.org/show_bug.cgi?id=1045972
Whiteboard: [qa+]
This is not about deployed versions but really about the dev version. I'm not sure how practical that would be to have functional tests for the dev instance. Any idea on how to do that, dan?
Flags: needinfo?(dmose)
OS: Mac OS X → All
Hardware: x86 → All
(In reply to Alexis Metaireau (:alexis) from comment #2)
> This is not about deployed versions but really about the dev version. I'm
> not sure how practical that would be to have functional tests for the dev
> instance. Any idea on how to do that, dan?

We don't really need tests for the dev version specifically, but for sample.json - that file *needs* to be kept up to date (we've been bitten several times now) and having appropriate tests would help.

Either it needs tests, or it needs replaced by something that's going to have the correct (minimal?) layout that developers need when setting up a development server (and is easy for developers to copy/paste/adjust).
(Reporter)

Comment 4

3 years ago
So I think we may be able to thread an interesting needle here in an elegant way.  If we frame the problem to be solved as:

* as a dev, I should have to configure the minimal number of things to start contributing patches or running tests
* as a dev, I should rarely (if ever) trip on my dev.json failing because it doesn't have the latest syntax / attributes, and then have to debug and update it by hand.

One possibility could then be to make the path of least resistance be that (whenever practical) all config params should default to things that not only Just Work out of the box, but also (whenever practical) are identical to the values used for the existing end-to-end functional tests (under construction over in bug 1029183 and it's children).

In the ideal case, this means that the only values in most dev.json files would be non-public credentials.  This means we'd rarely have our own copies of attributes and such that have been obsoleted.

Would this fit with the server development workflow?
Flags: needinfo?(dmose)
That's supposed to already be the case :) What we need here is just to update the default configuration value to point to the right place, and there is no way to automate this, I fear, we just need to be careful :)
(Reporter)

Comment 6

3 years ago
Yeah, this is much more true than I had realized, which is great.  So I think what this means is that once we get bug 1029183, we'll get most of this automated testing for free.

As part of this, I suspect allowedOrigins wants to default to "[*]" as well.
https://github.com/mozilla-services/loop-server/commit/4d57728ea634bbe567f46aa9c30b3d5af5d9c0eb

Dan, can you confirm this is correct?
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
(In reply to Alexis Metaireau (:alexis) from comment #7)
> https://github.com/mozilla-services/loop-server/commit/
> 4d57728ea634bbe567f46aa9c30b3d5af5d9c0eb
> 
> Dan, can you confirm this is correct?

It'd be good to change

http://localhost:3000/content/#calls/{token}

to

http://localhost:3000/content/c/{token}

as that more matches the ongoing work to swap to the new url.

Actually, whilst you're here, you might as well make the rooms one http://localhost:3000/content/{token} since that's what it'll be once we've deployed rooms.
I don't know if the client dev server is able to currently serve these urls? is it the case?
Flags: needinfo?(standard8)
(In reply to Alexis Metaireau (:alexis) from comment #9)
> I don't know if the client dev server is able to currently serve these urls?
> is it the case?

It is fine for the local dev server that we use. The remote servers need their nginx configs updating (bug 1089657).
Flags: needinfo?(standard8)
You need to log in before you can comment on or make changes to this bug.