W3C home > Mailing lists > Public > public-appformats@w3.org > January 2008

Re: Comments on: Access Control for Cross-site Requests

From: Mark Nottingham <mnot@yahoo-inc.com>
Date: Thu, 3 Jan 2008 13:39:09 +1100
Cc: Ian Hickson <ian@hixie.ch>, Anne van Kesteren <annevk@opera.com>, "public-appformats@w3.org" <public-appformats@w3.org>
Message-Id: <EFACC4C0-446A-4688-9F4E-205607B703DC@yahoo-inc.com>
To: "Close, Tyler J." <tyler.close@hp.com>


On 03/01/2008, at 1:17 PM, Close, Tyler J. wrote:

Hey,

> The above comment leaves me with the impression that you too think  
> the client should be enforcing the server's access control policy. I  
> just find this a really strange position. Ian seems to support this  
> view with the perspective that client developers will deploy better  
> software faster than server developers. Is that also your rationale?
>
> Please keep in mind that a positive response to the GET request of  
> step 2 just means that the server admin is saying: "Yes, I've setup  
> some server-side software to control cross-domain requests". It  
> doesn't mean: "I'm blindly letting through all cross-domain  
> requests, my users be damned!", as some seem to be implying.


My concern was that it's quite binary; if it's on, the server is  
required to check the Referer-Root for *every* resource on it, even if  
it only wants to enable one resource for cross-domain access. That's a  
pretty high bar in some environments.

That having been said, I imagine it would be easy enough to come up  
with an Apache or IIS module to enforce a policy in some XML format. I  
don't buy into Ian's argument that it needs to be deployable without  
server-side changes at all; if people are motivated to allow cross- 
site requests, checking a header isn't a big deal. It's easy enough to  
do with rewrite rules if you need to, and many, many cheap Web hosts  
offer access to those.

So, I'll retract that comment.

Cheers,

--
Mark Nottingham       mnot@yahoo-inc.com
Received on Thursday, 3 January 2008 02:39:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:56:21 UTC