Re: [ovirt-devel] CORS enabled for oVirt REST API

From: "Greg Sheremeta" <gshereme(a)redhat.com&gt; To: devel(a)ovirt.org Cc: "Juan Hernández" <jhernand(a)redhat.com&gt; 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(a)redhat.com&gt; > To: devel(a)ovirt.org > Cc: "Juan Hernández" <jhernand(a)redhat.com&gt; > 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(a)redhat.com&gt; > > To: "Einav Cohen" <ecohen(a)redhat.com&gt; > > Cc: "Greg Sheremeta" <gshereme(a)redhat.com&gt;, "Juan Hernández" > > <jhernand(a)redhat.com&gt;, "Jenny Kang" > > <jennykang95(a)gmail.com&gt;, devel(a)ovirt.org, "Alon Bar-Lev" > > <alonbl(a)redhat.com&gt;, "Alexander Wels" <awels(a)redhat.com&gt;, > > "Barak Azulay" <bazulay(a)redhat.com&gt;, "Itamar Heim" <iheim(a)redhat.com&gt; > > 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(a)redhat.com&gt; > > > To: "Greg Sheremeta" <gshereme(a)redhat.com&gt; > > > Cc: "Juan Hernández" <jhernand(a)redhat.com&gt;, "Jenny Kang" > > > <jennykang95(a)gmail.com&gt;, devel(a)ovirt.org, "Alon Bar-Lev" > > > <alonbl(a)redhat.com&gt;, "Vojtech Szocs" <vszocs(a)redhat.com&gt;, "Alexander > > > Wels" > > > <awels(a)redhat.com&gt;, "Barak Azulay" > > > <bazulay(a)redhat.com&gt;, "Itamar Heim" <iheim(a)redhat.com&gt; > > > 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(a)redhat.com&gt; > > > > 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(a)redhat.com > > > > > > > > > > _______________________________________________ > Devel mailing list > Devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel _______________________________________________ Devel mailing list Devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/devel