Subject: PROPFIND Depth:1 and ACLs

From: Cyrus Daboo <[email-masked]>
Date: Wed, 11 Apr 2007 13:21:04 -0400

Hi folks,
Say I have a collection that has DAV:read privilege for 
DAV:unauthenticated, and two resources, A and B in that collection. 
Resource A has DAV:read for the DAV:unauthenticated, but resource B does 
not (it has DAV:read for DAV:authenticated).

Now lets say that user does a PROPFIND Depth:1 on the collection. What 
should the multi-status response contain? Obviously an entry for the 
collection and one for resource A. But should there be a DAV:response for 
resource B? Certainly if there is, it ought not to include any requested 
properties, but if that is the case should the response simply not contain 
any properties at all, or list all properties as Forbidden?

My opinion is that resource B should not be listed at all in the PROPFIND 
Depth:1 results - if you can't read the resource content or properties you 
should not be able to see it at all in a directory listing. Other people 
have suggested that it ought to be returned in the propfind to at least 
alert someone that it is there.

The real problem is this: say I have a WebDAV browser and point it at the 
collection. Since unauthenticated access is allowed there, the browser can 
do an unauthenticated PROPFIND Depth:1 to list the collection contents (the 
server won't prompt for authentication). Using my approach, resource B 
would not appear in the listing. Thus a user who could authenticate and see 
resource B, would actually never be able to if they just relied on the 
"on-demand" nature of HTTP authentication. Using the other approach, 
resource B would be listed, and if a user clicked it in the browser they 
would be able to access it if they authenticate when the server prompts for 
that.

Any suggestions on how best to deal with this?

-- 
Cyrus Daboo

---

From: Julian Reschke <[email-masked]>
Date: Wed, 11 Apr 2007 23:51:00 +0200

Cyrus Daboo schrieb:
> collection and one for resource A. But should there be a DAV:response 
> for resource B? Certainly if there is, it ought not to include any 
> requested properties, but if that is the case should the response simply 
> not contain any properties at all, or list all properties as Forbidden?
> 
> My opinion is that resource B should not be listed at all in the 
> PROPFIND Depth:1 results - if you can't read the resource content or 
> properties you should not be able to see it at all in a directory 
> listing. Other people have suggested that it ought to be returned in the 
> propfind to at least alert someone that it is there.

That's the same question as whether a GET on a resource for which you 
don't have read access should return 403 (forbidden) or 404 (not found). 
Some think that 403 would mean to give away too much information already.

I think both positions have merits, and there are certainly examples in 
the real world for both.

For PROPFIND that means that the entry either doesn't show up, or is 
listed with a status of 403. Clients should expect both.

> The real problem is this: say I have a WebDAV browser and point it at 
> the collection. Since unauthenticated access is allowed there, the 
> browser can do an unauthenticated PROPFIND Depth:1 to list the 
> collection contents (the server won't prompt for authentication). Using 
> my approach, resource B would not appear in the listing. Thus a user who 
> could authenticate and see resource B, would actually never be able to 
> if they just relied on the "on-demand" nature of HTTP authentication. 
> Using the other approach, resource B would be listed, and if a user 
> clicked it in the browser they would be able to access it if they 
> authenticate when the server prompts for that.
> 

I think the 403 approach makes sense, except if you treat the existence 
of that resource to be secret as well.

Best regards, Julian

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 11 Apr 2007 21:20:33 -0400

Hi Julian,

> of that resource to be secret as well.

Of course it is not just the existence of the resource that is being given 
away, but also the "name" of the resource. Since most people name documents 
with something that is vaguely descriptive of the content, then exposing 
that name, even via a 403, maybe too much.

-- 
Cyrus Daboo