jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jou Kou-Rong" <Kou-Rong....@irs.gov>
Subject RE: unlock file
Date Thu, 23 Oct 2008 12:54:16 GMT
Angela,

I also have a need to maintain the lock token across sessions. Is using our application to
save the session token in the jackrabbit repository a reasonable approach?

Thanks,
Chuck


-----Original Message-----
From: Angela Schreiber [mailto:anchela@day.com] 
Sent: Thursday, October 23, 2008 8:26 AM
To: users@jackrabbit.apache.org
Subject: Re: unlock file

hi tobias

so the client side looks as follows:

- Netdrive sends a PROPFIND request to obtain the
   lock-token before any attempt is made to send the
   UNLOCK request.

- It probable expects that the lock-token to be
   provided (which is not the case).

- ... consequently doesn't even try to UNLOCK.

- maybe: Netdrive didn't remember the lock-token
   upon creating the lock and is therefore asking
   for it via PROPFIND.


the server side looks as follows:

- no session caching -> logout after each request.

- as discribed in my previous mail, the lock tokens
   are removed from the session to have the ability
   to attach them later on to a new session.

- JSR 170 mandates that the lock holder is not determined
   by a user identication but instead the lock holder
   can only be a single session object.
   thus: only the lock holding session can retrieve the token
         upon Lock#getLockToken().
   that's the reason why the token is not present in the
   PROPFIND response.

- if the client forgets the token the ability to unlock
   the node is lost (unless the impl. provides some sort
   of administrator that is always allowed to unlock).

for further reading you may also take a look at
http://issues.apache.org/jira/browse/JCR-779

with JSR 283 there will the possibility to specify a timeout hint as suggested in JCR-779.

alternatively, you may provide a custom SessionProvider upon SimpleWebdavServlet#getSessionProvider
that is able to return the same session through multiple requests and defines some sort of
automated logout after some time of inactivity.

regards
angela


truebner@sachsendv.de wrote:
> Hi Angela,
> 
> I had a look into the jackrabbit webdav api, to understand how things 
> are done.
> So here are the request headers from performing an unlock by netdrive 
> (that fails):
> 
> 12:07:45,436 INFO  [STDOUT] 23.10.2008 12:07:45 *INFO *
> SimpleWebdavServlet: [RequestMethod] PROPFIND 
> (SimpleWebdavServlet.java, line 83)
> 12:07:45,437 INFO  [STDOUT] 23.10.2008 12:07:45 *INFO *
> SimpleWebdavServlet: [RequestURI]
> /jackrabbit-webapp-1.4/repository/default/data/image.jpg
> (SimpleWebdavServlet.java, line 84)
> 12:07:45,437 INFO  [STDOUT] 23.10.2008 12:07:45 *INFO *
> SimpleWebdavServlet: [RequestProtocol] HTTP/1.1 
> (SimpleWebdavServlet.java, line 85)
> 12:07:45,438 INFO  [STDOUT] 23.10.2008 12:07:45 *INFO *
> SimpleWebdavServlet: [DavProperty] locktoken 
> (SimpleWebdavServlet.java, line 93)
> 12:07:45,439 INFO  [STDOUT] 23.10.2008 12:07:45 *INFO *
> SimpleWebdavServlet: [DavProperty] lockdiscovery 
> (SimpleWebdavServlet.java, line 93)
> 12:07:45,439 INFO  [STDOUT] 23.10.2008 12:07:45 *INFO *
> SimpleWebdavServlet: [Header] content-type: text/xml 
> (SimpleWebdavServlet.java, line 105)
> 12:07:45,439 INFO  [STDOUT] 23.10.2008 12:07:45 *INFO *
> SimpleWebdavServlet: [Header] depth: 0 (SimpleWebdavServlet.java, line
> 105)
> 12:07:45,440 INFO  [STDOUT] 23.10.2008 12:07:45 *INFO *
> SimpleWebdavServlet: [Header] host: xxxx.de (SimpleWebdavServlet.java, 
> line 105) 12:07:45,440 INFO  [STDOUT] 23.10.2008 12:07:45 *INFO *
> SimpleWebdavServlet: [Header] user-agent: Microsoft Data Access 
> Internet Publishing Provider DAV (SimpleWebdavServlet.java, line 105) 
> 12:07:45,440 INFO  [STDOUT] 23.10.2008 12:07:45 *INFO *
> SimpleWebdavServlet: [Header] accept-language: en-us 
> (SimpleWebdavServlet.java, line 105)
> 12:07:45,441 INFO  [STDOUT] 23.10.2008 12:07:45 *INFO *
> SimpleWebdavServlet: [Header] translate: f (SimpleWebdavServlet.java, 
> line
> 105)
> 12:07:45,441 INFO  [STDOUT] 23.10.2008 12:07:45 *INFO *
> SimpleWebdavServlet: [Header] pragma: no-cache 
> (SimpleWebdavServlet.java, line 105)
> 12:07:45,441 INFO  [STDOUT] 23.10.2008 12:07:45 *INFO *
> SimpleWebdavServlet: [Header] connection: close 
> (SimpleWebdavServlet.java, line 105)
> 12:07:45,442 INFO  [STDOUT] 23.10.2008 12:07:45 *INFO *
> SimpleWebdavServlet: [Header] authorization: Basic xxxx 
> (SimpleWebdavServlet.java, line 105)
> 
> And here I have the webdav multistatus response:
> <D:multistatus xmlns:D="DAV:">
>   <D:response>
>     <D:href>http://xxxxx.de/jackrabbit-webapp-1.4/repository/default/
> data/image.jpg</D:href>
>     <D:propstat>
>       <D:prop>
>         <D:getlastmodified>2008-08-18T14:04:47Z</D:getlastmodified>
>         <D:getcontentlength>14177</D:getcontentlength>
>         <D:getcontenttype>image/jpeg</D:getcontenttype>
>         <D:creationdate>2008-10-21T09:48:45Z</D:creationdate>
>         <D:getetag>"14177-1224582535208"</D:getetag>
>         <D:displayname>image.jpg</D:displayname>
>         <D:supportedlock>
>           <D:lockentry>
>             <D:lockscope>
>               <D:exclusive/>
>             </D:lockscope>
>             <D:locktype>
>               <D:write/>
>             </D:locktype>
>           </D:lockentry>
>         </D:supportedlock>
>         <D:resourcetype/>
>         <D:lockdiscovery>
>           <D:activelock>
>             <D:lockscope>
>               <D:exclusive/>
>             </D:lockscope>
>             <D:locktype>
>               <D:write/>
>             </D:locktype>
>             <D:depth>infinity</D:depth>
>             <D:timeout>Second-2147483</D:timeout>
>             <D:owner>editor</D:owner>
>           </D:activelock>
>         </D:lockdiscovery>
>         <D:iscollection>0</D:iscollection>
>       </D:prop>
>       <D:status>HTTP/1.1 200 OK</D:status>
>     </D:propstat>
>   </D:response>
> </D:multistatus>
> 
> Having a look into rfc 2513 (
> http://www.apps.ietf.org/rfc/rfc2518.html#sec-12.1.2) the response 
> seems to be ok.
> There is just the lock token missing, because I can't see any lock 
> related headers in the request of NetDrive.
> 
> Do you need more information?
> 
> Tobias
> 
> 
> Angela Schreiber <anchela@day.com> wrote on 22.10.2008 14:47:12:
> 
>> [image removed]
>>
>> Re: unlock file **SPAM Verdacht**
>>
>> Angela Schreiber
>>
>> to:
>>
>> users
>>
>> 22.10.2008 14:45
>>
>> Please respond to users
>>
>> hi
>>
>>> actually I don't think this is a webdav issue, it's more a question
> about
>>> unlocking files, locked by a previous session.
>> that's what the error says. but it can still be a webdav issue.
>>
>> with the default setup of the simple dav-servlet the lock tokens get 
>> removed from the session before it is logged out. if a new session is 
>> obtained the lock-tokens retrieved from the dav-request headers are 
>> put to the session.
>>
>> thus: implicit lock token transfer.
>> the only thing that is required is, that the client sends the correct 
>> lock token with a modification request
>> (If-Header) or an unlock request (Lock-Token header).
>>
>> this is basically what i wanted to take a closer look at in the 
>> conversation.
>>
>>> AFAIK I need the lock token for unlocking a file.
>> correct. as far as i know it is the client's responsibility to send 
>> the lock token it obtained from the LOCK request or a PROPFIND for 
>> DAV:lockdiscovery
>>
>>> This token is hold by the session created this file.
>> is hold by the session that created the lock by calling LOCK in 
>> webdav or (alternatively) interally by calling javax.jcr.Node.lock().
>>
>>> What if the session has ended?
>> if the session has ended it depends on the type of JCR lock you 
>> created:
>> - session-scoped locks are automatically removed
>>    (not used with the simple dav servlet)
>> - for open-scoped locks the lock token must be
>>    retrieved from the lock-holding session before.
>>    then removed from that session and later on
>>    added to second session to make the second
>>    become the lock-holder.
>>    -> see above for the logic implemented in the
>>       simple server.
>>
>>> So my question should be: How can I get the lock token from another
> (maybe
>>> allready ended) session?
>> yes, if you retrieved the lock token AND remove it from the session 
>> that is going to be logged out.
>>
>> see Session#getLockTokens/addLockToken/removeLockToken
>> for the corresponding instructions.
>>
>>> By the way, how can I trace the http conversion of a windows network 
>>> drive?
>> i use to connect to a proxy that logs the conversation instead of 
>> connecting to the server directly. i guess there is some sort of free 
>> available equivalent to that helper.
>>
>> angela
> 
> 
> 
> _________________________________________________________________
> 
> Sachsen DV Betriebs- und Servicegesellschaft mbH Täubchenweg 26
> 04317 Leipzig
> Amtsgericht Leipzig, HRB 18545
> 
> Geschäftsführer: Herbert Roller Brandão, Dr. Jean-Michael Pfitzner
> 
> Aufsichtsratsvorsitzender: Andreas Benninger


Mime
View raw message