Richard Jones <> writes:


I'm working on the ZeroVM project at Rackspace and as part of that I'm
writing a JavaScript based file manager for Swift which I've called
Swift Browser:

When writing this, I of course ran in to exactly the problems you
describe below.

> 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

This was the solution I picked first and it was not difficult to get
working. I used this middleware:

Since I only case about Swift, another solution that I've been using is
to use swauth (or really which lets
you authenticate to Swift directly. There are thus only a single origin
to consider and the same-origin problems disappear.

> 3. a new web service that proxies all the APIs and serves the static
>    Javascript (etc) content from the one origin (host).

That sounds like another good alternative. I'm not sure familiar with
how people normally deploy Swift, but I would imagine that people setup
some proxying anyway to rewrite the URLs to a nicer format.

> I have implemented options 2 and 3 as an exercise to see how horrid
> each one is.
> == CORS Middleware ==
> 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),

If this became a standard part of OpenStack, could one imagine that the
default WSGI pipelines would already contain the CORS middleware?

> 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.

I'm unsure why it would have to be different for each service? Would the
services not be configured mostly the same, as in:

  allow_origins =

> == New Single-Point API Service ==
> Actually, this is not horrid in any way - unless that publicURL
> rewriting gives you the heebie-jeebies.
> It works, and offers us some nice additional features like being able
> to host the service behind SSL without needing to get a bazillion
> certificates. And maybe load balancing. And maybe API access
> filtering.

I like this option for the flexibility it gives you.

Martin Geisler

Attachment: pgpbntQlgOsos.pgp
Description: PGP signature

OpenStack-dev mailing list

Reply via email to