[Rizzo]

First of all I think that the JSON-RPC API is one of the greatest XBMC additions of the last couple of years. It allows developers to access and control (almost) all of XBMC goodies. A lot of great applications and tools exist thanks to JSON-RPC. Even web developers can use the power of JSON-RPC in their web sites, but there is unfortunately one limitation: cross-domain requests aren’t possible.

I know that this has nothing to do with the JSON-RPC API, but everything with libmicrohttpd web server that XBMC uses. To bypass cross-domain requests web developers have to use cumbersome work-around like proxies and iframe solutions. Although it is probably a libmicrohttpd issue, but yet I want to make the following feature suggestion:

Enable CORS (cross-origin resource sharing) and/or JSONP to make cross-domain requests possible. More information about CORS and JSONP can be found at:

http://enable-cors.org/
http://en.wikipedia.org/wiki/JSONP

[da-anda]

would be a nice addition, but I'd probably not expose JSON_RPC to the world. Although things have been made a bit safer (only file access to defined shares) there could still be security issues, so be warned.

[Rizzo]

I agree that JSON RPC shouldn't be exposed to the world. I was more thinking of the ability to turn it on like you can turn on the web server. By turning on I mean to configure it so that only the web server you want can access it. And that's exactly what CORS meant to do.

[Suven]

+1

I don't really see what makes it dangerous to activate COR for XBMCs JSON-RPC. It is completly accesable via GET and TCP.

If you were visiting a 'bad' site which tries to read/delete/modify your library your XBMC had to be running in that very moment + the site would need to guess XBMCs IP and know that you are using it anyway.
I also do not see why somebody should put effort in stealing this data. What would the attacker gain?

From my understanding same-origin exists to protect the user from a SITE B which tries to read contents of Site A. For example reading the contents of a bank-accounts dashboard when the user is logged in in it. But that always requires site B to know about the URL of site A, which is easy in Web, but hard in wild networks.

The header Access-Control-Allow-Origin: could also be set to something like 192.168.1.* (where the first 3 octets are fetched from xbmcs own IP). For me, that would be enough.

[topfs2]

Not saying it isn't a valid idea, just wondering why you'd need this?

You want to access json rpc (which exist on device B) on device A? So you have a webserver on A and access the data on B? I guess same device but different port would also be a usecase?

[Rizzo]

It has been a while when I ran into this issue. As far as I can remember I tried to let my Web Server (Device A) get data from XBMC's Web Server (Device B). I used jQuery, Ajax and PHP. I'm not that sure anymore so please don't shoot me , but it guess it was working fine when my web server and XBMC ran on the same device with different ports. The trouble occurred, i think, when I separated them and let them run on different devices with different IP addresses.

Eventually I solved it the other way round. I put a HTML page with Jquery on the XBMC Web Server and let it transfer XBMC data to my web server when my web server calls the HTML page (the iFrame solution). Of course I had to allow my Web Server to accept calls from XBMC by setting the Access-Control-Allow-Origin with the IP address of XBMC in the header. Unfortunately this isn't the best or easiest way to accomplish it, hence my cross-domain feature request.

[Suven]

Not saying it isn't a valid idea, just wondering why you'd need this?

You want to access json rpc (which exist on device B) on device A? So you have a webserver on A and access the data on B? I guess same device but different port would also be a usecase?

For me it is really fast and easy to hack some JS into a HTML-File. This could also be easily shared with different people. A webserver on device A is not needed. Just a browser.

That is why I would like to have this feature. For me it is much easier to do a POST-Request via Ajax then from JAVA, PHP or Ruby. That may only be me, but as the received data is JSON this seems quite obvious.

[jfcarroll]

Heh... I was just on IRC asking for this. It just requires a header to be set on the response to an "OPTIONS" call

[topfs2]

Not saying it isn't a valid idea, just wondering why you'd need this?

You want to access json rpc (which exist on device B) on device A? So you have a webserver on A and access the data on B? I guess same device but different port would also be a usecase?

For me it is really fast and easy to hack some JS into a HTML-File. This could also be easily shared with different people. A webserver on device A is not needed. Just a browser.

That is why I would like to have this feature. For me it is much easier to do a POST-Request via Ajax then from JAVA, PHP or Ruby. That may only be me, but as the received data is JSON this seems quite obvious.

Hmm, if that works then it seems like a valid use case. I thought open html on file didn't allow http access at all? no matter if its CORS or not, could be wrong on that though

@jfcarrol, yeah its not much to add afaik. If you want that would be lovely

[jfcarroll]

Already started. It's not as trivial as I indicated since it needs the right response headers in the right requests and there's more than one. I was thinking of making it an advanced option?

As far as the use-case goes, I was looking for it because I want to host an angularjs based app to control my xbmc somewhere besides XBMC itself (including the details of what's in the library/images/fanart/etc). But then when you want make a selection "play" you need to issue a json-rpc request to a machine that's not hosting the app. Browser security prevents this unless the secondary host has the correct headers set.

That requires CORS or JSONP (I'm doing CORS because I've been able to track down how - if someone thinks JSONP is a better solution then let me know and point me to what it entails - thanks).

[Montellese]

That requires CORS or JSONP (I'm doing CORS because I've been able to track down how - if someone thinks JSONP is a better solution then let me know and point me to what it entails - thanks).

Or Websockets (and you even get notifications on top) but obviously that's more involved.
If you work on adding this I wouldn't bother with JSONP as CORS is the more advanced and more secure solution. But I'd at least add an expert level setting (disabled by default) to Settings -> Services -> Webserver with a description of the advantage and the security risks it comes with.

[topfs2]

Agree with Montellese, if we can get CORS running we don't need JSONP.

Just as a reference, this is how JSONP works.
Basically you take the response you would otherwise send as json and put in a application/javascript file, were you call a callback with the given response.
So the response is { "result": "foo" } with JSONP you'd produce callback({ "result": "foo" });
Generally JSONP servers accept a param callback=foo which tells the server to do foo({ "result": "foo" }); instead.

EDIT: Do we need to make it a setting? Doesn't most of the bigger web servers enable it by default? Its a w3c sanctioned thing so afaik the security is fine?

[da-anda]

don't think we need a setting for it - any other tool can directly call JSONrpc without CORS or JSONp, it's only browsers that have the same-origin policy and need that workaround.

[topfs2]

And you could even do --disable-web-security on chrome and it will skip the CORS stuff, so feels unecessary for us as server to have an option.

[jfcarroll]

That's funny (how JSONP works) because I was thinking about a workaround in the app that would issue a jsonrpc request by building a <script> tag with angularjs except it appears you can't do JSON-RPC requests with a GET anymore.

No setting makes it easier so that's fine with me.