9:46 a.m.
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
1:09 p.m.
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.
--
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
1:40 p.m.
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
gshereme(a)redhat.com
2:36 p.m.
----- Original Message -----
From: "Greg Sheremeta" <gshereme(a)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.
>
> 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
gshereme(a)redhat.com
9:07 a.m.
Hi, sorry for late response, my comments below.
----- Original Message -----
From: "Einav Cohen" <ecohen(a)redhat.com>
To: "Greg Sheremeta" <gshereme(a)redhat.com>
Cc: "Juan Hernández" <jhernand(a)redhat.com>, "Jenny Kang"
<jennykang95(a)gmail.com>, devel(a)ovirt.org, "Alon Bar-Lev"
<alonbl(a)redhat.com>, "Vojtech Szocs" <vszocs(a)redhat.com>,
"Alexander Wels" <awels(a)redhat.com>, "Barak Azulay"
<bazulay(a)redhat.com>, "Itamar Heim" <iheim(a)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(a)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(a)redhat.com
>
9:30 a.m.
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>
To: "Einav Cohen" <ecohen(a)redhat.com>
Cc: "Greg Sheremeta" <gshereme(a)redhat.com>, "Juan Hernández"
<jhernand(a)redhat.com>, "Jenny Kang"
<jennykang95(a)gmail.com>, devel(a)ovirt.org, "Alon Bar-Lev"
<alonbl(a)redhat.com>, "Alexander Wels" <awels(a)redhat.com>,
"Barak Azulay" <bazulay(a)redhat.com>, "Itamar Heim"
<iheim(a)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(a)redhat.com>
> To: "Greg Sheremeta" <gshereme(a)redhat.com>
> Cc: "Juan Hernández" <jhernand(a)redhat.com>, "Jenny Kang"
> <jennykang95(a)gmail.com>, devel(a)ovirt.org, "Alon Bar-Lev"
> <alonbl(a)redhat.com>, "Vojtech Szocs" <vszocs(a)redhat.com>,
"Alexander Wels"
> <awels(a)redhat.com>, "Barak Azulay"
> <bazulay(a)redhat.com>, "Itamar Heim" <iheim(a)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(a)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(a)redhat.com
> >
>
9:47 a.m.
No objections, patch looks great and works. Moving on.
Thanks all :)
Greg
----- Original Message -----
From: "Greg Sheremeta" <gshereme(a)redhat.com>
To: devel(a)ovirt.org
Cc: "Juan Hernández" <jhernand(a)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(a)redhat.com>
> To: "Einav Cohen" <ecohen(a)redhat.com>
> Cc: "Greg Sheremeta" <gshereme(a)redhat.com>, "Juan
Hernández"
> <jhernand(a)redhat.com>, "Jenny Kang"
> <jennykang95(a)gmail.com>, devel(a)ovirt.org, "Alon Bar-Lev"
> <alonbl(a)redhat.com>, "Alexander Wels" <awels(a)redhat.com>,
> "Barak Azulay" <bazulay(a)redhat.com>, "Itamar Heim"
<iheim(a)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(a)redhat.com>
> > To: "Greg Sheremeta" <gshereme(a)redhat.com>
> > Cc: "Juan Hernández" <jhernand(a)redhat.com>, "Jenny
Kang"
> > <jennykang95(a)gmail.com>, devel(a)ovirt.org, "Alon Bar-Lev"
> > <alonbl(a)redhat.com>, "Vojtech Szocs" <vszocs(a)redhat.com>,
"Alexander
> > Wels"
> > <awels(a)redhat.com>, "Barak Azulay"
> > <bazulay(a)redhat.com>, "Itamar Heim" <iheim(a)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(a)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(a)redhat.com
> > >
> >
>
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
11:23 a.m.
This is great, thanks guys!
Vojtech
----- Original Message -----
From: "Greg Sheremeta" <gshereme(a)redhat.com>
To: devel(a)ovirt.org
Cc: "Juan Hernández" <jhernand(a)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(a)redhat.com>
> To: devel(a)ovirt.org
> Cc: "Juan Hernández" <jhernand(a)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(a)redhat.com>
> > To: "Einav Cohen" <ecohen(a)redhat.com>
> > Cc: "Greg Sheremeta" <gshereme(a)redhat.com>, "Juan
Hernández"
> > <jhernand(a)redhat.com>, "Jenny Kang"
> > <jennykang95(a)gmail.com>, devel(a)ovirt.org, "Alon Bar-Lev"
> > <alonbl(a)redhat.com>, "Alexander Wels"
<awels(a)redhat.com>,
> > "Barak Azulay" <bazulay(a)redhat.com>, "Itamar Heim"
<iheim(a)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(a)redhat.com>
> > > To: "Greg Sheremeta" <gshereme(a)redhat.com>
> > > Cc: "Juan Hernández" <jhernand(a)redhat.com>, "Jenny
Kang"
> > > <jennykang95(a)gmail.com>, devel(a)ovirt.org, "Alon Bar-Lev"
> > > <alonbl(a)redhat.com>, "Vojtech Szocs"
<vszocs(a)redhat.com>, "Alexander
> > > Wels"
> > > <awels(a)redhat.com>, "Barak Azulay"
> > > <bazulay(a)redhat.com>, "Itamar Heim"
<iheim(a)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(a)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(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
3365
days inactive
3407
days old
7 comments
5 participants
participants (5)
-
Einav Cohen -
Greg Sheremeta -
Jenny Kang -
Juan Hernández -
Vojtech Szocs