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.]
--
Greg Sheremeta
Red Hat, Inc.
Sr. Software Engineer, RHEV
Cell: 919-807-1086
gsher...@redhat.com
_______________________________________________
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
