Bug 1181530 - [RFE] Add CORS support to the RESTAPI
Summary: [RFE] Add CORS support to the RESTAPI
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: RestAPI
Version: ---
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ovirt-3.6.0-rc
: 3.6.0
Assignee: Juan Hernández
QA Contact: Jiri Belka
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-01-13 10:49 UTC by Juan Hernández
Modified: 2016-03-11 07:19 UTC (History)
9 users (show)

Fixed In Version: ovirt-engine-3.6.0-0.0.master.20150412172306.git55ba764
Doc Type: Enhancement
Doc Text:
Feature: CORS support for the RESTAPI. Reason: Currently it isn't possible to send requests to the RESTAPI from JavaScripts applications that have been downloaded from a host other than the one where the RESTAPI itself runs. This is due to the SOP (same origin policy) imposed by browsers for security reasons. This affects any JavaScript application that wants to use the RESTAPI, and in particular it affects applications based on oVirt.js, unless they are deployed to the same host where the engine itself is running. Result: To allow JavaScript applications to call the RESTAPI in a controlled fashion CORS (Cross Origin Resource Sharing) support has been added to the RESTAPI. This support is controlled by two parameters: 1. CORSSupport. This controls if the support is enabled or disabled. Possible values are "true" and "false". When the value is "false" the support is disabled and the behaviour of the RESTAPI is exactly the same that before introducing this support. The defaujlt value is "false", for backwards compatibility. If the value is "true" then not all CORS requests will be accepted, only those from origins specified in the CORSAllowedOrigins parameter. 2. CORSAllowedOrigins. This is a comma separated list of the origins that are accepted. The default is an empty string, which means that CORS support is effectively disabled. To actually enable it some value has to be specified. The value can also be "*", in this case all origins are accepted, but this isn't recommended. In practice, to use this support, the administrator will need to know what is the origin of the applications that are allowed to access the RESTAPI. For example, if a trusted application is available in "https://my.app" then the following configuration should be applied: # engine-config -s CORSSupport=true # engine-config -s CORSAllowedOrigins=https://my.app # systemctl ovirt-engine restart Then the CORS support will be enabled.
Clone Of:
Environment:
Last Closed: 2016-03-11 07:19:59 UTC
oVirt Team: Infra
Embargoed:
rule-engine: ovirt-3.6.0+
ylavi: planning_ack+
rule-engine: devel_ack+
pstehlik: testing_ack+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1186751 0 unspecified CLOSED New package request: ebay-cors-filter 2021-02-22 00:41:40 UTC
oVirt gerrit 36367 0 master MERGED restapi: Add CORS filter Never
oVirt gerrit 37367 0 None None None Never
oVirt gerrit 37370 0 None NEW packaging: Use CORS filter provided by its own package Never

Internal Links: 1186751

Description Juan Hernández 2015-01-13 10:49:53 UTC
Currently the RESTAPI doesn't respond to CORS (Cross Origin Request Sharing, see [1]) request sent by browsers. It should do so, and allow requests from a restricted and configurable set of origins.

[1] http://www.w3.org/TR/cors/

Comment 1 Sandro Bonazzola 2015-01-28 13:40:39 UTC
https://fedorahosted.org/ovirt/ticket/287 and requested it in Fedora on bug #1186751

Comment 2 Jiri Belka 2016-03-01 15:19:18 UTC
ok rhevm-backend-3.6.3.4-0.1.el6.noarch

1. all origins enabled OK

CORSSupport: true version: general
CORSAllowedOrigins: * version: general

2. specific url as origin OK

CORSSupport: true version: general
CORSAllowedOrigins: http://jb-rhevm36.example.com:8765 version: general

3. default (false + same origin having https) OK

CORSSupport: false version: general
CORSAllowedOrigins:  version: general

4. default (false + origin not having https) FALSE

this should fail, thus OK


Note You need to log in before you can comment on or make changes to this bug.