[x3d-public] Cross origin policies - An example

[Vincent Marchetti]

And the takeaway for X3D authors and providers is: If you want your content to be freely available and easily usable from your own server you should implement the CORS protocol on your server, at least for the X3D files. This will allow others to display your model in a Cobweb browser (and other  on their own web page.

I believe in walking the walk, so here's a file from my server which is available for direct viewing in another page's Cobweb browser, because the spri.kshell.com server allows CORS:

http://spri.kshell.com/xt/shape/2jzpf4bf9d18/shape_2334393636.x3d  [it's a gear!]

This issue popped up because we were trying to load local X3D files into our Cobweb browsers. The cross-origin policy and CORS protocol seems to be pretty clearly defined for pages and content retrieved under http and https schema. I don't see a clear definition of what the policy should be or is for pages and models with file:// schema URLs. On the one hand, it's convenient to just read files directly from your filesystem. On the other hand, if the browser allows XmlHttpRequests to the file:// schema, it's giving the javascript author read-access to your hard drive. That's why I think we see differences among browsers as to how they handle it. My own preferred solution is to just run the suggested Python SimpleHTTPServer on a high obscure port number (8999, but now it's not obscure anymore), and load my Cobweb or X3DOM page and x3d models from that.

> On Apr 14, 2016, at 9:38 AM, Vincent Marchetti <vmarchetti at ameritech.net> wrote:
> 
> This is an example of how involved the issues of cross origin policy and CORS (cross-origin resource sharing) can get; specifically from X3D and the Cobweb browser. Since this example seems to involve server downtimes, I should point out that my description of events is from the 7 am- 8 am EDT (1100-1200 UTC) on April 14, 2016 time frame.
> 
> I started out wanting to write a quick email to the X3D WG about an application of the Extrusion node, whose spec we've been trying to clarify in the past few weeks (months?). There is an example model labeled Currencies on the Cobweb page I was going to highlight, that uses Extrusion node as part of line graph  of currency exchange rate vs time.
> 
> I went to the cobweb page at http://titania.create3000.de/cobweb/ . The example I want is "Currencies", the third choice from the top on Page 1 of the examples list. The model loads, but the plot was flat at zero, and the user-interaction didn't work; normally you can click on a currency and the plot would spring to life.
> 
> Here's my recreation of what's going on, and what went wrong:
> 1. The X3D model is hosted on github, https://github.com/create3000/cobweb/blob/master/cobweb.js/examples/currencies/currencies.x3d
> A  secure web browser will not allow javascript on a http://titania.create3000.de page to make an XHR (XmlHttpRequest) to content on https://github.com unless the github server explicitly allowed it through the CORS mechanism. Apparently, Github as a policy will not do this. The workaround is that the URL for this example is actually:
> https://rawgit.com/create3000/cobweb/master/cobweb.js/examples/currencies/currencies.x3d
> 
> https://rawgit.com is a proxy, it retrieves the underlying file from github, puts appropriate HTTP headers on the content, and also implements the CORS protocol so that my web browser is willing to retrieve it by XHR.
> 
> So far, so good; the model loads.
> 
> 2. But then, in order to display up-to-date currency exchange rates, there is javascript in the currencies.x3d model to retrieve data from http://www.ecb.europa.eu (specifically an XML file at http://www.ecb.europa.eu/stats/eurofxref/eurofxref-hist-90d.xml )
> Once again, Chrome would not allow retrieving from this server through XHR.
> 
> And again, a proxy comes to the rescue, in this case the proxy is https://crossorigin.me, and the actual URL called by the currencies.x3d script is :
> https://crossorigin.me/http://www.ecb.europa.eu/stats/eurofxref/eurofxref-hist-90d.xml
> 
> which gets the XML file by alternative method, and delivers it to the X3D script with CORS permission. However, the crossorigin.me server is down, so no currency exchange data gets to the X3D script, and it's lifeless.
> 
> So the tricky part to get understand is that both the currencies.x3d file on Github and the xml data on www.europa.eu are intended to be publically available, so there's no backdoor sneaking of private content here; and in fact files are directly retrieved if you just enter their URLs into the brower address bar. It's just that the web browser won't retrieve them through XmlHttpRequest.
> 
> Vincent Marchetti
> vmarchetti at ameritech.net
> 
> 
> 
> 
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org

Vincent Marchetti
vmarchetti at ameritech.net