[Openstack] Using Nova APIs from Javascript: possible?

Nick Lothian nick.lothian at gmail.com
Mon Apr 30 11:56:43 UTC 2012


I'm testing out the existing  JStack code at the moment.

It's been enjoyable process so far.
On Apr 30, 2012 7:30 PM, "javier cerviño" <jcervino at dit.upm.es> wrote:

> Hi Adrian,
>
> I've just seen you submitted your Swift-based CORS implementation to
> Gerrit. Would you mind if we do the same for Nova, Keystone and Glance? On
> the other hand, it could be better to wait for its approval because we
> could apply changes proposed by the reviewers to the rest of components.
>
> We've just started to implement Glance API support in jStack, and then I
> will started with Swift. Is anybody out there who wants to join this
> challenge? You're welcome to propose changes, write code, and so on. The
> idea is to develop full OpenStack API in JavaScript, so that community
> could start working with it.
>
> Cheers,
> Javier.
>
> 2012/4/27 javier cerviño <jcervino at dit.upm.es>
>
>> Hi!
>>
>> We have just published the code of the portal in Github. You can find it
>> in https://github.com/ging/horizon-js. It will only work with Keystone
>> and Nova if they have CORS implemented.
>>
>> Adrian, we didn't make big changes in your code, only logger classes and
>> a little problem we found with PUT requests in some cases (I have to take a
>> deeper look into this problem, anyway). We've made tests from  iPhone,
>> iPad, Safari, Firefox and Chrome and we didn't have any problems. But on
>> the other hand CORS doesn't work in IE9 with PUT and DELETE methods. Next
>> week I will test it with Android and Opera browsers.
>>
>> Sure! It will be very interesting to submit your code to gerrit!!
>>
>> Diego, I will talk with Joaquin to check if we can show you a demo in two
>> weeks!!
>>
>> Cheers,
>> Javier.
>>
>> 2012/4/27 Adrian Smith <adrian_f_smith at dell.com>
>>
>>> I'd be really interested to hear how you go on with the CORS middleware Javier.
>>> Did it work as-is or did you have to modify it? Was there much effort
>>> involved in using it with Nova?
>>>
>>> From your experience it sounds like there's decent CORS support in
>>> browsers now so it's probably time to submit this change to gerrit.
>>>
>>> Adrian
>>>
>>>
>>> 2012/4/27 Diego Parrilla Santamaría <diego.parrilla.santamaria at gmail.com
>>> >
>>>
>>>> Awesome Javier!!!!
>>>>
>>>> Anxiously waiting for a meeting with you guys to see your progress!
>>>>
>>>> Cheers
>>>> Diego
>>>>  --
>>>> Diego Parrilla
>>>> <http://www.stackops.com/>*CEO*
>>>> *www.stackops.com | * diego.parrilla at stackops.com** | +34 649 94 43 29|
>>>> skype:diegoparrilla*
>>>> * <http://www.stackops.com/>
>>>> *
>>>>
>>>> *
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Apr 26, 2012 at 9:50 AM, javier cerviño <jcervino at dit.upm.es>wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I'm glad to hear that there's a lot of interest in the implementation
>>>>> of Openstack JavaScript clients. Actually, in my group we're
>>>>> developing a "single page" application developed entirely in
>>>>> JavaScript, that widely supports Nova and Keystone APIs.  This work is
>>>>> part of a European Project called FI-Ware (http://www.fi-ware.eu/), in
>>>>> which we are currently using Openstack APIs.
>>>>>
>>>>> We've modified Nova and Keystone installations by adding CORS support.
>>>>> We did it by implementing a kind of filter on their APIs. For doing
>>>>> this we used Adam's implementation
>>>>> (https://github.com/adrian/swift/tree/cors), and we adapted it to Nova
>>>>> and Keystone components. We also developed a JS library
>>>>> (http://ging.github.com/jstack/) that can be used by both web and
>>>>> Node.js applications, for example. This library aims to provide same
>>>>> functionalities as python-novaclient, adding support for Keystone API.
>>>>>
>>>>> And finally we are copying Openstack horizon functionality, using JS
>>>>> library and other frameworks such as jQuery and Backbone.js to
>>>>> implement the web application. This web application is an
>>>>> "early-stage" work, but we will probably publish it by the end of this
>>>>> week. I will let you know the github link.
>>>>>
>>>>> We didn't find much problems with CORS implementation and support in
>>>>> browsers.  For the time being, according to our experiments, the only
>>>>> web browser that is not usable at all with this technology is Internet
>>>>> Explorer, but we have tried it in Google Chrome, Safari and Firefox as
>>>>> well and we didn't have any problems.
>>>>>
>>>>> Cheers,
>>>>> Javier Cerviño.
>>>>>
>>>>> On 26 April 2012 06:28, Nick Lothian <nick.lothian at gmail.com> wrote:
>>>>> >
>>>>> >
>>>>> > On Thu, Apr 26, 2012 at 5:49 AM, Adam Young <ayoung at redhat.com>
>>>>> wrote:
>>>>> >>
>>>>> >> Let me try to summarize:
>>>>> >>
>>>>> >> 1.  If you are running from a web browser,  post requests to hosts
>>>>> or
>>>>> >> ports other than the origin are allowed,  but the headers cannot be
>>>>> >> modified.  This prevents the addition of the token from Keystone to
>>>>> provide
>>>>> >> single sign on.
>>>>> >>
>>>>> >> 2.  There are various browser side technologies (JSONP, CORS) that
>>>>> get
>>>>> >> around this limitation, but they are typically not enabled,  and
>>>>> can be
>>>>> >> considered security issues.  While implementing these might require
>>>>> support
>>>>> >> from teh Openstack server,  they are fundamentally browser
>>>>> decisions.
>>>>> >>
>>>>> >
>>>>> > This is inaccurate. JSONP is supported by all browsers since
>>>>> ~Netscape 4.0.
>>>>> >
>>>>> > CORS is supported by all modern browsers: IE > 8, Firefox > 3.5,
>>>>> Chrome > 3,
>>>>> > Safari > 4
>>>>> > (See
>>>>> http://en.wikipedia.org/wiki/Cross-origin_resource_sharing#Browser_support
>>>>> ).
>>>>> > Additionally, CORS support is not a browser decision - the server
>>>>> has to
>>>>> > EXPLICITLY opt-in to support it.
>>>>> >
>>>>> > Obviously CORS support *can* be a security issue - that is why it is
>>>>> > disabled unless the server enables it.
>>>>> >
>>>>> > I do not believe that CORS support adds any additional security
>>>>> issues above
>>>>> > what the OpenStack APIs already face. Specially, the most common
>>>>> problem
>>>>> > (CSRF) is not an issue here because the APIs are not authorised on a
>>>>> session
>>>>> > basis.
>>>>> >
>>>>> >  [snip]
>>>>> >>
>>>>> >>
>>>>> >> I've been working on Single Sign on Issues for another project for
>>>>> the
>>>>> >> past year and a half.  Here's a couple things I've learned.
>>>>> >>
>>>>> >>
>>>>> >> Kerberos is designed to solve this problem.  It has the benefit of
>>>>> being
>>>>> >> integrated into the browser.  Where Kerberos fails is that:
>>>>>  typically it
>>>>> >> only allows a single authentication provider (KDC in Kerberso
>>>>> speak) and it
>>>>> >> does not work well with Firewalls.
>>>>> >>
>>>>> >> The only crytographically secure way to authenticate on the web
>>>>> that can
>>>>> >> get around the firewall issue is Client side X509 certificates.
>>>>>  This is the
>>>>> >> foundation for https://blueprints.launchpad.net/keystone/+spec/pki.
>>>>>  This
>>>>> >> could, in theory, work in with OAuth, OpenID,  or some other
>>>>> distributed
>>>>> >> authorization service,  or we could embed the authorization
>>>>> information
>>>>> >> right into the Certitificate, which is what I suggest we do.
>>>>> >>
>>>>> >>
>>>>> >
>>>>> > To be clear, identity/authorisation is NOT the problem here. The
>>>>> OpenStack
>>>>> > APIs work well for my use cases, once I work around the cross domain
>>>>> POST
>>>>> > problem.
>>>>> >
>>>>> > However, I've also worked with SSO solutions. The simple truth is
>>>>> that
>>>>> > client side certificates do not play well with the web - browser
>>>>> support
>>>>> > ranges from non-existent (on some mobile platforms -
>>>>> > see
>>>>> http://mobilitydojo.net/2010/12/28/client-certificate-support-across-mobile-platforms-a-summary/
>>>>> ) to
>>>>> > abysmal (there is a reason why many websites that use certificates
>>>>> end up
>>>>> > using a Java applet), and their interaction with cross domain
>>>>> Javascript is
>>>>> > unknown.
>>>>> >
>>>>> > Even if certificates did work for identification, CORS would still
>>>>> be needed
>>>>> > - many OpenStack APIs require a POST request which is impossible
>>>>> without
>>>>> > it.
>>>>> >
>>>>> >
>>>>> > Nick
>>>>> >
>>>>> > _______________________________________________
>>>>> > Mailing list: https://launchpad.net/~openstack
>>>>> > Post to     : openstack at lists.launchpad.net
>>>>> > Unsubscribe : https://launchpad.net/~openstack
>>>>> > More help   : https://help.launchpad.net/ListHelp
>>>>> >
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~openstack
>>>>> Post to     : openstack at lists.launchpad.net
>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to     : openstack at lists.launchpad.net
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120430/1469b1b4/attachment.html>


More information about the Openstack mailing list