[ovirt-devel] CORS enabled for oVirt REST API

Tue Jan 20 15:07:12 UTC 2015

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
> > 
> 