[ovirt-devel] CORS enabled for oVirt REST API

Tue Jan 20 15:30:44 UTC 2015

Einav, Juan, Vojtech, and I are all +1 for enabling CORS to
a configurable set of restricted domains.

Any objections?

----- Original Message -----
> From: "Vojtech Szocs" <vszocs at redhat.com>
> To: "Einav Cohen" <ecohen at redhat.com>
> Cc: "Greg Sheremeta" <gshereme at redhat.com>, "Juan Hernández" <jhernand at redhat.com>, "Jenny Kang"
> <jennykang95 at gmail.com>, devel at ovirt.org, "Alon Bar-Lev" <alonbl at redhat.com>, "Alexander Wels" <awels at redhat.com>,
> "Barak Azulay" <bazulay at redhat.com>, "Itamar Heim" <iheim at redhat.com>
> Sent: Tuesday, January 20, 2015 10:07:12 AM
> Subject: Re: [ovirt-devel] CORS enabled for oVirt REST API
> 
> Hi, sorry for late response, my comments below.
> 
> 
> ----- Original Message -----
> > From: "Einav Cohen" <ecohen at redhat.com>
> > To: "Greg Sheremeta" <gshereme at redhat.com>
> > Cc: "Juan Hernández" <jhernand at redhat.com>, "Jenny Kang"
> > <jennykang95 at gmail.com>, devel at ovirt.org, "Alon Bar-Lev"
> > <alonbl at redhat.com>, "Vojtech Szocs" <vszocs at redhat.com>, "Alexander Wels"
> > <awels at redhat.com>, "Barak Azulay"
> > <bazulay at redhat.com>, "Itamar Heim" <iheim at redhat.com>
> > Sent: Tuesday, December 23, 2014 9:36:02 PM
> > Subject: Re: [ovirt-devel] CORS enabled for oVirt REST API
> > 
> > > ----- 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.
> 
> Juan, I've looked at http://gerrit.ovirt.org/#/c/36367 and I think it's
> a good starting point. Can't we just write some ServletContextListener
> to initialize CORSFilter with regard to allowed source origins? For example,
> read some Engine config option like "CORSAllowedSourceOrigins" and update
> CORSFilter's "cors.allowed.origins" param?
> 
> Aside from setting up CORSFilter's allowed source origins, I don't see
> any other work needed to put CORSFilter into use for Engine REST API.
> 
> > > >
> > > > 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.
> 
> Trying to put Engine and custom webapp on same origin, just for the webapp
> to talk to REST, is much more complicated and per-custom-webapp solution.
> "Engine supporting CORS" approach sounds much more natural, especially
> since REST API is the official HTTP interface to work with Engine.
> 
> > > >
> > > >
> > > 
> > > 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.*
> 
> Indeed. Before oVirtJS, web browsers were not considered as typical
> clients of REST API. Since Same-Origin Policy applies to web browsers,
> and since oVirtJS (primarily) supports browser as runtime environment,
> REST API itself should simply acknowledge this and adapt properly.
> 
> CORS seems like a natural solution here.
> 
> > > 
> > > 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.
> 
> Right. JavaScript webapp using oVirtJS might not even need its own
> server-side; it can use oVirtJS to do all the stuff it needs to do.
> 
> The core issue is not how the webapp is deployed, it's about how
> oVirtJS talks with Engine. XHR being subject to SOP, REST API should
> simply support CORS.
> 
> > > 
> > > 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.]
> 
> From custom webapp standpoint, oVirtJS can be treated simply as
> a dependency, hosted as a static resource, just like jQuery etc.
> We could publish oVirtJS as web package to Bower etc. similar to
> other JavaScript libraries and frameworks, to make it easier for
> developers to consume within their own builds.
> 
> Hosting oVirtJS through Engine is possible (since we're planning
> to build oVirtJS as part of building the whole Engine project).
> 
> > 
> > - 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.
> 
> If the client webapp is hosted on http://my-webapp/ and Engine
> is hosted on http://engine-host/ then even if oVirtJS is served
> from Engine, Same-Origin Policy will prevent it to talk with
> Engine, because the client webapp's source origin is different.
> 
> > 
> > - 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.
> 
> Exactly! This is a known limitation in UI plugins.
> 
> If UI plugin's HTML page (host page and/or custom content page)
> is loaded from external server, Same-Origin Policy will prevent
> it from talking with REST API. This is one of reasons why we
> developed server-side Engine infra to host static UI plugin files,
> because serving these files via Engine will put them on Engine
> origin.
> 
> All in all, I think we just need CORS as a proper solution to
> web browser (custom webapp, external UI plugin etc.) trying to
> talk with REST API.
> 
> > 
> > > 
> > > --
> > > Greg Sheremeta
> > > Red Hat, Inc.
> > > Sr. Software Engineer, RHEV
> > > Cell: 919-807-1086
> > > gshereme at redhat.com
> > > 
> > 
> 