XF 2.2 Permission Error when trying to DELETE attachments via API

Hello,

I've been trying to figure out why I'm getting permission errors during a DELETE attachment API call.

The API user is the same as I've used to upload the attachments, and the attachments are attached to the post by posting the thread first, and using the first_post_id return data to include as the context[post_id] value. The user API permissions are also set to allow attachment delete, read, write, as well as permissions to delete, read, write the threads/posts. The only data being sent to the attachment endpoint is the DELETE request, the XF-Api-Key, and the id in the URL.

Any ideas what I need to include or am missing?

INFO:main: Deleting attachment ID 883084
INFO:main: Response status code: 403
INFO:main: Response content: b'{\n "errors": [\n {\n "code": "do_not_have_permission",\n "message": "You do not have permission to view this page or perform this action.",\n "params": []\n }\n ]\n}'
ERROR:main: An error occurred: 403 Client Error: Forbidden for url: https://tractorbynet.com/forums/api/attachments/883084

Thanks,
Ibrahim
 
Is the API key a super user key? If so, you'll need to authenticate as a user with permissions to delete the attachment (use the XF-Api-User header) or bypass permissions (include api_bypass_permissions=1 in the URL). If the API key is a user key, that user will need permissions to manage attachments in the pertinent forum. If the API key is a guest key, you will not have permission to delete attachments.
 
It was a user key, but I tried to use a super user as well, setting up both the XF-Api-User header, and then simply trying api_bypass_permissions=1, and both return the same error.

INFO:main:Response status code: 403
INFO:main:Response content: b'{\n "errors": [\n {\n "code": "do_not_have_permission",\n "message": "You do not have permission to view this page or perform this action.",\n "params": []\n }\n ]\n}'
ERROR:main:An error occurred: 403 Client Error: Forbidden for url: https://tractorbynet.com/forums/api/attachments/883084?api_bypass_permissions=1

The API key I've been using has successfully added threads, edited posts, soft-deleted threads, added attachments after a post, posted without attachments, and haven't had any errors.

This is the only exception to my permission errors. Is it possible that I've attached the files incorrectly?

My method is: Posting a thread, getting the first_post_id, then using a attachments/new-key API call to get the attachment key and when I upload attachments the context[post_id] is set to the first_post_id.

Any thoughts?
 
This is the only exception to my permission errors. Is it possible that I've attached the files incorrectly?
Maybe. Does the xf_attachment table show the attachment as having the content type and ID set as you expect? And is there any temp_hash or unassociated value set? For the avoidance of doubt I've just tested and it seemed to work ok:

Code:
{
  "success": true
}
// DELETE /api/attachments/1/
// HTTP/1.1 200 OK
// Cache-Control: no-cache
// Content-Type: application/json; charset=utf-8
// Date: Fri, 02 Aug 2024 19:53:54 GMT
// Expires: Thu, 01 Jan 1970 00:00:01 GMT
// Server: nginx
// Vary: Accept-Encoding
// X-Content-Type-Options: nosniff
// Xf-Latest-Api-Version: 1
// Xf-Request-User: 1
// Xf-Request-User-Extras: {"conversations_unread":0,"alerts_unviewed":0}
// Xf-Used-Api-Version: 1
// Transfer-Encoding: chunked
// Request duration: 0.196726s
 
I checked and it does seem like the specific attachment wasn't set up correctly.

Right now, the content_id is 0, and there a temp_hash as well as unassociated '1' set.

So I dug around a little more because there are also attachments that ARE set up correctly and I realized this may have been a before/after a bug fix.

It's functioning now because I'm now selecting the list of attachments via the get post/{id} endpoint rather than, incorrectly, the get attachments/ endpoint.

Working as intended now! Thanks for pointing me in better directions!
 
FWIW you can include the attachment key used to upload the attachment as key to delete unassociated attachments, though this isn't strictly necessary as unassociated attachments are cleaned up periodically.

You can also associate them when creating a thread by creating a key with the node_id context set, but the current approach is ok too.
 
Back
Top Bottom