Remote ECP Comments

I would definitely like to see the Search functionality documented in the External Control Guide actually implemented in the Netflix channel. I took the code that used Search out of my 2.0 release of DVPRemote because support was not there when I shipped.

I'll second gonzotek's request for a "Clear" command to wipe out anything in text/search fields.

"fluke" wrote:
The bottom line is that support for Cross-Origin Resource Sharing would provide more flexibility in what frameworks that could be used to interface the Roku. Given that the frameworks that adopt CORS tend to also be the most multi-platform, I would hope that Roku would take the time to support it in future firmware versions.

Bump :). I'm wondering, is there any chance at all of Roku implementing CORS? I'd really like to do (for example) the following in javascript from the local network:

var appsRequest = new XMLHttpRequest();
function getApps(){
	var url = 'http://' + ROKU_IP + ':8060/query/apps';
	appsRequest.open('GET', url, true);
	appsRequest.onreadystatechange = displayApps;
	appsRequest.send();
}

function displayApps(){
	var appsXML = appsRequest.responseText;
	...
}

I've been working on getting a much-improved Remoku to a finally releasable state. In pure javascript, html and css, it can reliably scan the network for Rokus, perform the standard remote functions (including sending text), and show & launch apps, but only if the <apps> xml is pasted into a form field by hand. It'd be great to not have to place that last requirement on the user.

Re-bump. I have updated my Roku to version 2.9 (build 1553) and still am not getting any CORS support from the Roku. I think it might be possible that our request is too vague.

Currently, the Roku returns HTTP headers of:

HTTP/1.1 200 OK
Content-Length: 0
Server: Roku UPnP/1.0 MiniUPnPd/1.4

What we require is the Roku to provide HTTP headers in the form of:

HTTP/1.1 200 OK
Content-Length: 0
Server: Roku UPnP/1.0 MiniUPnPd/1.4
Access-Control-Allow-Origin: *

This will allow modern web browsers to interact with the Roku via ECMAscript (Javascript/Jscript). Otherwise, the cross-site scripting protection in the browser will block the script from getting the replies from the Roku.

"RokuKevin" wrote:
It would also enable internet sites to more easily create cross-site scripting attacks on the Roku.

--Kevin

Hi Kevin, thanks for responding.
Right now, the Roku responds to ECP commands from any address, local or remote. I have written javascript that can scan for Rokus on the local network and subsequently control them. The only thing I can't access directly (in the current firmware) is the channel list. I appreciate the need for security against scripted attacks, so if there's an alternative that would enable a pure js solution while maintaining security, I'm completely open to it.

I'm sure you may be wondering how I can pick up the Roku addresses from js. Here's what I'm doing to scan for local Roku boxes:
In my remote app, I create a hidden iframe with a src = http://w.x.y.z:8060/query/apps and initialize a boolean to false. Then I start a timer with a 750ms timeout. If/when the iframe loads, the boolean is set to true. Then, when the timeout occurs, if the variable is true, then there is probably a Roku at that address and it is added to a list of available units to control. Then the last octet variable is incremented by 1 and process repeats. Scanning through the entire last octet takes, at most, slightly more than 3 minutes, and there is a field for the user to indicate how many Rokus they own, so the script will stop looking if it finds them all. I also ask for the first three octets. On my network of two rokus, one wireless and one wired, using an iphone and chrome (both wireless) this process generally only takes 10 seconds or so.

I've thought this through a bit and obviously, a bad guy could silently scan every possible ip without prompting for any user input at all, and simply record its place in a cookie when the page is left, then pickup the scan anytime the evil page is loaded. If he made the reasonable guess that most home networks are of the 192.168 variety, and most of them have a 0, 1, or 2 for the third octet, it wouldn't take near as long as simply starting at 1.1.1.1 and working up, to detect Rokus. And once he has the address, he can then send any set of commands he'd like, since the Roku will happily process a command from any non-authenticated client.

After seeing the new SDK features, I'd planned to create a companion channel for remoku that would incorporate a simple webserver to request the channel list internally, then send it on to the remote app without restriction, which would remove my need for a CORS policy. Unfortunately, I couldn't get the web server example to run (debugger details posted here). When it's working, I have some other things planned for the companion channel as well, like serving the whole remote from it, so users could install from the channel store and then be presented with a screen on the tv like "Now browse to http://192.168.1.8:8888/ to start using Remoku".

So, at least until I can serve content from the Roku myself, I'm still stuck for a solution to my original problem, the channel list being unavailable to js. Any thoughts?

gonzotek,

How would you know the ipAddress of the Roku to send your requests to in a javascript implementation??

--Kevin

"RokuKevin" wrote:
gonzotek,

How would you know the ipAddress of the Roku to send your requests to in a javascript implementation??

--Kevin

In the case of my hosted site, user input. You can try it out for yourself, link's in my sig. I realize that auto-detection via ssdp (or any other multicast solution) is impossible in javascript. I've open sourced the code (simplified bsd) in the hopes that developers could include it in client/server apps. In those cases, the IP could be detected in the server and pre-populated into a browser based remote. This would be useful because a web app works across many devices(iphone, android, pc, kindle, and Nintendo DS are all confirmed, for example). I have a thread started in the general discussion forum with generally positive responses, despite the lack of auto-detection(which I don't see a solution to), and restrictions of the apps query. viewtopic.php?f=28&t=33676

A good idea for the apps list is to add a JSON format list, so it can be added to a script tag

Considering that Roku is still an IPv4 only device, it seems realistic to ask the user to look-up the address that is assigned to it via the Settings menu and then provide it the remote control application. Hence, lack of access to SSDP is currently is not much of an issue.

Even if Roku where to support IPv6 only networks (is IPv6 even on the Roku road-map right now?), as long as it follows the default Linux 2.6 behavior for local scope auto-assignment (RFC3513), discovering the logical location of the Roku is as easy as asking the user the last 6 characters of the MAC address. The beginning of what would be the Roku's local scope IPv6 address (fe80::20d:4b) is already known.

If SSDP does end up being needed, a short initialization program or script could write out a file containing emcascript array of discovered Roki. If the SSDP emcascript file is found by the web application, then it will use that as the default location(s) instead of prompting the user.

The bottom line is that support for Cross-Origin Resource Sharing would provide more flexibility in what frameworks that could be used to interface the Roku. Given that the frameworks that adopt CORS tend to also be the most multi-platform, I would hope that Roku would take the time to support it in future firmware versions.

It would also enable internet sites to more easily create cross-site scripting attacks on the Roku.

--Kevin