Description: 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.) Actual Results: 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. Expected Results: 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) Reproducible: Always User Profile Reset: No Additional Info: 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. \\myServerDomain.com@SSL\DavWWWRoot\DAV\ioC8Whe4fk-2QhGllJokKA\sample.odt 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. Very nice. 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 [1]. 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 [2]. Unless you're sure it worked fine in 6.3, and started not working in 6.4, then it's good to check in 6.3.0.4 (or 6.3.0.0.beta1, or any 6.3.0.x RC) first. [1] https://wiki.documentfoundation.org/QA/Bibisect [2] https://wiki.documentfoundation.org/QA/Bibisect/Windows
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 6.4.0.0.alpha0+ (x64).
(In reply to Demarthe from comment #4) > To sum up : > # first bad commit: [f202498f5a7ea226aaece686dbb25117e92a04f5] source > 20b1e6440aacab043753e93be4499e939a80b05b Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Fri Jun 28 00:10:08 2019 -0700 cc: Norbert Thiebaud
(In reply to Dieter from comment #5) > Author: Norbert Thiebaud <nthiebaud@gmail.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. https://cgit.freedesktop.org/libreoffice/core/commit/?id=20b1e6440aacab043753e93be4499e939a80b05b author Mike Kaganski <mike.kaganski@collabora.com> 2019-01-09 10:54:10 +0300 committer Mike Kaganski <mike.kaganski@collabora.com> 2019-06-28 08:33:46 +0200 tdf#126121: WebDAV redirection detection
Hi, May we have some feedback on this bug ? Do you need more informations from us ? Thanks
Mike, can you have a look at it?
https://gerrit.libreoffice.org/c/core/+/114686 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": https://git.libreoffice.org/core/commit/a3843f1cb0095e843bc4ee7ed20802147f63c7ba 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: https://wiki.documentfoundation.org/Testing_Daily_Builds 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.