The proposed way is: - use CORS filter for enginesso.war (https://gerrit.ovirt.org/68062) - at host installation, add the host to CORSAllowedOrigins - on engine host: # engine-config -s 'CORSAllowedOrigins=[host IPs]'
So if Cockpit's plugin accesses the oVirt REST API, CORS will work.' On Fri, Dec 9, 2016 at 3:42 PM, Marek Libra <[email protected]> wrote: > 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-t > ype: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_ty > pe=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
