# Má resposta CSRF ao tentar excluir usuário por API
**URL:** https://meta.discourse.org/t/bad-csrf-response-when-trying-to-delete-user-by-api/87887
**Category:** Support
**Created:** [Maio 19, 2018, 2:15pm UTC](https://meta.discourse.org/t/bad-csrf-response-when-trying-to-delete-user-by-api/87887 "2018-05-19T14:15:20Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@ATPJD](https://meta.discourse.org/u/ATPJD)
#### Post date: [Maio 19, 2018, 2:15pm UTC](https://meta.discourse.org/t/bad-csrf-response-when-trying-to-delete-user-by-api/87887/1 "2018-05-19T14:15:20Z")
I am trying to delete a user by API following the [docs](https://docs.discourse.org/#tag/Users%2Fpaths%2F~1admin~1users~1%7Bid%7D.json%2Fdelete).
We use SSO, which seems to make the API require a cookie header coming from SSO authentication. I got past that, and as long as I supply the cookie, other types of actions work fine by GET. But the DELETE results in this “BAD CSRF” error.
Maybe a bug? I don’t even know where to begin troubleshooting this. Any help appreciated.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [Maio 19, 2018, 7:24pm UTC](https://meta.discourse.org/t/bad-csrf-response-when-trying-to-delete-user-by-api/87887/2 "2018-05-19T19:24:49Z")
Are you using an API key for this action? It is required.
---
### Author:  [@ATPJD](https://meta.discourse.org/u/ATPJD)
#### Post date: [Maio 19, 2018, 9:04pm UTC](https://meta.discourse.org/t/bad-csrf-response-when-trying-to-delete-user-by-api/87887/3 "2018-05-19T21:04:30Z")
Yes. I’ve tried both the generic one for “system” and my own, as an admin. I have been passing these as GET or POST parameters along with the cookie.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [Agosto 1, 2018, 7:43am UTC](https://meta.discourse.org/t/bad-csrf-response-when-trying-to-delete-user-by-api/87887/4 "2018-08-01T07:43:17Z")
Hmmm, where is this at? Did it get resolved?
---
### Author:  [@ATPJD](https://meta.discourse.org/u/ATPJD)
#### Post date: [Agosto 1, 2018, 11:55am UTC](https://meta.discourse.org/t/bad-csrf-response-when-trying-to-delete-user-by-api/87887/5 "2018-08-01T11:55:54Z")
No, and I really need to get it working. I’ve not tried again since May 19. If there are updates affecting this functionality, should I try again? Thank you very much for the follow-up.
---
### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [Agosto 1, 2018, 6:52pm UTC](https://meta.discourse.org/t/bad-csrf-response-when-trying-to-delete-user-by-api/87887/6 "2018-08-01T18:52:15Z")
I have tested deleting users through the API on a live hosted site with SSO enabled. I’m using [Postman](https://www.getpostman.com/) to make the API request. It is deleting users for me. The response is `{"deleted": true}`. The all\_users API key and API username need to be included in the body of the request.
One thing I have found is that sending the parameter `"block_email": false` actually causes the email address to be blocked. Sending the parameter `"block_ip": false` also blocked the IP address the first time I made the request. After allowing the IP address through Admin/Logs/Screened IPs, subsequent requests sending the `"block_ip": false` parameter did not block the IP address.
Edit: I just did a quick test with this on my local dev environment. Setting the `block_email` and `block_ip` params to false causes [these two code blocks](https://github.com/discourse/discourse/blob/master/app/services/user_destroyer.rb#L57) to be run. I’ve tested this both with Postman, and making the request with curl. If neither of those params are set, everything works as it should.
---
### Author:  [@system](https://meta.discourse.org/u/system)
#### Post date: [Março 5, 2021, 7:26am UTC](https://meta.discourse.org/t/bad-csrf-response-when-trying-to-delete-user-by-api/87887/7 "2021-03-05T07:26:16Z")
---
### Author:  [@blake](https://meta.discourse.org/u/blake)
#### Post date: [Março 5, 2021, 3:29pm UTC](https://meta.discourse.org/t/bad-csrf-response-when-trying-to-delete-user-by-api/87887/8 "2021-03-05T15:29:54Z")