Re: PROPFIND Depth:1 and ACLs

('binary' encoding is not supported, stored as-is)

I'd suggest this is only a problem if you view all requests as isolated
events with no context.

Two (possibly related) approaches come to mind, authenticated v
unauthenticated contexts and sessions.

We usually have a good idea from the outset if the client is going to
need to be authenticated at some point in the session.

And we also know if we expect to be able to do what we want to do without 
authentication.

It's also the case that waiting until you hit a resource requiring
authentication allows a client to discover things about the structure and 
importance of your data. - it at least lets them know there is something
out there which defeats the purpose of sending "not found"

Having an unauthenticated context means the server knows it's a "guest"
user. The response is always to act as if resources to which the client
has no access are just not there.

Similarly in an authenticated context - if there are resources we don't
want the user to know about we just don't tell them they exist.

==============Original message text===============
On Wed, 11 Apr 2007 13:21:04 EDT Cyrus Daboo wrote:


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



===========End of original message text===========