cryptomator / cryptomator/android

Access shared folders in OneDrive for Business

Open
#262 1 comment 2 reactions 0 assignees View on GitHub
storage:onedrive type:feature-request
Dominant language
Kotlin
Stars
1.2k
Forks
216
PR merge metrics
No merged PRs in 30d

Description

## Status Quo
OneDrive (personal account): You can access shared folders. If you're unable to access a shared folder that was shared with you (i.e., you are not the owner), you have to [add the shared folder to your OneDrive](https://support.microsoft.com/en-us/office/add-and-sync-shared-folders-to-onedrive-for-home-8a63cd47-1526-4cd8-bd09-ee3f9bfc1504#bkmk_add).

OneDrive for Business (work/school account): You can only access shared folders that you own. Even if you [add a shortcut to "My Files"](https://support.microsoft.com/en-us/office/add-shortcuts-to-shared-folders-in-onedrive-for-work-or-school-d66b1347-99b7-4470-9360-ffc048d35a33), you cannot access the shared folder.

## Technical Details
Currently, Cryptomator sets the permission scope to `Files.ReadWrite` during authentication. However, there is a [difference between OneDrive and OneDrive for Business](https://docs.microsoft.com/en-us/onedrive/developer/rest-api/concepts/direct-endpoint-differences?view=odsp-graph-online#permissions). But even if the scope is set to `Files.ReadWrite.All`, our tests have shown that shared items (not being the owner) still don't magically appear.

To make this point clear: Shortcuts are not part of the [directory listing](https://docs.microsoft.com/en-us/graph/api/driveitem-list-children?view=graph-rest-1.0&tabs=http). That's probably the saddest part about this issue. It seems that there is no way to implement this feature transparently. There is no way to "merge" shared files with your own files. That's actually what the shortcuts are for (in my opinion) but they're missing.

There is an API to list all shared items (not being the owner) via [`GET /me/drive/sharedWithMe`](https://docs.microsoft.com/en-us/graph/api/drive-sharedwithme?view=graph-rest-1.0&tabs=http). With these identifiers, you can access the shared folders. But that's only possible if the permission scope `Files.ReadWrite.All` has been requested and granted.

## Proposed Solution
If we'd like to support this feature, we have to change the permission scope to `Files.ReadWrite.All`. There doesn't seem to be any further restrictions. When changing the permission scope, the user will be prompted to authenticate again. A drawback could be that an admin has to give consent _again_ due to the change (needs further testing).

Since personal accounts are not affected by this issue, the `driveType` should be retrieved and persisted after a successful authentication. You can get it via [`GET /me/drive`](https://docs.microsoft.com/en-us/graph/api/drive-get?view=graph-rest-1.0&tabs=http).

When adding a vault in OneDrive: If the `driveType` is `business` (and maybe `documentLibrary`?!), we need to present a choice between the user's own files and shared items. An optimization could be to detect if there are any shared items at all so that the choice can be skipped. In case of shared items, we need a new screen that lists all available shared folders (shared _files_ don't make any sense here). If one of the folder is selected, the "new" root identifier is the one from the selection (incl. drive identifier).

Caveat: If we set the selected folder as root, there will be the problem that the root folder doesn't have a name (classic example if the vault is the root folder itself). When implementing this feature, we should experiment with setting the parent reference as root but still _showing_ the shared folder directly.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.