Ok, that sounds like a good place to start. I'll investigate tomorrow to see whether my turning security off caused the change in behaviour. Thanks.
And although the spec may say the lock owner is informational Slide's behaviour was to enforce locks and I hope that it will do the same again once I enable security (or work around it). Weird thing is that during one run of the slide server locks were getting enforced. The next time I started the server after submitting some changes I had just added to my tree they weren't :-) It certainly seems to be config related. Thanks, Warwick -----Original Message----- From: Carlos Villegas [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 01, 2004 8:49 PM To: Slide Users Mailing List Subject: Re: unlocking locks owned by others Warwick Burrows wrote: >Can any user unlock another user's locks? I didn't think that was >valid. What I'm seeing in 2.1B1 is that any user (the default for the >CLI being called "Slide") can unlock a lock owned by another user. I >worked my way through the client piece of the puzzle and I see that it >is setting the locktoken in the header of the unlock request. But I >don't see where its setting the owner? eg. > > > >... > >Is it supposed to set the owner information in the request header so >that the server knows who is trying to do the unlock and can compare it >to the lock owner? I've still to look into the server side. I'm running >my configuration with security disabled but locks enabled in >slide.properties. > > > Isn't it because security is disabled? There is a permission for unlocking other user's locks. If security is disabled, no checks are done, which means anybody can unlock any lock. Also, my understanding is that the owner element in the lockMethod request is only informational. (The spec says it may contain phone number or home page of owner). A lock is identified only by the lock token and the principal owner of the token is determined by the current user (the user that was authenticated on login). Similarly, unlock uses the current session user as the principal requesting the unlock. Carlos --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
