On Nov 5, 2004, at 8:45 AM, Julian Foad wrote:
> Ben Collins-Sussman wrote:
>> 1. check to see if there's a pre-existing lock on the file.
>> if not, proceed normally.
>> 2. if there's a lock, look at the 'owner' field in the lock. Is
>> it the same as the authenticated username? If not, error out.
>> 3. [check the lock-token]
>
> I'm not in this conversation, really, but, from a bystander's point of
> view, it is not clear why step 2 is needed. Why not just proceed to
> checking the lock token, which presumably includes the user name in
> some plain or implied form, without first checking the user name
> explicitly?
Just because you're doing a commit from a working copy that has a
lock-token belonging to "fred", doesn't mean you *are* fred. You might
be sharing a working copy with fred. You might have stolen his working
copy, who knows?
The locking design, from day 1, has always been that locking requires
two independent forms of authentication:
A. normal username/password authentication ("who's doing the
commit?")
B. a lock-token from a working copy ("which working copy is doing
the commit?")
These credentials must both be presented to make use of a lock. A
lock-token by itself is not proof of your identity: anybody can
fabricate one of those. They're publically fetchable things! A
username by itself isn't sufficient, because you might be using
multiple working copies or applications: the lock-token represents
authentication from a particular working copy or app. You don't want
them stomping on each other's activities, just because they all happen
to know your name/password.
(By the way, this design isn't some crazy thing I made up: it comes
from the WebDAV spec, and long predates even the DeltaV spec. While
WebDAV isn't wholly driving our design process, this is just one of
those things that seemed to make sense and fit well into Subversion.
Take a look at the locking-funcspec and locking-ui docs in notes/.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 5 16:30:49 2004