[whatwg] ContextAgnosticXmlHttpRequest: an informal RFC

[Chris Holland]

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/