> > What appears to be happening is that the unlock() method in the LockImpl
> > class does a series of 3 checks, which is sensible enough.
>
> Before, it wasn't checking anything, which was bad because DELETE started by
> unlocking all the locks which were on a resource before deleting the
> resource itself (so you could delete locked resources).
Ahh... I didn't realise that. ok, seems reasonable now.
>
> > The final of
> > thes, checkLockToken(), calls slideToken.checkLockToken(). This then
> > fails, because there's no reason that that particular slideToken would
> > have been used for the lock.
>
> That one should be ok.
> With the WebDAV servlet, the client has to submit the lock's lock token in
> the unlock command, and the lock token ends up in the Slide token.
> If you don't use WebDAV, SlideToken.isEnforceLockTokens() should return
> false, and checkLockToken() will always return true.
That was the key I was missing - I didn't realise that
isEnforceLockTokens() should return false (and indeed, my code which
uses slide directly does not - I'll fix that), so none of this ended up
making sense to me :-)
The fact that the lock token wasn't ending up the slide token also
confused me.
>
> > Surely we should be either not doing this at all (because when we do the
> > actual lock removal, if the lock isn't present, it'll fail), OR we
> > should be consulting the stores - the store knows whether there's a
> > lock, nothing else is guaranteed to (unless I'm missing something).
>
> You have to check the lock token to prevent :
> - being able to delete or overwrite (using copy or move) a locked resource
> - lock stealing
>
> Also, it's required by WebDAV, and I thought it was a good concept, so I
> moved the token check to the core (instead of doing it in the WebDAV
> servlet).
Yes, this makes sense now that I understand why it's neccesary to check
at this point.
Just noticed a commit - thanks for fixing this!
>
> Good luck for your exams :)
Thanks a lot.
Michael
