Child Item

Dropbox scoped-app folder: Visibility of uploaded files to other users

We have a scoped-app, which mounts a folder owned by the app into my account. By piecing-together an invitation URL, we can mount it into other users' accounts as well (all are licensed under a team account). We can formulate a URL to generate an offline access-token, but we couldn't see any events for user operations after initially running the URL. Using an online access-token URL, we started seeing events.

Even when two people add an app, it looks like one user can't see the files that the other uploads. If one user specifically shares one of the files with the other user, the other user is added to the permissions for that file and then gets an email with a link that they can specifically open, but that file is still not visible just by looking at the folder. They can choose to 'save a copy' into their Dropbox, but it's not the same file (and will not show subsequent updates). **Any idea how we can allow more than one user to see a file that any one on the team with our app installed has copied into its folder?**

Also, is it possible to share the app's folder with other users? Alternatively, is it possible to create a subdirectory under it and share that? Whenever I attempt to do this and choose to share it with "specific people" (in the same popup), I get this:

..and the spinner just spins endlessly.

One might think that creating an app with "full Dropbox" scope might work, but the description specifically says "Access to all files and folders *in a user's Dropbox*.", which leads me to believe I'll get the same exact result as I'm currently dealing with.

Thank you. I've been having a problem trying to find these answers. The answers may be out there, but maybe this question will further increase the surface area in which to find them for other developers.

Find more posts tagged with

API

Abuse

Comments

Greg-DB

When using the "app folder" access type, each user gets their own separate app folder in their own account when they authorize the app to connect to their account. The app folders for different users of an app do not sync with each other.

Also, currently, app folders are incompatible with shared/team folders, meaning you can't share an app folder, put a shared/team folder inside an app folder or put an app folder in a shared/team folder.

If you want all users of your app to connect to the same content and have that sync across users, you'd instead need to register and use an app with the "full Dropbox" access type and invite all of the users to a single shared folder or team folder. Apps with the "full Dropbox" permission don't get app folders, and can instead access anything in the connected accounts, such as shared/team folders.

dsoprea

Well, there you go, then. Thank you. Standby.

dsoprea

Thank you for that. The development app is now a full-Dropbox type. It looks like changes will induce an event with one team and the ID of each team-member (there are three on this account):

2023-10-17T09:30:13 [2023-10-17 09:30:13,210 wew.handler_plugins.   DEBUG] Received Dropbox event:
2023-10-17T09:30:13 {
2023-10-17T09:30:13     "delta": {
2023-10-17T09:30:13         "teams": {
2023-10-17T09:30:13             "dbtid:AADBsJ4zo2S_tS_n3iyHzatB4h16n2yT-2c": [
2023-10-17T09:30:13                 "dbmid:AAAfY_5hmDSrYzFkd7T2BrWPPepevkydBY0",
2023-10-17T09:30:13                 "dbmid:AAA22dYwGQDF4xFp03M2NWEZq_7jgJV0XX8",
2023-10-17T09:30:13                 "dbmid:AAD0WqFm-gWxsfpUj1qAMXiUKYJTcGXRrjk"
2023-10-17T09:30:13             ]
2023-10-17T09:30:13         }
2023-10-17T09:30:13     },
2023-10-17T09:30:13     "list_folder": {
2023-10-17T09:30:13         "teams": {
2023-10-17T09:30:13             "dbtid:AADBsJ4zo2S_tS_n3iyHzatB4h16n2yT-2c": [
2023-10-17T09:30:13                 "dbmid:AAAfY_5hmDSrYzFkd7T2BrWPPepevkydBY0",
2023-10-17T09:30:13                 "dbmid:AAA22dYwGQDF4xFp03M2NWEZq_7jgJV0XX8",
2023-10-17T09:30:13                 "dbmid:AAD0WqFm-gWxsfpUj1qAMXiUKYJTcGXRrjk"
2023-10-17T09:30:13             ]
2023-10-17T09:30:13         }
2023-10-17T09:30:13     }
2023-10-17T09:30:13 }

We do this for each, while we're trying to debug what's going on:

dbxt = dropbox.dropbox_client.DropboxTeam(
        app_key=_DROPBOX_KEY,
        app_secret=_DROPBOX_SECRET,
        oauth2_refresh_token=_DROPBOX_REFRESH_TOKEN)

dbxtm = dbxt.as_user(member_id)
account = dbxtm.users_get_current_account()

root_namespace = account.root_info
root_namespace_id = root_namespace.root_namespace_id

root = dropbox.common.PathRoot.root(root_namespace_id)
dbxtmr = dbxtm.with_path_root(root)

cursor_id = <use account.account_id to get stored cursor ID, if any>
entries = <get files by passing the cursor-ID to dbxtmr.files_list_folder() or dbxtmr.files_list_folder_continue()>

We're testing by uploading images into a subdirectory of the root. However, we're consistently getting an empty set of entries (last statement). When the cursor doesn't exist, the API is returning a list of the two root subdirectories (and not the actual uploaded files). When the cursor already exists, we get nothing. Keep in mind that we're doing this for each of the members in the list and getting nothing from all of them. So, why would the API only return folders and never files? Should I somehow be using `is_admin()` instead of `is_user()`? I tried it before, but it wasn't letting me:

AuthError('c8b5e...6708b', AuthError('invalid_select_admin', None))

The subdirectory is configured to be visible to all three members. When I created another folder, I got the same result. When I tried uploading the images to the account root, the files started showing-up in the events. So, it is only happening when I upload into a folder.

When I tried uploading to the same folder using the "Admin Console" UI, I got no webhook events at all.

What might I be missing?

dsoprea

I was missing the `recursive` argument to `files_list_folder()`. Once I added that and set the path root to the one subdirectory, this started showing the right changed files and narrowed under the right scope.

Instead of having to audit all of the given members, receiving the exact same list of changed files, and then deduplicating, what is the best way of receiving the changed files just once? Isn't there some way of just getting the list of changed files for just the member that actually made the changes? I'd have no idea where to get the ID of the member responsible for the changes, though, as the headers don't appear to receive that information and all of our other calls are done in the context of a particular member. The headers would be the only place with information that would transcend that.

Headers:

{
    "accept": "*/*",
    "accept-encoding": "gzip,deflate",
    "content-length": "414",
    "content-type": "application/json",
    "host": "webhook.staging.oboit.net",
    "user-agent": "DropboxWebhooks/1.0",
    "x-amzn-trace-id": "Root=1-652e66a3-1b528b3b17693ec067fe369c",
    "x-dropbox-signature": "95338...2cb8a",
    "x-forwarded-for": "34.225.110.50",
    "x-forwarded-port": "443",
    "x-forwarded-proto": "https"
}

Greg-DB

From your sample webhook payload, I see that your app is linked to the team itself, and so receives the list of all team members with changes. If you want to be notified for just one account, and don't actually need the connection to the entire team, you could instead link the app to a specific account instead of the whole team.

When using an "team scopes", the app is connected to the entire team. When not using any team scopes, the app is connected only to a particular account.

So, to do that, you could:

Unlink the app from the team using this page. (This can only be done by a team admin.)
Disable any team scopes using the "Permissions" tab on the app using the app's page on the App Console. (This can only be done by the app owner.)
Reconnect the app, now without any team scopes, to the relevant account with the shared folder.

Two things to note with this setup though:

This would notify you of changes in that particular account, whether or not that particular account was the one that made those changes; that is, the changes may be in a shared folder that account has, but performed by a different account. It sounds like this may be acceptable for your use case, but I'm highlighting it just in case.
This would rely on that particular linked account remaining active. If that account is disabled, the integration would break.

dsoprea

Given how many different ways the account and webhooks can be configured and how difficult the flow is to understand, I'm more concerned at keeping the flow no more unintuitive than it already has to be. I don't want it to be very difficult to switch to auditing a different member if the member we're currently auditing leaves the company. So, I'm keeping the team scope, memoizing (i.e. caching into the process heap) the email-addresses that are associated with each of the member IDs as we're looking them up, and then filtering for a particular user configured via the environment. We have control over the member. We have control over the path.

Since we're only getting a list of the members that actually have specific access to the file/folder that is being touched, we just have to be careful, if we ever end-up enumerating one or more paths that might not include this audited, principal user, that we need to more intelligently manage the context (or else we'll fail when filtering for them and coming up empty).