Richard Jones <r1chardj0...@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
pgpbntQlgOsos.pgp
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
