Child Item

Get a list of Namespaces a single user has access to

Hey,
I've been interacting with a number of end points and I'm trying to rely upon the permissions dropbox has defined in RBAC when knowing whether a user can use a number of files returned from a search.

Currently i'm polling for event changes using https://api.dropboxapi.com/2/files/list_folder
What i'm wanting to do is store the `shared_parent_id` / `shared_id` associated with that file/folder so that when it comes to searching I can compare those id's with a list of names spaces an individual has access to so that I can filter out files that individual can access and return them from elastic search.

Staring with a user email:

On request to get things we get the list of all members using https://api.dropboxapi.com/2/team/members/list_v2
Get the team_member_id when the email matches
Call https://api.dropboxapi.com/2/users/get_current_account using the Dropbox-API-Select-User with the team_member_id to get the root_namespace_id
Call https://api.dropboxapi.com/2/files/list_folder using the Dropbox-API-Select-User with the team_member_id and the Dropbox-API-Path-Root with the root_namespace_id to get a list of namespaces the user currently can access.

The problem i've noticed is that if there is:
- If User A has Access to FOLDER A as a namespace, if FOLDER A/FOLDER B is a separate namespace it’s shared_id will be different to FOLDER A so how can we when polling for an event whereFOLDER A/FOLDER B/example.txt is created confirm whether User A should have access or not.

I've seen that I could call https://api.dropboxapi.com/2/files/list_folder recursively too see all they have access to but the amount of files to do that on the fly isn't a performant feasibility. So my overall question - Is there a way of just getting a list of namespaces a user has access to not just the root? Or alternatively is there a better way of achieving this?

Find more posts tagged with

Developers

Comments

Greg-DB

If you want to list everything a user has in their account, you can use /2/files/list_folder. Anything returned there when calling for that user is something that the user has access to. However note that users may have access to namespaces that aren't currently mounted in their account, and so would not be returned there. And as you said though, that returns folder contents, not just the namespaces themselves, so that can be excessive. In any case, note that if you do use that, make sure you also implement /2/files/list_folder/continue. Also, you can have Dropbox perform the recursion for you by setting "recursive": true on /2/files/list_folder, if you aren't already.

Alternatively, you can use /2/sharing/list_folders and /2/sharing/list_folders/continue to list all of the shared folders a user has access to. That won't give you all namespaces technically, since it excludes "app folders" which are type of namespace. That may be acceptable for your use case though.

A different approach would be to list all namespaces for the entire team, using /2/team/namespaces/list and /2/team/namespaces/list/continue. You could then list the members of each team folder or shared folder using /2/sharing/list_folder_members and /2/sharing/list_folder_members/continue with Dropbox-API-Select-Admin.

jacques_coney

Thanks Greg for the thorough reply.

The /2/sharing/list_folders and /2/sharing/list_folders/continue seems to be along the lines of what I am after. However, when playing around with the endpoint it if in the scenario with Folder A all contents within in are shared by extension because A is shared so A/B/C etc under the same namespace. Is it possible to have the endpoint/an endpoint return only a list of parent shared folders based upon their access so something like:
- User has access to all of A so in the response it is just A not A/B, A/C etc
- but also in the scenario where the user has access to A/B and A/C but not A it returns A/B and A/C
if that makes sense. Basically my concern is wanting to do this on the fly getting every nested folder back in the response based upon the large data set I have will become a performance issue having to call the `continue` endpoint an unreasonable amount of times, so just trying to see if I can thin out the information of some nested folder information that can be implied? Or is this how it currently works?

Здравко

Hi @jacques_coney,

Do you mean something like mentioned here? 🤔

Hope this helps.

Greg-DB

It sounds like the /2/sharing/list_folders and /2/sharing/list_folders/continue endpoints are still the best option here. There isn't another option like that. These will list each shared folder that the user has access to, so whether or not something is listed there depends on if the particular folder was shared as a shared folder. (Each shared folder is a "namespace' with some members/permissions set. You can find more information on that in the Team Files Guide.)