Hi all! While digging further into lock support for the Webav component I discovered 2 issues where I do not see a solution for, yet. Therefore I'd like to discuss these here on the list. I hope that I can summarize the 2 issues without digging too deep into other aspects of WebDAV.
Null resources ============== Introduction ------------ Webdav supports a request called LOCK, which allows a user to acquire a lock on a certain resource. We want to handle locking completly independant from the backend (as a plugin for the currently marked private plugin API). To support locking of not yet existent resources a so called "null-lock" must be supported and the resource affected by a null-lock is called a "lock-null resource". Null-locks might be used by a client before uploading a new non-collection (file) resource (PUT method) or before creating a new collection (directory) resource (MKCOL). Lock-null resources must only support a certain set of operations and are not allowed to support certain others. For example: A lock-null resource must appear in the response to a PROPFIND request (which is used for directory-listings), but must not support the GET operation, since it is physically not existent. If a lock-null resource is unlocked without a successful PUT or MKCOL method call, it must disappear again. The problem ------------ For our special case this means, that we need to "physically" create lock-null resources in the utilized backend, to make it persist during requests, whenever a null-lock is acquired. This lock-null resource must not appear as a real resource to the client (e.g. must not have a correct content type and must not responde to GET requests). If the resource is unlocked again, it must be removed from the backend again. In our internal handling, that means, that we need to intervene any of the operations not supported by a lock-null resource (e.g. COPY, MOVE, PROPPATCH) requests to check is a lock-null resource is affected and remove it potentially or forbid the operation. Furthermore, we need to intervene any operation that is supported by a lock-null resource to remove potential information from responses that must not be available for lock-null resources. This will mean a lot of internally generated requests to the backend and a lot of processing of the backend generated responses. For example, if a MOVE request is issued by a client, we need to check the whole affected directory tree for lock-null resources and remove those from the destination and send a special error code for them in the response. Atomicity of operations also comes into play here, since our internal requests to the backend might interfer with other external requests. For example, a null-lock might be acquired by the client while we are internally checking the correctness of a MOVE request (race-condition). Solution attempts ----------------- I currently do not see a full solution for this problem, still there are some ideas in my mind, that might be helpful. For lock-null resources we can invent a special dead-property namespace to indicate such resources. If a special (for lock-null resources forbidden) operation occurs, we can easily check for them using a PROPFIND request. Creating and maintaining lock-null resources should then be not problem. For the race-condition issue, we'll definitly need support in the backend, because I see no other solution attemt here to ensure the consistency. Authentication ============== Introduction ------------ WebDAV describes locks in terms of so called lock-tokens, which identify a single lock on a single resource uniquely. Lock-tokens must be unique over all servers, all resources for all times. However, lock-tokens are not secret. Every client can simple perform a PROPFIND request, to discover lock tokens of an active lock. The WebDAV RFC only gives the hint, that authentication mechanisms in place must ensure, that a lock is only being manipulated and used by its correctl owner. The property that is used to describe lock information (ACTIVELOCK) still provides a field "owner" which can be used to store certain information on the lock owner that might be used to verify access to the lock. The problem ----------- We currently do not support any authentication mechanism in the Webdav component. To realize locking, we need to support at least 1 authenticattion model in the component. Solution attempts ----------------- A possibility to integrate this would be a WebdavAuthenticationTiein, while supporting certain mechanisms like OpenID and TypeKey could be impossible (WebDAV clients usualy don't support standard HTTP browsing). However, realizing this tie-in is a dedicated task and will consume quite some ammount of time. An intermediate solution could be to rely on certain client-provided data, like the client IP address. This is a very insecure authentication theme, but it will at least help us to identify the owner of a lock in some way. Another problem here are users which perform WebDAV operations through a proxy server. That's it from my side for now. I hope to get some creative and helpful answers and comments! :) Cheers! Toby -- Mit freundlichen Grüßen / Med vennlig hilsen / With kind regards Tobias Schlitt (GPG: 0xC462BC14) eZ Components Developer [EMAIL PROTECTED] | eZ Systems AS | ez.no -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
