| Summary: | LibreOffice fails to refresh Locks when using WebDAV with Authorization | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Julian Kalinowski <Julian.Kalinowski> |
| Component: | LibreOffice | Assignee: | Julian Kalinowski <Julian.Kalinowski> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | oliver.brinzing, xiscofauli |
| Priority: | medium | ||
| Version: | 6.4.3.2 release | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Windows (All) | ||
| Whiteboard: | target:7.1.0 target:7.0.0.1 | ||
| Crash report or crash signature: | Regression By: | ||
| Attachments: |
HTTP log of locking during document loading
HTTP log of lock refresh attempt HTTP log of lock refresh attempt |
||
|
Description
Julian Kalinowski
2020-06-04 12:59:46 UTC
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 :) |