W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2007

Re: PROPFIND Depth:1 and ACLs

From: <douglm@rpi.edu>
Date: Sun, 15 Apr 2007 22:40:41 -0400
Message-Id: <200704160240.l3G2ef61004676@smtp7.server.rpi.edu>
Cc: w3c-dist-auth@w3.org
To: cyrus@daboo.name
('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=========== Received on Monday, 16 April 2007 11:40:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:41 UTC