Re: PROPFIND Depth:1 and ACLs

Cyrus Daboo schrieb:
> 
> 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.

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.
> 
> Any suggestions on how best to deal with this?

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

Best regards, Julian

Received on Wednesday, 11 April 2007 21:51:18 UTC