<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 09/11/2014 03:15 AM, Richard Jones
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAHrZfZDiYMpZ7hyVuRoAfyQ2ry0cBbv_JZSFtTy6N8Qq94aOWA@mail.gmail.com"
      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 moz-do-not-send="true"
                href="https://horizon.company.com/">https://horizon.company.com/</a>"
              you cannot, for example, call from that</div>
            <div>Javascript code to an API on "<a moz-do-not-send="true"
                href="https://apis.company.com:5000/v2.0/tokens">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>
    I don't think these are mutually exclusive.  I can see people
    wanting either in some deployments.<br>
    <br>
    <br>
    <br>
    <blockquote
cite="mid:CAHrZfZDiYMpZ7hyVuRoAfyQ2ry0cBbv_JZSFtTy6N8Qq94aOWA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div><br>
          </div>
          <div><br>
          </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
                moz-do-not-send="true"
                href="https://review.openstack.org/#/c/119485/">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>
    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>
    <br>
    This is for the non-trivial deployment case like MOC:<br>
    <br>
    <a class="moz-txt-link-freetext" href="http://www.bu.edu/hic/projects/massachusetts-open-cloud/">http://www.bu.edu/hic/projects/massachusetts-open-cloud/</a><br>
    <br>
    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.<br>
    <br>
    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>
    <br>
    So, lets have these two approaches work in parallel.  THe proxy will
    get things goint while we work out the CORS approach.<br>
    <br>
    <blockquote
cite="mid:CAHrZfZDiYMpZ7hyVuRoAfyQ2ry0cBbv_JZSFtTy6N8Qq94aOWA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div><br>
          </div>
          <div>That's a lot of work, and confusing for deployers.
            Configuration management</div>
          <div>tools can ease *some* of this burden (the *.conf files)
            but those paste files</div>
          <div>are a bit of a mess :(</div>
          <div><br>
          </div>
          <div>Once the config change is in place, it works (well,
            except for an issue I ran</div>
          <div>into relating to oslo.middleware.sizelimit which I'll go
            into in another</div>
          <div>place).</div>
          <div><br>
          </div>
          <div>The implementation hasn't been pushed up for review as
            I'm not sure it should</div>
          <div>be. I can do this if people wish me to.</div>
          <div><br>
          </div>
          <div><br>
          </div>
          <div>== New Single-Point API Service ==</div>
          <div><br>
          </div>
          <div>Actually, this is not horrid in any way - unless that
            publicURL rewriting</div>
          <div>gives you the heebie-jeebies.</div>
          <div><br>
          </div>
          <div>It works, and offers us some nice additional features
            like being able to host</div>
          <div>the service behind SSL without needing to get a bazillion
            certificates. And</div>
          <div>maybe load balancing. And maybe API access filtering.</div>
          <div><br>
          </div>
          <div>I note that <a moz-do-not-send="true"
              href="https://openrepose.org">https://openrepose.org</a>
            already exists to be *something* like</div>
          <div>this, but it's not *precisely* what I'm proposing. Also
            Java euwww ;)</div>
          <div><br>
          </div>
          <div><br>
          </div>
          <div>So, I propose that the idea of CORS-in-all-the-things as
            an idea be</div>
          <div>put aside as unworkable.</div>
          <div><br>
          </div>
          <div>I intend to pursue the single-point API service that I
            have described as a</div>
          <div>way of moving forward in prototyping a pure-Javascript
            OpenStack Dashboard.</div>
        </div>
        <div><br>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>