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.
== 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.
This is for the non-trivial deployment case like MOC:
http://www.bu.edu/hic/projects/massachusetts-open-cloud/
Where one "Horizon" instance is going to have to talk to multiple,
non-trusted instances for each of the services. CORS should only be
acceptable between services in the same service catalog. Yes, I realize
this is not security enforcment, it is just one step in the strategy.
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.
So, lets have these two approaches work in parallel. THe proxy will get
things goint while we work out the CORS approach.
That's a lot of work, and confusing for deployers. Configuration
management
tools can ease *some* of this burden (the *.conf files) but those
paste files
are a bit of a mess :(
Once the config change is in place, it works (well, except for an
issue I ran
into relating to oslo.middleware.sizelimit which I'll go into in another
place).
The implementation hasn't been pushed up for review as I'm not sure it
should
be. I can do this if people wish me to.
== 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 note that https://openrepose.org already exists to be *something* like
this, but it's not *precisely* what I'm proposing. Also Java euwww ;)
So, I propose that the idea of CORS-in-all-the-things as an idea be
put aside as unworkable.
I intend to pursue the single-point API service that I have described as a
way of moving forward in prototyping a pure-Javascript OpenStack
Dashboard.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
