You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
Forum Discussion
Issue unsharing a folder using API
I have a issue related to shared folder unsharing. I gonna post the requests and corresponding results.
Running 2/sharing/list_mountable_folders:
curl -X POST https://api.dropboxapi.com/2/sharing/list_mountable_folders \
--header 'Authorization: Bearer sl.BQ...' \
--header 'Content-Type: application/json' \
--data '{}'... does return:
{
"entries": [
{
"access_type": {
".tag": "owner"
},
"is_inside_team_folder": false,
"is_team_folder": false,
"path_lower": "/music",
"name": "Music",
"policy": {
"acl_update_policy": {
".tag": "editors"
},
"shared_link_policy": {
".tag": "anyone"
},
"viewer_info_policy": {
".tag": "enabled"
}
},
"preview_url": "https://www.dropbox.com/scl/fo/5vl.../h?dl=0",
"shared_folder_id": "3104120081",
"time_invited": "2022-09-29T17:34:02Z",
"access_inheritance": {
".tag": "inherit"
}
},
...
]
}For readability, the important entry is listed only (some non important content is stripped, but id is the actual).
Next while I'm trying unshare the same folder using /2/sharing/unshare_folder:
curl -X POST https://api.dropboxapi.com/2/sharing/unshare_folder \
--header 'Authorization: Bearer sl.BQ...' \
--header 'Content-Type: application/json' \
--data '{"shared_folder_id":"3104120081"}'The result is an async id:
{
".tag": "async_job_id",
"async_job_id": "dbjid:AABWMExqheAMvyb_UB-tiU5GcyV0Z1AWnBzBuV6EMZEHaFDv9QFv5ru1mpNqFYC1KizxEvJ3lweB4WwZQ1kcwlQI"
}And at the end the result on checking job status using /2/sharing/check_job_status:
curl -X POST https://api.dropboxapi.com/2/sharing/check_job_status \
--header 'Authorization: Bearer sl.BQ...' \
--header 'Content-Type: application/json' \
--data '{"async_job_id":"dbjid:AABWMExqheAMvyb_UB-tiU5GcyV0Z1AWnBzBuV6EMZEHaFDv9QFv5ru1mpNqFYC1KizxEvJ3lweB4WwZQ1kcwlQI"}'...results in:
{
".tag": "failed",
"failed": {
".tag": "unshare_folder_error",
"unshare_folder_error": {
".tag": "no_permission"
}
}
}In addition to 'no_permission':
x-dropbox-request-id: 2188ae550fd2438198dbe457909a661a
Why this 'no_permission' gets up?
Здравко Thanks for the detailed post! It looks like the issue is that the shared folder contains a nested shared folder, and so cannot be unshared. You would need to move the nested shared folder out first before you can unshare the parent shared folder.
I'll ask the team to see if we can improve the error reporting in that case.
- Greg-DB
Dropbox Staff
Здравко Thanks for the detailed post! It looks like the issue is that the shared folder contains a nested shared folder, and so cannot be unshared. You would need to move the nested shared folder out first before you can unshare the parent shared folder.
I'll ask the team to see if we can improve the error reporting in that case.
Thanks Greg-DB,
It's still strange - something that's not supposed to be possible (nesting shared folder) is essentially possible. In such a case should be possible undone it in the same (or similar, at least) reverse way, but there's not such way! Could be considered on system root level (not only API).
By the way using such moves your system can get tricked!!! Shared folder receiver can change access from "can view" only to "can edit" without any granting from folder owner. It's enough to be available at some point (not necessarily now - can be in the past) some folder with "can edit" permissions from the same owner. I don't know is this something intentional from Dropbox side, but can be considered as a security hole! I performed such a trick with owner verbal granting.
Thanks again.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
