[jira] [Comment Edited] (OAK-10166) Oak creates bogus lock token causing locking issue when editing a document by WebDAV with LibreOffice

["Julian Reschke (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OAK-10166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17737054#comment-17737054 ] 

Julian Reschke edited comment on OAK-10166 at 6/26/23 9:05 AM:
---------------------------------------------------------------

[~baedke] - do you want to have a look? (I personally believe it's a client bug that we may want to report...)


was (Author: reschke):
[~baedke] - do you want to have a look?

> Oak creates bogus lock token causing locking issue when editing a document by WebDAV with LibreOffice
> -----------------------------------------------------------------------------------------------------
>
>                 Key: OAK-10166
>                 URL: https://issues.apache.org/jira/browse/OAK-10166
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: core, jcr
>    Affects Versions: 1.48.0
>            Reporter: Miguel Moquillon
>            Assignee: Manfred Baedke
>            Priority: Major
>             Fix For: 1.54.0
>
>
> In a webapp application using Apache Jackrabbit Oak implementation of the JCR, the WebDAV access of office documents are provided with Jackrabbit {_}SimpleWebDavServlet{_}.
> When a document is opened through WebDAV by an office suite (here LibreOffice), a lock token is created and passed to the client. This lock token is generated by _JcrActiveLock_ which delegates the generation to _LockTokenMapper_ which, in the case of Oak, uses for doing {_}LockImpl#getLockToken(){_}. This method returns as token the path in the JCR of the node representing the file. Because the path contains the '/' separators, those are converted in "%2f". But, some office suite like LibreOffice seams to parse this token because they send back as token in the request header "Lock-Token" the token value in which the '/' character is encoded in "%2F" instead of "%2f" provoking consequently an error when unlocking the document.
> It should be fine to avoid to pass the path of the document in the JCR as a token value. At least, it should be encoded in Base64 or any other encoder.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)