W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

RE: XDomainRequest Integration with AC

From: Sunava Dutta <sunavad@windows.microsoft.com>
Date: Thu, 31 Jul 2008 19:41:21 -0700
To: Jonas Sicking <jonas@sicking.cc>, "public-webapps@w3.org" <public-webapps@w3.org>
CC: Maciej Stachowiak <mjs@apple.com>, "annevk@opera.com" <annevk@opera.com>, Sharath Udupa <Sharath.Udupa@microsoft.com>, Zhenbin Xu <Zhenbin.Xu@microsoft.com>, Gideon Cohn <gidco@windows.microsoft.com>, IE8 Core AJAX SWAT Team <ieajax@microsoft.com>
Message-ID: <083D18C6B9B71F4CBCA7B76D97B748310C818A66CC@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>

In offline conversations with Jonas on the topic of supporting the url syntax I think Jonas mentioned a good point regarding supporting <URL> for the private scenario. Namely, in caching scenarios allowing the URL to be sent in the response header if mistakes happen (for example Vary by origin header is not sent or ignored) doing so will ensure that it fails securely. I'm not so sure about the value for the public data scenario (other than consistency). Here's what I came up with, feel free to add on or elaborate.

Pros (of supporting URL syntax in public scenarios)
*       Supporting URL allows for a site to return data that's related to a particular site, but is non user specific (no creds)

Cons
*       A better architecture here is that a site will rely on the Access-Control-Origin header to determine the site and then decide to send the data or not. Along those line it as a few teammates said it seems wasteful to support <URL> syntax for the public scenario as we don't want the data to be sent on the client and dumped. The server should simply not send the content if the Origin is not what is desired.
*       The second problem that comes to mind is that clients cannot be trusted. The resource server essentially is relying on the  client to enforce the domain check.  However since this is anonymous access, the client could well be evil.com's server, which would simply ignore the <URL> and grab data.   The resource server has no way of telling who the request party really is -- it is just an anonymous HTTP client. This may instill a false sense of security for server operators.
*       The third challenge here is that the access-control-origin header may be spoofable therefore this scenario is not reliably solved.

On an issue that *May* be related, section 4.3 of the latest editors draft says, "The Access-Control-Credentials HTTP response header indicates whether the response to request can be exposed when the credentials flag is true. When part of the response to an preflight request it indicates that the actual request can be made with credentials."
Does this mean that credentials can only be sent in a second request or 'actual request' *after* a preflight request is sent *and* the response Access-Control-Credentials header is true? (Or can creds be sent without pre-flight? Pardon me if we discussed this prior and I've forgotten) Of course all this is assuming the credentials flag is true, which is the prerequisite.

> -----Original Message-----
> From: Jonas Sicking [mailto:jonas@sicking.cc]
> Sent: Wednesday, July 30, 2008 10:32 AM
> To: Sunava Dutta
> Cc: Maciej Stachowiak; annevk@opera.com; Sharath Udupa; Zhenbin Xu;
> Gideon Cohn; public-webapps@w3.org; IE8 Core AJAX SWAT Team
> Subject: Re: XDomainRequest Integration with AC
>
> And note that this syntax should be supported even in the public data
> scenario.
>
> / Jonas
>
> Jonas Sicking wrote:
> >
> > Please note that
> >
> > Access-Control-Allow-Origin: url
> >
> > is also allowed syntax. Where the url must contain only scheme,
> domain
> > and host.
> >
> > So the following syntax is allowed:
> > Access-Control-Allow-Origin: http://example.com
> >
> > It is somewhat unclear if the following syntaxes are allowed:
> >
> > Access-Control-Allow-Origin: http://example.com/
> > Access-Control-Allow-Origin: http://example.com/?
> > Access-Control-Allow-Origin: http://example.com/#
> > Access-Control-Allow-Origin: http://example.com/;
> >
> >
> > I think the first one should be ok, but not the other three.
> >
> > / Jonas
> >
> >
> >
> > Sunava Dutta wrote:
> >> Access-Control-Allow-Origin: * seems to be the consensus for the
> >> public scenario, please confirm.
> >> On a less urgent note did we get any further traction on the
> >> discussion on angle brackets for the URL specified scenario? The
> last
> >> mail here seems to be on 7/21.
> >>
> >>
> >>> -----Original Message-----
> >>> From: Maciej Stachowiak [mailto:mjs@apple.com]
> >>> Sent: Saturday, July 19, 2008 9:32 PM
> >>> To: Jonas Sicking
> >>> Cc: Sunava Dutta; annevk@opera.com; Sharath Udupa; Zhenbin Xu;
> Gideon
> >>> Cohn; public-webapps@w3.org; IE8 Core AJAX SWAT Team
> >>> Subject: Re: XDomainRequest Integration with AC
> >>>
> >>>
> >>> On Jul 18, 2008, at 11:15 PM, Jonas Sicking wrote:
> >>>
> >>>> Maciej Stachowiak wrote:
> >>>>> On Jul 18, 2008, at 4:20 PM, Sunava Dutta wrote:
> >>>>>> I'm in time pressure to lock down the header names for Beta 2 to
> >>>>>> integrate XDR with AC. It seems no body has objected to Jonas's
> >>>>>> proposal. http://lists.w3.org/Archives/Public/public-
> >>> webapps/2008JulSep/0175.html
> >>>>>> Please let me know if this discussion is closed so we can make
> the
> >>>>>> change.
> >>>>> I think Anne's email represents the most recent agreement and I
> >>>>> don't think anyone has objected:
> >>> http://lists.w3.org/Archives/Public/public-
> webapps/2008JulSep/0142.html
> >>>>> The change would be: Instead of checking for
> >>>>> "XDomainRequestAllowed: 1" check for "Access-Control-Allow-
> Origin:
> >>>>> *" or "Access-Control-Allow-Origin: url" where url matches what
> was
> >>>>> sent in the Origin header.
> >>>> So I have one final request for a change to the above syntax.
> >>>>
> >>>> How would people feel about the syntax
> >>>>
> >>>> Access-Control-Allow-Origin: <url>
> >>> I don't think the angle brackets are necessary for forward compat,
> >>> since we can just disallow spaces from the URL.
> >>>
> >>>   - Maciej
> >>>
> >>>>
> >>>> This would give us at least something for a forwards compatibility
> >>>> story if we wanted to add to the syntax in future versions of the
> >>>> spec. I really think we are being overly optimistic if we think
> that
> >>>> the current syntax is the be-all end-all syntax that we'll ever
> want.
> >>>>
> >>>> For example during the meeting we talked about that banks might
> want
> >>>> to enforce that the requesting site uses a certain level of
> >>>> encryption, or even a certain certificate. A syntax for that might
> >>> be:
> >>>> Access-Control-Allow-Origin: origin <https://foo.com> encryption
> sha1
> >>>>
> >>>> Or that the site in question uses some opt-in XSS mitigation
> >>>> technology (such as the one drafted by Brandon Sterns in a
> previous
> >>>> thread in this WG). This could be done as
> >>>>
> >>>> Access-Control-Allow-Origin: origin <https://foo.com> require-xss-
> >>>> protection
> >>>>
> >>>> So the formal syntax would be
> >>>>
> >>>> "Access-Control-Allow-Origin:" "<" ("*" | url) ">"
> >>>>
> >>>> / Jonas
> >>>>
> >>>> / Jonas
> >>
> >>
> >
> >
>
Received on Friday, 1 August 2008 02:42:21 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:27 GMT