Client: Fix "legacy" private link generation feature for old servers, rely on DAV API for new servers

[hodyroff]

2.4.0 Alpha 1 with openSUSE Leap 42.2 against ownCloud Server 10.0.3

Expected behaviour

Right click, I can generate a private link which works or if the server does not support it - I can't and its greyed out.

Actual behaviour

Link gets generates, but its slightly off
Generated link: https://my.mydomain.com/index.php/f/03922059515
Real private link: https://my.mydomain.com/index.php/f/3922059

Steps to reproduce

1. Generate private link
2. open in web browser
3. access forbidden, ask owner for access

[ckamm]

@hodyroff What's going on here is that 10.0.3 does not contain the 'privateLinks' capability so the link url can't be retrieved by webdav. In this case the client falls back on generating the url itself -- which is more brittle but is supposed to work.

My best guess is that this server's instance id starts with "515"? Could you check what it is?

I thought that was forbidden by reading core's getInstanceId which only generates ids starting with "oc". If that assumption is wrong we'll need to revisit the fallback private link generation!

[michaelstingl]

Please don't use a fallback.

Sorry wasn't clear in https://github.com/owncloud/client/issues/6020 .

We have this funny issue that @hodyroff described, and additionally oC admins expect parameters in config.php like overwritehost are applied to the link. (with the 3.6.2 iOS app, I even created private links connected to a 8.2.x server)

[ckamm]

@michaelstingl So how does the iOS app do it? They must be using some kind of fallback generation then?

But yes, we can drop the fallback and make this feature available only for servers that announce their support in the capabilities. Unfortunately it requires minor changes in all shell integrations and is thus not trivial.

[michaelstingl]

@ckamm iOS app and Android app also implemented their own link generation, even on a server that don't have this feature. They also ignore overwritehost etc.

I somebody wants you to implement something that feels like it better should have a proper server-side implementation, instead of implementing it based on assumptions 3x on all client platforms, please say NO the next time! (maybe it's me that wants silly stuff)

[guruz]

The link @hodyroff mentioned above works for me (adjusting the hostname).
If this is so much as effort as @ckamm mentioned then we maybe just should keep the fallback in.
I would guess overwritehost should be applied as we use the Account's URL?

[guruz]

Sorry, I have picked the wrong link :-/
The generated one doesn't work.

[michaelstingl]

Okay, @hodyroff 's issue seems to be caused by a server side config problem.

For the handling of overwritehost in pre-10.0.4 oC's (fallback), we should mention the different behaviour in the release notes…

[ckamm]

@michaelstingl My plan after our discussion had two steps:

1. Query the numeric fileid with a PROPFIND to avoid the issue with invalid instance ids we've seen in this ticket
2. Query the ocs/v1.php/config to get the host variable and use that host when building the private link url. This should make the locally generated links respect overwritehost.

[ckamm]

PR is now available

[SamuAlfageme]

👍 neat!