----- Original Message ----- From: "Greg Sheremeta" <gshereme@redhat.com> Sent: Tuesday, December 23, 2014 2:40:12 PM
On 12/23/2014 02:09 PM, Juan Hernández wrote:
On 12/22/2014 04:46 PM, Jenny Kang wrote:
Hello,
As part of my OPW project, I'm trying to build a mobile web UI for oVirt but I'm having some troubles.
I cannot access the oVirt REST API because it doesn't allow cross origin resource sharing (CORS). The only way to access the API is to host the UI on the same IP as the engine. If it is enabled then people would be able to run the mobile UI directly from the desktop without hosting it anywhere.
Do you have any suggestions on how to access oVirt REST API from another host inside the browser? Any plans on enabling CORS on the REST API?
Thank you!
Cheers Jenny
There are no plans to enable CORS at the moment, basically because nobody expressed interest on having it. Good to see that you do. Adding CORS support to the RESTAPI shouldn't be that complicated, as there are already fairly easy to use filters that can be used with little effort. For example, you could use this one:
https://github.com/ebay/cors-filter
To add it to the RESTAPI you need to create a JBoss module for it, add it as a dependency, and activate it in the RESTAPI web.xml deployment descriptor. Should be something like this:
Note that this is just an example. Adding this to the engine should be done carefully. In particular we can't just enable CORS for every site, as that would open the door for many attacks. If we add CORS it should be only for a configurable restricted set of origins. It would be nice if you can work in this direction.
Once you have this CORS support you should be able to use the RESTAPI from your application. I'm attaching a simple example.
The alternative to CORS is to deploy your application in a web server that also acts as a reverse proxy for the engine. That way your web application and the proxied engine will have the same origin.
I think this is an important lesson learned for oVirt.js:
*Without CORS support, the only way for someone to use ovirt.js on the client-side is to 1. serve the ovirt.js application from the engine, or 2. use a proxy servlet/server as Juan described.*
Off the top of my head, both of those solutions will be unappealing to a client-side developer who may not even be using a server-side technology for their application.
Jenny and I discussed this with Alon on IRC today. He didn't seem thrilled about CORS, but I won't speak for him (he is cc'd).
I'd also like to mention that Itamar described the multiple-server scenario as being desirable. He spoke about being able to do exactly what Jenny is trying to do -- serve the ovirt.js application from a server that is not the engine. [Itamar, please correct me if I've misrepresented you.]
- I recall the same thing: we should not assume that a client app is using ovirt.js as a resource served from the engine server. - we have a very similar issue today with the UI-plugins: what happens when a UI-Plugin host page is served from an external server, and is attempting to perform REST-API requests? I am not sure if we have a real-life use-case for this today and/or if we have already put any thought in how to resolve this; in any case, a similar solution should be applied for the ovirt.js problem as well as the ui-plugins problem.
-- Greg Sheremeta Red Hat, Inc. Sr. Software Engineer, RHEV Cell: 919-807-1086 gshereme@redhat.com