VID-10: Tokenisation Support

Issue Information

Issue Type: New Feature
Priority: Major
Status: Closed

Reported By:
Ben Tasker
Assigned To:
Ben Tasker
Project: (VID)
Resolution: Cannot Reproduce (2019-04-15 13:03:46)
Target version: v0.14,
Components: Embed Code ,

Created: 2019-04-15 12:08:07
Time Spent Working

At startup, the player should make a call out to a path in order to authenticate and receive a token to allow playback of the video being embedded.

Initially this endpoint will just return a static value, as the aim is simply to make sure the embed code cached in the wild has support for it before even considering enabling tokens in production.

To receive the token, the player should place a request to and include the following params in the query string

- vidpath Path of the video to be played
- ref The referring page

The token server will respond with a JSON encapsulated object containing the following attributes

- status (boolean) - is auth granted?
- token (string) - the token string
- exp (unsigned int) - Expiry epoch for the token, 0 if no expiry

The embed code then needs to append token and exp to the manifest path the player will use as query string arguments t and e

Issue Links

Toggle State Changes



commit 9d199e2e3b4041ba96dd0d09b723af1241051247
Author: Ben Tasker <btasker@<Domain Hidden>>
Date: Mon Apr 15 12:37:56 2019 +0100

Commit Message: VID-10 Implemented token acquisition support in the embed javascript

When the player is first instantiated, it places a request to /token_endpoint, providing the referrer and the video to be played

If a token is not acquired, then the player is not loaded, and an image is instead written into the page to report that the video could not be played.

If a token is acquired, then the token (and specified expiry time) are appended to the video URL as a query string

resources/embed/embed.js | 67 ++++++++++++++++++++++++++++++++++++++++++-
resources/embed/failed.png | Bin 0 -> 6268 bytes
2 files changed, 65 insertions(+), 2 deletions(-)

View Commit | View Changes
This has been tested using the test player, and appears to work as expected. The URL's observed in Developer tools are:

- (the player page)
- (request out to the token endpoint)
- (request for the master manifest)
- (request out to Piwik when playback starts - VID-6)

The changes strip the token from the URL before it's submitted to Piwik so that users with different tokens (which will eventually be all of them) do not appear as different playback URLs in analytics.

The query string to /token_endpoint is a bit long for my liking. 99% of the time vidpath is going to start with so I'm inclined to say that should just be stripped out. The backend (once implemented) can then check whether the path starts with http or not if support is later added for playing back from other domains.

commit af217137798df41fda9a64ab45e305eeccfc8168
Author: Ben Tasker <btasker@<Domain Hidden>>
Date: Mon Apr 15 12:47:35 2019 +0100

Commit Message: VID-10 Trim the domain from the beggining of vidpath if it's my videos domain

resources/embed/embed.js | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

View Commit | View Changes
Startup time doesn't seem to be adversely affected by the inclusion of the tokenisation stuff, with cache disabled, Dev Tools shows a load time of 921ms on the test player page. Getting the token took just 41ms (although it'll obviously take a little longer when that ceases to be a static response)
For reference, the token endpoint has currently been implemented in Nginx config with the following location block
location = /token_endpoint {
        return 200 '{"status": true, "token": "OqBvCvqg49QJgGKDHFbdNccB", "exp": 0}';

The token there is just a string generated with gen_passwd and is otherwise meaningless.

Marking this as complete, as the embed code now supports the retrieving and appending of a token.

Seems logical that a separate issue should be raised for implementing the token generation (with yet another for the edge handling of tokens). Both of those will likely come much later though.
btasker changed status from 'Open' to 'Resolved'
btasker added 'Cannot Reproduce' to resolution
btasker changed status from 'Resolved' to 'Closed'