Ian's Cross-Domain XmlHttpRequest Proposal (was: Fwd: several messages on ContextAgnosticXmlHttpRequest)

Hi there, in the forwarded e-mail below, i'm simply trying to
understand/digest Ian Hickson's proposal for Cross-Domain hooks in
XmlHttpRequest, with a couple of "Notes" which some of you might like
to read/answer/address.

The version of Ian's proposal I read lives at:
http://lists.w3.org/Archives/Public/public-webapi/2006Jun/0012

Quick recap, key concerns:
---------------------------------------
Keeping in mind that a service author has gone through the trouble of
taking steps to make their service data available to 3rd-party
documents, and that in a sensical world of reasonable developers, this
really ought to be enough, my basic concerns still remain:

- Should the user agent automatically send cookies to domainTWO.com?
- Should the user agent automatically send cached http/basic auth
credentials to domainTWO.com?

I'm leaning toward "No" on both these questions.

more cosmetic notes are also embedded in below.

The full email:
--------------------

---------- Forwarded message ----------
From: Chris Holland <frenchy@gmail.com>
Date: Mar 13, 2007 9:07 AM
Subject: Re: several messages on ContextAgnosticXmlHttpRequest
To: Anne van Kesteren <annevk@opera.com>


Hello Anne :)

Thank you very much for including me in this process. As i'm trying to
digest Hixie's proposal ... let me know if i get the ideas more or
less right:

considering a document living at
http://host.domainONE.com/somepage.html trying to make an
XmlHttpRequest to http://host.domainTWO.com/get/some/data ....


a user agent would send:

A) In case of traditional GET or POST methods:

Refer-Root: http://host.domainONE.com/
     .... which would allow the operator of
http://host.domainTWO.com/get/some/data to establish some internal
access rules, if it chooses to do so.
Referer:  http://host.domainONE.com/somepage.html
    .... which is our good old standard misspelled http header, which
we could use for even more granular internal access rules, and/or
simply information/stats-tracking.

==> DOCUMENT ACCESS CHECK: The response payload to this request will
be made accessible to the user-agent, if and only if necessary headers
were sent-along with the response, to trigger a successful DOCUMENT
ACCESS CHECK. If that fails, then a network-level failure is thrown.

B) In case of non-traditional GET or POST methods, such as possible
TRACE/PUT/DELETE ... etc, We don't want to flat out forbid them, but
we do want provide some caution and have the service provider
explicitly, knowingly, allow those thru the following mechanism:

1) The client first performs a GET Request to
http://host.domainTWO.com/get/some/data, and includes in the request
an HTTP header called:
XmlHttpRequest-Security-Check whose value would be "TRACE/PUT/DELETE
.... etc.", whatever the method was originally intended. Let's use
"PUT" in our example.

..... Note: i would assume we also want Referer-Root: and Refer: to be
sent as part of this step, to allow more granular decisions in step 2)
below?

2) http://host.domainTWO.com/get/some/data must subsequently make some
decisions as to whether it even wants to allow the requester to send a
PUT method.

.... Note: say step 2) is successful, and the service provider sent
Allow:PUT in the response, should the client cache that response? If
yes, for how long? What if i build a service that allows a PUT today,
and i change my mind an hour later and i want to forbid that. If not,
then this round-trip check would be performed every time a PUT is
attempted.

.... Note 2: okay, Hixie's Note actually addresses that in the
following paragraph. Should the service provider use a good old
"Expires:" header to define how long the client should cache the
result of the XmlHttpRequest-Security-Check process?

3) Upon a successful METHOD SECURITY-CHECK ( which might be a more
descriptive name for that header than just
xmlhttprequest-security-check unless that header can have multiple
purposes), the user-agent can now actually perform the PUT request,
according to a mechanism similar to what's described in A) above:

==> DOCUMENT ACCESS CHECK: The response payload to this PUT request
will be made accessible to the user-agent, if and only if necessary
headers were sent-along with the response, to trigger a successful
DOCUMENT ACCESS CHECK. If that fails, then a network-level failure is
thrown.

C) DOCUMENT ACCESS CHECK PROCESS:
  This process is the common final step to processes A) and B) above.
It determines whether the response from the 3rd-party server can even
be read by the originating script. It relies on a set of directives
that can live in two possible places:
    1) Multiple Content-Access-Check: headers
    2) <?access-control?> Processing Instructions embedded in the XML
document returned, if and only if the MIME type of the document indeed
describes the document as an XML document.

==> This mechanism is entirely defined here:
http://www.w3.org/TR/access-control/

Ok, i think this looks like something i could see myself using :).

A few more notes:

What about cookies and cached http basic auth credentials? In my
ContextAgnosticXmlHttpRequest proposal, I was explicitly forbidding a
user agent from blindly sending those to prevent malicious
cross-polination of sensitive data. But now that I consider Hixie's
spec, if a service provider goes through the trouble of specifying
access-control directives that explicitly allow the document to be
accessed by third-parties, one would assume they would make sure they
TRULY entrust domainONE.com with everything they expose at
http://host.domainTWO.com/get/some/data  including anything that may
have relied on prior authentication resulting in a cookie having been
set. I'm just a bit possibly worried about people building "web
frameworks" that set very loose Content-Access-Control directives for
convenience and making certain services more "ubiquitously available".

Thought: Should the "Cookie" header only be sent to domainTWO if and
only if the document on domainONE sets it in a setRequestHeader?

Thought: What about basic auth headers. Could we just not send them?
Or perhaps also let domainONE's document, send them thru
setRequestHeader.

What about making all non-standard http headers X- headers? I guess
that's what his P.S. note covers :) XXX-header-name, heh heh :).
Catchy.

Please let know what i've missed/misunderstood, a good purpose of this
email was to ensure i grokked Hixie's spec correctly :)

Thanks for your time!

-Chris



On 3/7/07, Anne van Kesteren <annevk@opera.com> wrote:
> Hi,
>
> Hixie forwarded your comments to me as I'm now the editor of the
> XMLHttpRequest specification:
>
>    http://www.w3.org/TR/XMLHttpRequest/
>
>
> On Tue, 08 Mar 2005 03:44:15 +0100, Chris Holland <frenchy@gmail.com>
> wrote:
> > I was hoping some of you might be able to give me some feedback on an
> > informal RFC i put together on my blog:
> >
> > http://chrisholland.blogspot.com/2005/03/contextagnosticxmlhttprequest-informal.html
> >
> > I'm basically looking to enable some sort of cross-host *and*
> > cross-domain interoperability between documents via a modified clone
> > of the XmlHttpRequest object, while attempting to tread very carefully
> > on various security issues, such as Cookies and Basic-Auth
> > credentials. A "ContextAgnosticXmlHttpRequest" would be a new object
> > developers could use, beyond the traditional XmlHttpRequest.
>
> The current proposal for doing cross-site XMLHttpRequest is located here:
>
>    http://www.w3.org/mid/Pine.LNX.4.62.0606062320020.10674@dhalsim.dreamhost.com
>
> If this proposal does not satisfy your needs please raise this on
> public-webapi@w3.org.
>
> Cheers,
>
>
> --
> Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>
>


--
Chris Holland
http://chrisholland.blogspot.com/


-- 
Chris Holland
http://chrisholland.blogspot.com/

Received on Friday, 16 March 2007 08:37:33 UTC