Hi Warwick
Warwick Burrows wrote:
I'm using the Slide CLI from the source tree on top of the webdav client. All the latest code from the 2.1 release branch. The trace for the UNLOCK request that I included below is the debug output of running the CLI with "set debug on". So what would the difference be in the result if the locktoken is sent with the "if" condition rather than the "lock-token" header?
The difference is that using the "Lock-Token header with UNLOCK is given in the WebDAV spec. and I don't know whether using the If-header will work with other webdav servers too.
The If header is intended to provide the lock token to write actions that are protected by locks.
And what is the kill-lock permission? Who would have this permission in a
default Slide installation?
Have a look at your Domain.xml. In the namepace configuration you will find a line like <kill-lock>/actions/unlock</kill-lock>. It says you must have the permission /actions/unlock to kill locks (i.e. to remove locks for which you are not owner). Typically the root user and the owner has that permission to remove locks which are left accidentally. But with security disabled I think this permission will not be checked.
BTW, even though security is disabled I still get the actual lock owner name back from the server in lock discovery calls so it knows who the owner is even if it doesn't enforce lock ownership.
Seems I mixed up security and authentication. You have security disabled (slide.properties) but authentication enabled (web.xml), right? Well, than your locks should have a proper owner.
Warwick
-----Original Message-----
From: Stefan L�tzkendorf [mailto:[EMAIL PROTECTED] Sent: Thursday, September 02, 2004 4:18 AM
To: Slide Users Mailing List
Subject: Re: unlocking locks owned by others
Well, my first answer was a little bit ... quick written.
As Carlos said, with security disabled anybody has the kill-lock permission.
The lock owner is the prinipal as that your are authneticated at the webapp.
So in addition to the first point with security disabled all users are treated as the single user "unauthenticated" so everybody is the lock owner and don't need "kill-lock".
But I observed a similar behavior with security _enabled_. You can delete resources that an other one has locked if you provide the lock token in the If header. That's invalid, I think, and that't I talk aboud in bug 30982.
An other point to mention. UNLOCK should not use the If header it must use the Lock-Token header to provide the lock token to be removed. What client do you use?
Cheers, Stefan
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.
to server ---------------------------------------------------
UNLOCK /slide/files/my%20stuff/outf HTTP/1.1 If: (<opaquelocktoken:600107b7c611f08d4bf10af71e6d3a3f>) User-Agent: Jakarta Commons-HttpClient/2.0rc3 Host: localhost:20080 Cookie: $Version=0; JSESSIONID=D1E5A4582544A30F431FFE72C628DEEB; $Path=/slide Content-Length: 0
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.
Thanks, Warwick
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- 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]
