[ovirt-devel] CORS enabled for oVirt REST API

[Einav Cohen]

> ----- Original Message -----
> From: "Greg Sheremeta" <gshereme at 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:
> >
> >    http://gerrit.ovirt.org/36367
> >
> > 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 at redhat.com
>