1046114 - Change the URL format for the webapp for calls / rooms

Status: RESOLVED FIXED

(Hello (Loop) :: Server, defect, P1)

Description

[Romain Testard [:RT]]

When getting to Beta we'll want to use the "Firefox Hello" brand.
The beta release will start implementing a new URL format as follows:
https://hello.firefox.com/<token> 

This URL should not be a simple redirect to a mozilla.com page and the link clicker address bar should tell him he is on https://hello.firefox.com/<token>

Comment 1

[Rémy Hubscher (:natim)]

This is related to loop-client deploiement.

Comment 2

[Romain Testard [:RT]]

Update - this will be required only for Beta Fx35.

Comment 3

[Romain Testard [:RT]]

Update from Arcadio -  Changing required URL format to https://firefox.com/hello/<token>

Comment 4

[Rémy Hubscher (:natim)]

Having a subdomain will be much easier to handle than a subpath because of the way the DNS and the deploiements works.

Also loop-client is static so it might be possible. I will let the OPS do the final call.
But https://hello.firefox.com is definitly easier than https://firefox.com/hello

Comment 5

[Benson Wong [:mostlygeek]]

definitely going https://hello.firefox.com would be much easier. Using https://firefox.com/hello will require https://firefox.com to have extra http level routing logic.

Comment 6

[:shell escalante]

Hi Arcadio - based on comment 4 & 5 from the server team and operations team - are we OK with the original https://hello.firefox.com?

Comment 7

[Romain Testard [:RT]]

Summary of a separate e-mail thread with Chris/Alexis/Arcadio:
* https://firefox.com/hello or https://hello.firefox.com will redirect to the Firefox Hello product page
* https://hello.firefox.com will be the functional domain when placing calls
* https://hello.firefox.com{token} will be displayed in the desktop client panel when the URL gets generated and in the link clicker browser's URL bar

Comment 8

[Alexis Metaireau (:alexis)]

nipick, this is https://hello.firefox.com/{token} (there was a missing slash).

Comment 9

[Chris More [:cmore]]

(In reply to Romain Testard [:RT] from comment #7)
> Summary of a separate e-mail thread with Chris/Alexis/Arcadio:
> * https://firefox.com/hello or https://hello.firefox.com will redirect to
> the Firefox Hello product page
> * https://hello.firefox.com will be the functional domain when placing calls
> * https://hello.firefox.com{token} will be displayed in the desktop client
> panel when the URL gets generated and in the link clicker browser's URL bar

Should we change the summary of this bug to reflect comment 7?

I previously had other firefox.com/foo vanity URLs created in bug 870410.

Comment 10

[Romain Testard [:RT]]

(In reply to Chris More [:cmore] from comment #9)

> Should we change the summary of this bug to reflect comment 7?
> 
Sure, now done.

Comment 11

[Alexis Metaireau (:alexis)]

Romain, when exactly do we need to activate this? Fx35 is uplifting 2014-10-13, do we need to change our conf ahead of time?

Comment 12

[Romain Testard [:RT]]

Alexis, ideally the new URl should be available on release date on the 14th to users although I see no issues with changing the conf ahead of time given the low useage.
I NI Arcadio so he is aware.
I NI Mark for info as ideally the brand change on the landing page of the link clicker UI and this change should happen on the same day as bugs 1070753 and 1078345

Comment 13

[Alexis Metaireau (:alexis)]

Romain, the current implementation uses a hash in the urls: e.g. "https://call.mozilla.com/#call/K6ppEFY7y9s", can you confirm we want this to be changed to directly "https://hello.firefox.com/K6ppEFY7y9s" instead? (with no hash and no /call part).

If so, standalone client code will need to be updated, as well as the server configuration.

Comment 14

[Alexis Metaireau (:alexis)]

Here are some IRC logs with out conversation:

:RT said:
> regarding the # I'd rather not have it as it is just an extra character on the URL,
> making it the URL more cryptic.
> is there any good reason to have the # ?

:Alexis said:
> I though we had a good reason for it to be there (it's not logged, for instance),
> but I might be wrong.

:Standard8 said:

> that's a point, if we didn't have the hash, would it show up on routers across the internet?
> isn't it only the domain that gets that info

:Alexis
> I think this is never sent to the servers, it's just used by the clients

:Standard8:
> the hash form would only by the clients, but if its the non-hash form,
> wouldn't that be sent? (maybe encrypted)

:Alexis:

> the non-hash form would be sent, correct. but because we're using SSL nobody
> will be able to see it apart from the servers handling the domain
> I would rather have the hash and not send the info at all, so if TLS is compromised we don't leak anything, but that has the cost of having an extra # in the urls.


Adam, we would be interested to have your opinion here about the hash vs no-hash discussion :)

Comment 15

[Rémy Hubscher (:natim)]

Any way I think we need to differenciate call-urls tokens and rooms tokens.

So it could be either: https://hello.firefox.com/calls/K6ppEFY7y9s or https://hello.firefox.com/#calls/K6ppEFY7y9s for calls and https://hello.firefox.com/calls/K6ppEFY7y9s or https://hello.firefox.com/#calls/K6ppEFY7y9s for rooms.

We can configure the server to tell to serve /calls/* and /rooms/* to index.html and then let the browser route to the correct page.

Something like: https://gist.github.com/shreyas-satish/8452999 for the nginx part.

Comment 16

[Alexis Metaireau (:alexis)]

That's correct, but a bit different from the discussion about hashing we're talking about.

There are a lot of different ways to do the routing between calls and rooms, for instance:

- the hash part (#)
- the domain (hello.firefox.com for calls and rooms.firefox.com for rooms)
- the hash itself (we could say that the ones starting by 1 are for calls and the ones by 2 are rooms)
- the url itself (without the hash part).

We clearly need a path forward for distinguishing between rooms and calls.

Here we're discussing about how we deal for the upcoming release (13th of october) about the links that the users will see, and need to take action on how to distinguish between these now :)

Comment 17

[Romain Testard [:RT]]

Clearing my NI as my answer waas given on the IRC thread above.
If it does not compromise security I'd rather not have the #

Comment 18

[Rémy Hubscher (:natim)]

> Here we're discussing about how we deal for the upcoming release (13th of october) about the links that the users will see, and need to take action on how to distinguish between these now :)

If you are talking about next Monday, there is no doubt about the path forward:

 1. We configure the DNS and SSL certificate for hello.firefox.com
 2. We change the loop-server configuration to return callUrls on the right domain
 3. We stick with our current loop-client behavior which is #/calls/:token

If we are making a long term decision, the first decision is: Do we want loop-client to handle both calls and rooms? 

 - If yes, I think we should continue to have /calls/:token and /rooms/:token (or /c/:token and /r/:token if you prefer)
 - If no, I think we should have two separate DNS.

I would personally answer yes to that first question.


About the login of /calls/:token if we remove the #, I am not sure to understand the security point because we are asking for GET https://loop-server/calls/:token anyway at loop-client startup.

Also removing the # will improve the user experience and fix some bugs about changing the callToken directly in the url.

Comment 19

[Alexis Metaireau (:alexis)]

DNS and SSL are already in place, waiting for client changes to be ready (this was bug 1079751).

We're waiting for latest client code changes before pushing this to prod.
Otherwise we will need to break compatibility at one point in time, and we want to avoid that whenever possible.

Sticking with the current behavior is not what product wants here (it seems); There is a decision to make before we can take any action: Romain, can you weight in here please?

About the hash part in the url, the discussion is around having it or not. Having it in there means this information cannot be linked by the link clicker, since the browser retains this data for client side use. Not having it means it's less cryptic for the users. We're waiting for Abr feedback on this.

Romain, I'm adding you back here since I think we need a decision from you about what to do to distinguish between calls / rooms.

Comment 20

[Alexis Metaireau (:alexis)]

(e.g. we're making a long term decision, and we need to do it before next monday).

Comment 21

[Rémy Hubscher (:natim)]

> Otherwise we will need to break compatibility at one point in time
> We're making a long term decision, and we need to do it before next monday

True

Comment 22

[Alexis Metaireau (:alexis)]

Adding a few more thoughts here about the hash part, after some irc discussion:

it actually doesn't make any difference if we have it or not here: the loop-client server will not have it in its logs, but loop-server will get the information anyway.

So, from what :RT said in an earlier comment, it means that we should not use the hash part. The discussion about how to distinguish between calls and rooms stays intact, though.

Comment 23

[Mark Banner (:standard8)]

(In reply to Alexis Metaireau (:alexis) from comment #19)
> DNS and SSL are already in place, waiting for client changes to be ready
> (this was bug 1079751).
> 
> We're waiting for latest client code changes before pushing this to prod.
> Otherwise we will need to break compatibility at one point in time, and we
> want to avoid that whenever possible.

AFAIK there's no client changes needed for pushing the domain name change to production. We could still be hello.firefox.com/#call/<token> for now without needing to change loop-client.

Please correct me if I am wrong.


The scheme changes to the url, will need changes in loop-client (and hence for that to be deployed before the server changes). We should be able to make these in backwards-compatible ways.

Comment 24

[Alexis Metaireau (:alexis)]

 
> AFAIK there's no client changes needed for pushing the domain name change to
> production. We could still be hello.firefox.com/#call/<token> for now
> without needing to change loop-client.
> 
> The scheme changes to the url, will need changes in loop-client (and hence
> for that to be deployed before the server changes). We should be able to
> make these in backwards-compatible ways.

That's correct, it means that users will start to see http://hello.firefox.com/#calls/{token} links at the beginning, and then will change to http://hello.firefox.com/{token} (or a different url, depending on the discussion outcome).

I was under the assumption that we didn't wanted the users to see the http://hello.firefox.com/#calls/{token} links, and it doesn't seem to be the case (my bad).

Let's wait on client deploy then, and continue the discussion about calls VS rooms urls.

Comment 25

[Romain Testard [:RT]]

(In reply to Alexis Metaireau (:alexis) from comment #24)
>  
> > AFAIK there's no client changes needed for pushing the domain name change to
> > production. We could still be hello.firefox.com/#call/<token> for now
> > without needing to change loop-client.
> > 
> > The scheme changes to the url, will need changes in loop-client (and hence
> > for that to be deployed before the server changes). We should be able to
> > make these in backwards-compatible ways.
> 
> That's correct, it means that users will start to see
> http://hello.firefox.com/#calls/{token} links at the beginning, and then
> will change to http://hello.firefox.com/{token} (or a different url,
> depending on the discussion outcome).
> 
> I was under the assumption that we didn't wanted the users to see the
> http://hello.firefox.com/#calls/{token} links, and it doesn't seem to be the
> case (my bad).
> 
> Let's wait on client deploy then, and continue the discussion about calls VS
> rooms urls.

Yes, regardless of room URLs or call URLs the intention is to have a URL looking like http://hello.firefox.com/{token}

Comment 26

[Alexis Metaireau (:alexis)]

Okay, then that means we need to have a way to distinguish between tokens directly, since they will do the routing part.

Abr, Standard8, what do you think, should we encode this information in the tokens? It's not currently possible with the server implementation to know what the tokens are for just by looking at them.

Should we prepend "c" or "r" to them in front for instance? (which would make the token one char longer, also).

Comment 27

[Adam Roach [:abr]]

Three comments:

1) I agree with the current analysis that the "#" should be removed.

2) For distinguishing calls from rooms, there's no reason that the token needs to encode the information about whether it corresponds to a call or a room (and, in any case, that ship has sailed: the currently issued tokens do not conform to the proposed pattern). I'm a bit confused about why the server can't distinguish between the two patterns, since it must store all valid tokens. In a worst case, it seems you can check the rooms table; and, if you find no match, check the calls table.

3) We do want to retain the direct calling capability in the client for now, for at least two reasons: first, direct calling URLs that have been already issued aren't going to stop working. They'll just gradually expire. Second, we are almost certainly going to want to revive this ability in the future for SMB-targeted "click here to call us" kind of capabilities.

Going back to #2 (and I'm tagging Romain for this), it seems to me that the cleanest way to handle this may be to keep calls.mozilla.com for direct calling, and introduce hello.firefox.com along with rooms. That way, the domain could be used as a very easy indicator for whether we're using rooms or calls. Romain: would that be okay?

Comment 28

[Alexis Metaireau (:alexis)]

You're right, actually it's possible on the server side to know that by looking in its database. But we don't have any unique constraint between call url ids and rooms url ids, so they can overlap.

Comment 29

[Romain Testard [:RT]]

(In reply to Adam Roach [:abr] from comment #27)
> Three comments:
> 
> 1) I agree with the current analysis that the "#" should be removed.
> 
> 2) For distinguishing calls from rooms, there's no reason that the token
> needs to encode the information about whether it corresponds to a call or a
> room (and, in any case, that ship has sailed: the currently issued tokens do
> not conform to the proposed pattern). I'm a bit confused about why the
> server can't distinguish between the two patterns, since it must store all
> valid tokens. In a worst case, it seems you can check the rooms table; and,
> if you find no match, check the calls table.
> 
> 3) We do want to retain the direct calling capability in the client for now,
> for at least two reasons: first, direct calling URLs that have been already
> issued aren't going to stop working. They'll just gradually expire. Second,
> we are almost certainly going to want to revive this ability in the future
> for SMB-targeted "click here to call us" kind of capabilities.
> 
The call URLs will remain for the FxOS mobile app too

> Going back to #2 (and I'm tagging Romain for this), it seems to me that the
> cleanest way to handle this may be to keep calls.mozilla.com for direct
> calling, and introduce hello.firefox.com along with rooms. That way, the
> domain could be used as a very easy indicator for whether we're using rooms
> or calls. Romain: would that be okay?
The plan was to introduce the Hello name with the Hello URL in Beta.
I think it will be confusing because:
* Link receivers will have a calls.mozilla.com URL when they get invited to Firefox Hello conversations. The mozilla name is less well know than Firefox and I can see people being cautious when clicking and sharing their camera with a domain they don't recognize
* We are trying to move away from the call concept and it was the purpose of the string modification exercise we went through for Fx34

So I'd vote to keep hello.firefox.com domain for all URLs but I'll let you make that call given that it sounds like we may have an overlap issue between room and call URLs that would make that approach impossible?

Comment 30

[Mark Banner (:standard8)]

Having calls.mozilla vs hello.firefox is likely to cause more pain for development - rather than having three servers running locally, I could see us having to set up the dev version to handle both rooms and calls (check one then the other), then prod versions would have to be configured differently to check just one.

Not impossible, but brings potential differences between dev and prod.

Comment 31

[Alexis Metaireau (:alexis)]

Checking one then the other doesn't prevent the fact that we can have collisions between the two, and then you could get a call where you should get a room.

If we want to go for hello.firefox.com/{token} then the tokens themselves should be using for the routing. Adam, how does that sound?

Also, I'm not clear as to what we should do for the uplift. Without any further information, I will change the configuration to point to hello.firefox.com/#calls/{token}.

Comment 32

[Adam Roach [:abr]]

(In reply to Mark Banner (:standard8) from comment #30)
> Having calls.mozilla vs hello.firefox is likely to cause more pain for
> development - rather than having three servers running locally, I could see
> us having to set up the dev version to handle both rooms and calls (check
> one then the other), then prod versions would have to be configured
> differently to check just one.
> 
> Not impossible, but brings potential differences between dev and prod.

This is a good point. The issue I'm running in to is that attempts to make the tokens self-identifying is that the already-issued tokens don't conform to any constraints that we want to add now (for example, if we wanted to use Alexis' proposal to tell them apart, we end up with situations where already-issued call tokens start with "r").

The only thing that we're 100% certain about is that call URLs have tokens that are 11 characters long. If we bumped room tokens in size so that they're 12 characters, then we have an easy distinguisher.

(In reply to Alexis Metaireau (:alexis) from comment #31)
> Checking one then the other doesn't prevent the fact that we can have
> collisions between the two, and then you could get a call where you should
> get a room.

The server could ensure that they don't ever collide, but I'm getting the impression that the handling is separate enough that solutions along these lines won't be elegant. Would you be happy with a token-length-based differentiation?

> If we want to go for hello.firefox.com/{token} then the tokens themselves
> should be using for the routing. Adam, how does that sound?

I'm not sure what you're proposing here. GET against any of the tokens needs to return the standalone client. The server isn't going to be taking different actions based on the token for this operation.

> Also, I'm not clear as to what we should do for the uplift. Without any
> further information, I will change the configuration to point to
> hello.firefox.com/#calls/{token}.

I guess we do that for now. Mark had mentioned getting some backwards-compatible code in place that would allow for a transition. I'll ping him to figure out when that would be possible.

Comment 33

[Adam Roach [:abr]]

(In reply to Romain Testard [:RT] from comment #29)
> So I'd vote to keep hello.firefox.com domain for all URLs but I'll let you
> make that call given that it sounds like we may have an overlap issue
> between room and call URLs that would make that approach impossible?

Well, we need a distinguisher. It can be the domain name (which Mark points out makes life painful for testing). It can be something we look up in the server (which Alexis points out requires adding more constraints to the server, which probably has performance implications). We could do something like varying it based on the length of the token, but that's brittle and likely to cause problems in the future.

Considering that standalone client direct calls are a temporary construct (and therefore we don't really need to spend a ton of time making them as polished as possible), I think a good balance between the technical constraints, the desire to have things on hello.firefox.com, and the need to distinguish between the type of call would be:

* Calls are identified by tokens of the form https://hello.firefox.com/c/{token}
* Rooms are identified by tokens of the form https://hello.firefox.com/{token}

(Note that I didn't accidentally leave out an /r/ here -- the rooms are just a bare token, of the format that Romain ultimately wants).

RT: Is that something you could go along with?

Comment 34

[Romain Testard [:RT]]

Great idea !

Comment 35

[alainez]

+1

Comment 36

[Randell Jesup [:jesup] (needinfo me)]

Jumping in with a drive-by comment:

To summarize about #:

Remove it. Burn it with fire.  IMHO

If it's supposed to be a parameter for the server, it should be ?call={hash} or /call/{hash}, depending (I'd think ?call={hash} is more appropriate).  This is how URIs work (says the last person who significantly touched Firefox's URL parsing ;-) ).  If it's a parameter solely for the app, it can be ?call= (as current, via window.location or whatever) OR (better) you can have the server send content generated with that call= parameter (i.e. feed it to the app in the contents of the loaded page, not via the window.location).  That might not be wanted on the server side in order to be able to serve a static page, perhaps, in which case ?call= (or ?room=) and grabbing the param from window.location/etc will work (ugly, but works).

As mentioned in other bugs, pasting a new call URL with .../#call/{hash} causes the browser to assume that it's a position within the *same* document, and not load the new URI (it just decides that anchor/sub-resource can't be found).  You have to hit Reload after return when pasting it, or open a new tab to paste it into.  This can be confusing even to a developer until they look closely at the URL (and in fact most users will think they're calling the new URL, and are actually calling the old URL (as did I)).

If we're trying to hide the {hash} from the server.... it's true that the fragment-identifier is not (supposed to) be sent to the server.  However, that hash must be used at some point (over an https connection to some server, unless it's used to somehow enable a p2p direct serverless connection - interesting idea, but not Hello/Loop), and as mentioned we fetch it from the server (on the generating end; the server wouldn't know the IP of the person clicking the link - but some server would know if they then hit call).

If there's a valid reason to hide that info from the server, we should discuss it and alternatives.  The hash value will be in the local history in any case.

Comment 37

[Rémy Hubscher (:natim)]

FWIW the loop-client is a HTML5 app only. The loop-client server doesn't need to get the hash.

Comment 38

[Rémy Hubscher (:natim)]

Also with `react-router` you get the `componentWillReceiveProps()` call on a hash modification so that you can update your state.

Comment 39

[Randell Jesup [:jesup] (needinfo me)]

(In reply to Rémy Hubscher (:natim) from comment #37)
> FWIW the loop-client is a HTML5 app only. The loop-client server doesn't
> need to get the hash.

Right, but #{params} causes real problems since the browser will not reload the document on a paste/return (though perhaps it IS available in location - if so, maybe it's ok if the application can reliably get the last-pasted version - perhaps it's just a client bug where it looks up the {hash} at load time, instead of click time.

Comment 40

[Randell Jesup [:jesup] (needinfo me)]

(In reply to Rémy Hubscher (:natim) from comment #38)
> Also with `react-router` you get the `componentWillReceiveProps()` call on a
> hash modification so that you can update your state.

If so, perhaps it's not an issue then (and if this is reliable across all link-clicking browsers which for now means FF/Chrome/Opera)

Comment 41

[Rémy Hubscher (:natim)]

The last comment is out of scope for this bug.

As decided in Comments 33 and 34 , we will stick with this two URLs for the standalone client:

 * Calls are identified by tokens of the form https://hello.firefox.com/c/{token}
 * Rooms are identified by tokens of the form https://hello.firefox.com/{token}

Comment 42

[Rémy Hubscher (:natim)]

The client is already ready to handle both the old and new format. So we can move foward on this.

Comment 43

[James Bonacci [:jbonacci]]

FYI: Loop-Server 0.12.5 is now out in Stage and Prod