W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1998

Re: Locking questions

From: Jim Amsden <jamsden@us.ibm.com>
Date: Fri, 10 Jul 1998 16:07:49 -0400
To: <w3c-dist-auth@w3.org>
Message-ID: <5040100020249391000002L012*@MHS>

The app knows which credential it submitted in the lock request, but the
activelock in the lockdiscovery returned in the prop of a lock result entity
body does not contain this information. Owner is not sufficient as it is
optional and does not necessarily contain the authorization credentials. So if
there are a number of shared write locks on the resource, there is no way for
the client app to figure out which one is his - the one just granted.

Unfortunately, the spec does not say what happens with locked resources within
a collection other than that the locks are not copied or moved. It only says
that the destination must available (i.e., unlocked or locked by requesting
requesting principal, and have an If header containing the target lock tokens)
for copy, and the source and destination for a move. The only statement about
locks in a collection is that they aren't copied or moved. So If a principal
has a resource locked in an unlocked collection, and another principal moves
the collection to another url, then the lock is lost and anyone can edit the
resource and then move it back. I doubt this was the intention of the spec, but
it seems to be the way it reads.

Can anyone clarify these issues? They seem like potential show stoppers.

w3c-dist-auth-request@w3.org on 07/10/98 02:33:07 PM
Please respond to w3c-dist-auth-request@w3.org
To: Jim Amsden/Raleigh/IBM@ibmus
cc: w3c-dist-auth@w3.org
Subject: Re: Locking questions

Jim Amsden wrote:

> But there may be many shared locks in the lockdiscovery property. How would an
> application figure out which one was the one just created for this user?

Because the app knows which credentials it submitted in the LOCK request.

> If locks are lost on a move, why bother having the lock
> tokens in the If header? Could users subvert locking by moving the resource to
> another location, editing it, and then moving it back?

No, because they can't move it if someone else has locked it.

|John (Francis) Stracke    |My opinions are my own.|S/MIME supported |
|Software Retrophrenologist|=========================================|
|Netscape Comm. Corp.      | "Where's your sense of adventure?"      |
|francis@netscape.com      | "Hiding under the bed."                 |
New area code for work number: 650
Received on Friday, 10 July 1998 16:04:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:14 UTC