/meta endpoint is returning a 500 for shares

[JuancaG05]

Describe the bug

I was trying to test deep links for shares in the Android app and I just realised that by using the theoretical correct deep link (this is, the private link provided by the propfind call but replacing https:// by owncloud://), the endpoint is returning a 500 with an empty response.

Steps to reproduce

1. Construct the deep link corresponding to a share (private link but replacing https:// with owncloud://)
2. Click the deep link. The Android and iOS apps will send to the /meta endpoint what comes after the /f/ in such link, that is the file ID
3. /meta endpoint will respond with a 500

Expected behavior

The /meta response should include the correct information for the file requested.

Actual behavior

The /meta response is a 500 error.

Setup

I'm using ocis-traefik.latest, redirected from https://ocis.owncloud.works:

ownCloud Web UI 8.0.0-alpha.12 
Infinite Scale 5.0.0-alpha.5+71f7c1e73 Community

Additional context

• I think this is specific for oCIS 5.0, since with 4.0 it worked for iOS app (Android didn't have this feature yet).
• I also checked just in case it is problem of sending %21 instead of ! in the file ID, but that's not the case, the same 500 response is received in both cases.
• Just to be clear: this is working for normal files, the 500 response just occurs with shares.

[jesmrec]

Clients send the following request (by curl), using the space id from shares

curl -k -X PROPFIND -H 'authorization:Bearer <token>' https://ocis.ocis-traefik.latest.owncloud.works/remote.php/dav/meta/a0ca6a90-a365-4782-871e-d44447bbc668$a0ca6a90-a365-4782-871e-d44447bbc668%2521eb249b94-9051-4743-9e36-577b08b851e%20a:4c510ada-c86b-4815-8820-42cdf82c3d51:121da02e-80a3-46cd-8593-837ba4d478a4 --data-binary '\<\?xml version="1.0"?>\n<d:propfind  xmlns:d="DAV:" xmlns:oc="http://owncloud.org/ns">\n  <d:prop>\n    <oc:meta-path-for-user />\n  </d:prop>\n</d:propfind>'
<?xml version="1.0" encoding="UTF-8"?>

Response is 500 with empty body

[jesmrec]

Clarification about the scenario to reproduce (not real life scenario)

1. User1 shares an item with User2, so User2 has the file into its shares space/mountpoint... whatever

2. Getting the private link or the file-id of the shared item in the account of User2 (PROPFIND returns it if you ask for it). For our example, the file id is

a0ca6a90-a365-4782-871e-d44447bbc668$a0ca6a90-a365-4782-871e-d44447bbc668!a64a3467-fdd6-4df5-b177-c518d9f74e97:1165bccb-5cd0-434a-8fef-eb90098730fb:0b317a25-6737-4477-aa6c-67a416390581

3. Using that file-id, calling the meta endpoint to resolve it, that means, to know its path into the account. This is the request with curl:

curl -k -u <user:pwd> 'https://<url>:9200/remote.php/dav/meta/a0ca6a90-a365-4782-871e-d44447bbc668$a0ca6a90-a365-4782-871e-d44447bbc668!a64a3467-fdd6-4df5-b177-c518d9f74e97:1165bccb-5cd0-434a-8fef-eb90098730fb:0b317a25-6737-4477-aa6c-67a416390581' --data-binary '<?xml version="1.0"?>\n<d:propfind  xmlns:d="DAV:" xmlns:oc="http://owncloud.org/ns">\n  <d:prop>\n    <oc:meta-path-for-user />\n  </d:prop>\n</d:propfind>'  -X PROPFIND -i

Response is

HTTP/1.1 500 Internal Server Error
Access-Control-Allow-Origin: *
Content-Length: 0
Content-Security-Policy: default-src 'none';
Date: Wed, 20 Dec 2023 17:03:30 GMT
Vary: Origin
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Permitted-Cross-Domain-Policies: none
X-Request-Id: ae8671afc5c5/Cyj1dfDyDJ-027952
X-Robots-Tag: none
X-Xss-Protection: 1; mode=block

it should return the requested <oc:meta-path-for-user /> in the PROPFIND

[butonic]

<oc:meta-path-for-user /> can only be relative to a space root, that is why ocis also returns an oc:spaceid property. Is the android app aware of that? Is iOS, for that matter?

Why do you have to look up the path at all? A stat to https://<url>:9200/remote.php/dav/spaces/a0ca6a90-a365-4782-871e-d44447bbc668$a0ca6a90-a365-4782-871e-d44447bbc668!a64a3467-fdd6-4df5-b177-c518d9f74e97:1165bccb-5cd0-434a-8fef-eb90098730fb:0b317a25-6737-4477-aa6c-67a416390581 should give you the propfind result for the resource. The response contains the spaceid, and ocis should also give you a oc:file-parent, an id that allows you to navigate up.

I know this wall not allow you to show the full path to the resource, eg. as breadcrumbs, but it would allow showing a ...

In any case, I would like to understand the neccessity of the path. Fetching it is time consuming and in the graph api we might be able to return it as part of the parent property of driveItems. So, I'm just trying to learn.

Aside from the above the 500 is a bug, but we can only fix it by returning a path relative to a space root, since absolute paths ar a thing of the past.

[JuancaG05]

<oc:meta-path-for-user /> can only be relative to a space root, that is why ocis also returns an oc:spaceid property. Is the android app aware of that?

Yes we are, in fact we do already navigate correctly when we receive the response for a file that is not in the personal space in an oCIS account.

Why do you have to look up the path at all? A stat to https://<url>:9200/remote.php/dav/spaces/a0ca6a90-a365-4782-871e-d44447bbc668$a0ca6a90-a365-4782-871e-d44447bbc668!a64a3467-fdd6-4df5-b177-c518d9f74e97:1165bccb-5cd0-434a-8fef-eb90098730fb:0b317a25-6737-4477-aa6c-67a416390581 should give you the propfind result for the resource. The response contains the spaceid, and ocis should also give you a oc:file-parent, an id that allows you to navigate up.

Well, firstly, we need it for oC10 as well, where we are using the /meta endpoint too. But the real point here is that we need the absolute path because we need to discover the different folders where the objective file is located. This is, fetch each of these files from the server so that we can finally navigate to the aim file. We need to do it that way because we just fetch the root folder of each space in first instance, and then we fetch each of the subsequent folders. We cannot do it backwards (with just the file and its file-parent) since these won't be in our local database yet and we cannot retrieve and fetch each of the parents until we arrive to the root folder of the corresponding space.

Aside from the above the 500 is a bug, but we can only fix it by returning a path relative to a space root, since absolute paths ar a thing of the past.

Yes, let's say we need the "absolute path" but just within the space. But remember this is just happening with the files inside the Shares space, so it wouldn't be a problem since the Shares space has a constant ID (https://github.com/owncloud/web/blob/2ab7e6da432cb344cd86f3451eea1678461c5c90/packages/web-client/src/helpers/space/types.ts#L11).

I hope I explained properly, just ask me if you have any other question 👍.

[michaelstingl]

Status: Prio 2 in case of a regression, according to @micbar

[micbar]

update has landed in ocis.