- From: Yaron Goland <yarong@microsoft.com>
- Date: Tue, 14 Jul 1998 17:19:48 -0700
- To: "'Jim Amsden'" <jamsden@us.ibm.com>, w3c-dist-auth@w3.org
> <jra> > 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? I see > that it works with exclusive locks because there can only be one. > </jra> So we agree that we can always resolve the proper lock token for an exclusive lock, the question now is how to handle a shared lock. I believe that the core of your misunderstanding is that you believe that when a shared lock is issued there will be multiple lock tokens for each owner of the shared lock. That is not the case. A shared lock has one and only one lock token assigned to it, regardless of the number of owners. Thus if you ask for a shared lock and you get back a successful result then you need only examine the body to find out which entry describes the shared lock you asked for (by definition there can be only one) and you know which one identifies your lock token. A further legitimate issue is how to identify your lock in the case where you have "lost" your memory. Again the owner header can be useful here. Shared locks are free to add multiple entries inside of owner so a client can always recognize its own owner entry. However I certainly believe that the world will be a better place when the standard principal identifier is agreed on by the ACL types. > <jra> > But DAV did specify Basic (with SSL) and Digest authorization > schemes must be > supported for security. They both provide the principal > userid. Couldn't this > be used? > > Next, the temporary hack couldn't be relied upon as not all > servers would > necessarily do it the same way. > > So I still don't see how an application can get the lock > token from the lock it > just requested. > </jra> > However SSL uses a completely different principal identifier (a certificate). Rather than try to shoe horn a "universal" principal identifier we decided to punt the problem to the ACL group. Yaron
Received on Tuesday, 14 July 1998 20:19:27 UTC