Início de sessão do Salesforce CLI através de uma VPN: CLI, navegador e host de API

As falhas de início de sessão do Salesforce CLI são reportadas como um único problema e normalmente são três. O processo da CLI corre algures, o navegador que conclui o fluxo web corre algures, e a chamada API posterior corre algures, e esses três locais não têm de partilhar uma rota, um resolvedor ou uma lista de permissões. Compará-los é a forma mais rápida de descobrir qual está realmente a ser bloqueado pelo túnel. Nada na saída do início de sessão indica qual dos três falhou.

Três hosts, uma história de início de sessão

O fluxo de início de sessão web entrega o passo de identidade a um navegador, e esse navegador está frequentemente no portátil enquanto a CLI está num host de desenvolvimento remoto ou num contentor. O portátil tem o cliente VPN, o host remoto tem o que a equipa de plataforma lhe deu, e nenhuma das duas disposições cobre automaticamente a outra. Um ícone VPN na barra de estado não diz nada sobre um host que nunca executou o cliente.

Após o início de sessão, a CLI faz os seus próprios pedidos à API a partir de onde vive o processo. Esses pedidos precisam de DNS, encaminhamento, confiança TLS e autorização de cliente do lado da org, que são quatro verificações separadas e cada uma pode falhar sozinha. Um navegador que iniciou sessão lindamente não lhe diz nada sobre nenhuma delas.

Mantenha as duas metades numa única linha temporal, mas avalie-as separadamente. Assim um único ticket pode dizer qual metade quebrou sem transformar isso numa discussão sobre propriedade.

Retire a entrada da org da org, não da memória

O fluxo web recebe um URL de instância e guarda o resultado sob um alias, e ambos os valores devem vir do proprietário da org em vez do histórico de terminal de um colega. Um host sandbox copiado de um ticket antigo é uma causa comum de um início de sessão que autentica contra a org errada e depois falha em cada consulta.

Use a forma que o plugin instalado documenta, com o seu próprio host e alias aprovados. Essa documentação é a referência para as opções que mudaram entre o sfdx e a CLI atual.

sf org login web --instance-url https://acme--uat.sandbox.my.salesforce.com --alias uat
sf org display --target-org uat

O nome do host e o alias acima são exemplos, não valores predefinidos que deva copiar. Conclua os passos normais de identidade do navegador e de MFA em vez de os contornar com um script, e nunca coloque uma palavra-passe, um identificador de sessão ou uma semente de autenticador num comando de shell para saltar o pedido.

O que a autorização em cache prova

Um alias que aparece na lista de autorizações local prova que um início de sessão já teve sucesso naquela máquina. A lista é lida do armazenamento local e não contacta a org para confirmar que o token ainda funciona, por isso uma entrada com bom aspeto e uma chamada API rejeitada podem ser ambas verdadeiras. Trate a cache como um registo do passado, não como um teste de conectividade em direto. Uma verificação da cache responde a uma pergunta de suporte, mas nunca encerra uma investigação de conectividade.

A mesma distinção aplica-se à sessão do navegador. Um separador que ainda mostra a org não significa que o token guardado da CLI corresponda à política atual, porque a duração do token, as restrições de IP e as regras da aplicação cliente são aplicadas na fronteira da API.

Leia o registo local antes de o apagar, pois o alias e o host da org são os dois factos que o suporte vai pedir. Remover um alias é reversível, mas remover o errado a meio de um incidente só acrescenta um segundo problema.

Onde o pedido à API é realmente rejeitado

Siga um pedido do início ao fim e anote que componente responde. Uma falha TLS nomeia um problema diferente de um 403, que nomeia um problema diferente de um tempo limite, e o tempo limite é o único dos três que aponta o túnel como primeiro suspeito. Ler a classe de erro antes da mensagem poupa muita adivinhação. Anote a classe antes de voltar a executar seja o que for.

As restrições de endereço de origem são o caso que produz um início de sessão que funciona e uma consulta que não, porque o fluxo do navegador e o pedido à API podem sair por endereços diferentes. Corrigir isso com uma lista de permissões mais ampla é uma decisão do proprietário da org, não uma conveniência, e deve ser o menor intervalo que cobre o host.

Registe o comando que falha, o alias, o host de execução e o carimbo temporal, e deixe o token fora de tudo o que colar no ticket. Esse resumo de quatro linhas é o que o proprietário da org precisa para verificar o seu lado.

Verifique o fluxo a partir do host que o vai usar

Teste a partir da máquina que vai executar a carga de trabalho. Um início de sessão verificado no seu portátil não diz nada sobre um agente de compilação noutra zona de rede, e a diferença é exatamente o que tenta encontrar.

Use uma leitura autorizada inofensiva para a verificação, e guarde o primeiro erro se falhar.

sf org list auth
sf org display --target-org uat
sf data query --target-org uat --query "select Id, Name from Organization"

Quando o início de sessão tem sucesso mas a consulta falha, os candidatos restantes são DNS, encaminhamento, interceção TLS e política de cliente do lado da org, e cada um tem o seu próprio dono. Quando o próprio início de sessão falha, o navegador e a CLI provavelmente não estão no mesmo host, e a correção pertence à disposição entre eles e não ao túnel. A automatização recebe mais uma regra: um trabalho sem supervisão precisa de um início de sessão aprovado baseado em certificado, porque uma sessão interativa em cache copiada para um worker não é um desenho de identidade.