Getting 403: Permission Denied error when using JWT Auth. credentials to upload, download and delete file from Box
When i try to upload, download and delete a file from Box Folder using JWT Application Credentials, i am receiving Permission_Denied error.
{"type":"error","status":403,"code":"access_denied_insufficient_permissions"}
My Application settings are as follows:
- Provided read and write access in Application Scopes under Configuration Tab
- Added Service account as Editor to all the folders that I need to perform the action.
- Service account is also added to the collaborators list in Box Application
- Application is re-authorised from Enterprise Admin Team
Can anybody please guide me on what am I doing wrong here or am I missing anything ?
-
Hi AASHRUTI SINGH,
That is a bit odd, so let's try to troubleshoot.
Since I don't know what stack you're using I'll use the CLI.
Consider the following service user associated with the CLI:
❯ box users:get --fields type,id,name,login --csv
type,id,name,login
user,20130487697,JWT,AutomationUser_1827756_bs5C1GfCgv@boxdevedition.comWhen I try to list the items of another user folder, I get a 404 not found error (not insufficient privileges):
❯ box folders:items 191494027812 --fields type,id,name --csv
Unexpected API Response [404 Not Found | 30gxkzhayvxsghbq.09370dd2894de2edb1012daaedb3b1e3a] not_found - Not FoundIf the other user adds this service user as an editor to the folder:
Note: This sharing with a service user might be the source of the issue. You have to share using the auto generated login of the service user.
Then I get the items of the folder:
❯ box folders:items 191494027812 --fields type,id,name --csv
type,id,name
folder,192444166451,Audio
folder,192444586290,Images
folder,192442970500,VideoNow if I remove the share of the folder I get back to the 404 error:
❯ box folders:items 191494027812 --fields type,id,name --csv
Unexpected API Response [404 Not Found | haxvdhayw2nfpwp.0932536f44bf64cb51d7f8c94c1e92d8a] not_found - Not FoundThis JWT app is configured as:
- Enterprise access
- All content actions (read/write all files)
- All administrative actions
- Make API calls using the as-user header
- Generate user access token
This means it can impersonate the user, so this works even with the explicit share, which from your description seems more appropriate:
❯ box folders:items 191494027812 --fields type,id,name --csv --as-user 18622116055
type,id,name
folder,192444166451,Audio
folder,192444586290,Images
folder,192442970500,VideoFrom the information you included, it should work, so play with these concepts to help narrow down the causes, and look into if the as-user is a more appropriate solution for your user case, since it avoids having to explicitly share each folder with the service user.
Let us know if this helped.
Best regards
Please sign in to leave a comment.
Comments
1 comment