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

RE: [access-control] Update

From: Sunava Dutta <sunavad@windows.microsoft.com>
Date: Wed, 9 Jul 2008 14:54:17 -0700
To: Jonas Sicking <jonas@sicking.cc>, Anne van Kesteren <annevk@opera.com>
CC: WebApps WG <public-webapps@w3.org>
Message-ID: <083D18C6B9B71F4CBCA7B76D97B748310C813A498F@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>
Jonas said:
"> I have a few comments:
>
> The name "Access-Control-Origin" is IMHO confusing. First of all I
> would
> expect "allow" or "grant" or something like that somewhere in the
> syntax
> to indicate that the header is granting access. I have two counter
> proposals:
>
> "Access-Control-Allow-Origin" ":" URL | "*"
> or
> "Access-Control" ":" "allow" "<" URL ">"
>
> I would prefer the latter one as that gives us better opportunity for
> future expansions if needed. That way the future expansions can be made
> such that existing clients bail due to unrecognized syntax if we so
> desire."


I prefer
Access-control: *
Access-control: <URL>

In the future, denying a particular URL can be represented using the "-" sign?
Access-control: -<URL>

Thoughts?

> -----Original Message-----
> From: public-webapps-request@w3.org [mailto:public-webapps-
> request@w3.org] On Behalf Of Jonas Sicking
> Sent: Wednesday, July 09, 2008 1:23 PM
> To: Anne van Kesteren
> Cc: WebApps WG
> Subject: Re: [access-control] Update
>
>
> Looks great!
>
> I have a few comments:
>
> The name "Access-Control-Origin" is IMHO confusing. First of all I
> would
> expect "allow" or "grant" or something like that somewhere in the
> syntax
> to indicate that the header is granting access. I have two counter
> proposals:
>
> "Access-Control-Allow-Origin" ":" URL | "*"
> or
> "Access-Control" ":" "allow" "<" URL ">"
>
> I would prefer the latter one as that gives us better opportunity for
> future expansions if needed. That way the future expansions can be made
> such that existing clients bail due to unrecognized syntax if we so
> desire.
>
>
> Similarly, should we rename Access-Control-Credentials to
> Access-Control-Allow-Credentials? This feels less important to me.
>
>
> Lastly, the 'URL' token http://dev.w3.org/2006/waf/access-control/#url

> should not be a full URL, and I don't think we want to depend on HTML5
> for it either. Currently we seem to be allowing the syntax
>
> Access-Control-Origin: http://foo.com/bar/bin/baz.html

>
> which I think is very bad as it seems to indicate that only that page
> would be allowed to POST, which of course isn't something that we can
> enforce.
>
> Additionally, the way the spec was written before we could create a
> conformat implementation now without having to worry about HTML5
> changing things under us.
>
> Note that when I said during the meeting that the URI paring was the
> hardest part, I didn't mean that URI parsing was hard. I meant it in
> the
> sense that the spec was so easy to implement that it was even simpler
> than URI parsing.
>
> So I strongly think we should bring back the language the spec used to
> have for parsing origins. And then the HTML5 spec can refer to the AC
> spec for origins if it so desires.
>
> Adding a dependency on HTML5 is bad for a couple of reasons:
> 1. We want to be able to ship implementations now and not change their
> parsing later as that can have security implications.
> 2. It has been politically hard to add dependencies to unfinished
> specs.
> Weather we think the concerns raised have merit or not, the debate is
> likely going to cause the spec to get delayed.
>
> Mostly I care about 1 above.
>
>
> I haven't reviewed the headers/methods stuff yet. But it looks good at
> an initial overview.
>
> / Jonas
>
>
> Anne van Kesteren wrote:
> >
> > Hi,
> >
> > The WebApps WG had a F2F last week in Seattle. While I'm still a bit
> > buzzed by the jet lag I managed to "finish" the work I started during
> > the weekend on updating the Access Control for Cross-Site Requests
> (AC)
> > specification to match resolutions and proposals made during the F2F
> > meeting. The meeting logs of the F2F are not publicly available yet,
> but
> > since the editor's draft is, I will summarize what I changed and
> > depending on whether you trust me or not, you can infer from that
> what
> > we decided upon...
> >
> > The draft is available at the same place as usual:
> >
> >   http://dev.w3.org/2006/waf/access-control/

> >
> > Here is what I changed:
> >
> >  * <?access-control?> is dropped. Might return in AC2.
> >
> >  * Access-Control is now Access-Control-Origin which takes * or a
> URL.
> > In other words, whether or not a site grants access is simplified *a
> > lot*. Implementors who told me this was the most complex part to
> > implement can rejoice. This also makes this specification consistent
> > with Web Sockets and postMessage(), both defined in HTML5.
> > (Access-Control-Origin is not to be confused with the old
> > Access-Control-Origin, which is now Origin.)
> >
> >  * Access-Control-Credentials provides an opt in mechanism for
> > credentials. Whether or not credentials are included in the request
> > depends on the "credentials flag", which is set by a hosting
> > specification. Preflight requests are always without credentials.
> >
> >  * Four new headers are introduced to deal with headers and method
> opt
> > in. Two request headers (set by the user agent):
> > Access-Control-Request-Method and Access-Control-Request-Headers. And
> > two response headers: Access-Control-Allow-Method and
> > Access-Control-Allow-Headers. (The introduction of these headers also
> > affected the preflight result cache.)
> >
> >  * The HTTP header blacklist is gone as that is something that
> affects
> > all hosting specifications, including same-origin requests, and
> > therefore is inappropriate in a specification intended solely for non
> > same-origin requests.
> >
> >  * I've referenced HTML5 for several concepts which hopefully
> encourages
> > code reuse in user agents and also makes sure that we don't have to
> > change if HTML5 does.
> >
> >  * An access control check is now also performed when the redirect
> steps
> > are applied to prevent data leakage from intranet pages.
> >
> > So please review the changes made and the significant revisions to
> the
> > processing model. Much appreciated. If you would like to review the
> CVS
> > log entries you can do so here (changes since last time start at
> 1.178,
> > "MASSIVE CHANGE"):
> >
> >   http://dev.w3.org/cvsweb/2006/waf/access-control/Overview.html

> >
> >
> > Kind regards,
> >
> >
>
>

Received on Wednesday, 9 July 2008 21:55:16 GMT

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