Hello,
Yes, I could reproduce the bug (with two differents servers). But I
would like to know if somebody else can reproduce it and if it is really
a bug.
There could be a reason for Slide developers to process the write
requests like that...
If it is a bug what are the classes to patch ?
I am very eager to have answers to this question because we are about to
use Slide on a large scale with sharing functionalities. :-)
Thomas
delbd wrote:
accroding to RFC 3744 WebDAV Access Control Protocol May 2004
3.1. DAV:read Privilege
The read privilege controls methods that return information about the
state of the resource, including the resource's properties. Affected
methods include GET and PROPFIND. Any implementation-defined
privilege that also controls access to GET and PROPFIND must be
aggregated under DAV:read - if an ACL grants access to DAV:read, the
client may expect that no other privilege needs to be granted to have
access to GET and PROPFIND. Additionally, the read privilege MUST
control the OPTIONS method.
3.2. DAV:write Privilege
The write privilege controls methods that lock a resource or modify
the content, dead properties, or (in the case of a collection)
membership of the resource, such as PUT and PROPPATCH. Note that
state modification is also controlled via locking (see section 5.3 of
[RFC2518]), so effective write access requires that both write
privileges and write locking requirements are satisfied. Any
implementation-defined privilege that also controls access to methods
modifying content, dead properties or collection membership must be
aggregated under DAV:write, e.g., if an ACL grants access to
DAV:write, the client may expect that no other privilege needs to be
granted to have access to PUT and PROPPATCH.
Appendix B. WebDAV Method Privilege Table (Normative)
...
+---------------------------------+---------------------------------+
| METHOD | PRIVILEGES |
+---------------------------------+---------------------------------+
| PUT (target exists) | <D:write-content> on target |
| | resource |
| PUT (no target exists) | <D:bind> on parent collection |
| | of target |
read priviledge on path should not be needed, and it seems you can reproduce bug
(as i said i didn't have much time to check it here, i siply granted read privilege, heritable on
source and everything went well). Maybe filling a bug report should be a good
idea :D
Le Mardi 28 Juin 2005 16:08, Thomas Bellembois a écrit :
Hello,
ACL evaluation is in accordance with your explanations.
But for the "write" permission Slide apparently requires a "read"
permission on the full path of the resource for the connected user, as
David said (we can see that in debug mode).
I have not found this requirement in the RFC, but perhaps not read well...
Regards,
Thomas
--
+---=( Thomas Bellembois )=---+
| CRI - University of Rennes 1 - FR |
| [EMAIL PROTECTED] |
| +33 2 23 23 69 60 |
+-----------------------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
