POST response does not return correct path when creating public link

[jesmrec]

Describe the bug

Creation of a public link: the POST request does not return the path to the item.

Steps to reproduce

Steps to reproduce the behavior:

1. Create a public link to item that is not placed in root folder, for example item /A/land2.jpg. Following curl request will help:

curl -k -u user1:xx 
-H 'User-Agent:Mozilla/5.0 (Android) ownCloud-android/3.0-beta.2' 
-H 'Content-Type:application/x-www-form-urlencoded' 
-X POST 'https://xx.xx.xx.xx:9200/ocs/v2.php/apps/files_sharing/api/v1/shares?format=json' 
--data-binary 'path=/A/land2.jpg&shareType=3&permissions=1&name=link1'

Expected behavior

path field in POST response containing the path to the item: "path":"/A/land2.jpg",

Actual behavior

path field in POST response does not contain the path:

{
   "ocs":{
      "meta":{
         "status":"ok",
         "statuscode":200,
         "message":"OK"
      },
      "data":{
         "id":"fNrugBtjyVzaGnf",
         "share_type":3,
         "uid_owner":"user1",
         "displayname_owner":"Perez",
         "additional_info_owner":"user1@own.com",
         "permissions":1,
         "stime":1669628641,
         "parent":"",
         "expiration":"",
         "token":"wKqmsitvMoSnEJB",
         "uid_file_owner":"user1",
         "displayname_file_owner":"Perez",
         "additional_info_file_owner":"user1@own.com",
         "state":0,
         "path":"/land2.jpg",  <============= MISSING PATH
         "item_type":"file",
         "mimetype":"image/jpeg",
         "storage_id":"shared::/land2.jpg",
         "storage":0,
         "item_source":"652fc57c-8044-43e8-9a7a-3b0a8a40689c$affb1013-b397-42f3-afe8-31295c4a2235!19d43b6f-19e1-499c-b243-dd91f1eefc90",
         "file_source":"652fc57c-8044-43e8-9a7a-3b0a8a40689c$affb1013-b397-42f3-afe8-31295c4a2235!19d43b6f-19e1-499c-b243-dd91f1eefc90",
         "file_parent":"652fc57c-8044-43e8-9a7a-3b0a8a40689c$affb1013-b397-42f3-afe8-31295c4a2235!98a20954-c44c-40a0-a178-12b02c67a448",
         "file_target":"/land2.jpg",
         "share_with_user_type":0,
         "share_with_additional_info":"",
         "mail_send":0,
         "name":"link1",
         "url":"https://xx.xx.xx.xx:9200/s/wKqmsitvMoSnEJB"
      }
   }
}

this is causing a problem in mobile clients: When public link is created, it is not reflected till parent folder is refreshed.

Setup

Container created with the following docker-compose file:

version: "3.7"

services:
  ocis:
    image: owncloud/ocis:2.0.0-rc.2
    ports:
      - 9200:9200
      - 9215:9215
    environment:
      OCIS_INSECURE: "true"
      OCIS_URL: "https://xx.xx.xx.xx:9200"
      IDM_CREATE_DEMO_USERS: "true"
      IDM_ADMIN_PASSWORD: "admin"
      PROXY_ENABLE_BASIC_AUTH: "true"
    restart: "no"
    entrypoint:
      - /bin/sh
    # run ocis init to initialize a configuration file with random secrets
    # it will fail on subsequent runs, because the config file already exists
    # therefore we ignore the error and then start the ocis server
    command: ["-c", "ocis init || true; ocis server"]

Additional context

Problem does not happen in oC10, where the path field contains the correct path.

[butonic]

some remarks: clients should be sending a space property together with a path relative to the space. This was introduced with https://github.com/cs3org/reva/pull/2913

We decided to deprecate the parameter "space_ref". We decided to use "space" parameter instead. The difference is that "space" must not contain a "path". The "path" parameter can be used in combination with "space" to create a relative path request

for the space id we accept

// The accepted formats are:
// <providerid>$<spaceid>!<nodeid>  -> <providerid>$<spaceid>, <nodeid>
// <providerid>$<spaceid>       -> <providerid>$<spaceid>, <spaceid>
// <spaceid>                -> <spaceid>, <spaceid>

Now for the path in the response we see that when listing public links the path does contain the parent folders ... we need to check why the create response does not contain them.

[felix-schwarz]

@butonic Currently, the iOS client uses the File ID as space_ref. Can it also just pass that to space - or should it pass only the space id?

If it should pass only the space id, that will be a challenge because #5355 is still unsolved. And, by extension, without a deterministic way to determine the space id of a shared item, providing the correct, relative path will be a challenge as well.

[micbar]

@felix-schwarz See the examples above. you can provide anything from a complete resourceID to a single spaceID.

[JuancaG05]

@butonic I tried sending in the param space the space ID where the file is located (the one that comes in the id property for a space in the /me/drives endpoint), which has format ...$..., and I receive a 404 from the server. The response is:

{
  "ocs": {
    "meta": {
      "status": "failure",
      "statuscode": 404,
      "message": "Wrong path, file/folder doesn't exist"
    }
  }
}

And the curl command to reproduce it is:

curl -k -u user1:xxx  -H 'User-Agent:Mozilla/5.0 (Android) ownCloud-android/3.0-beta.2'  -H 'Content-Type:application/x-www-form-urlencoded'  -X POST 'https://xxx.xxx.xxx.xxx:9200/ocs/v2.php/apps/files_sharing/api/v1/shares?format=json' --data-binary 'path=/A/land2.jpg&shareType=3&permissions=1&name=link1&space=52c34980-e15f-49bf-a47f-c151c7d6ec9a$d45835cb-8606-4075-9488-076d315119f5' | json_pp

Tested on ocis.owncloud.works

[jesmrec]

any ETA for this fix?

[kobergj]

Since getting the path is an expensive operation and might leak data I only added it for the POST public link case. Let me know if other endpoints are also affected.

fix is here https://github.com/cs3org/reva/pull/4004 needs a reva bump after merge