> ----- Original Message ----- > From: "Greg Sheremeta" <[email protected]> > 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 > [email protected] > _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
