Roku Developer Program

[bosborne]

So I noticed that roVideoScreen supports the ifHttpAgent, which allows you to call the function EnableCookies().

I'm trying to get a Cookie-based token authorization system working. It works where the initial request for a stream includes a secure Token. The response from the CDN server sets a couple of Cookie headers that must be re-sent back on each subsequent request (for sub-playlists, key files, and media files).

Is this not possible? I have called EnableCookies() on my roVideoScreen object. In the while event loop, I try printing out the Cookies but the result is always an empty array. This seems to be tricker than a normal roUrlTransfer object, where there is just one single request. I have Cookies working well with that. Since the roVideoScreen object is making several HTTP requests, I wonder if that is screwing things up?

[RokuChris]

That sounds very much like something I've run into before. I got it to work by requesting the manifest with a roURLTransfer first, extracting the cookies from that response and assigning them to the roVideoScreen before starting playback.

[bosborne]

Interesting. I'm actually wondering if the problem here is that the CDN is not setting an expiration date on the Cookie, which I've found will cause the Roku Cookie cache to ignore the Cookie (which sort of makes sense, since a set-cookie w/o an expiration is essentially a session cookie one time cookie). So I wonder if this would actually work if a non-zero value was set by the CDN.

Anyway, I was indeed able to set the Cookie headers manually. I couldn't get it working with SetCookies, but I was able to just construct the Cookie header myself and add it, and now it works.

One thing I noticed is that Roku appends any query string parameters that were placed on the first request along with every other request. So requests for the sub playlist, key files, and media segments all get the query strings appended. It doesn't appear to matter, as I can get video playback working either way.

Is this intentional by Roku? What is the reason?

[RokuMarkn]

"bosborne" wrote:

One thing I noticed is that Roku appends any query string parameters that were placed on the first request along with every other request. So requests for the sub playlist, key files, and media segments all get the query strings appended. It doesn't appear to matter, as I can get video playback working either way.

Is this intentional by Roku? What is the reason?

Yes this is intentional. It is the way the HLS player works in iOS. Some providers depend on this iOS behavior, so we copied it, although it's not clear that it's strictly correct according to the spec.

--Mark

[bosborne]

It would be great if that could be disabled.

The problem is that Akamai only allows the main manifest and .key files to be served over HTTPS. Everything else is over HTTP. So now the plain HTTP requests for the media segments and sub playlists have that token in them and anyone can snoop it and get the token. If they are smart enough to take that token and the parent playlist URL, they can load the stream into VLC or something and copy it down.

I have an expiration set on the token, but I have to set that to several hours assuming that someone may watch the stream that long.