Box API Delete Trash not working.
Hi I am trying to develop an PowerShell script to delete trash files from users accounts. I have been able to get the script to get the list of users, get the first four files in the trash, but when I go to delete the files it comes back to me with an error.
What I have done:
- I have Co-Admin Auth in the system
- My app has the permissions
- The user I am trying to delete files is not an admin or co-admin
- I have tried this with the token and also using the As-user.
I continue to get two types of errors. Without the As-User I get a remote server error 404 Not Found. With the As-User I get a remote server error 403 Forbidden.
Code for deletion of files:
$uri = "https://api.box.com/2.0/files/$var2/trash"-replace(' ','')
$headers = @{"Authorization"="Bearer $token"}
Invoke-RestMethod -Uri $uri -Method Delete -Headers $headers -ContentType "applicaiton/x-www-form-urlencoded"
I am looking for help with this issue or where it is going wrong.
-
Is it possible to provide more detail about the exact 403 error response you're seeing? If possible, the entire error response (minus any sensitive information) would be really useful to help me troubleshoot what might be happening. At first glance, this looks similar to other scenarios I've seen where you're authenticated as a user/application that does not have permission to delete a user's files (maybe a Service Account?), and also does not have permission to use the As-User header — hence the 403 when you try to use it. More information could help confirm or dispute that possibility.
In general, there are a few considerations and questions I can give you about exactly what you're trying to do:
1. What type of authentication is your application using?
a. If it's traditional 3-;egged OAuth2, which account are you logged in as — your Co-Admin account, the user who owns the file, or some other account?
b. If it's server auth with JWT, which account are you authenticated as: the Service Account, your Co-Admin user,the user who owns the file, or some other account?
2. When you say your app has the permissions, which permissions or scopes do you mean? If this is a JWT authentication app, does your application have either the "Perform Actions as Users" or "Generate User Access Tokens" features turned on in the Box Developer Console?
a. If the application has those features turned on, did you or the enterprise administrator (re-)authorize the application AFTER those features were turned on? The application needs to be reauthorized after any change in permissions or scopes, and a lot of people forget to do that. If you're able to, you might want to try reauthorizing the application to see if that fixes the issue.
-
Hello MWiller,
1. What type of authentication is your application using?
OAuth 2.0 with JWT (Server Authentication), which when I log into the QA environment I am Co-Admin.
2. When you say your app has the permissions, which permissions or scopes do you mean?
JWT authentication app, my application has both of the "Perform Actions as Users" or "Generate User Access Tokens" features turned on in the Box Developer Console. Yes the Administrator authorized the application and I have not changed them since. I have only gotten the developer token for each run.
As for the error message, this is the best that I can do it appears:
Invoke-Restmethod : The remote server returned an error: (403) Forbidden.
At C:\Users\JuozaEC\Documents\Other Projects\Box Trash Deletion\test.ps1:24 char:1
+ Invoke-Restmethod -Method DELETE -Uri $uri -Headers $headers -Content ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-RestMethod], WebException
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeRestMethodCommand
System.Management.Automation.CmdletInvocationException: The remote server returned an error: (403) Forbidden. ---> System.Net.WebException: The remote s
erver returned an error: (403) Forbidden.
at Microsoft.PowerShell.Commands.WebRequestPSCmdlet.GetResponse(WebRequest request)
at Microsoft.PowerShell.Commands.WebRequestPSCmdlet.ProcessRecord()
--- End of inner exception stack trace ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Management.Automation.Internal.PipelineProcessor.SynchronousExecuteEnumerate(Object input)
at System.Management.Automation.PipelineOps.InvokePipeline(Object input, Boolean ignoreInput, CommandParameterInternal[][] pipeElements, CommandBaseA
st[] pipeElementAsts, CommandRedirection[][] commandRedirections, FunctionContext funcContext)
at System.Management.Automation.Interpreter.ActionCallInstruction`6.Run(InterpretedFrame frame)
at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame) -
I tried setting up a test application with a similar setup to yours — let me know if any of these aren't correct:
- App was created by a Co-Admin user
- App uses JWT authentication
- App has the following scopes:
- Read all files and folders stored in Box
- Read and write all folders stored in Box
- Manage users
- Manage groups
- App has both Advanced Features turned on
- Perform Actions as Users
- Generate User Access Tokens
Using this app, I generated a Developer Token (which should grant access to the Co-Admin account) and was able to successfully make As-User calls with the ID of a managed user to do the following:
- Get the list of files in their root folder
- Move on of those files to trash
- See the file in the trash
- Delete the file from the trash
So, at the very least, if everything above looks like what you're trying to do, this should in theory be possible. I have a few more questions that might help us troubleshoot what's going wrong in your case — could you try making these API calls manually via curl or Postman so you can see the full API response? The stack trace form PowerShell isn't very useful for troubleshooting since it only includes the status code.
- If you make an API call with your Developer Token to GET https://api.box.com/2.0/users/me without the As-User header, is the user information that gets returned your Co-Admin account?
- If you make an API call with your Developer Token to GET https://api.box.com/2.0/users/ without the As-User header, is the user information that gets returned the managed user in your enterprise?
- If you make an API call with your Developer Token to GET https://api.box.com/2.0/users/me with the As-User header of the managed user, do you still see the 403 error?
-
mwiller,
The following is correct with one addition in blue:
- App was created by a Co-Admin user
- App uses JWT authentication
- App has the following scopes:
- Read all files and folders stored in Box
- Read and write all folders stored in Box
- Manage users
- Manage groups
- App has both Advanced Features turned on
- Perform Actions as Users
- Generate User Access Tokens
- Application Access
- Enterprise
I have tried the runs in PowerShell that you suggested. Answers in blue below:
- If you make an API call with your Developer Token to GET https://api.box.com/2.0/users/me without the As-User header, is the user information that gets returned your Co-Admin account? Type returns user.
- If you make an API call with your Developer Token to GET https://api.box.com/2.0/users/ without the As-User header, is the user information that gets returned the managed user in your enterprise? I tried two different user IDs one regular user returned type user which I expected. When I tried the Box Admin I get the same type user.
- If you make an API call with your Developer Token to GET https://api.box.com/2.0/users/me with the As-User header of the managed user, do you still see the 403 error? When I do this I do not get an error but still shows user.
At the moment, I can not install Curl or Postman.
-
Hmm, if you get a valid response in all those cases then the problem doesn't seem to be with the As-User header. However, without knowing more about the exact error that you're seeing (the JSON from the response body and any response headers), I can't really say what might be the issue here. If possible, could you try getting information from the raw HTTP response to help troubleshoot further?
-
Hello mwiller,
We found out why I got the 443 error. Here I had a meeting with some people and found a couple of things that I wish to bring to your attention. So I tried with Postman and was able to get some response back while also talking to the Admin about the errors we were seeing. So one thing we found was that the admin had trash setup that users could not delete their own trash which posed a problem for the script because I could not even delete someone else's trash (using As-User or as the administrator). The Permanent Delete Trash API appears to make calls to a user's trash but if the feature is turned on to prohibit user's to delete their own trash the API can not be executed and if you execute as (As-User) Administrator the trash file is not found since it does not show in the Admins trash. So my question would be is why was the Permanent Delete Trash API created and act this way? Is there a way around the As-User and running the API to delete all trash for all users? This is the error that I was getting from Postman which I have sent to you in an email, when I ran it as myself (I have Co-Admin rights) against a regular User's Trash item with the users able to delete their trash enabled.
サインインしてコメントを残してください。
コメント
11件のコメント