-
Notifications
You must be signed in to change notification settings - Fork 2.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
fix downloadURL of public links #38532
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
0fd331f
to
496ab61
Compare
@C0rby when and how can the double prefix occur? I don't understand the context of owncloud/web#4689 (review) |
@@ -169,7 +169,7 @@ public function propFind(PropFind $propFind, INode $node) { | |||
$sharedResourcePath = '/' . $shareNode->getName(); | |||
} | |||
|
|||
$path = $server->getBaseUri() . $server->getRequestUri(); | |||
$path = '/remote.php/dav/' . $server->getRequestUri(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This results in a partial URL starting with a /.
So it is not relative, but rooted.
I'd normally object that, as it looks like it should break, when installing owncloud in a subdirectory.
But as you introduce that exactly to fix something with subdirectories, I assume you know what you are doing -- there are other places in the propFind() code that also returns paths starting with a '/'. That seems to be consistent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good spot. In fact the leading slash gets removed again in ownCloud Web. So it'd be fine to have a relative URL here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also note that legacy "/remote.php/webdav/" endpoint is still supported I think. It doesn't seem a good idea to mix both endpoints. I don't know if some webdav clients could throw errors if you change the endpoint; at least I would be suspicious
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This results in a partial URL starting with a /.
So it is not relative, but rooted.
Yes, you're right.
I'd normally object that, as it looks like it should break, when installing owncloud in a subdirectory.
It's the client responsibility to prepend the base path to this. Including the subdirectory if owncloud was intalled in one.
But as you commented here: owncloud/web#4689 (comment)
Why do we go for flexibility? I'd argue that a full URL is more robust, as no errors can be made during URL-assembly.
I was thinking that maybe in a loadbalanced setup having the full URL could break things. After thinking about it again I don't think so anymore.
The instances would have to configure the overwrite.cli.url
anyways right? So I could just use that as the base url and it should point to the load balancer/public address.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also note that legacy "/remote.php/webdav/" endpoint is still supported I think. It doesn't seem a good idea to mix both endpoints. I don't know if some webdav clients could throw errors if you change the endpoint; at least I would be suspicious
I see your point but will a generic webdav client even use this owncloud proprietary attribute?
Or am I wrong and this isn't a proprietary attribute?
Anyways this feature is especially implemented to solve a problem of webclients or more specifically of ownCloud web.
Our other clients don't even need this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I lack enough insights to review the fix itself.
It affects the behavior of the propFind() method. Not sure how widely used that method is.
Please provide a clear example how to make a PROPFIND call that would benefit from that.
Is this a problem with new code, or is the same problem also present in released versions?
It's not a problem in released versions. This PR fixes a problem which was introduced with a new feature for 10.7 #38376 To test this you can send this PROPFIND request:
You have to do propfind requests for public shares with and without passwords. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested the patch in https://188.34.186.241/owncloud (Classic UI only!)
Looks good. Thanks!
Or maybe not: Could that be related? #38543
@micbar @jnweiger, regarding putting the full URL into Or is there any other reliable way to get the owncloud base path like |
496ab61
to
16ab8db
Compare
I found a way. And now the downloadURL is a full URL not a rooted/relative URL. So the handling for the frontend should be easier now. :) |
If owncloud was setup under a subdirectory it would return the path including the subdirectory which we don't want. Now we put the full URL into the downloadURL.
16ab8db
to
55aa8b7
Compare
Kudos, SonarCloud Quality Gate passed! |
Description
Make the downloadURL always relative to the owncloud base path.
Related Issue
Motivation and Context
If ownCloud is setup in a subdirectory like
https://example.com/owncloud/
then we don't wan't to include the subdirectory in the relative downloadURL.Screenshots (if appropriate):
Types of changes
Checklist: