Le 20/02/2014 18:15, Adam Roach a écrit :
> The "version" allows us to transition between schemes in the future,
> if we need to change the properties of the URL -- it allows us to
> unambiguously change the format of the {token} [2]. For example, if we
> decide to re-key the HMAC, we can increase the version number. The
> same goes if we decide to add fields, encode them differently, or even
> go to a completely different design (such as a sparse key into a
> database table).
Right! If I get this right, this is to be able to have an URL generated
at a time /t1/ still be valid at /t2/, where /t2/ - /t1/ <= token duration.

That's useful when a) on a transition period and b) if we're planning to
have such URLs not temporary (e.g. without expiration).

My assumption was that these URLs would always be temporary, and in this
case we probably want to shut down the node once <token max duration> is
reached.

That's interesting, because I had something in mind that I haven't made
explicit: because the token server returns nodes to use for the users, I
was planning on using this in order to avoid charging the load
balancers. e.g. something like this (Bob wants to be called):

1. Temp URL is generated by the server for Bob. This URL is tied to a
node, e.g. https://node42.loop.services.mozilla.com/call/{token}
2. Bob gives this URL to Alice in order to be called
3. Alice clicks on the link and the node know what's the format of the
token because /node42/ runs only this version of the service.

As long as the version of the service is valid, node42 is up, and when
this is not valid anymore we can ditch it.

However, this approach doesn't work well in the case we want these
temporary URLs to be persistant (the b. case).

This all boils down to: do we want to support such "persistent" URLs ?
If yes, then what you're proposing (versioning the token) is useful. If
not, then I think we can avoid doing so.

— Alexis
_______________________________________________
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Reply via email to