Re: XHR without user credentials

On Tue, Jun 9, 2009 at 12:21 PM, Anne van Kesteren <annevk@opera.com> wrote:

> On Tue, 09 Jun 2009 21:15:18 +0200, Tyler Close <tyler.close@gmail.com>
> wrote:
> > Could you provide a code example that shows how to send an XHR request
> > to the same Origin without credentials using the HTML5 <iframe>
> > element?
>
>   <iframe sandbox="allow-scripts" src="..."></iframe>
>
> where ... is some page that does an XMLHttpRequest to the a page that is
> same origin with the page that contains the <iframe>. (The page being
> fetched will have to specify Access-Control-Allow-Origin:* as the request is
> coming from a unique origin by virtue of the sandbox attribute. The request
> will include an Origin header but the value will always be null.)
>
> Also, if the document="" or some such attribute is introduced the code will
> no longer have to be on a separate page.
>

Hi Anne,

I've now read the relevant portions of <
http://dev.w3.org/html5/spec/Overview.html#the-iframe-element>. Looks like a
great start on the right direction! I'm genuinely enthused. Some questions:

The second example says "[...] and the origin sandbox restrictions are
lifted, allowing the gadget to communicate with its originating server."  I
don't understand this. Given the cors this document assumes, couldn't the
gadget do a cross-domain xhr to the originating server anyway?

Does an xhr from a sandboxed unique origin iframe carry any credentials in
the sense in which we've been using in this thread:
* HTTP auth info
* cookies (I think the text implied not, but I'd like to check.)
* client-side certs
* REFERRER
* identified Origin (clearly not if I understand the spec)
* Anything else I forgot?

If it does transmit any of these currently, are there any objections to
revising the spec so that it doesn't?

What happens if a data: URI appears as the value of the src attribute? Would
this allow the containing page to construct and provide the source directly?
Or is this what the document="..." you mention above is for?

How does a sandboxed, unique origin iframe communicate with its containing
page? My guess is postMessage, which is necessarily asynchronous. However,
the useful functionality of the GuestXHR we've been discussing would be
async as well. (Unless html5 has separate provisions to make sync xhr
practical, which would be surprising.) So async GuestXHR would play well
with async postMessage as follows:

Given the above elements including the removal of all credentials and the
acceptance of either document="..." (if I have that right) or
src="data:...", then it seems we may be able to build the GuestXHR we've
been talking about as an object in the containing page that uses postMessage
to relay requests to a sandboxed unique origin iframe acting as a credential
removal laundry. Is this analysis right? What am I missing? In what ways
would these not be equivalent?

If the above speculations are on the right track, it could be the basis for
something much simpler than cors for enabling cross origin xhr requests:
Only allow cross origin xhrs from browsing contexts that have the "sandboxed
origin browsing context flag" set. These xhrs are credential-free and not
associated with any other origin, and so can safely go cross-origin. For any
browsing context without this flag set, its xhr is restricted by the
conventional old same-origin policy. If it want to issue a cross origin
request, it can use a sandboxed unique origin iframe to launder out any
credential confusion.

The recommended server behavior would then be to allow or deny an "Origin:
null" request based only on authorization information explicitly placed into
the payload, avoiding confused deputy confusions.

All redirect-path origin accumulation problems disappear as unnecessary, as
would server-side origin-based ACLs.

Thanks for your patience and my apologies for taking so long for following
up on your question.

-- 
   Cheers,
   --MarkM