W3C home > Mailing lists > Public > public-appformats@w3.org > July 2007

Re: [ac] wildcard rules and subdomains

From: Thomas Roessler <tlr@w3.org>
Date: Tue, 10 Jul 2007 10:46:07 +0200
To: Jonas Sicking <jonas@sicking.cc>
Cc: "WAF WG (public)" <public-appformats@w3.org>
Message-ID: <20070710084607.GU6561@raktajino.does-not-exist.org>

On 2007-07-09 14:14:17 -0700, Jonas Sicking wrote:

> Thomas Roessler wrote:

>> On 2007-07-06 17:18:11 -0700, Jonas Sicking wrote:
>>
>>
>>> The other use case if your putting a resource on a server that
>>> grants access, but you don't want your particular resource to be
>>> accessible cross domain.
>>
>> That use case is actually a recipe for desaster -- mainly because
>> there is no way for the server operator to know whether a client is
>> going to honor a policy or not.  After all, the client could be old
>> and predate (and therefore ignore) the access-control language.
>>
>> That kind of scenario is, in fact, another reason why the
>> access-control language should not be able to express restrictions
>> that go beyond the existing sandbox model.  People will try to use
>> the language with "deny" for the use case that you describe, and (as
>> you said) "bad things will happen."
>
> If the client doesn't support AC then it'll deny access due to the existing 
> same-origin policies. I don't see how this is a problem.

In that case I misread your use case, apologies.  I was assuming
that you were talking of a resource to which access would be granted
due to same-origin policies, but the policy author (seeing that
nifty "deny" statement) tries to restrict further.  Which would
inevitably fail.

(Incidentally, that scenario -- that I *thought* you were talking of
-- is one of the reasons against "deny" that I forgot to mention in
my earlier summary.)
-- 
Thomas Roessler, W3C  <tlr@w3.org>
Received on Tuesday, 10 July 2007 08:46:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:07 UTC