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.
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!
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.
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?
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." :-)
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.
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.
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.
Summary: [Server][Share url] Token could not be part of the URL to share → [Server] POST /call-url should return the token inside a "callToken" property.
(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.
Created attachment 8453112 [details] [review] Link to github PR
Attachment #8453112 - Flags: review?(alexis+bugs)
docs: https://github.com/mozilla-services/docs/commit/e00b99f9ccd948e8fc5ce62afe0c13a6f6ad1eb0 code: https://github.com/mozilla-services/loop-server/commit/43688a11062b30e1a664413f473a85f49f642d0b
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Attachment #8453112 - Flags: review?(alexis+bugs) → review+
OK. Verified in code and docs.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.