RE: Locking questions

Jim Amsden writes:
> Sure, I'll take a T-shirt - large. But, I don't think we're out
> of the woods yet. There are still a couple of problems. First,
> as you already noted, there is no way for an application that
> has "lost" a lock token to use a lockdiscovery property to get
> it back. Using the owner element hack is a work-around, but
> would result in non-standard servers. Another is for the
> application to just try each lock token until it finds one that
> works. Pretty ugly. This really limits the usefulness of
> lockdiscovery too.

So what you suggest is an operation which returns, for a given resource, all
lock tokens for locks owned by the principal making the request.  This is
different from lockdiscovery, since lockdiscovery gives you all lock tokens
owned by all principals.

I'm not yet convinced that requiring applications to persistently store lock
tokens is a bad idea, and if they get sufficiently confused to lose their
persistently stored lock tokens, then the brute force mechanism of trying
each one in turn doesn't seem that bad for an infrequent error recovery
situation (i.e., losing the persistently stored lock token for a shared lock
in which there were more than one principal actively locking the resource).

If such a feature is needed (I'm not yet convinced), then a "LOCKINFO"
method could potentially solve this dilemma.  The semantics would be to
return the lock tokens (in suitable XML packaging) for all locks owned by
the principal who made the request.

> Worse than this though is that locking on the server can't work
> for the same reason. Say a principal submits a PUT request on a
> locked resource. The If header contains a precondition containing
> the appropriate lock token for the locked resource. However, the
> server can't determine if the requesting principal owns the given
> lock token! This is because the server can't lookup the lock using
> a lockdiscovery since it's activelock elements don't contain the
> principal.

This is true iff the server only stores the same information as is contained
in the activelock element.  However, as you adroitly point out, a server
which only stores this information will be unable to validate a principal
against a lock token.

> So there is no way for the server to determine if the
> resource is locked by the requesting user. If you leave out the
> principal and don't match on it in the server, then any application
> could get any lock token it wanted out of the lockdiscovery property
> and modify anything. Servers could of course use some other mechanism
> to attach principals to lock tokens, but this re-introduces the same
> authorization id problem that DAV was trying to avoid.

It's much easier to implement a single server, where you can set
authentication policies, than writing an interoperability specification like
WebDAV which has to accomodate many different policies.

So, I can easily imagine a server which has an internal notion of principal
(each principal having an associated id), and which maps these principal ids
to basic (via SSL) and digest authentication credentials.  This server would
then persistently store the principal identifier with each lock token owned
by that principal.  This mapping of principal id to lock token would be
internal to the server, and would not be exposed via the lockdiscovery
mechanism (since there is still no standard, interoperable way of
identifying principals in DAV).  But, when the principal submits a lock
token with either basic (via SSL) or digest auth credentials, the server
*does* have sufficient information to map the auth credentials to the
internal principal identifier, and the server can verify that the
authenticated principal does, in fact, own a given lock token.

> It would also fragment lock information producing poor encapsulation in
> implementations. In addition, DAV wouldn't have proper "closure"
> in that it wouldn't save information it requires to meet its own
semantics.

These assertions need more backup before I'll accept them.

> It all boils down to you can't have principal based locking without the
> principal. I suggest DAV use the userid from the Basic or Digest
> scheme and that all methods requiring access permission (e.g., any method
> that updates a locked resource in this version of DAV) submit an
Authorization
> header.

This is how the Web works today, as specified by RFC 2068.  If you're trying
to modify a resource and it's not world-readable, you'll be asked (via a 401
Unauthorized response with a WWW-Authenticate header) to submit
authentication credentials.  This is capability that WebDAV inherits from
HTTP.

> When ACLs are introduced, there will have to be some upward-compatible way
to
> identify a principal. The reason for using the userid instead of the whole
> authorization header is to avoid the particularities of the authorization
> schemes. It is highly likely that any ACL, authorization, or
> locking scheme will have to identify principals as that's kind of the
point.

This will indeed be a challenge.

> Another suggestion: LOCK should return an activelock elmement, not a
> lockdiscovery. 99.99% of the time, its the lock token just granted the
> application needs, and if more information is needed, use
> PROPFIND to get the
> lockdiscovery. This simplifies client applications significantly.

In my mind, I envisioned a function which takes an lockdiscovery XML subtree
and outputs a list of filled-in lock objects.  This routine is reusable
everywhere a lockdiscovery is returned.  If this routine must be written
once for receiving a lockdiscovery, I don't see why it adds complexity to
reuse it for LOCK responses.

- Jim

Received on Thursday, 16 July 1998 23:44:11 UTC