- From: Chris Holland <frenchy@gmail.com>
- Date: Mon, 21 Mar 2005 17:57:54 -0800
I On Fri, 11 Mar 2005 16:12:50 +0100, Hallvord Reiar Michaelsen Steen <hallvord at hallvord.com> wrote: > On 10 Mar 2005 at 0:24, Chris Holland wrote: > > > When requesting a different host, we don't want the user agent to be > > sending along cookies pertaining to that domain. Same goes for any > > cached HTTP Basic Auth credentials. > > Why not? Given that we add a mechanism for letting the third-party > server control access to resources on a resource-by-resource basis, I > don't see why we would want to prevent the third-party server from > using sessions / cookies. Authentication is mostly a GUI problem (and > GUI has always been ridiculous for HTTP auth anyway, with no way to > terminate a session). It would not be a good thing if a JS request in > the background could cause a HTTP authentication popup for a user > name / password unrelated to the site you're browsing, so I agree > with disallowing that. Am I missing anything regarding cookies? Well it depends on how granularly we're granting access to resources. The X-Allow-Foreign-Hosts header we were talking about earlier, wouldn't lend itself to much granularity on specific resources. The Mozilla/SOAP authorization model, seems a bit overkill for our use cases. consider a commerce-driven web application: commerce.foo.com which offers an easily accessible URI to "view my past orders": http://commerce.foo.com/my/pastorders/ that URI returns valid xhtml. Later-on, that same site wants to offer a list of its most popular items to the public, and some other developer sets-up a URI that returns an RSS feed: http://commerce.foo.com/mostpopular/ Now, if they want other sites to publish their RSS data, if they follow our spec, and try to be careful, they'll make sure /mostpopular/ returns the X-Allow-Foreign-Hosts header, and will make sure /my/pastorders/ does not. They'll make damn sure that anything that starts with /my/* doesn't. But let's be paranoid, and say they misconfigure their server, and all responses include our header. blam, /my/* is exposed, foreign documents can start sending authenticated queries to /my/*, and sniff results by crawling the resulting DOM. when it comes to cookies, I would advocate one of 2 approaches: 1) disable cookies for a ContextAgnosticHttpRequest 2) maintain an entirely separate cookie table for this request. the question then becomes, do we maintain a separate cookie table for each referring document? We'd essentially be considering each referring document to be a separate application through which a user would re-establish credentials to communicate with a foreign site. sounds rather painful. Where XmlHttpRequest differs from the whole SOAP model is that SOAP isn't a protocol through which a user casually surfs the web while establishing credentials on certain sites, while XmlHttpRequest, in its current incarnation, fully leverages everything that HTTP offers. I was hoping to slightly scale back some of those features in a ContextAgnosticXmlHttpRequest. Is there anything in the SOAP protocol that warrants persistence of any types of credentials such as what the HTTP protocol provides with Basic-Auth and Cookies ? > -- > Hallvord Reiar Michaelsen Steen > http://www.hallvord.com/ > > Note: mail to hallvors at online.no will still be read but you may > want to start using > hallvord at hallvord.com instead > > -- Chris Holland http://chrisholland.blogspot.com/
Received on Monday, 21 March 2005 17:57:54 UTC