<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 12 September 2014 07:50, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><div class="h5">
<div>On 09/11/2014 03:15 AM, Richard Jones
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>[This is Horizon-related but affects every service in
OpenStack, hence no</div>
<div>filter in the subject]</div>
<div><br>
</div>
<div>
<div>I would like for OpenStack to support browser-based
Javascript API clients.</div>
<div>Currently this is not possible because of cross-origin
resource blocking in</div>
<div>Javascript clients - that is, given some Javascript
hosted on</div>
<div>"<a href="https://horizon.company.com/" target="_blank">https://horizon.company.com/</a>"
you cannot, for example, call from that</div>
<div>Javascript code to an API on "<a href="https://apis.company.com:5000/v2.0/tokens" target="_blank">https://apis.company.com:5000/v2.0/tokens</a>"
to</div>
<div>authenticate with Keystone.</div>
</div>
<div><br>
</div>
<div>There are three solutions to this problem:</div>
<div><br>
</div>
<div>1. the Horizon solution, in which those APIs are proxied
by a very thick</div>
<div> layer of additional Python API, plus some Python view
code with some</div>
<div> Javascript on the top only calling the Horizon view
code,</div>
<div>2. add CORS support to all the OpenStack APIs though a
new WSGI middleware</div>
<div> (for example oslo.middleware.cors) and configured into
each of the API</div>
<div> services individually since they all exist on
different "origin"</div>
<div> host:port combinations, or</div>
<div>3. a new web service that proxies all the APIs and serves
the static</div>
<div> Javascript (etc) content from the one origin (host).
APIs are then served</div>
<div> from new URL roots "/name/" where the name is from the
serviceCatalog</div>
<div> entry. Static content can be served from "/static/".
The serviceCatalog from</div>
<div> keystone will be rewritten on the fly to point the API
publicURLs at the</div>
<div> new service. Requests are no longer cross-origin.</div>
<div><br>
</div>
<div>I have implemented options 2 and 3 as an exercise to see
how horrid each one<br>
</div>
<div>is.</div>
</div>
</div>
</blockquote>
<br></div></div>
I don't think these are mutually exclusive. I can see people
wanting either in some deployments.</div></blockquote><div><br></div><div>I think I agree :)</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""><blockquote type="cite"><div dir="ltr"><div>
<div>== CORS Middleware ==</div>
<div><br>
</div>
<div>
<div>For those wanting a bit of background, I have written
up a spec for oslo that</div>
<div>talks about how this could work: <a href="https://review.openstack.org/#/c/119485/" target="_blank">https://review.openstack.org/#/c/119485/</a></div>
</div>
<div><br>
</div>
<div>The middleware option results in a reasonably nice bit of
middleware. It's</div>
<div>short and relatively easy to test. The big problem with
it comes in</div>
<div>configuring it in all the APIs. The configuration for the
middleware takes</div>
<div>two forms:</div>
<div><br>
</div>
<div>1. hooking oslo.middleware.cors into the WSGI pipeline
(there's more than</div>
<div> one in each API),</div>
<div>2. adding the CORS configuration itself for the
middleware in the API's main</div>
<div> configuration file (eg. keystone.conf or nova.conf).</div>
<div><br>
</div>
<div>So for each service, that's two configuration files *and*
the kicker is that</div>
<div>the paste configuration file is non-trivially different
in almost every case.</div>
</div>
</div>
</blockquote></span>
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.<br></div></blockquote><div><br></div><div>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.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">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.<br></div></blockquote><div><br></div><div>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}).</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">So, lets have these two approaches work in parallel. THe proxy will
get things goint while we work out the CORS approach.<br></div></blockquote><div><br></div><div>I will look at submitting my middleware for inclusion anyway then.</div><div><br></div><div><br></div><div> Richard</div><div><br></div></div></div></div>