Re: More comments on access-control

On Mon, 19 Nov 2007 23:55:26 +0100, Ian Hickson <ian@hixie.ch> wrote:
> I don't plan to change the cited text -- it doesn't have the problem I
> mentioned (it's all in the present progressive). You didn't use the exact
> same text, the problem was introduced in your changes.

I see. Tried to fix it.


>>> Why is the "*." bit redundant in the domain part? How do I make sure
>>> something matches "livejournal.com" but not
>>> "ianhickson.livejournal.com"?
>>
>>   allow <livejournal.com> exclude <ianhickson.livejournal.com>
>>
>> or more generic
>>
>>   allow <livejournal.com> exclude <*.livejournal.com>
>
> Hm. Ok. I'm pretty sure this is confusing enough that it'll be the source
> of security holes in future, though.

There is a scenario where you allow example.org and then later example.org  
gives away subdomains to random users without considering the impact. But  
there's also the problem Jonas mentioned. I'm not sure what we should give  
precedence.


> Does
>
>    allow <*.livejournal.com> exclude <livejournal.com>
>
> ...exclude everything in livejournal.com? (It seems that it does.)

Yes.


>>> 2.4. Referer-Root (sic) HTTP header: Do we need to continue
>>> misspelling this?
>>
>> It seems more consistent with the existing header.
>
> Sure, but it's inconsistent with document.referrer, rel=noreferrer, and
> the English word "referrer".

When making a script on the server rel=noreferrer and document.referrer  
are not really relevant and Referer is. If other people feel strongly  
about this too though than I'm willing to change it, but I rather not at  
this point.


>>> 3.1. Cross-site Access Request: Does the referrer root URI include the
>>> port even if it is the default port?
>>
>> That's what the definition says, no?
>
> I guess so. Why?

Consistency.


>> > 3.1. Cross-site Access Request: what does "Specifications are strongly
>> > encouraged to define this in equivalent ways." mean?
>>
>> I reworded this. The intention is that specifications base it on the
>> same "source" as much as possible.
>
> I still don't really understand what that means I should do, as a spec
> editor.

Removed. The idea is that if you have a feature like  
HTMLImageElement.getImageData() and also SVGImageElement.getImageData()  
which depend on a cross-site GET access request for that functionality in  
case of non same-origin URIs they both use the same "source" by having the  
SVG and HTML people coordinate for instance.


>>> 3.1.1. Generic Cross-site Access Request Algorithms: What does
>>> "transparently follow the redirect while observing the set of request
>>> rules" mean?
>>
>> It somehow needs to point back to the algorithm that invoked it where
>> there is a list of "request rules" which define what to do in case of a
>> network error, redirect, etc.
>
> I don't think the spec is clear enough on this point at the moment. I'm
> not sure I'd know what to do, as an implementor.

I tried making it more clear by having <i>request rules</i> marked up in  
all instances.


> Well, for variables I recommend <var>. For specific terms, <dfn> and <i>.
> For keywords, <b>. For normal terms, nothing.

What to use for return values or values of flags?


> Using current request URI is fine, but it needs to be clearer in the spec
> what's going on. e.g. have some note somewhere in the main algorithm
> pointing out the possible side-effects of the steps defined in the other
> section.

Done.


>>> I'm assuming this is related to the "macro" steps in "3.1.1. Generic
>>> Cross-site Access Request Algorithms", but it isn't clear to me how
>>> this all works. For example, those refer to "origin" but I don't know
>>> what origin that is.
>>
>> That's defined at the start of the algorithm that invokes it. It's the
>> referrer root URI.
>
> The way the steps are factored out as actual steps that you substitute  
> in, rather than as a separate algorithm that you invoke, is a little
> confusing, IMHO. I couldn't tell the "scope" of the "variables" (to use
> programming terms). I think I understand what the spec is trying to say
> now but it could probably be written more clearly (though I'm not sure
> exactly how). Sorry to be so vague in my complaints!

I added a paragraph at the start of the generic thingie explaining where  
the variables are coming from.


>> Actually, the idea *was* that the PUT would simply not be allowed. Error
>> flag to "fail" and "detail" to "network". I guess we should revisit
>> that. See below.
>
> Yeah I don't think it would make sense for it to fail. You can just
> imagine someone doing:
>
> [...] Certainly if it didn't work it'd be very confusing.

Fixed.


>>> Incidentally, you should mention whether the authorization request
>>> cache can have multiple items with the same key. (It seems that it
>>> can.)
>>
>> The idea is that you can't. When would this be possible?
>
> In the example above, the way the algorithm is currently defined, it is
> possible for two items to be added with the same key (but with different
> expires headers and methods). The spec doesn't say what should happen if
> you add an item when there is already an item.

I now defined it in such a way that you can't have duplicates. Expired  
entries are removed "automatically" and if there's a key match for a  
non-expired entry, but no method match the entry is simply removed and a  
new authorization request is done.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Tuesday, 20 November 2007 14:14:38 UTC