API fails on secondsite, worked on primary/default site

dev
1

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”}

What’s the secret sauce I’m missing?

2

Did you make a new api key on the second site? Like like the key is invalid.

3

Yeah, I tried two different new keys, no dice.

If it is logging the error, I’m not spotting where.

It is apparently accessing the right key according to the API menu:

a233… deactivating huskerlist subscribers 24x24 6 hours 1 min

1 Like
4

I also tried creating an API key for the system user, same error.

5

I’d try a global key and then try to reduce the scope.

6

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: