Roku Developer Program

[mosten]

"bbefilms" wrote:
SSL access now works on screen components such as roVideoScreen but serverside SSL client verification for them is broken.

[update] Can one of the Roku devs indicate whether this will be fixed in the next firmware update?

I've asked about the same thing previously, I don't think it's even on the roadmap.

[bbefilms]

"mosten" wrote:
I've asked about the same thing previously, I don't think it's even on the roadmap.

SSL *is* finally working for streams with the build pushed out late last week, which is great, but they haven't made the client certificate available for SSL from these components. From the component documentation for roUrlTransfer:

1) Add the Roku CA certificate to the web server’s certificate authorities keychain. The Roku CA certificate is available in the SDK distribution package, in certs/cacert.pem
2) Configure your web server to reject any connection that does not have a valid client certificate.

Doing the above would block a streams request to the same server.

If you're serving streams from another computer/3rd party and are not bothered about client verification, SSL works fine for both feeds and streams. It seems insane to me though, that client-side verification wasn't included in last week's build.

[RokuKevin]

Note that arbitrary client certificates do not work with the SDK. Only Roku signed client certificates generated by the firmware work.

Roku signed client certificates should work with this build. They provide the ability for your web server to authenticate that its connecting to a Roku box.

The client certificates are unique on each box. The client certificates are signed by a Roku CA, and the Roku CA signing cert is included in the SDK.

If you would like to authenticate that your web server is connecting to a Roku box, you must configure your web server to accept client certs signed by the Roku CA cert.

If you would like to authenticate that your web server is connecting to your particular application on the box, you should also configure your web server to accept connections only from requests with an x-roku-reserved-dev-id that matches the devid from your application pkg.

--Kevin

[bbefilms]

"RokuKevin" wrote:
Roku signed client certificates should work with this build.

They don't - the Roku client certificate isn't being made available by ssl connections made by screen objects such as roVideoScreen, they only work with feed connections made by roUrlTransfer. Please can you confirm this.

[RokuKevin]

I'll look into this.

--Kevin

[bbefilms]

"RokuKevin" wrote:
I'll look into this.

Thanks Kevin.

[RokuKevin]

Confirmed problem. The current firmware release only sends the client cert using the roUrlTransfer object.

It does not send the client cert on other objects that implement the ifHttpAgent interface (including roVideoScreen).

I will push to include a fix for this in the next firmware release.

Thanks for pointing this out bbefilms.

--Kevin

[RokuKevin]

The AddHeader() method works in the ifHttpAgent interface... So you could add standard Basic Authentication to access of your video streams.

Assume you've setup "video" as an roVideoScreen and specified all the parameters to play a video. Now you want to add basic authentication to it. (You're already using SSL, so no one can snoop the passwd in the authorization header that is sent in the clear). You can now turn Basic Authentication on your server, test with curl, and then change your brightscript app like so:

video = CreateObject("roVideoScreen")

REM setup videoclip associative array to play your video
REM setup SSL on the video object

ba = CreateObject("roByteArray")
ba.FromAsciiString("yourUserName:yourPassword")
video.AddHeader("Authorization", "Basic " + ba.ToBase64String())

video.SetContent(videoclip)
video.show()

--Kevin

[TommyTheKid]

OK, this just burned me too. I need to be able to use something like "video.SetUsernameAndPassword(user, passwd)" and apparently thats not there. I just had the webserver folks recompile/reconfigure to use DIGEST auth, because it seemed like BASIC auth is purposely disabled. Now I am starting to get the hint that I need to use basic auth again 😉

What is the ETA on this firmware?


Tommy

[TommyTheKid]

*EDIT*
My original problem was a typo in the AddHeader, I have since found a worse problem: viewtopic.php?f=34&t=26200

Tommy