API falha no secondsite, funcionou no site primário/padrão

Estou dividindo um site em dois sites separados usando o método multi-site e é hora de “Bater a Cabeça” na API - de novo.

Agora, o que estou tentando fazer é desativar os usuários da lista 1 (o site padrão) na lista 2 (o segundo site).

Já desativei os usuários na lista 2 a partir da lista 1, tudo o que mudei em meu script PHP foi gerar uma nova chave de API no segundo site, inseri-la na chamada CURL e estou recebendo erros de acesso inválido.

Aqui está uma chamada expurgada (faltando a maior parte da chave de API), que é válida apenas para este usuário e acesso global.

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

Qual é o “molho secreto” que estou perdendo?

Você criou uma nova chave de API no segundo site? Tipo, tipo, a chave é inválida.

Sim, tentei duas chaves novas diferentes, sem sucesso.

Se estiver registrando o erro, não estou vendo onde.

Aparentemente está acessando a chave certa de acordo com o menu da API:

a233… desativando assinantes huskerlist 24x24 6 horas 1 min

1 curtida

Também tentei criar uma chave de API para o usuário do sistema, mesmo erro.

Eu tentaria uma chave global e depois tentaria reduzir o escopo.

Pelo que pude apurar, não há opção para reduzir o escopo de uma chave de API para que ela lide com desativações, essa não é uma das opções disponíveis, mas uma chave global não funciona de qualquer forma. (APIs precisam de trabalho, na minha humilde opinião.)

Não sei onde está o código deactivate.json, uma busca no meu servidor não o encontra, então aparentemente não é um arquivo separado. Estou imaginando se há algo específico sobre este ser um secondsite que não está correto, porque funcionou muito bem no site padrão.

Não seria o primeiro problema que encontro com secondsites, embora eu não tenha certeza se alguém já registrou o primeiro como um problema, tem a ver com código em um arquivo de configuração nginx que verifica se o nome de domínio na URL é o padrão, eu apenas comento essas linhas de código sempre que faço uma reconstrução. Relatei este problema nesta postagem: