[
https://issues.apache.org/jira/browse/OAK-10166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber moved JCR-4916 to OAK-10166:
---------------------------------------------
Key: OAK-10166 (was: JCR-4916)
Workflow: no-reopen-closed (was: no-reopen-closed, patch-avail)
Project: Jackrabbit Oak (was: Jackrabbit Content Repository)
> 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
> Reporter: Miguel Moquillon
> 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)
