I agree that things should be pluggable, but OpenStack needs to have a default.
Users need to know that they can point OpenStack client applications at OpenStack providers and it should work. I would prefer a signature based approach as the default (as signatures limits replay attacks; tokens allow an eavesdropper to make arbitrary requests if they obtain a token). Jesse On Mar 2, 2011, at 7:34 AM, Jorge Williams wrote: > Soren, > > Really good question about why we didn't use cookies. There are two problems > that I see with cookies. > > 1) Weak support in HTTP client libraries. HTTP libs tend to not handle them > at all or to not handle them correctly. In the Java world, for example, > java.net.* doesn't handle cookies very well. There are certainly other libs > that handle them, but a whole bunch of software is built on top of java.net.* > including some popular REST libraries. > 2) Say you make a request and don't include your cookie in it. A typical > webapp will simply redirect you to a login form. But what should happen in a > REST API? Should you get a 401? I think it's a little fuzzy how we would > handle this correctly. > > If you want browser support -- and personally I think all of our APIs should > be browser friendly -- I think the best approach is to support an establish > scheme like HTTP Basic or Digest. These schemes have great client lib > support. They are supported in a friendly way by browsers. And they don't > break HTTP semantics, so you don't get a redirect when you should be getting > a request for credentials. > > That said, I really feel we should take a pluggable approach to > authentication so that we can let operators and clients decide what they need. > > -jOrGe W. > > > On Mar 1, 2011, at 3:08 PM, Eric Day wrote: > >> On Tue, Mar 01, 2011 at 10:02:37PM +0100, Soren Hansen wrote: >>> 2011/3/1 Eric Day <e...@oddments.org>: >>>> Well, hopefully with a shared, modular service, we can add a token >>>> module that uses cookies instead. :) >>> >>> Sure :) I was just hoping to extract whatever wisdom might have been >>> behind the decision to seemingly reinvent the concept of cookies. >>> Perhaps there's some reason to avoid cookies I'm missing... Sorry, >>> didn't mean to hijack your thread :) >> >> That's what this thread is for, figure out what we have and what do >> we want? :) >> >> Perhaps Jorge or someone else on the Rackspace auth side can share >> some reasons for the decisions? >> >> -Eric >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp > > > > Confidentiality Notice: This e-mail message (including any attached or > embedded documents) is intended for the exclusive and confidential use of the > individual or entity to which this message is addressed, and unless otherwise > expressly indicated, is confidential and privileged information of Rackspace. > Any dissemination, distribution or copying of the enclosed material is > prohibited. > If you receive this transmission in error, please notify us immediately by > e-mail > at ab...@rackspace.com, and delete the original message. > Your cooperation is appreciated. > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp