Edit files from our Websites with "IT Hit Webdav Ajax Library" (https://www.webdavsystem.com/ajax/) is not possible with cookie authentication.
Steps to Reproduce:
1. On windows 10, mount a shared network on webdav url https://myServerDomain.com/DAV
2. Open file with this kind of url \\myServerDomain.com@SSL\DavWWWRoot\DAV\ioC8Whe4fk-2QhGllJokKA\sample.odt
3. LibreOffice should open the file with no webdav protocol (or manage cookies in webdav http calls.)
Windows Webclient is no more used.
LibreOffice opens our network file with the webdav protocol.
Http Cookies are not kept and sent back during the exchanges with our application.
Cookies must be managed by LibreOffice during the http calls and sent back.
or \\server@SSL\DavWWWRoot\ should not be managed to keep Windows access to the file (without lock and full webdav)
User Profile Reset: No
Our application is using IT Hit Webdav Ajax Library to edit LibreOffice files (https://www.webdavsystem.com/ajax/).
Sample url : https://myServerDomain.com/DAV/ioC8Whe4fk-2QhGllJokKA/sample.odt
This tool opens a windows folder on the url like https://myServerDomain.com/DAV
and then we can open our files like a file in shared network.
This uses the Windows service "WebClient" to host all the web calls to open the remote file.
The user-agent seen by our application is "Microsoft-WebDAV-MiniRedir".
Since the first version 6.4 (we tested on the rc and not the 6.4 alpha), Libreoffice detects that the shared network is a webdav share and starts a webdav communication with our application.
We see a user-Agent "LibreOffice" in the http request but the authentication cookie is lost during the calls.
Without the cookie, user is disconnected and it's a HTTP 401. User sees a prompt for a basic authentication by login/password.
We used a single-use token in the url to authenticate our user on a file.
This is the best trick to manage openId session on our application.
Hve you tested with latest version from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version. Change to RESOLVED WORKSFORME, if the problem went away.
Yes, the bug is still present in version 7.1.2.
If you don't mind downloading 7-8 GB, the best would be if you could bibisect it as described in . Bibisecting is using git bisect to look through a repository of binary builds. There's an individual repository for each version, in this case you probably need 'bibisect-win64-6.4' from .
Unless you're sure it worked fine in 6.3, and started not working in 6.4, then it's good to check in 220.127.116.11 (or 18.104.22.168.beta1, or any 6.3.0.x RC) first.
Created attachment 171011 [details]
Git bibisect execution log
Here is the full bibisect log.
To sum up :
# first bad commit: [f202498f5a7ea226aaece686dbb25117e92a04f5] source 20b1e6440aacab043753e93be4499e939a80b05b
So the only version we could see working while bibisecting was 22.214.171.124.alpha0+ (x64).
(In reply to Demarthe from comment #4)
> To sum up :
> # first bad commit: [f202498f5a7ea226aaece686dbb25117e92a04f5] source
Author: Norbert Thiebaud <firstname.lastname@example.org>
Date: Fri Jun 28 00:10:08 2019 -0700
cc: Norbert Thiebaud
(In reply to Dieter from comment #5)
> Author: Norbert Thiebaud <email@example.com>
> Date: Fri Jun 28 00:10:08 2019 -0700
That is the commit in the bibisect repo, not the source commit. The actual commit is the following one, identified by the 'source sha' in the result. Let's add Mike to CC.
author Mike Kaganski <firstname.lastname@example.org> 2019-01-09 10:54:10 +0300
committer Mike Kaganski <email@example.com> 2019-06-28 08:33:46 +0200
tdf#126121: WebDAV redirection detection
May we have some feedback on this bug ? Do you need more informations from us ?
Mike, can you have a look at it?
It will add a new expert configuration option: org.openoffice.Office.Common/Load/DetectWebDAVRedirection, which would control this new behavior introduced in tdf#126121. By default, it will be true, allowing to detect the WebDAV mapped drives, and using WebDAV to get file's properties. When set to false, it will return to the older way of using Windows mechanisms of accessing the file through system path.
This allows to centrally configure the option in corporate environments if needed: see https://wiki.documentfoundation.org/Deployment_and_Migration#Some_tricks_for_post_deployment_configuration
Note that this will be only available since 7.2.
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":
tdf#141164: Add an expert config for WebDAV redirection detection
It will be available in 7.2.0.
The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
The bug is fixed within the daily build when DetectWebDAVRedirection is set to false. It's ok for us.
Thank you all for the work.
Marked as fixed based on comment 12, from reporter.