RE: HOW_TO_IDENTIFY_LOCK_OWNER

   From: Lisa Dusseault [mailto:lisa@xythos.com]

   Geoff said:
   > The client should never automatically reuse a lock taken out
   > by another client (irrespective of whether or not it was another
   > client with the same authentication credentials), but should only
   > steal another client's lock on explicit request by the user.

   Not even that liberal: the client should only *remove* another
   client's lock on explicit request by the user.  The client should
   never reuse another client's lock.  Ever.  (The ambiguity may just
   be in the word steal - I'm not sure what you intend here Geoff)

I completely agree with Lisa here.  By "steal", I meant unlocking the
old lock, and creating a new lock on the same resource.

   > So I agree that information about the user that took out the lock
   > is required, but this info is available in the DAV:owner field.

   No, this info is not necessarily available in the DAV:owner field.
   Because the client can submit this field, the client can submit
   bogus information, and it's not necessarily possible for the server
   to decide if the information is bogus.

It doesn't matter what the server thinks ... the purpose of the
DAV:owner field is to let a client know whether it is "his own" lock,
and if not, how to contact the lock owner.  In either case this is a
client/client communication, not a client/server.  For security
reasons, if a client wishes/needs to submit "bogus" (or obscure)
information, it should be allowed to do so, and not have these
security wishes violated by the server.  The only "harm" of this bogus
information is that the user might not recognize "his own" lock (which
should be the user's choice) or that another user might not be able to
contact him (which also should be his choice).

   > The only reason this information needs to be supplemented, is to
   > let the client know whether or not the user will in fact be allowed
   > to steal the lock (assuming that he/she wants to), and that is the
   > info provided by the DAV:can-lock and DAV:can-unlock privileges.

   It's not necessarily an issue of privilege, it may be an issue of
   system policy.  I'm not sure if using can-lock and can-unlock
   privileges addresses that.

The DAV:can-lock and DAV:can-unlock address the system policy issues
that I am aware of.

Cheers,
Geoff

Received on Tuesday, 15 January 2002 10:44:42 UTC