Inicio de sesión de Salesforce CLI a través dunha VPN: CLI, navegador e host de API

Os fallos de inicio de sesión de Salesforce CLI denúncianse como un só problema e adoitan ser tres. O proceso da CLI execútase nalgún sitio, o navegador que completa o fluxo web execútase nalgún sitio e a chamada posterior á API execútase nalgún sitio, e eses tres lugares non teñen por que compartir unha ruta, un resolutor nin unha lista de permitidos. Comparalos é a forma máis rápida de saber cal está bloqueando realmente o túnel. Nada na saída do inicio de sesión indica cal dos tres fallou.

Tres hosts, unha historia de inicio de sesión

O fluxo de inicio de sesión web entrega o paso de identidade a un navegador, e ese navegador adoita estar no seu portátil mentres a CLI está nun host de desenvolvemento remoto ou nun contedor. O portátil ten o cliente VPN, o host remoto ten o que lle deu o equipo de plataforma, e ningunha das dúas configuracións cobre automaticamente a outra. Unha icona de VPN na barra de estado non di nada sobre un host que nunca executou o cliente.

Despois do inicio de sesión, a CLI fai as súas propias solicitudes á API desde onde viva o proceso. Esas solicitudes necesitan DNS, encamiñamento, confianza TLS e autorización de cliente por parte da org, que son catro comprobacións separadas e cada unha pode fallar pola súa conta. Un navegador que iniciou sesión perfectamente non lle di nada sobre ningunha delas.

Manteña ambas as metades nunha soa liña temporal, pero púntueas por separado. Así un só ticket pode dicir que metade se rompeu sen convertelo nunha discusión sobre a propiedade.

Tome a entrada da org da org, non da memoria

O fluxo web toma un URL de instancia e garda o resultado baixo un alias, e ambos os valores deberían vir do propietario da org en lugar do historial de terminal dun colega. Un host de sandbox copiado dun ticket antigo é unha causa común dun inicio de sesión que se autentica contra a org equivocada e logo falla en cada consulta.

Use a forma que documenta o complemento instalado, co seu propio host e alias aprobados. Esa documentación é a referencia para os indicadores que cambiaron entre sfdx e a CLI actual.

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

O nome de host e o alias de arriba son exemplos, non valores predeterminados que deba copiar. Complete os pasos normais de identidade do navegador e de MFA en lugar de sortealos con scripts, e nunca coloque un contrasinal, un identificador de sesión ou unha semente de autenticador nun comando de shell para saltar o aviso.

Que demostra a autorización en caché

Un alias que aparece na lista de autorizacións local demostra que un inicio de sesión tivo éxito unha vez nesa máquina. A lista lese do almacenamento local e non contacta coa org para confirmar que o token segue funcionando, así que unha entrada de aspecto saudable e unha chamada á API rexeitada poden ser certas á vez. Trate a caché como un rexistro do pasado, non como unha proba de conectividade en vivo. Unha comprobación da caché responde a unha pregunta de soporte, pero nunca pecha unha investigación de conectividade.

A mesma distinción aplícase á sesión do navegador. Unha lapela que aínda mostra a org non significa que o token almacenado da CLI coincida coa política actual, porque a vida do token, as restricións de IP e as regras da aplicación cliente aplícanse no límite da API.

Lea o rexistro local antes de borralo, xa que o alias e o host da org son os dous datos que pedirá o soporte. Eliminar un alias é reversible, pero eliminar o equivocado no medio dun incidente só engade un segundo problema.

Onde se rexeita realmente a solicitude á API

Siga unha solicitude de principio a fin e anote que compoñente responde. Un fallo de TLS nomea un problema distinto dun 403, que nomea un problema distinto dun tempo de espera, e o tempo de espera é o único dos tres que apunta ao túnel como primeiro sospeitoso. Ler a clase de erro antes da mensaxe aforra moitas conxecturas. Anote a clase antes de volver executar nada.

As restricións de enderezo de orixe son o caso que produce un inicio de sesión que funciona e unha consulta que non, porque o fluxo do navegador e a chamada á API poden saír por enderezos distintos. Arranxalo cunha lista de permitidos máis ampla é unha decisión do propietario da org, non unha comodidade, e debería ser o rango máis pequeno que cubra o host.

Capture o comando que falla, o alias, o host de execución e a marca de tempo, e deixe o token fóra de todo o que pegue no ticket. Ese resumo de catro liñas é o que o propietario da org necesita para comprobar o seu lado.

Comprobe o fluxo desde o host que o vai usar

Probe desde a máquina que executará a carga de traballo. Un inicio de sesión verificado no seu portátil non di nada sobre un axente de compilación noutra zona de rede, e a diferenza é exactamente o que intenta atopar.

Use unha lectura autorizada inofensiva para a comprobación, e quede co primeiro erro se falla.

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

Cando o inicio de sesión ten éxito pero a consulta falla, os candidatos restantes son DNS, encamiñamento, intercepción de TLS e política de cliente por parte da org, e cada un ten o seu propio dono. Cando falla o propio inicio de sesión, o navegador e a CLI probablemente non están no mesmo host, e a corrección pertence á configuración entre eles e non ao túnel. A automatización recibe unha regra máis: un traballo sen supervisión necesita un inicio de sesión aprobado baseado en certificado, porque unha sesión interactiva en caché copiada a un worker non é un deseño de identidade.