MikeNolan is encountering an “Invalid_Access” error when trying to deactivate users via the REST API on a second site in a Discourse multi-site setup, despite successfully doing so on the primary site. He generated new API keys for the second site, including one for the system user, but all attempts fail with the same error: “You are not permitted to view the requested resource.” pfaffman suggests trying a global API key and reducing scope, but MikeNolan notes that scope reduction options don’t include deactivation permissions—and global keys still fail. He suspects the issue may be specific to second sites, referencing a prior nginx config issue tied to domain validation that also breaks second sites. He notes the API endpoint deactivate.json isn’t a physical file on the server, making debugging harder. He concludes that Discourse’s API needs improvement and links to a prior report on multi-site issues: Multisite vs Multiple Containers.
I’m splitting a site into two separate sites using the multi-site method and it’s Bang Your Head against the API time–again.
Now what I’m trying to do is inactive the users from list 1 (the default site) on list 2 (the secondsite.)
I’ve already inactivated the users on list 2 from list 1, all I changed in my PHP script was to generate a new API key on the second site, insert it into the CURL call and I’m getting Invalid_Access errors.
Here’s an expurgated call (missing most of the API key), which is valid for this user only and global access.
curl -X PUT -H “Content-Type: multipart/form-data;” -H “Api-Key: a23…” -H “Api-Username: nolan” “https://nu-sports.tssi.com/admin/users/4/deactivate.json/”
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 98 0 98 0 0 212 0 --:–:-- --:–:-- --:–:-- 4454
{“errors”:[“You are not permitted to view the requested resource.”],“error_type”:“invalid_access”}
As far as I can tell, there’s no option to reduce the scope of an API key so that it handles deactivations, that’s not one of the options available, but a global key doesn’t work anyway. (API’s need work, IMHO.)
I don’t know where the deactivate.json code is, a search on my server doesn’t find it, so apparently it isn’t a separate file. I’m wondering if there’s something specific about this being a secondsite that isn’t correct, because it worked great on the default site.
It would not be the first problem I’ve found with secondsites, though I"m not sure if anyone ever logged the first one as a problem, it has to do with code in an nginx config file that checks to make sure the domain name in the URL is the default one, I just comment out those lines of code whenever I do a rebuild. I reported this problem in this post:
