Hi,

How can external, purely JavaScript application, running in a browser and
served from non-engine host access the oVirt REST API?

Recent SSO implementation does not provide CORS support. It can be fixed by
https://gerrit.ovirt.org/68062 .

How shall this support for external application look like?

More details are in our so far discussion with Juan bellow.

For completeness, there's already another patch providing SSO for non-GWT
applications, but deployed along with the ovirt-engine and packaged in
.war, no matter if the application itself is non-Java one.
See https://gerrit.ovirt.org/#/c/67206/ .

---------- Forwarded message ----------
From: Juan Hernández <[email protected]>
Date: Fri, Dec 9, 2016 at 2:40 PM
Subject: Re: CORSSuport
To: Marek Libra <[email protected]>


On 12/09/2016 02:26 PM, Marek Libra wrote:
> Thanks for your quick response and fast action :-)
>
> I'm working on integration of oVirt to Cockpit, ideally purely JS
> application (Cockpit's plugin) will access oVirt REST API without using
> any proxy.
> The Cockpit is running on an oVirt host.
>
> IIUC, the OAuth token is *required* to access the REST API.
>

The OAuth token isn't strictly required at the moment: the API also
supports HTTP basic authentication. The OAuth token will be required
when support for version 3 of the API and support for basic
authentication are removed. We intend to remove those two things in
version 4.2 of oVirt.

> If so, there are just two options for external javascript application
> willing to access the API:
> [1] either reuse "externaly given Bearer token'' - some oVirt web
> application served from engine node would need to provide it to the JS
> application running elsewhere
> [2] or call the /ovirt-engine/sso service to get one
>
> Regarding [1], I havn't tried it yet, but from checking the SSO filters
> in ovirt-engine, this might work since it's retrieving session based on
> token. What do you think?
>
> Regarding [2], the patch you posted would be needed.
>
> Do I miss something?
>

There is option 3: use HTTP basic authentication. But that won't work
with oVirt 4.2 or newer, so doesn't look like a reasonable thing.

I think that the only reasonable option is [2]. However, we can't (or
should not) just configure the existing CORS support to accept any
origin (CORSAllowedOrigins=*) as that isn't secure. We will probably
need to have a dynamic list of allowed origins: the list of hosts. That
would need extensive changes to the CORS filter.

So, for your experiments, you can just move the current filter so that
it can be used by the SSO application. But for real use we need to think
a bit deeper on how should CORS support work. I'd suggest that you open
this discussion to a wider audience, within your team, or in the
upstream mailing list.

> Thanks
>
> On Fri, Dec 9, 2016 at 1:53 PM, Juan Hernández <[email protected]
> <mailto:[email protected]>> wrote:
>
>     On 12/09/2016 01:38 PM, Marek Libra wrote:
>     > Hi Juan,
>     >
>     > I'm trying to set up CORS on ovirt-engine following instructions in
>     > https://gerrit.ovirt.org/#/c/36367/
>     <https://gerrit.ovirt.org/#/c/36367/> .
>     > But I can't get the 'Access-Control-Allow-Origin' to be returned.
>     >
>     > -- My ovirt-engine:
>     >
>      ovirt-engine-4.1.0-0.0.master.20161121231311.git19a0953.el7.
centos.noarch
>     >
>     > -- On engine host:
>     > # engine-config -s CORSSupport=true
>     > # engine-config -s 'CORSAllowedOrigins=*'
>     > # systemctl restart ovirt-engine
>     >
>     >
>     > -- My JS call looks like:
>     >
>     > var url = baseUrl +
>     >
>     '/sso/oauth/token?grant_type=urn:ovirt:params:oauth:grant-
type:http&scope=ovirt-app-api';
>     > $.ajax(url, {
>     >     type: 'GET',
>     >     headers: {
>     >         'Accept': 'application/json',
>     >         'Authorization': 'Basic ' + window.btoa(user + ':' + pwd),
>     >         'Content-Type': 'application/xml'
>     >     } })
>     >     .then(data => {
>     >         logDebug(`login successful: ${JSON.stringify(data)}`);
>     >         Promise.resolve(data)
>     >     })
>     >     .catch(data => {
>     >         logDebug('Ajax failed: ' + JSON.stringify(data));
>     >         return Promise.reject(data);
>     >     });
>     >
>     >
>     > -- From Chrome:
>     > Request
>     >
>     URL:https://engine.local/ovirt-engine/sso/oauth/token?
grant_type=urn:ovirt:params:oauth:grant-type:http&scope=ovirt-app-api
>     <https://engine.local/ovirt-engine/sso/oauth/token?grant_
type=urn:ovirt:params:oauth:grant-type:http&scope=ovirt-app-api>
>     > Request Method:OPTIONS
>     > Status Code:200 OK
>     > Remote Address:192.168.122.100:443 <http://192.168.122.100:443>
>     <http://192.168.122.100:443>
>     >
>     > Response Headers:
>     > HTTP/1.1 200 OK
>     > Date: Fri, 09 Dec 2016 11:56:08 GMT
>     > Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips
>     > Content-Encoding: gzip
>     > Set-Cookie: locale=en_US; path=/; HttpOnly; Max-Age=2147483647;
>     > Expires=Wed, 27-Dec-2084 15:10:15 GMT
>     > X-XSS-PROTECTION: 1; MODE=BLOCK
>     > X-CONTENT-TYPE-OPTIONS: NOSNIFF
>     > X-FRAME-OPTIONS: SAMEORIGIN
>     > Content-Type: application/json
>     > Content-Length: 116
>     > Keep-Alive: timeout=5, max=100
>     > Connection: Keep-Alive
>     >
>     > Request Headers:
>     > OPTIONS
>     >
>     /ovirt-engine/sso/oauth/token?grant_type=urn:ovirt:params:
oauth:grant-type:http&scope=ovirt-app-api
>     > HTTP/1.1
>     > Host: engine.local
>     > Connection: keep-alive
>     > Access-Control-Request-Method: GET
>     > Origin: https://192.168.122.141:9090
>     > User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64)
AppleWebKit/537.36
>     > (KHTML, like Gecko) Chrome/55.0.2883.75 Safari/537.36
>     > Access-Control-Request-Headers: authorization, content-type
>     > Accept: */*
>     > Referer:
>     https://192.168.122.141:9090/cockpit/@localhost/machines/index.html
>     <https://192.168.122.141:9090/cockpit/@localhost/machines/index.html>
>     > Accept-Encoding: gzip, deflate, sdch, br
>     > Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
>     >
>     > -- restapi.war/WEB-INF/web.xml contains CORSSupportFilter
>     configuration
>     > but
>     > -- enginesso.war/WEB-INF/web.xml doesn't
>     >
>     > How is it supposed to work, please?
>     > Is there already suggested procedure to have CORS running?
>     >
>     > Thanks,
>     > Marek
>     >
>
>     The CORS support was intended only for the API, thus it isn't
available
>     for other applications. If you want to be able to use it in the SSO
>     application, then it needs to be moved to a module where it can be
>     shared. Something like this:
>
>       core: Move CORS filter from API to utils
>       https://gerrit.ovirt.org/68062
>
>     If this is more than an experiment, then I'd suggest you take
ownership
>     of that patch.
>
>
_______________________________________________
Devel mailing list
[email protected]
http://lists.phx.ovirt.org/mailman/listinfo/devel

Reply via email to