- From: <jamsden@us.ibm.com>
- Date: Wed, 26 Jan 2000 12:42:33 -0500
- To: w3c-dist-auth@w3.org
But Geoff, the semantics you describe below would make locks useless (maybe your intent?!). If only the lock token was used to protect from overwrite conflicts, then any user could just do a PROPFIND, get the lock token from the DAV:lockdiscovery element, and then have at the resource! The spec indicates that the user agent owning the lock, the one taking out the lock in the LOCK request, must be specified along with the lock token. It does not however say exactly what the user agent is. That's because ACLs weren't done yet, and the working group didn't want to define principal. So they just punted and left if up to the server implementation with server-specific ACL mechanisms until the ACL spec was done. This is why the principal element wasn't included in the DAV:activelock element. However, I think we've made enough progress in defining ACLs and principals that we can now safely include this information in DAV:activelock in which case all problems are resolved. "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>@w3.org on 01/25/2000 04:24:54 PM Sent by: w3c-dist-auth-request@w3.org To: w3c-dist-auth@w3.org cc: Subject: Re: RFC-2518 LOCK-TOKEN: header From: bill@carpenter.ORG (WJCarpenter) gmc> Section 6.3 of RFC-2518 states that you can get the lock token gmc> through the lock discovery property: Yeah, that's what I was thinking (especially as the lock discovery property is the prescribed payload returned after a successful LOCK request). But Jim Amsden is right that that's not sufficient. ... The DAV:owner property is just so much commentary by the LOCK requester. It explicitly has no bearing on the out-of-band authentication. In short, it can be a complete lie or completely irrelevant. I think the idea of DAV:owner was for human consumption, in case you want to track down the LOCK owner and beat him/her with a stick until s/he releases the LOCK. It is by design not at all helpful to the server in deciding whether the principal attempting a change is the LOCK holder or not. There seem to be two issues here. The first is whether a server should authenticate that the principal specifying the lock token in an IF header is the same principal that created the lock token in a lock request. This is not required by WebDAV, since it is pretty pointless to carefully guard a lock token when as soon as you UNLOCK the resource, anyone can come in and trash the resource. Lock tokens are for avoiding merges, not for security. So if you want interoperable security, you should become active in the WebDAV ACL's effort. If you try to get it from WebDAV locking and lock tokens, you will be doomed to disappointment. But that's not because WebDAV locking is broken (it in fact does a great job of avoiding merges), but rather that it doesn't do what it wasn't designed to do. The second issue is whether a client other than the lock requesting client should be able to use the lock token to get access to a resource. Doing so would violate the whole design of the lock token scheme, which is to have a protocol for reliably deciding whether a *particular* client has the authority granted by the lock token. The protocol only works if only the client that made the LOCK request uses the generated lock token. The fact that the lock token was issued to a particular principal is irrelevant. So a client should always get its own lock token, not appropriate an existing one. If a resource is already exclusively locked, it first will need to UNLOCK the resource. This then guarantees that if the other client (that issued the LOCK request) is still around, it will notice the "cancellation" by the failure of its next update request. For exclusive LOCKs, you can assume from the lock discovery part of a successful response that you got the applicable token mentioned. For shared LOCKs, you need the LOCK-TOKEN: header or some additional goop in lock discovery conveying "authenticated" ownership. There is even less point in authenticating shared lock ownership (which I guess makes it a negative number, since I argue above that there is no point in authenticating exclusive lock ownership :-). If you are a principal that has the right to take out a shared lock, you can just get one - you don't need to use some existing shared lock. For the problem you mention, of multiple clients being run by the same principal, there is no sanctioned, unambiguous way to do lock discovery. There is a sanctioned unambiguous way to do lock discovery ... there just is (by design) no sanctioned way to do lock appropriation (:-). Cheers, Geoff P.S. I may be all wrong about this, since my livelihood is versioning, not locking, but I don't think so (:-).
Received on Wednesday, 26 January 2000 18:01:09 UTC