[ovirt-devel] CORS enabled for oVirt REST API

Mon Feb 2 17:23:06 UTC 2015

This is great, thanks guys!

Vojtech

----- Original Message -----
> From: "Greg Sheremeta" <gshereme at redhat.com>
> To: devel at ovirt.org
> Cc: "Juan Hernández" <jhernand at redhat.com>
> Sent: Wednesday, January 28, 2015 4:47:01 PM
> Subject: Re: [ovirt-devel] CORS enabled for oVirt REST API
> 
> No objections, patch looks great and works. Moving on.
> 
> Thanks all :)
> 
> Greg
> 
> ----- Original Message -----
> > From: "Greg Sheremeta" <gshereme at redhat.com>
> > To: devel at ovirt.org
> > Cc: "Juan Hernández" <jhernand at redhat.com>
> > Sent: Tuesday, January 20, 2015 10:30:44 AM
> > Subject: Re: [ovirt-devel] CORS enabled for oVirt REST API
> > 
> > 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
> > > > > 
> > > > 
> > > 
> > _______________________________________________
> > Devel mailing list
> > Devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel