Open Stack

On 12 September 2014 07:50, Adam Young <ayoung at redhat.com> wrote:

>  On 09/11/2014 03:15 AM, Richard Jones wrote:
>
>  [This is Horizon-related but affects every service in OpenStack, hence no
> filter in the subject]
>
>  I would like for OpenStack to support browser-based Javascript API
> clients.
> Currently this is not possible because of cross-origin resource blocking in
> Javascript clients - that is, given some Javascript hosted on
> "https://horizon.company.com/" you cannot, for example, call from that
> Javascript code to an API on "https://apis.company.com:5000/v2.0/tokens"
> to
> authenticate with Keystone.
>
>  There are three solutions to this problem:
>
>  1. the Horizon solution, in which those APIs are proxied by a very thick
>    layer of additional Python API, plus some Python view code with some
>    Javascript on the top only calling the Horizon view code,
> 2. add CORS support to all the OpenStack APIs though a new WSGI middleware
>    (for example oslo.middleware.cors) and configured into each of the API
>    services individually since they all exist on different "origin"
>    host:port combinations, or
> 3. a new web service that proxies all the APIs and serves the static
>    Javascript (etc) content from the one origin (host). APIs are then
> served
>    from new URL roots "/name/" where the name is from the serviceCatalog
>    entry. Static content can be served from "/static/". The serviceCatalog
> from
>    keystone will be rewritten on the fly to point the API publicURLs at the
>    new service. Requests are no longer cross-origin.
>
>  I have implemented options 2 and 3 as an exercise to see how horrid each
> one
>  is.
>
>
> I don't think these are mutually exclusive.  I can see people wanting
> either in some deployments.
>

I think I agree :)


== CORS Middleware ==
>
>  For those wanting a bit of background, I have written up a spec for oslo
> that
> talks about how this could work: https://review.openstack.org/#/c/119485/
>
>  The middleware option results in a reasonably nice bit of middleware.
> It's
> short and relatively easy to test. The big problem with it comes in
> configuring it in all the APIs. The configuration for the middleware takes
> two forms:
>
>  1. hooking oslo.middleware.cors into the WSGI pipeline (there's more than
>    one in each API),
> 2. adding the CORS configuration itself for the middleware in the API's
> main
>    configuration file (eg. keystone.conf or nova.conf).
>
>  So for each service, that's two configuration files *and* the kicker is
> that
> the paste configuration file is non-trivially different in almost every
> case.
>
> This is one reason I thought that it should be done by auth_token
> middleware.  The other reason is that I don't think we want to blanket
> accept CORS from everywhere, but instead we should do so based on the
> service catalog.
>

It's very important to understand that CORS is entirely advisory. Nothing
is required to pay any attention to it. Modern browsers do, of course, but
in the absence of a browser initiating a CORS conversation (by sending an
Origin header) the CORS middleware should do nothing whatsoever. A GET
request will still return the body of data requested - it's just that the
browser will see the CORS header and block an application from seeing that
data. Security through access controls, XSS protections, etc. must be
handled by other mechanisms.


For a POC deployment, for a small company, all-in-one,  what you are doing
> shouild be fine, but then, if you were running all of your services that
> way, in one web server, you wouldn't need CORS either.
>

This isn't possible in the current OpenStack model - all the APIs run on
different ports, which count as different origins for cross-origin resource
issues (origin is defined as {protocol, host, port}).


So, lets have these two approaches work in parallel.  THe proxy will get
> things goint while we work out the CORS approach.
>

I will look at submitting my middleware for inclusion anyway then.


     Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140912/72d0cad2/attachment.html>