HTTP Authentication in roVideoPlayer - how?

Can you add an HTTP 'Authorization' Header using ifHttpAgent.AddHeader(), as described in RFC 2617, section 2, Basic Authentication Scheme, and in Wikipedia, Basic Access Authentication?

"belltown" wrote:
Can you add an HTTP 'Authorization' Header using ifHttpAgent.AddHeader(),

I suspect that'll work, but is this "the canonical way" of doing it on Roku?
It seems to me the user:password@URL above is working but not sure - roVideoPlayerEvent is new to me.

"EnTerr" wrote:

"belltown" wrote:
Can you add an HTTP 'Authorization' Header using ifHttpAgent.AddHeader(),

I suspect that'll work, but is this "the canonical way" of doing it on Roku?
It seems to me the user:password@URL above is working but not sure - roVideoPlayerEvent is new to me.

The Authorization header is the standard HTTP way of implementing Basic Authorization, ideally over an encrypted connection. (It's not specific to roVideoPlayer, but should work the same for any component that supports the ifHttpAgent interface.) Some user agents support putting the credentials in the url; some don't; some used to support it, but have since deprecated the practice. I don't have my Roku with me to confirm, but I would guess that in your case the Roku is extracting the credentials from the url and adding the Authorization header to the GET/POST request, which would be equivalent to you having added the header yourself. I haven't seen any documentation from Roku to the effect that this behavior is supported -- but you know what Roku documentation is like. Hopefully, someone from Roku could comment on whether putting credentials in the url is "supported".

"EnTerr" wrote:
I tried that in CustomVideoPlayer example and it slightly changed the error log but not sure is it because it cannot parse such URL or because of error down the road.

I'd guess the former. The @ symbol is probably triggering the "invalid track path/url" error. You could test it by requesting the same URL via roUrlTransfer to see if you get the -3 (CURLE_URL_MALFORMAT) response.

"TheEndless" wrote:
I'd guess the former. The @ symbol is probably triggering the "invalid track path/url" error. You could test it by requesting the same URL via roUrlTransfer to see if you get the -3 (CURLE_URL_MALFORMAT) response.

Testing with roUrlTransfer:

• user:pwd@ included in URL did not cause errors


• but did not help either (i.e. did not help w/authentication)


• instead i had to .addHeader("Authorization", "Basic <censored base64>") and it worked.

With roVideoPlayer though, not so. Seems:

• user:pwd@ causes silent error (no specific msg but does not seem to reach to 401 even)


• .addHeader() did not help

Quite puzzling.

That's puzzling indeed.

It's quite possible that there's a bug in ifHttpAgent or whatever code is responsible for adding the Authorization header for the roVideoPlayer. (I've already found one bug in ifHttpAgent, although that was to do with cookie handling, but that doesn't preclude there from being other bugs in code that isn't used frequently.) Several years ago there was a bug reported in the way ifHttpAgent handles authentication.

Or it could be that the server you are communicating with is not handling the Authorization header in the way expected, or requires additional stuff to happen (cookies, redirects, etc.), although I don't see why it would work for roUrlTransfer but not for roVideoPlayer, if they both implement ifHttpAgent.

Or your code may not be doing what you think it's doing.

In any case, it might be worth using tcpdump and/or Wireshark to examine the network traffic between the Roku and the video server. That's helped me a lot in the past with these types of issues, for example sometimes you get a 401 error which might be all that is returned to your BS code, but in the trace there might be a corresponding html page returned with a very descriptive error message that your code never saw. If you can compare the traces that worked (roUrlTransfer, or retrieving the video via curl or a web browser) with those that didn't, it might help narrow down the problem. I'm assuming the video in question is not on a server you control. If so, you could try setting up your own server configured to serve videos using Basic Authorization, access the video from your Roku and examine your computer's network interface using Wireshark. If this doesn't work then likely it's a Roku problem; if it does work, you can compare that working trace with the traces taken between the Roku and the problem video server.

I just found this post in which RokuKevin states that Basic Authentication should work with any of the screen components by adding the headers yourself: http://forums.roku.com/viewtopic.php?p=354231&sid=087cbf53485e7a1985b892afc4e8c3da#p241364

Here's an example of how to do it: http://forums.roku.com/viewtopic.php?p=159066&sid=c468fce74f1bc0d8057769c51a03533a#p159384

Another thing to try: Do you get the same result from roVideoScreen as you do from roVideoPlayer?

"belltown" wrote:
Here's an example of how to do it: viewtopic.php?p=159066&sid=c468fce74f1bc0d8057769c51a03533a#p159384

Another thing to try: Do you get the same result from roVideoScreen as you do from roVideoPlayer?

Thank you for your attention and detailed answers/ideas, belltown!
Yes, i was pretty much doing what RokuKevin suggested in that post - with one difference, i was on roVideoPlayer and not roVideoScreen. For the sake of testing, i changed the code, this time with roVideoScreen - both with and without the .addHeader("Authorization", ...) i see exactly the same in debug log:

------ Running ------
roVideoScreenEvent 11, 0: HTTP status 401
roVideoScreenEvent 11, 0: Unspecified or invalid track path/url.
roVideoScreenEvent 9,-5: {"MediaFormat":{}}
roVideoScreenEvent 1, 0: 
roVideoScreenEvent 9,-5: The format is not supported or the media is corrupt.{"MeasuredBitrate":1990,"StreamBitrate":0,"Url":"http://192.168.1.23/h264.raw"}

Now if i completely drop my pants (disable server-side User Access Control), i get this:

------ Running ------
roVideoScreenEvent 20, 0: Stream started.{"IsUnderrun":false,"MeasuredBitrate":1990,"StreamBitrate":0,"Url":"http://192.168.1.23/h264.raw"}
roVideoScreenEvent 11, 0: Content contains no playable tracks.
roVideoScreenEvent 9,-5: {"MediaFormat":{}}
roVideoScreenEvent 1, 0: 

Tests kinda, sorta seem to hint setting "Authorization" header - while working with roUrlTransfer - does not seem to work anymore with roVideoPlayer/roVideoScreen.

I realize i am in a screwy place because (a) i cannot get clean log due to 2nd issue, the particular stream format seems unsupported (or do i have to add some magic param <> "mp4"?) and (b) server-side is a streaming appliance i cannot tap into (network sniffing is not completely out of the question but much frown on my side).

PS. ditto with roVideoPlayer: regardless of "Authorization" header, i get exactly the same log with
roVideoPlayerEvent 11, 0: HTTP status 401
In contrast, when pant-less, i see logged
roVideoPlayerEvent 20, 0: Stream started. {"IsUnderrun":false, "MeasuredBitrate":1990, "StreamBitrate":0, "Url":"http://192.168.1.23/h264.raw"}

I'd make sure the video is actually playable on the Roku first (before going further down the authentication path).

Try downloading it using curl, e.g.

curl -v -u username:password -o test.mp4 http://192.168.1.23/h264.raw

Then examine the downloaded file with mediainfo (use http://www.videohelp.com/tools/MediaInfoXP if you're on Windows and want the malware-free version!)

If it plays directly on your computer and it looks like it contains Roku-supported codecs, then try playing the downloaded file, served from your computer, on your Roku (without authentication).

Your post mentioned a ".raw" extension, rather than ".mp4", so it's likely not a Roku-supported container format. Post the mediainfo output and I'm sure someone will be able to tell you whether it's supported or not.

Are you specifying a StreamFormat?