We can certainly try your suggestions but I think the path of least resistance is to support an existing authentication scheme. You're right in stating that the semantics are extremely close to cookies. I'd note that http auth schemes almost always work in the exact same way -- that is client keeps track of the data, you get the header on every request, etc.
-jOrGe W. On Mar 2, 2011, at 8:17 AM, Soren Hansen wrote: 2011/3/2 Jorge Williams <jorge.willi...@rackspace.com<mailto:jorge.willi...@rackspace.com>>: 1) Weak support in HTTP client libraries. a) This surprises me. I definitely remember using cookies with several different http libraries. b) There is *no* support for the current alternative, since it's something that was made up for this particular purpose. If people use http libriaries that do support cookies, they get Rackspace Cloud API auth support for free. If not, they simply have to do it manually in a manner elmost identical to what they have to do now, except with a different HTTP header name. 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. What if we supported cookes on the server side, but noted in the API docs that broken clients can pass the it as the X-Auth-Token header? 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. 401 sounds reasonable. If the client says it Accepts: text/html, we could redirect it somewhere useful. If not, just leave the response empty. How does that sound? 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 would certainly work. I was just specifically wondering why we're doing something that has semantics extremely close to cookies, yet don't use cookies. Whatever it is we do that makes it possible to do stuff directly in a browser sounds great to me. :) -- Soren Hansen Ubuntu Developer http://www.ubuntu.com/ OpenStack Developer http://www.openstack.org/ 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
