> From: Andreas Probst [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, October 09, 2002 12:18 PM > To: Slide Users Mailing List > Subject: RE: Verifying access > > > Hi all, > > please see intermixed. > > Andreas > > > On 8 Oct 2002 at 14:47, Julian Reschke wrote: > > > > From: Jacob Lund [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, October 08, 2002 2:42 PM > > > To: 'Slide Users Mailing List' > > > Subject: RE: Verifying access > > > > > > > > > Thanks for the reply! > > > > > > From what I can see in the thread you referred to, they do not verify > > > that they have access rights! > > > > > > You where right about the lock-token! In the case where a > user asks for > > > a lock-token (lockdiscovery or propfind) on a resource where another > > > user took out the lock - the locktoken will be: > > > opaquelocktoken:faketoken! However this response does not seem to be > > > > If this is indeed returned, it's a severe bug in Slide that needs to be > > fixed. > > I thought the faketoken was returned to prevent users from > stealing other users' locks.
That may be the intent, but it breaks the protocol. The URI returned as lock token - must be a legal URI (this one isn't, because it doesn't follow the syntactic rules for the opaquelocktoken scheme) - must identity the lock. Prevention of other principals (ab)using the lock token is a completely separate issue that needs to be treated somewhere else. > > > described in the webdav or the deltaV documentation! Is this slide > > > sprcific?? > > > > > > Basically what I need is some command the verifies write-access to a > > > resource! Are there any commands beside PUT and PROPPATCH that are > > > denied when a lock is taken on a resource? DELETE, RENAME, ...: -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
