Access shares with owner's URL, not virtual path

[labkode]

Current OCIS, as tested in https://ocis.owncloud.com works in the following way when accessing shares.

Workflow: Katherine shares my folder with Einstein.

Logged in as Katherine

https://ocis.owncloud.com/files/spaces/personal/katherine/myfolder?fileId=166d1210-cdb9-50ab-9f1e-ecb9ef12a304%24534bb038-6f9d-4093-946f-133be61fa4e7%2133ca5587-29fd-48f3-abba-8305f57ad2b5&items-per-page=100

Logged in as Einstein
https://ocis.owncloud.com/files/spaces/share/myfolder?shareId=166d1210-cdb9-50ab-9f1e-ecb9ef12a304%3A534bb038-6f9d-4093-946f-133be61fa4e7%3Ab52d90fa-80ec-4b6b-a306-edcbd918dbbd&fileId=166d1210-cdb9-50ab-9f1e-ecb9ef12a304%24534bb038-6f9d-4093-946f-133be61fa4e7%2133ca5587-29fd-48f3-abba-8305f57ad2b5&sort-by=name&sort-dir=asc&items-per-page=100

Each recipient has its own share URL, relative to the user (in this case shareID=166...), that means if you send it to another person that person (even he has access), won't be able to access it.

CERNBox
CERNBox use-case is that the recipient will be able to access the share by using the owner's URL:
https://ocis.owncloud.com/files/spaces/personal/katherine/myfolder?fileId=166d1210-cdb9-50ab-9f1e-ecb9ef12a304%24534bb038-6f9d-4093-946f-133be61fa4e7%2133ca5587-29fd-48f3-abba-8305f57ad2b5&items-per-page=100

CERNBox url looks like this. They need to be the same in OCIS edge.

Personal
https://cernbox.cern.ch/files/spaces/eos/user/g/guse...

Workspaces:
https://cernbox.cern.ch/files/spaces/eos/project/a/aproject/...

Personal spaces and Work spaces
They already behave with a full path (relative to space root). Sharing is the one that differs from this model.

@dragotin @aduffeck

[dragotin]

related: #5355

[dragotin]

Related draft pull request for Reva: https://github.com/cs3org/reva/pull/3836/files

[dragotin]

For web, @kulmann agreed to look into this next week - so there will be progress.

[kulmann]

In order to work on this in web, ocis needs some changes first...

use case 1: share the browser URL, with fileIds being disabled

description

einstein shares a personal folder Photos/2019/Norway with marie, then points her to the folder by giving her the browser URL:
https://owncloud.test/files/spaces/personal/einstein/Photos/2019/Norway

resolve URL in web

Because of the URL path segment /files/spaces/, web knows that this is a space URL. It will try to resolve a driveAlias + relativePath from the rest of the URL, namely personal/einstein/Photos/2019/Norway. That happens via comparison of the string to all known drive aliases (try with full string, if no matching drive alias is found cut off the last segment and repeat).

missing information from ocis

1. There is no API for finding einstein's personal space by drive alias when being logged in as marie. drives.listAllDrives only lists spaces marie is a member of (including her personal space). Spaces don't appear in the response when marie has a share to the space. I.e. having a share to a folder in einsteins personal space doesn't expose the space to marie. As a result:
   a) web doesn't have a chance to find the matching drive alias for personal/einstein/Photos/2019/Norway
   b) let me be clear: since web couldn't identify a space, it can't make webdav calls. From here on everything's broken. 💔
2. If (1) would be possible, it would be desirable to call drives.listAllDrives with a drive alias filter. Otherwise we would need to preload space meta data in memory in web. If a user has access to thousands of spaces that's rather inefficient.

use case 2: share the browser URL, with fileIds being enabled

description

Similar to use case 1, einstein shares a personal folder Photos/2019/Norway with marie, then points her to the folder by giving her the browser URL:
https://owncloud.test/files/spaces/personal/einstein/Photos/2019/Norway&fileId=1284d238-aa92-42ce-bdc4-0b0000009157%244c510ada-c86b-4815-8820-42cdf82c3d51%214c510ada-c86b-4815-8820-42cdf82c3d51

resolve URL in web

Because of the URL path segment /files/spaces/, web knows that this is a space URL. Since a fileId is present in the URL, web looks up the fileId in the preloaded list of marie's spaces and doesn't find it. This can easily be extended in web to call drives.getDrive with the fileId as param.

missing information from ocis

1. Calling drives.getDrive with a fileId that belongs to a space where marie is not a member will result in a 404 Not Found. Web needs at least the drive alias (for url path correction if needed) and ideally also the webdav url of the space (because for web we want to move away from concatenation of server url and relative webdav path and use the webdav url from the space instead, in order to make federation possible).

use case 3: navigate into share via Shared with me page

description

Similar to use case 1, einstein shares a personal folder Photos/2019/Norway with marie. Then marie logs in and visits her Shared with me page, accepts the share and then clicks on it.

construct URL in web

Web currently builds URLs for shares in the form of https://owncloud.test/files/spaces/share/norway?shareId=xyz&fileId=abc. We want to construct a URL like presented in use cases 1 and 2. Thus we need the drive alias in OCS shares responses.

missing information from ocis

1. Calling /ocs/v1.php/apps/files_sharing/api/v1/shares?shared_with_me=true should return drive aliases as they are from the share owners perspective in the response.

more ideas

1. The behaviour described above should not only work for accepted shares but also for pending and declined shares. Think of the end to end UX: marie would see some kind of "not found" page if she didn't accepted the share before entering the URL into the browser. Technically webdav access to pending and declined shares is already possible - as long as the grants exist the share state shouldn't matter.

@micbar how can we make this actionable? 🙈

[micbar]

We do not need to get the drives via graph. I have a reva pull request opened which exposes the space root alias and the space root id on a share. That was designed to mitigate the issues you describe here because i was not expecting that we can get a full drives listing for all drives where the shares are originating. We also do not need all that drive information.

I could provide an ocis branch where you could work against.

[kulmann]

But why would we want that information on OCS if we want to move sharing to graph and not use it in OCS anymore?

[kulmann]

We also do not need all that drive information.

Of course not. So far I can only tell that we want drive alias and webdav url to be exposed. What speaks against exposing that information via graph?

I could provide an ocis branch where you could work against.

That would be much appreciated for a start. Thank you

[kulmann]

@mbarz thank you for #6300 - that seems to work and I would love to see it merged soonish. As a result I can already have share URLs identical for the share owner and all share receivers. Probably still has rough edges, but I'm getting there.

The next two prios for unblocking web would be (in that order):

1. provide the driveAlias and the fileId of the share owners space via OCS /shares response. Reason: For building the shared with me page with URLs like described above (with the drive alias and path from the share owner).

2. provide mountpoints in the /me/drives graph response not only for accepted shares, but also for pending and declined shares. Reason: if a share owner copies their browser URL and gives it to the share receiver (e.g. via chat) to point to the resource, the share receiver now needs to accept the share first before they can use the URL.

(1) is particularly important. (2) will be needed for a good UX.

[mbarz]

Your welcome 😊
But I think you meant to thank @micbar

[kulmann]

Your welcome 😊
But I think you meant to thank @micbar

Nono, just pinging you for fun from time to time. 😂🙈

[tbsbdr]

realtes to: owncloud/web@49e125f

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.