<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<div>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.</div>
<div><br>
</div>
<div>-jOrGe W.</div>
<div><br>
</div>
<br>
<div>
<div>On Mar 2, 2011, at 8:17 AM, Soren Hansen wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div>2011/3/2 Jorge Williams <<a href="mailto:jorge.williams@rackspace.com">jorge.williams@rackspace.com</a>>:<br>
<blockquote type="cite">1) Weak support in HTTP client libraries.<br>
</blockquote>
<br>
a) This surprises me. I definitely remember using cookies with several<br>
different http libraries.<br>
<br>
b) There is *no* support for the current alternative, since it's<br>
something that was made up for this particular purpose. If people use<br>
http libriaries that do support cookies, they get Rackspace Cloud API<br>
auth support for free. If not, they simply have to do it manually in a<br>
manner elmost identical to what they have to do now, except with a<br>
different HTTP header name.<br>
<br>
<blockquote type="cite"> 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.<br>
</blockquote>
<br>
What if we supported cookes on the server side, but noted in the API<br>
docs that broken clients can pass the it as the X-Auth-Token header?<br>
<br>
<blockquote type="cite">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.<br>
</blockquote>
<br>
401 sounds reasonable. If the client says it Accepts: text/html, we<br>
could redirect it somewhere useful. If not, just leave the response<br>
empty. How does that sound?<br>
<br>
<blockquote type="cite">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.<br>
</blockquote>
<br>
That would certainly work. I was just specifically wondering why we're<br>
doing something that has semantics extremely close to cookies, yet<br>
don't use cookies. Whatever it is we do that makes it possible to do<br>
stuff directly in a browser sounds great to me. :)<br>
<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br>
</font></font></div>
</blockquote>
<blockquote type="cite">
<div><br>
-- <br>
Soren Hansen<br>
Ubuntu Developer <a href="http://www.ubuntu.com/">http://www.ubuntu.com/</a><br>
OpenStack Developer <a href="http://www.openstack.org/">http://www.openstack.org/</a><br>
</div>
</blockquote>
</div>
<br>
<PRE>
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 abuse@rackspace.com, and delete the original message.
Your cooperation is appreciated.
</PRE></body>
</html>