<div dir="ltr">May be it's a bit too late, but in mid 2012 the FIWARE team developed a horizon clone 100% in Javascript. <a href="https://github.com/ging/horizon-js">https://github.com/ging/horizon-js</a><div><br></div><div>Sadly, CORS support was not even in roadmap for OpenStack, so the horizon-js project was not valid for production at that time.</div><div><br></div><div>In StackOps we developed Portal to tackle the lack of CORS support. We wanted to have 100% javascript 'plugins' or 'apps' that could be upgraded easily in a single and unified user interface. StackOps Portal also implements a proxy to all the different OpenStack (and not OpenStack) REST API services. We also wrap authentication and authorization in the proxy: the javascript plugins do not know about credentials, they are injected in the proxy/man-in-the-middle software.</div><div><br></div><div>Portal has evolved and now it's more like a 'chroot' for safe execution of javascript apps. And we use it for our own OpenStack extensions (accounting, rating, billing, monitoring, advanced network management...). </div><div><br></div><div>So maybe if you want to discuss about how to proceed in the future for a 100% javascript user interface, maybe we can talk about it in Paris.</div><div><br></div><div>Regards</div><div>Diego</div><img width="1" height="1" class="mailtrack-img" src="https://mailtrack.io/trace/mail/1fd490f07255c1cc090d56cd2b5d21b1536ba1cf.png"></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"> -- <br><span style="border-collapse:separate;font-family:Times"><span style="border-collapse:collapse;font-family:arial,sans-serif"><div align="left" style="font-size:13px"><div><font><span lang="ES" style="font-family:Arial">Diego Parrilla<br><a href="http://www.stackops.com/" title="file:///C:/Documents%20and%20Settings/carolina.capsir.per1/Application%20Data/Microsoft/Signatures/www.garrigues.com
www.garrigues.com" style="color:rgb(7,77,143)" target="_blank"><span title="file:///C:/Documents%20and%20Settings/carolina.capsir.per1/Application%20Data/Microsoft/Signatures/www.garrigues.com"></span></a></span></font><font face="Arial" style="font-family:arial,helvetica,sans-serif"><b>CEO</b><font size="1"><br></font></font><span style="border-collapse:separate;font-family:Times;font-size:medium"><span style="border-collapse:collapse;font-family:arial,sans-serif;font-size:13px"></span></span><b><font face="Arial" style="font-family:arial,helvetica,sans-serif"><a href="http://www.stackops.com/" target="_blank"><b>www.stackops.com</b></a> | </font></b><font face="Arial" style="font-family:arial,helvetica,sans-serif"><font size="1"> <a href="mailto:diego.parrilla@stackops.com" target="_blank">diego.parrilla@stackops.com</a></font></font><span style="border-collapse:separate;font-family:Times;font-size:medium"><span style="border-collapse:collapse;font-family:arial,sans-serif;font-size:13px"><font color="#004438" face="Arial"><b><b><span lang="EN-GB" style="font-size:10pt"></span></b></b></font></span></span><font face="Arial" style="font-family:arial,helvetica,sans-serif"><font size="1"> | </font></font><span style="font-family:arial,helvetica,sans-serif;font-size:x-small">+34 91 005-2164 | </span><a style="font-size:x-small;font-family:arial,helvetica,sans-serif">skype:diegoparrilla</a></div></div><div style="font-size:13px"><font color="#004438" face="Arial"><b><p><span style="border-collapse:separate;color:rgb(0,0,0);font-family:Times;font-size:medium"><span style="border-collapse:collapse;font-family:arial,sans-serif;font-size:13px"><span style="border-collapse:separate;font-family:Times;font-size:medium"><span style="border-collapse:collapse;font-family:arial,sans-serif;font-size:13px"><font color="#004438" face="Arial"><b><b><span lang="EN-GB" style="font-size:10pt"><img src="http://stackops.s3-external-3.amazonaws.com/STACKOPSLOGO-ICON.png"></span></b></b></font></span></span></span></span></p></b></font></div></span></span><div><br></div></div></div>
<br><div class="gmail_quote">On Thu, Sep 11, 2014 at 9:15 AM, Richard Jones <span dir="ltr"><<a href="mailto:r1chardj0n3s@gmail.com" target="_blank">r1chardj0n3s@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><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 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><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 href="https://openrepose.org" target="_blank">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>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>