Open Stack

Richard Jones <r1chardj0n3s at gmail.com> writes:

Hi,

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:

  https://github.com/zerovm/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:

  http://blog.yunak.eu/2013/07/24/keystone_cors/

Since I only case about Swift, another solution that I've been using is
to use swauth (or really https://github.com/zerovm/liteauth) 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:

  [filter:cors]
  allow_origins = https://static.company.com

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

http://google.com/+MartinGeisler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141015/09365b9c/attachment.pgp>