Re: [access-control] Update
On Wed, 9 Jul 2008, Jonas Sicking wrote: 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. This is exactly how postMessage() works and it seems nice to align with that. I am very strongly against this syntax as it gives a false sense of security. To the point where I don't think I'd be willing to implement it in firefox. The fact that postMessage allows this sounds very unfortunate and something that I will look into fixing in that spec. I don't want to carry this mistake forward into Access-Control. I have changed postMessage()'s definition to make sure that targetOrigin doesn't have a path, query, or fragment part. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [access-control] Update
On Mon, 20 Oct 2008, Ian Hickson wrote: On Wed, 9 Jul 2008, Jonas Sicking wrote: 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. This is exactly how postMessage() works and it seems nice to align with that. I am very strongly against this syntax as it gives a false sense of security. To the point where I don't think I'd be willing to implement it in firefox. The fact that postMessage allows this sounds very unfortunate and something that I will look into fixing in that spec. I don't want to carry this mistake forward into Access-Control. I have changed postMessage()'s definition to make sure that targetOrigin doesn't have a path, query, or fragment part. Now fixed to actually work. Search for host-specific. (Better names welcome.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [access-control] Update
Anne van Kesteren wrote: On Thu, 10 Jul 2008 01:13:52 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: This is exactly how postMessage() works and it seems nice to align with that. I am very strongly against this syntax as it gives a false sense of security. To the point where I don't think I'd be willing to implement it in firefox. The fact that postMessage allows this sounds very unfortunate and something that I will look into fixing in that spec. Let me know how that works out. postMessage() is shipping already in various implementations... I will keep you updated. Until then I very strongly feel we need to change the parsing rules to refer to rfcs 3986 and 3490 the way the previous draft did. 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. Well, in the end we want all those concepts implemented in the same way everywhere, right? So I'm not sure how this matters. So why not let HTML5 refer to Access-Control? I don't really see how that would work. Access-Control can define how to parse the 'origin' part of the URI and HTML5 can refer to that. Or they can both refer to the same RFCs. / Jonas
Re: [access-control] Update
Anne van Kesteren wrote: * 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. An alternative syntax I've been thinking about for opting in to cookies is: Access-Control: allow-with-credentials http://foobar.com There are a couple of advantages to this syntax. First of all it keeps down the number of headers. Second, and more importantly, it cleanly disallows opting in to cookies while wildcarding. We'd simply make the syntax for the header Access-Control: Access-Control : allow-rule | allow-with-cred-rule allow-rule: allow (URL | *) allow-with-cred-rule: allow-with-credentials URL One, albeit not big, issue with the current proposal is that it allows someone to say. Access-Control-Origin: * Access-Control-Allow-Credentials: true which is somewhat unfortunate. While this can be defined to be rejected by an implementation that supports the Access-Control-Allow-Credentials header. An implementation like XDR which doesn't will still allow the syntax. / Jonas
Re: [access-control] Update
On Wed, 09 Jul 2008 22:22:52 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: The name Access-Control-Origin is IMHO confusing. It's more or less identical to how it works for Web sockets. (Called Websocket-Origin there.) 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. This is exactly how postMessage() works and it seems nice to align with that. 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. Well, in the end we want all those concepts implemented in the same way everywhere, right? So I'm not sure how this matters. 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. Again, we want to have code reuse and not have separate concepts for same origin throughout the browser and Web platform. Since it uses exactly the same semantics as several HTML5 features, e.g. postMessage and Web sockets, that are also being deployed and shipped by all browsers who plan to implement this specification, I don't think this is much of a problem. Also, technically it is the superior solution, which should take care of 2. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
RE: [access-control] Update
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: [EMAIL PROTECTED] [mailto:public-webapps- [EMAIL PROTECTED] 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
RE: [access-control] Update
I prefer Access-control: * Access-control: URL I suppose it would be slightly shorter, but it's also less clear. Why is it less clear? Seems explicit to me. Access-control: -URL What is the use case for this? I suggested this as equivalent to Jonas recommendation... Access-Control : deny URL (Jonas had it at allow) I'd like to keep the simple check simple and stable over time. New features can be added through headers, as we're doing with credentials, headers, and methods I think this proposal is simple. It has the benefits of what I think Jonas meant when he said he would prefer the latter one as it allows for future expansions. Having Access-control as opposed to Access-Control-Allow-Origin enables the header to be flexible. -Original Message- From: Anne van Kesteren [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 09, 2008 3:18 PM To: Sunava Dutta; Jonas Sicking Cc: WebApps WG Subject: Re: [access-control] Update On Wed, 09 Jul 2008 23:54:17 +0200, Sunava Dutta [EMAIL PROTECTED] wrote: I prefer Access-control: * Access-control: URL I suppose it would be slightly shorter, but it's also less clear. In the future, denying a particular URL can be represented using the - sign? Access-control: -URL What is the use case for this? I'd like to keep the simple check simple and stable over time. New features can be added through headers, as we're doing with credentials, headers, and methods. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [access-control] Update
On Jul 9, 2008, at 3:17 PM, Anne van Kesteren wrote: On Wed, 09 Jul 2008 23:54:17 +0200, Sunava Dutta [EMAIL PROTECTED] wrote: I prefer Access-control: * Access-control: URL I suppose it would be slightly shorter, but it's also less clear. I would be in favor of Access-Control or Access-Control-Allow, I think Access-Control-Origin and Origin are confusing in combination. It seems unclear from the names which is a request header and which is a response header. Regards, Maciej
Re: [access-control] Update
Maciej Stachowiak wrote: On Jul 9, 2008, at 3:17 PM, Anne van Kesteren wrote: On Wed, 09 Jul 2008 23:54:17 +0200, Sunava Dutta [EMAIL PROTECTED] wrote: I prefer Access-control: * Access-control: URL I suppose it would be slightly shorter, but it's also less clear. I would be in favor of Access-Control or Access-Control-Allow, I think Access-Control-Origin and Origin are confusing in combination. It seems unclear from the names which is a request header and which is a response header. Agreed. I also think that putting a somewhat more verbose syntax will give us a better forwards compat story. For example Access-Control: allow-without-query-parameters * or Access-Control: allow-only-tuesdays * I have a hard time believing that we would never find it useful to extend the syntax in future versions of the spec. I also as an implementor don't find it hard to strip out allow before the origin. I also find it very useful that you can just look at the header in order to realize that it is granting some sort of access, which putting the word allow in the syntax does. So either Access-control: allow * or Access-control-Allow: * fulfills that. That said, I would be ok with simply Access-Control: * as well. If we need degradation in the future we can always invent new headers... / Jonas
Re: [access-control] Update
Anne van Kesteren wrote: On Wed, 09 Jul 2008 22:22:52 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: The name Access-Control-Origin is IMHO confusing. It's more or less identical to how it works for Web sockets. (Called Websocket-Origin there.) If only we had the editor of that spec around... ;) 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. This is exactly how postMessage() works and it seems nice to align with that. I am very strongly against this syntax as it gives a false sense of security. To the point where I don't think I'd be willing to implement it in firefox. The fact that postMessage allows this sounds very unfortunate and something that I will look into fixing in that spec. I don't want to carry this mistake forward into Access-Control. 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. Well, in the end we want all those concepts implemented in the same way everywhere, right? So I'm not sure how this matters. So why not let HTML5 refer to Access-Control? / Jonas
Re: [access-control] Update
As promised, I've discussed the proposal we discussed at the F2F with my extended team and we're excited about making the change to integrate XDomainRequest with the public scenarios specified by Access Control. This means IE8 will ship the updated section of Access Control that enables public data aggregation (no creds on wildcard) while setting us up on a trajectory to support more in the future (post IE8) using the API flag in an XDR level 2. Awesome! I think this is great news for the web community. I just want to say great job to all those involved in seeing convergence being reached. I believe many web developers are going to benefit from this specification, and much more so now that it will be accessible across browsers. Thank you for your efforts, Kris
Re: [access-control] Update
On Thu, 10 Jul 2008 01:13:52 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: This is exactly how postMessage() works and it seems nice to align with that. I am very strongly against this syntax as it gives a false sense of security. To the point where I don't think I'd be willing to implement it in firefox. The fact that postMessage allows this sounds very unfortunate and something that I will look into fixing in that spec. Let me know how that works out. postMessage() is shipping already in various implementations... I don't want to carry this mistake forward into Access-Control. It seems bad to do something totally different, especially since it's pretty obvious what the net result is. 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. Well, in the end we want all those concepts implemented in the same way everywhere, right? So I'm not sure how this matters. So why not let HTML5 refer to Access-Control? I don't really see how that would work. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
