You are not logged in.
Hi,
I have an API Integration which needs to respect a user's permissions when fetching folders and images from Chorus.
I use the /rest/v1/auth/impersonate/byemail method to switch the session and then call various method to display relevant folders and images to the user.
The /rest/v1/folders/{folderId}/files method works as expected - returning just the images within a folder that the user should be able to access.
The problem I'm having is that the /rest/v1/folders/{folderId}/folders method does not seem to respect the current user's permissions. It seems to return all the child folders for a given folderID regardless of whether they contain any content that the current user can access.
This results in a very poor UX with many empty folders being displayed.
I have tried to create a hasContent method which I run on each returned folder. This first checks for any child images, if none are found it checks for child folders.
If the folder contains at least one image we can quickly return true. But if the folder contains only child folders we need to run the same test on each these, and so on down the hierarchy. In my tests this has resulted in hundreds of requests, making this an unworkable solution.
Is there any way to limit the /rest/v1/folders/{folderId}/folders method to only return folders which contain content available to the current user?
Many thanks,
Malcolm
Offline
Hi Malcolm,
Thanks for the description of what you are trying to achieve. We don't have a more efficient way to return only populated folders at the moment so your hierarchy processing approach is the best way for now.
Best Regards,
Steve
Offline
Hi again Malcolm,
I've been looking at this, and am wondering if we misinterpreted your query. I say this because I've found what I think is a bug in the REST API.
Does your setup involve a Space with different Roles, and the permissions on the folders in the Space are configured so some roles have access, but others don't. e.g. something like this:
Space
|-- Folder A <-- Only Role A has access
|-- Folder B <-- Only Role B has access
|-- Folder C <-- Only Role C has access
If so, then apologies as we misinterpreted your original query to be simply about whether subfolders, and sub-sub-folders, etc had any contents at all. And not whether the contents should be blocked by permissions.
Regarding the possible bug (which I will need to further investigate) it looks to me like /rest/v1/folders/{folderId}/folders is returning all folders regardless of permissions, whereas /rest/v1/content/{folderId}/folders is filtering on permissions.
The /rest/v1/content/... endpoints were added more recently and handle all the different possible file and folder types. I think it would be possible for you to switch to these endpoints to resolve the permissions issue. The sequence of calls would be /rest/v1/content/{folderId}/content to get a list of IDs (which will include folders and files), and then passing those IDs (possibly in batches) to /rest/v1/content/multi.
Either way I will investigate the bug and get back to you,
Best wishes,
Ben
Offline
Hi Ben,
Many thanks for your reply.
Yes, this issue is all around user permissions.
We are working with client's account and I don't know whether they have set permissions on the folders within a space, or on the resources within them. Does this have an impact?
I will find out and get back to you.
Regarding the The /rest/v1/content/... endpoints - I did experiment with them but found I was getting 403 responses when I switched users. They worked fine when I connected as our main API user, but after I switched the session via the /impersonate/byemail method I would frequently fail to get a valid response.
Do you need to grant access to these end points at a user level?
Many thanks,
Malcolm
Offline
No extra grants are required our end to enable those endpoints, so I am surprised by 403 responses. Particularly if you were getting 403s from /content queries which the /folders queries returned without error.
If you can provide more details I would be happy to investigate.
Ben
Offline
Thanks, Ben,
I will try to recreate the issues I was having with the /content end points.
I can confirm that our client is setting permissions at folder level, so your description of folders with different permissions within a space is accurate. e.g.
Space
|-- Folder A <-- Only Role A has access
|-- Folder B <-- Only Role B has access
|-- Folder C <-- Only Role C has access
Best wishes,
Malcolm
Last edited by Electric Putty (2022-02-10 23:55:04)
Offline
Hi Ben,
Regarding your post from 2022-02-08 16:32:54 - have you had a chance to investigate the possible issue with the /rest/v1/folders/{folderId}/folders end point returning all folders regardless of permissions?
We are getting some pressure from our client to find a resolution to this.
Thanks,
Malcolm
Offline
Hi Malcolm,
Just to confirm that a decision has been made to change the behaviour although we don't yet have an estimate for when it will be released.
Hope that takes a little of the pressure off.
Best Regards,
Steve
Offline
Hi again Malcolm
Just wanted to let you know that the code has been patched so that the /rest/v1/folders/{folderId}/folder endpoint now honours the folder level permissions and won't return child folders that the authorised account doesn't have permission to view contents of.
Best wishes,
Ben
Offline