Subject: DAV:read privilege and browsing

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Tue, 28 Nov 2006 15:24:10 -0800

I'm looking for a bit of guidance as to the DAV:read privilege and  
its effect on PROPFIND.

   If I don't have DAV:read on a resource, but I do have DAV:read on  
its parent collection, when I do a PROPFIND with depth=1 on the  
parent, should I be able to see the child?

   It's not clear to me from the ACL spec what I can or can not expose  
without DAV:read.  My interpretation is that DAV:read on the parent  
means you can read its list of children.

   I obviously shouldn't be able to read (all of?) the child's  
properties, but there is some merit to wanting to be able to see that  
the child's URI is present, even if I can't read the child's  
properties or content.  I might even want to expose the DAV:resource- 
type property so you can tell if it's a collection, etc.

   This also nominally affects GET, when I'm rendering a directory  
listing of the parent.  I'd like to show all children, but if you  
aren't allowed to see them in PROPFIND, it makes sense that they  
should be hidden from the rendered listing as well.

   Varying the GET result on the authentication is problematic from a  
user experience point of view.  If an unauthenticated request is  
allowed to see some children, I'll only see part of what I would see  
if I authenticated, but the browser won't be asked to authenticate  
because then unauthenticated users wouldn't be able to see the parent  
at all.

	-wsv

---

From: Julian Reschke <[email-masked]>
Date: Thu, 30 Nov 2006 09:32:05 +0100

Wilfredo Sánchez Vega schrieb:
>   I'm looking for a bit of guidance as to the DAV:read privilege and its 
> effect on PROPFIND.
> 
>   If I don't have DAV:read on a resource, but I do have DAV:read on its 
> parent collection, when I do a PROPFIND with depth=1 on the parent, 
> should I be able to see the child?

I guess the answer is "it depends". In the SAP KM implementation, we 
return all children, but if the user doesn't have read access, they come 
back with a 403 status. As far as I can tell, this is exactly to the 
letter of the spec, and has the advantage that a client can see the 
difference between "not there" and "not accessible". This may be 
importance for instance when creating new items in the collection - you 
don't want to hide something only to tell the user later that it can't 
be created because it already exists.

> means you can read its list of children.

Yep. The issue here is that RFC3744 only talks about PROPFIND in 
general, without making a statement about Depth=1. Maybe we need to fix 
this.

> the child's URI is present, even if I can't read the child's properties 

Right.

> or content.  I might even want to expose the DAV:resource-type property 
> so you can tell if it's a collection, etc.

I don't think RFC3744 would allow the latter, even though I would 
consider it harmless...

> listing of the parent.  I'd like to show all children, but if you aren't 
> allowed to see them in PROPFIND, it makes sense that they should be 
> hidden from the rendered listing as well.

Correct. I personally think they should appear in both, potentially 
marked up as non-accessible (greyed out...).

> ...

Funny enough, over on the Slide mailing list we are just discussing 
this. Seems that the Slide client easily gets confused, but hopefully 
that can e fixed.

Best regards, Julian