CORS enabled for oVirt REST API
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
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.
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:
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@redhat.com
----- Original Message ----- From: "Greg Sheremeta" <gshereme@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:
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@redhat.com
Hi, sorry for late response, my comments below. ----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Greg Sheremeta" <gshereme@redhat.com> Cc: "Juan Hernández" <jhernand@redhat.com>, "Jenny Kang" <jennykang95@gmail.com>, devel@ovirt.org, "Alon Bar-Lev" <alonbl@redhat.com>, "Vojtech Szocs" <vszocs@redhat.com>, "Alexander Wels" <awels@redhat.com>, "Barak Azulay" <bazulay@redhat.com>, "Itamar Heim" <iheim@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@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:
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@redhat.com
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@redhat.com> To: "Einav Cohen" <ecohen@redhat.com> Cc: "Greg Sheremeta" <gshereme@redhat.com>, "Juan Hernández" <jhernand@redhat.com>, "Jenny Kang" <jennykang95@gmail.com>, devel@ovirt.org, "Alon Bar-Lev" <alonbl@redhat.com>, "Alexander Wels" <awels@redhat.com>, "Barak Azulay" <bazulay@redhat.com>, "Itamar Heim" <iheim@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@redhat.com> To: "Greg Sheremeta" <gshereme@redhat.com> Cc: "Juan Hernández" <jhernand@redhat.com>, "Jenny Kang" <jennykang95@gmail.com>, devel@ovirt.org, "Alon Bar-Lev" <alonbl@redhat.com>, "Vojtech Szocs" <vszocs@redhat.com>, "Alexander Wels" <awels@redhat.com>, "Barak Azulay" <bazulay@redhat.com>, "Itamar Heim" <iheim@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@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:
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@redhat.com
No objections, patch looks great and works. Moving on. Thanks all :) Greg ----- Original Message -----
From: "Greg Sheremeta" <gshereme@redhat.com> To: devel@ovirt.org Cc: "Juan Hernández" <jhernand@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@redhat.com> To: "Einav Cohen" <ecohen@redhat.com> Cc: "Greg Sheremeta" <gshereme@redhat.com>, "Juan Hernández" <jhernand@redhat.com>, "Jenny Kang" <jennykang95@gmail.com>, devel@ovirt.org, "Alon Bar-Lev" <alonbl@redhat.com>, "Alexander Wels" <awels@redhat.com>, "Barak Azulay" <bazulay@redhat.com>, "Itamar Heim" <iheim@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@redhat.com> To: "Greg Sheremeta" <gshereme@redhat.com> Cc: "Juan Hernández" <jhernand@redhat.com>, "Jenny Kang" <jennykang95@gmail.com>, devel@ovirt.org, "Alon Bar-Lev" <alonbl@redhat.com>, "Vojtech Szocs" <vszocs@redhat.com>, "Alexander Wels" <awels@redhat.com>, "Barak Azulay" <bazulay@redhat.com>, "Itamar Heim" <iheim@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@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:
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@redhat.com
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
This is great, thanks guys! Vojtech ----- Original Message -----
From: "Greg Sheremeta" <gshereme@redhat.com> To: devel@ovirt.org Cc: "Juan Hernández" <jhernand@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@redhat.com> To: devel@ovirt.org Cc: "Juan Hernández" <jhernand@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@redhat.com> To: "Einav Cohen" <ecohen@redhat.com> Cc: "Greg Sheremeta" <gshereme@redhat.com>, "Juan Hernández" <jhernand@redhat.com>, "Jenny Kang" <jennykang95@gmail.com>, devel@ovirt.org, "Alon Bar-Lev" <alonbl@redhat.com>, "Alexander Wels" <awels@redhat.com>, "Barak Azulay" <bazulay@redhat.com>, "Itamar Heim" <iheim@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@redhat.com> To: "Greg Sheremeta" <gshereme@redhat.com> Cc: "Juan Hernández" <jhernand@redhat.com>, "Jenny Kang" <jennykang95@gmail.com>, devel@ovirt.org, "Alon Bar-Lev" <alonbl@redhat.com>, "Vojtech Szocs" <vszocs@redhat.com>, "Alexander Wels" <awels@redhat.com>, "Barak Azulay" <bazulay@redhat.com>, "Itamar Heim" <iheim@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@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:
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@redhat.com
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
participants (5)
-
Einav Cohen -
Greg Sheremeta -
Jenny Kang -
Juan Hernández -
Vojtech Szocs