Signed Tokens in HLS URL Segment QueryStrings
I am using the premium version of JW Player v7.4.3.
I have successfully setup the player and my server-side code to do HLS streaming by serving m3u8 files and ts segment files via an Amazon Cloudfront Private Content distribution. In order for this to work, I have implemented Cloudfront Signed Cookies. While this works in Safari/iOS, this approach doesn't currently work in Chrome due to Bug #1185 that will be fixed in v7.5 by adding the withCredentials property.
The downside to using cookies for authentication is that a small minority of our clients block cookies by default. We do have instructions to show them how to properly enable cookies just for our streaming domain, but this obviously isn't a user-friendly approach.
A more reliable approach would be for all Cloudfront m3u8/ts requests to have the signed tokens added to the querystring, thus avoiding cookies all together. However, adding the signed url tokens to every single *.ts segment url within the *.m3u8 file would make a VERY large file (we typically stream programs >60 minutes with many segments) and would require a lot of extra back-end work to dynamically generate m3u8 files with dynamic signed tokens.
Is there any way in the HTML5 player to automatically append signed tokens (specified in javascript) to the querystring of all outbound streaming requests? It could be something along the lines of a property called "appendCredentials" or perhaps a version of the new "withCredentials" that would allow one to specify querystring instead of cookies.
The format of actual segment requests would be something like:
http://www.example.com/path/segment_[number].ts?[SignedTokenString]
(where [SignedTokenString] is what would be specified dynamically in javascript)
Assuming there currently isn't a way I can accomplish this in javascript, are there any plans to add this feature in the future?
I believe this would provide a lot of value to anyone using CDNs that support signed tokens in the URL (and would be more reliable than cookie based approaches).
Thanks.
