[
https://issues.apache.org/jira/browse/OAK-10166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17740583#comment-17740583
]
Manfred Baedke commented on OAK-10166:
--------------------------------------
I Missed that somehow. I agree.
> 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
>
> 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)
