1035980 - [Server] POST /call-url should return the token inside a "callToken" property.

Status: VERIFIED FIXED

(Hello (Loop) :: Server, defect)

Description

[Borja Salguero [:borjasalguero]]

Currently we are extracting the Token from the URL, however in the future, if we use a URL shortener, we could have a lot of issues here.

In order to avoid this, we could return 'token' as a separate param when requesting a 'callUrl' to the Server.

Comment 1

[Borja Salguero [:borjasalguero]]

Hi Tarek,
This is the bug I mentioned during our weekly update, related with including the 'token' as a param in the returned object from the server when requesting a call url. Could you take a look? Thanks!

Comment 2

[Alexis Metaireau (:alexis)]

Borja, I'm not sure to understand what your fears are here. In case we use some url shortener, we will probably not do that directly in the loop server, so the client will know the token when it's generated.

Comment 3

[Rémy Hubscher (:natim)]

There is no problem of having the token inside the URL.

Also URLs are already shortened since Bug 1026426

If you want even shorter URLs, you will use an URL shortener which will do a 302 from your shortened URL to the one we generate.

In any case this will be a problem because the token will always be part of the URL at some point.

Where you are true is that in case of URL shortener you will need to handle the multiple HTTP 302 that may happen in order to get the token.

Also even if we give you back the token from the API how this will help the link-clicker that only get the URL?

Comment 4

[Alexis Metaireau (:alexis)]

I suspect Rémy wanted to say "In any case this will *not* be a problem because the token will always be part of the URL at some point." :-)

Comment 5

[Tarek Ziadé (:tarek)]

Borja, as Rémy said, whatever the URL ends being, there will be a 302 redirection, so:

=> http://call.services.mozilla.com/xxx will return a 302 with a longer URL, that the client will follow.

This is not something the client has to worry about as long as it respects the HTTP protocol and follow redirections.

Comment 6

[Alexis Metaireau (:alexis)]

Tarek, sorry to contradict you but "http://call.services.mozilla.com/xxx" isn't actually returning a 302. It's where the static assets are being deployed.

The flow is as follows:

1.  Alice client generates a new call-url and gets back a link;
1a. Alice's client can store the call-url token locally at this stage to reuse it later if needed;
2.  Alice gives her link to Bob so he can call her;
3.  Bob clicks on the link and arrives either a. directly to the server serving static assets or b. on the loop server which does a 302 to the correct location.

I don't understand why we're talking about doing 302s on the call.s.m.c domain, and what's the problem with call-url tokens we're discussing here.

Comment 7

[Alexis Metaireau (:alexis)]

After a discussion with Borja, it make sense to add a `callToken` parameter to the response, so that if the format change in the future, the client don't need to parse it.

I've updated the title of the bug to reflect that.

Comment 8

[Tarek Ziadé (:tarek)]

    (In reply to Alexis Metaireau (:alexis) from comment #6)
    > Tarek, sorry to contradict you but "http://call.services.mozilla.com/xxx"
    > isn't actually returning a 302. It's where the static assets are being
    > deployed.

    I messed up my example I guess, I was talking about the callUrl url, so:


    => calling the <callUrl> will return a 302 with a longer URL, that the client will follow.

    This is not something the client has to worry about as long as it respects the HTTP protocol and follow redirections.

Comment 9

[Rémy Hubscher (:natim)]

Attachment: Link to github PR

Comment 10

[Alexis Metaireau (:alexis)]

docs: https://github.com/mozilla-services/docs/commit/e00b99f9ccd948e8fc5ce62afe0c13a6f6ad1eb0
code: https://github.com/mozilla-services/loop-server/commit/43688a11062b30e1a664413f473a85f49f642d0b

Comment 11

[James Bonacci [:jbonacci]]

OK. Verified in code and docs.