-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: Files shared via Public Share Links no longer accessible (HTTP 401) #43287
Comments
I had the chance to test in another 28.0.2 instance, and there it is working without a problem... Does someone here in the community maybe have some tip, where to start checking? I'm using |
I have create a topic in the Nextcloud help forum: Should I close this issue here? I cannot really determine if it's a bug or not... |
I'm unable to reproduce this behavior. Those CSP errors should not be occurring. I don't have those errors. Your browser console Network tab may offer more clues, such as if being blocked by a browser extension or something. |
I see the same behavior, files on a public share link cannot be opened, and the network tab shows a 401 response. The share app only sets this header for the PROPFIND of the folder, but not for the PROPFIND of a file, that's triggered when clicking on it. |
Cc @nextcloud/server-frontend |
Because it was fixed for 28.0.2.... |
No this is not fixed in 28.0.2 . As I wrote above, the issue here is that the webdav app doesn't set the X-Requested-With header at all when sending the PROPFIND request for a single file. @koelle25 can you check if the other nextcloud instance that doesn't have this issue, has the server to server share option enabled? |
I am almost sure it has, but I will check it and also my private instance for this setting.
Am 4. Februar 2024 10:00:13 UTC schrieb Sebastian Scheibner ***@***.***>:
…No this is not fixed in 28.0.2 . As I wrote above, the issue here is that the webdav app doesn't set the X-Requested-With header at all when sending the PROPFIND request for a single file.
@koelle25 can you check if the other nextcloud instance that doesn't have this issue, has the server to server share option enabled?
--
Reply to this email directly or view it on GitHub:
#43287 (comment)
You are receiving this because you were mentioned.
Message ID: ***@***.***>
|
As aforementioned, enabling Publicly shared links should not depend on |
Yes indeed, I can confirm this. The other instance has @skjnldsv Please re-open this issue |
Sad to find this bug and seeing it is still closed after days of users reporting that it is still valid and I also just got reports from users not being able to open files where office/richdocuments comes into play for folders shared via public shares and it behaves just like op demonstrates in the video in the initial bugreport with the spinner cycling. The instances are on 28.0.2 as well and we disabled the NOTE: Interestingly (at least in my case) this only affects files opened from within a public folder share, if the single file is shared instead it works. Please re-open this issue. |
I also have this issue. Sending a link with documents that dont open as expected is embarassing, and enabling |
/reopen @nextcloud/server-frontend @joshtrichards @szaimen @skjnldsv |
Nope, 28.0.3 is fixed for me |
Can you point us to the resolving PR/Commit? I cannot find anything related to this issue in the Pre-Release Notes... |
@koelle25 you're right, I was heading a different direction, thanks for pushing back 👍 |
Addressed, release is tomorrow |
Bug description
When trying to access files via a share link they cannot be opened anymore. In the developer console there are multiple errors:
It's not because of HTTP/3, I also tried with HTTP/2, same behaviour. Also the error message regarding the text app also seems unrelated, I also tried with with it disabled but same behaviour again.
The bug seems to be existing since upgrade to Nextcloud 28 (28.0.1 actually). I'm now on 28.0.2 but bug is still there.
Steps to reproduce
Dateien.-.Kolle.s.Cloud.Mozilla.Firefox.2024-02-02.13-11-12.video-converter.com.mp4
Expected behavior
I can access the shared file(s) via the public link.
Installation method
Community Docker image
Nextcloud Server version
28
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.2
Web server
Nginx
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
Upgraded to a MAJOR version (ex. 22 to 23)
Are you using the Nextcloud Server Encryption module?
None
What user-backends are you using?
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info
NGINX access.log entries regarding the problem:
The text was updated successfully, but these errors were encountered: