Description: When loading a document from a WebDAV Server with Authorization, LibreOffice first tries to perform every WebDAV HTTP Request without Authorization Header. As this results in a a 401 Unauthorized Response, LibreOffice tries again with correctly set Authorization Header (this is for WWW-Authenticate: Negotiate, I don't know if there are other cases). Now, requests succeed as expected. This is shown in webdav-lock-conversation.txt. However, WebDAV locks need to be refreshed from time to time. As LO does this, it again tries without Authorization header first, receives 401 Unauthorized - and gives up. This is shown in webdav-lockrefresh-conversation.txt (well, there is not much to show as the conversation just ends after the 401 response). Expected: LO should try again, just like it does when loading a document. The conversations were logged with a closed-source WebDAV server. I will try to reproduce with another one soon. Also I'm not quite sure what the correct behaviour is when refreshing a lock. Servers could also accept lock refresh commands without authorization, but obviously, this one doesn't and the WebDAV RFC does not seem to be specific about that. Steps to Reproduce: 1. use webdav server with authorization and locking enabled 2. open odt from webdav server (should lock the file) 3. wait e.g. 180s Actual Results: lock is gone as it is not refreshed Expected Results: lock should be refreshed correctly Reproducible: Always User Profile Reset: Yes Additional Info: Version: 6.4.3.2 (x86) Build-ID: 747b5d0ebf89f41c860ec2a39efd7cb15b54f2d8 CPU-Threads: 4; BS: Windows 10.0 Build 17763; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded
Created attachment 161610 [details] HTTP log of locking during document loading
Created attachment 161611 [details] HTTP log of lock refresh attempt
I tried to dig into this bug and found that my log of the failed LOCK request is not sufficient. What happens before that is actually relevant: I have a failed PROPFIND Request (HTTP 500 Internal Server Error), which is handled by NeonSession.HandleError(): https://git.libreoffice.org/core/+/refs/heads/master/ucb/source/ucp/webdav-neon/NeonSession.cxx#1826 I'll attach a new logfile where you can see the failed request before the lock refresh. There, the RequestEnvironment is reset. However, when refreshing Locks as in NeonLockStore, the session is re-used. So now, when the NeonAuth Callback is called by neon, it will fail in this line: https://git.libreoffice.org/core/+/refs/heads/master/ucb/source/ucp/webdav-neon/NeonSession.cxx#285 because there is no DAVAuthListener registered anymore. For all other cases, this is not a problem as calls to NeonSession typically provide a new RequestEnvironment - but refreshing locks does not. I'm going to investigate why the internal server error appears at all, but i think this also is a bug in LibreOffice. When sessions are re-used, the DAVAuthListener must not be cleared in HandleError.
Created attachment 161810 [details] HTTP log of lock refresh attempt
Another clarification: HandleError is called regardless whether there was an error, so the RequestEnvironment is reset in any case and will be missing when refreshing locks. This may only affect Authorization Types NTLM and Negotiate, because for those, the AuthListener is called after a 401. For Digest Authentication, credentials are cached in the session and re-used, so no 401 will occur. Possible solutions IMHO: 1. Don't reset RequestEnvironment (m_aEnv in NeonSession). Should work as it is reset by all NeonSession methods anyway - except the LOCK() method for refreshing locks. 2. Don't reset the whole RequestEnvironment, but instead exclude the AuthListener as it is obviously needed again. Maybe AuthListener shouldn't be a part of RequestEnvironment at all? 3. Set RequestEnvironment when refreshing locks. As this is done within NeonLockStore, it somehow needs a reference to the AuthListener, which is usually set by DAVResourceAccess. It could cache it somewhere but this doesn't seem like a valid idea.
Julian Kalinowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/af7e5983e53746acd3b453d38942950a7ab83c22 tdf#133673 fix webdav lock refresh with Auth:Negotiate It will be available in 7.1.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.
Julian Kalinowski committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/1d4bd2c6c71ff64423b69e79274f751683370674 tdf#133673 fix webdav lock refresh with Auth:Negotiate It will be available in 7.0.0.1. 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.
A polite ping to Julian Kalinowski: Is this bug fixed? if so, could you please close it as RESOLVED FIXED ? Otherwise, Could you please explain what's missing? Thanks
This bug is fixed for me. Thanks everybody :)