openstack team mailing list archive

[Adrian Smith <adrian@xxxxxxxx>]

I have no issue with you submitting your code Javier. As you say though, it
might be worth waiting until it's accepted into Swift so you can take
advantage of suggestions.

Adrian

2012/4/30 javier cerviño <jcervino@xxxxxxxxxx>

> 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@xxxxxxxxxx>
>
>> 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@xxxxxxxx>
>>
>>> 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@xxxxxxxxx
>>> >
>>>
>>>> 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@xxxxxxxxxxxx** | +34 649 94 43 29|
>>>> skype:diegoparrilla*
>>>> * <http://www.stackops.com/>
>>>> *
>>>>
>>>> *
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Apr 26, 2012 at 9:50 AM, javier cerviño <jcervino@xxxxxxxxxx>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@xxxxxxxxx> wrote:
>>>>> >
>>>>> >
>>>>> > On Thu, Apr 26, 2012 at 5:49 AM, Adam Young <ayoung@xxxxxxxxxx>
>>>>> 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@xxxxxxxxxxxxxxxxxxx
>>>>> > Unsubscribe : https://launchpad.net/~openstack
>>>>> > More help   : https://help.launchpad.net/ListHelp
>>>>> >
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~openstack
>>>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>